bigbrownbeastiebigbrownface@googlemail.com writes:> On Mar 29, 3:48 pm, joemcder <jm1...@hotmail.com> wrote: >> fredbasset1...@gmail.com wrote in news:df23d9fc-e93f-44eb-90cd- >> b4b1c2398...@v23g2000pro.googlegroups.com: >> >> >> >> > Hi All, >> >> > I'm starting a new embedded control project soon, it looks fairly >> > simple so far, read some analog and digital inputs and provide some >> > PRM, digital & serial RS485 outputs. Sampling at about 10Hz should be >> > sufficient. I'm thinking a lower speed 16 or 32bit CPU will do the >> > job. >> >> > I'd like to use a CPU which: >> >> > supports source level debugging & fast code download for rapid turn >> > around cycles >> > has onboard Flash for of at least 64K >> > has plenty of eval. boards and ref. designs available >> > has uCos|| ported to it >> > a free compiler and tools (I would pay if the tools where really good) >> > optionally, can support C++ >> >> > I'm wide open to using a PIC, ARM, Freescale, Atmel chip, anything at >> > this stage >> >> > I know this question is fairly general but can anyone recommend a CPU >> > meeting the above requirements? >> >> > Thanks, >> > Fred >> >> 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 -http://www.microchip.com/forums/Default.aspx? >> AVR -http://www.avrfreaks.net >> >> 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 > > Interesting suggestion - again no uC/OSII and no C++.In fact gcc-avr can do c++, it's just that nobody actually wants to do that!> Gosh i wish you guys luck with your projects, given the specifications > required you come up with every solution that does not meet spec.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.> 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.avr-libc is pretty good in my experience. -- John Devereux
CPU recommendations?
Started by ●March 23, 2009
Reply by ●March 30, 20092009-03-30
Reply by ●March 30, 20092009-03-30
John Devereux wrote:> bigbrownbeastiebigbrownface@googlemail.com writes: > >> On Mar 29, 3:48 pm, joemcder <jm1...@hotmail.com> wrote: >>> fredbasset1...@gmail.com wrote in news:df23d9fc-e93f-44eb-90cd- >>> b4b1c2398...@v23g2000pro.googlegroups.com: >>> >>> >>> >>>> Hi All, >>>> I'm starting a new embedded control project soon, it looks fairly >>>> simple so far, read some analog and digital inputs and provide some >>>> PRM, digital & serial RS485 outputs. Sampling at about 10Hz should be >>>> sufficient. I'm thinking a lower speed 16 or 32bit CPU will do the >>>> job. >>>> I'd like to use a CPU which: >>>> supports source level debugging & fast code download for rapid turn >>>> around cycles >>>> has onboard Flash for of at least 64K >>>> has plenty of eval. boards and ref. designs available >>>> has uCos|| ported to it >>>> a free compiler and tools (I would pay if the tools where really good) >>>> optionally, can support C++ >>>> I'm wide open to using a PIC, ARM, Freescale, Atmel chip, anything at >>>> this stage >>>> I know this question is fairly general but can anyone recommend a CPU >>>> meeting the above requirements? >>>> Thanks, >>>> Fred >>> 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 -http://www.microchip.com/forums/Default.aspx? >>> AVR -http://www.avrfreaks.net >>> >>> 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 >> Interesting suggestion - again no uC/OSII and no C++. > > In fact gcc-avr can do c++, it's just that nobody actually wants to do > that! >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...>> Gosh i wish you guys luck with your projects, given the specifications >> required you come up with every solution that does not meet spec. > > 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. > >> 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. > > avr-libc is pretty good in my experience. >Agreed - BBBBBF's comment about AVR's sounds like it is due to either ignorance or prejudice.
Reply by ●March 30, 20092009-03-30
"David Brown" <david@westcontrol.removethisbit.com> wrote in message news:49d0b1a2$0$14785$8404b019@news.wineasy.se...> > 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...Have to disagree with you there. ;) Steve -- http://www.fivetrees.com
Reply by ●March 31, 20092009-03-31
Steve at fivetrees wrote:> "David Brown" <david@westcontrol.removethisbit.com> wrote in message > news:49d0b1a2$0$14785$8404b019@news.wineasy.se... >> 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... > > Have to disagree with you there. >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.> ;) >
Reply by ●March 31, 20092009-03-31
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
Reply by ●March 31, 20092009-03-31
Pertti Kellomaki wrote:> 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.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.
Reply by ●March 31, 20092009-03-31
David Brown <david@westcontrol.removethisbit.com> writes:> Pertti Kellomaki wrote: >> 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. > > 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<<IOBIT(s);\ else IOPORT(s) &= ~(1<<IOBIT(s));\ } while(0) /* read input pin state of port pin s */ #define pio_inp(s) ((IOPIN(s) & 1<<IOBIT(s)) != 0) /* set data direction of port pin s to output (x==1) or input (x==0) */ #define pio_dd(s, x) do {\ if(x) IODDR(s) |= 1<<IOBIT(s);\ else IODDR(s) &= ~(1<<IOBIT(s));\ }while(0) /* helper macro e.g. PORTD.5 would be #define mybit PIO(D,5) */ #define PIO(port,n) (PORT##port, DDR##port, PIN##port, n) #endif /* H_PIO */ ======================================================================== -- John Devereux
Reply by ●March 31, 20092009-03-31
John Devereux wrote:> David Brown <david@westcontrol.removethisbit.com> writes: > >> Pertti Kellomaki wrote: >>> 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. >> 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). >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.
Reply by ●March 31, 20092009-03-31
David Brown <david@westcontrol.removethisbit.com> writes:> John Devereux wrote:[...]>> 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). >> > > 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).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!> It's not a *huge* step forward from what can be achieved by C macros, > but it is slightly more flexible.-- John Devereux
Reply by ●March 31, 20092009-03-31
David Brown wrote:> It's not a *huge* step forward from what can be achieved by C macros, > but it is slightly more flexible.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
