CPU recommendations?

You might check out the ST STM8. The source-level debugger works pretty well. Cosmic has a free compiler for up to 16K, and as best I can tell from the license, there are no restrictions on using the free compiler for a commercial purpose. The full tools that will produce a larger FLASH image are something around $1800.

The necessary debugging pod is only about 100 Euros.

However, I do work with high production volumes, and ST's pricing is attractive. If you're doing work with annual volumes of less that 10K or so, I'm not sure the STM8 would be the right choice. For low volumes, naturally piece-cost is less important.

Not sure about uCos.

If you're not easily able to find info or a sales rep, post again and we can get into direct contact.

The Lizard

I have been successful with the Atmel AVR under similar circumstances.

Avr-gcc is very good. Equally supported on Windows and FreeBSD. Linux guys can take clues from the FreeBSD port as to the good patches such as the one adding binary constant support (specify values in binary).

The AVR JTAG ICE mkII is pricy at $300 but the ECROS ICE Cube at $40 is

99.99% as good so long as you select a CPU that it supports. Is best to buy an Atmel AVR-ISP for about $40 as ISP is needed to enable JTAG but once JTAG is enabled its all you need for uploading code and debugging. 64k is a pretty big code space for a "simple" project. Keep it down to 32k CPUs and the AVR Dragon (from Atmel) is $50. Supports debugWire, JTAG, and ISP (in-system programming in Atmel-speak). But once again one must ensure in advance that the CPU is supported by the Dragon. Only way to get the Dragon list is download and install AVR Studio, then go to the online help file for Dragon.

The Dragon will program parts larger than 32k via ISP, it just won't debug.

C++? Noooooooo!!!!! ;)

The venerable H8 family might fit all your needs, except for the C++/64k bloat thing... The KPIT/GNU toolchain is free, as is the HEW environment from Renesas, and the flash programming utilities...

I mean, really: C++ on embedded? Seriously? By all means write OO code, but C++ is not a serious contender. It's just b0rked. On a desktop you can get away with it, but otherwise this emperor is nekkid.

Steve

--

You have a slightly mixed up set of requirements here - it does not sound like you need anything more than a small 8-bit device, and 64k flash is probably at least four times overkill. If you don't have any particular reason (such as familiarity) to choose anything else, then go for an Atmel AVR. If you want to use uCOS, your easiest starting point is to find an evaluation board with example code for uCOS - there should be lots to choose from. Go for avr-gcc for development tools (from ) along with AVR Studio. C++ support is limited to the language only (i.e., you can work with classes, templates, etc., but there is no library support for exceptions, or run-time interfaces, and no class libraries).

Look at STM32.

Has all of those periperals. Free compiler upto 32kb from IAR (and with Thumb2 instructions you get quite a lot of code in that) - next step is the 256kb baseline edition. A number of uC/OSII ports available for download. IAR has embedded C++ support STM32 with IAR / J-Link provides trace information using SWO. J-Trace module for bigger external trace memory available for less then 1000EUR (cheapest Cortex trace you will ever find). STM32 can go to the lower speeds/powers if needed

Kit of STM32 and JLink for around 200EUR - look around.

I do not quite understand your idea of looking for a free compiler, but then using an expensive RTOS.. seems like you should build on concrete by using good tools and start to use the silicon vendor supplied librarys/freeRTOS and decide to buy an RTOS.

e y

from

age

or

can

I can only second this recommendation by adding, go to the STM8S. There have been a couple new ones just announced, meaning ST has definitely still some focus on these devices. There was another recommendation to use STM32, well these two families share peripherals, so if you start out with the STM8S and need to upgrade later, the STM32 will provide a very easy upgrade. Both are supported by Raisonance and if you are using this particular compiler, switching between the two is a piece of cake. What Lizard did not mention, if you start out and need 16/32k flash or less of programming space, the compiler for the STM8S (16k) as well as the one for STM32 (32k) from Raisonance are free. For further reading:

Features of the new STM8S devices

An Schwob

.

be

)

tty

ll from

image

K or

,

e can

crocontrollers__...

pray tell me where are the uc/OSII ports for STM8 or Raisonance ?

snipped-for-privacy@gmail.com wrote in news:df23d9fc-e93f-44eb-90cd- snipped-for-privacy@v23g2000pro.googlegroups.com:

I've used both PIC and Atmel AVR with the free GNU C tool chain. Both companies provide a decent development environment that wraps the compiler. PIC does charge too much for an 'advanced' version of the compiler, but you do not need it.

Microchip (PIC) has an online store selling directly in small quantities at good prices. I find this quite valuable.

Very Important: Excellent on-line community support. PIC -

AVR -

I repeat, both are excellent! Unless you are sitting in a university or a professinal engineering company, you may have trouble with getting help with other products.

I cannot see much value to C++ in this context. Without dynamic memory allocation, C++ is just bloatware.

Joe

e r

Interesting suggestion - again no uC/OSII and no C++.

Gosh i wish you guys luck with your projects, given the specifications required you come up with every solution that does not meet spec.

BTW PIC and AVR librarys and available code in abundace but it truly truly poor and crap. Good luck if you want to move away to a different 'controller.

In fact gcc-avr can do c++, it's just that nobody actually wants to do that!

It happens very, very often that the "spec" is the problem. A much better solution is often found by checking q the assumptions. In my opinion a good engineer or consultant should do this when appropriate, rather than blindly following the customers first idea. It is part of the value they bring to a project, part of what the customer is paying for.

avr-libc is pretty good in my experience.

--

John Devereux

That's note quite true. avr-gcc supports the C++ language quite well (there are occasional bugs found - it is much less used than avr-gcc C so issues that are specific to the combination of c++ and avr have had less testing). However, there is no C++ library for avr-gcc, and that means no exceptions, no RTTI, and no STL. However, those are features you seldom want in a small embedded system.

People *do* use avr-gcc with C++, but not nearly as many as use C. There are certainly good reasons for using C++ in such small systems - done well, classes, templates, and stronger typing can give you a better development environment (clearer and safer source code and at least as small and fast object code). The problem with C++ in such systems is that there are very few developers who know how to use C++ well...

Agreed - BBBBBF's comment about AVR's sounds like it is due to either ignorance or prejudice.

Have to disagree with you there.

;)

Steve

--

On which part - the idea that C++ *can* lead to better source code than C, or that very few C++ developers can actually write C++ that is better than a typical C program on a small micro?

One only has to look at the C++ features that have been copied into C (examples include "inline", \\comments, and mixing variable declarations and code) to see that there are features from C++ that are of benefit to C code and C programmers.

I have certainly come across parts of my C coding where I have thought it would be far neater and clearer to use classes - mostly just for encapsulation (which is really just syntactic sugar - lcd.init() instead of lcdInit()), but sometimes with inheritance (single and non-virtual, of course). I've also seen the benefits of RAII for things like an interrupt-disabler class, and I've seen templates that provide neat and flexible interfaces to things like port IO pins, while generating ideal assembly code in the end.

I haven't switched to C++ because I don't have the experience to do it well, but if I ever get the time to learn it properly, I will.

If template metaprogramming were a bit more accessible, it would be a great asset for embedded programming. Think general purpose libraries that can be parameterized and aggressively optimized for a given target.

--
Pertti

Indeed - templates in C++ are one of its ugliest parts (and C++ has lots of ugly syntax). Templates have such great potential for writing reusable libraries of code that are automatically generating in optimal forms. But partly because of an obsession with compatibility with C, the syntax for templates is enough to make a grown perl programmer cry. Add to that the limitations of compiling to object code then linking to an executable (a limitation introduced when 32 K memory was top-of-the-range, and totally unnecessary by the time C++ was conceived) so it's hard to know where templates are and what is being generated, and you can see why templates have a reputation for causing bloat. And finally you have the error messages - a small typo in template code can quickly lead to pages of gibberish from the compiler.

All in all, templates have the potential for huge benefits for programs, but it is *not* easy to write a good template library.

Don't know if it is the sort of thing you mean, but I use a C macro based "template" for abstracting port pin I/O. (Inspired by a previous discussion here I think).

It lets me write:

#define rx PIO(D,0) #define tx PIO(D,1)

...

pio_dd(rx,0); // data direction pio_dd(tx,1);

pio_out(tx,1); // set output high

...

if(pio_inp(rx)) ... // read input

It works on any of the processors I use provided I write a suitable header for that family. It compiles down to single machine instructions (where that is possible on the chip).

Here is the AVR version:

======================================================================== /* ATMEGA8 port I/O macros */ #ifndef H_PIO #define H_PIO

#define P4_1(a,b,c,d) a #define P4_2(a,b,c,d) b #define P4_3(a,b,c,d) c #define P4_4(a,b,c,d) d

#define IOPORT(s) P4_1 s #define IODDR(s) P4_2 s #define IOPIN(s) P4_3 s #define IOBIT(s) P4_4 s /* output x on port pin x */ #define pio_out(s, x) do {\ if(x) IOPORT(s) |= 1

Yes, you can do that sort of thing with C macros (I do too, although with slightly different syntax). Pretty much anything is better than "TXPORT |= TXPIN" (or worse, "PORTD5 |= 0x02") in the middle of your code - it is vital that the port address and the pin number are kept together as a single symbol.

C++ templates let you go a bit further, however, so that you can use them like this:

rxPin.float(); txPin.deassert(); // Lo or hi depending on the definition of txPin

if (rxPin.isAsserted()) ...

The idea here is that the polarity of asserting or deasserting a pin can also be included in its definition, as can variations such as making an open drain output (which would control the data direction rather than the output register).

It's not a *huge* step forward from what can be achieved by C macros, but it is slightly more flexible.

[...]

Yes, I have done others for open-drain pins (as used in I2C). Although it is often as easy to do something like

#define scl pio_dd(SCL,0) #define _scl pio_dd(SCL,1)

scl; // scl floats high _scl; // slc pulled low

I have never thought of the polarity issue. Nice idea... I expect it could be worked into another macro. But I think it might cause *me* more confusion than it solves. These things only appear in very low level code in any case, where you end up probing the pin with a scope probe. I don't want to have to check on the pin definition each time to see if it should be pulsing low or high!

--

John Devereux

As far as I can see, C++ templates are an accidental Turing machine. So _in principle_ you can do arbitrarily complex computations at compile time. The Boost::Python library is a good example of what can be achieved.

--
Pertti