Why are you still using 8 bit MCUs?

[JTR]

I have found most PIC24s are now cheaper than an 8 bit PIC18, but I love 5v (Working mainly with automotive stuff so 5v sensors etc)

Matt

Well there are some 5V PIC24s, not a huge selection but "some." Of course there is the older dsPIC30s and all of these are 5V.

The PIC24 is an "agreeable" ISA to work with whether you code in C or assembler.  When used with C30 or XC16 in free mode it suffers a lot less from the lost of optimisations than all the other PIC families in my experience. I sometimes wonder if this family is under utilized simply based on a perception that 32-bits is the way to go. Anyway, that's just me musing and wondering...

[dannyf]

I sometimes wonder if this family is under utilized simply based on a perception that 32-bits is the way to go.

Definitely the case. PIC24, in my view, is the best mcu Microchip has to offer. Yet, it is grossly under-marketed and under-appreciated.

[nctnico]

you'll spend less time fiddling with algorithmic C code to make it work.

Is that really true?

"x = y+z;" is always the same (in C) on an 8-bit mcu or a 32-bit mcu.

I have plengty of math-intensive routines that run flawlessly, and unmodified, on 8-bit/16-bit and 32-bit mcus.

Wait until you start using pointers on an 8 bit PIC or 8051. Ofcourse it works but its soooo slow because the compiler needs to adds a lots of extra code in order to emulate a single memory map. Its actually so bad that Keil's compiler for the 8051 doesn't even attempt to support non-constant function pointers.

[dannyf]

I have to say that I have used pointers (to constants / variables / functions) on both chips. No ill feeling so far.

What specific issues are you referring to?

[mikeselectricstuff]

I sometimes wonder if this family is under utilized simply based on a perception that 32-bits is the way to go.

Definitely the case. PIC24, in my view, is the best mcu Microchip has to offer. Yet, it is grossly under-marketed and under-appreciated.

yes - it is nice, especially the pin remapping which makes PCB layouts really easy  - QFNs on 2 layers - no problem!

[mrflibble]

yes - it is nice, especially the pin remapping which makes PCB layouts really easy  - QFNs on 2 layers - no problem!

Okay, now I'm curious. I had more or less kicked out microchip due to one bad experience too many. But good chips are good chips, sooooo. Any particular ones in the PIC24 family with an awesome price/performance ratio? Or if you happen to know this, any ones with center aligned PWM?

In the meantime, time for a parametric search...

[senso]

I used one PIC24, for 2 weeks, could blink and led, add code to init the uart the pic just hanged lol, tried 5 of them, consistent behavior, no one in the microchips forum could understand the error, tried tons of code, bye bye   

[nctnico]

I have to say that I have used pointers (to constants / variables / functions) on both chips. No ill feeling so far.

What specific issues are you referring to?

Speed and code size. Another problem is that 8 bit PICs and 8051 basically have no stack so the compiler needs to emulate this as well. This means that function parameters and variables are in RAM. The compiler usually tries to seperate IRQ processes from the primary process and reuse as much space as possible. Now try a function which is used both from the main process and an interrupt... Try to think about how this will work with pointers to functions. In a device with banked memory like the 8 bit PICs the mapping of variables to memory usually needs some 'pragma' steering as well. If you want fast & small code then you have to resort to some sort of C slang where C starts to look like programming with assembler macros.

[mikeselectricstuff]

yes - it is nice, especially the pin remapping which makes PCB layouts really easy  - QFNs on 2 layers - no problem!

Okay, now I'm curious. I had more or less kicked out microchip due to one bad experience too many. But good chips are good chips, sooooo. Any particular ones in the PIC24 family with an awesome price/performance ratio? Or if you happen to know this, any ones with center aligned PWM?

In the meantime, time for a parametric search...

My default is a PIC24FJ64GA002, as you can get it in a 28QFN which is one of the better package size to capability ratios available (RAM in particular), and a few bigger ones when I've needed more UARTS, but haven't looked very hard at the rest of the rage. I've also use the GB ones for USB host. 

[mikeselectricstuff]

The main reason to go 32-bit (instead of 8- or 16-bit) is that you'll spend less time fiddling with algorithmic C code to make it work. 8-bit architectures often add restrictions to what you can do in C--compromises between what the language definition supplies and what the hardware can support. With a 32-bit ARM chip, the silicon is basically an engine that runs C.

The only people who say that are desktop programmers who don't really understand C or what the compiler does, or how CPUs work. In that respect 8 bit is usually easier than 32.

It really isn't about the core - 32Bit MCUs tend to come with much more complex peripherals, clocking schemes & PLLs, power management,  memory mapping, DMA etc. which take more figuring out than the simpler peripherals of typical 8-bit devices.

[dannyf]

especially the pin remapping

Absolutely agree with that. A life saver.

Or if you happen to know this, any ones with center aligned PWM?

The good thing about those chips is that their pwm / ic channels utilize dedicated timers. Kinda like the TI approach: identical feature-rich peripherals. Datasheet is your best friend at this point.

tried tons of code,

Not enough information to blame it on the chip alone.

[dannyf]

Speed and code size.

How  much slower do you think it is?

[nctnico]

The main reason to go 32-bit (instead of 8- or 16-bit) is that you'll spend less time fiddling with algorithmic C code to make it work. 8-bit architectures often add restrictions to what you can do in C--compromises between what the language definition supplies and what the hardware can support. With a 32-bit ARM chip, the silicon is basically an engine that runs C.

The only people who say that are desktop programmers who don't really understand C or what the compiler does, or how CPUs work. In that respect 8 bit is usually easier than 32.

Its the other way around. I dumped the 8051 in favor of the MSP430 because the MSP430 has one single memory space, a real stack etc. I was tired of having to jump through hoops because of the limits the 8051 imposed. I wanted to get my projects going and that was much quicker with the 16 bit MSP430 than the 8051. I really don't understand how having 2 or 3 different memory spaces each with different instructions to access them can be regarded as being simple.

@dannyf: for the project I worked on it was way too slow and way too big because of the compiler inferred pointer emulation. The code size was twice the size of the available memory. I rewrote the software (which ran perfectly on ARM; ARM loves pointers) to be a better fit for the PIC (which was in the existing hardware so I couldn't get rid of it).

[senso]

I used one PIC24, for 2 weeks, could blink and led, add code to init the uart the pic just hanged lol, tried 5 of them, consistent behavior, no one in the microchips forum could understand the error, tried tons of code, bye bye   

Kinda suggests the problem was you, if such a simple application failed.

Kinda suggests the samples they sent me had a hardware bug
Never had a problem with STM32F4's, Atmegas, Attinys, PIC32 and MSP430..

There are also some pic's that have hardware stack's, and no one is crying about that, each chip as its limitations, choose whatever fits the best.

[dannyf]

Kinda suggests the samples they sent me had a hardware bug

Tough to argue against thousands / millions (?) of such chips used successfully.

The code size was twice the size of the available memory.

I hope that doesn't mean the use of pointers doubled the memory.

I have used pointers on those chips and I can code faster with pointers than with normal assignments for some applications.

[andyturk]

In all cases you code for the device and environment.

I disagree. You code for the product requirements. Device selection comes later (assuming you have a choice).

The difference I see is I do not have an ad version to using a 8 or 16 bit microprocessor. 

You're more flexible than I am, to your credit. My recent projects have involved enough code that 8-bit mcus simply wouldn't work. One project used an MSP430 and required dancing around address space limitations.

By your derogatory comment of "code monkey" I now wonder why I would even bother to try explain my position to you as an peer.  I think giving you that credit was a mistake on my part.  As a person with decades of experience in electronics and programming I find your attitude deplorable.

Chill out, dude. I *am* a "code monkey". 

[WarSim]

In all cases you code for the device and environment.

I disagree. You code for the product requirements. Device selection comes later (assuming you have a choice).

Pre-device selection programming is usually limited to templates, resource map and POC code.  Err wait ... Your statement indicates a different methodology.

I think I now understand which of the three programming methodology you use.  It is a valid, but i believe that process is best suited to programming in a single architecture class.  It is faster process but restricted by class, because any class deviations will cause any increased speed to be lost.  So yes given your chosen programming methodology using only 32bit uC would be your best choice.  Because not all tasks are amenable to a 8/16 bit chip but all should work in a 32bit chip with varying levels of efficiency.  Until 64bit uC are made

Sorry can't remember the names right now.  My best guesses are deconstruction (me), code collection (you) and story board (scripters and web programers). 

I used code collection method when programming for mini-computers and PCs.  When I started with AI programming in 90's I changed methodologies.  It was all IP locked down, everything I did was essentially original.  Later in 00 when programming uC I found I preferred the deconstruction methodology for these tasks as well. 

This debate helped me remember more about the methodologies thanks. 

[Kjelt]

Until 64bit uC are made  

Thanks for the smiley because I really, really would not know what to use a 64 bit address space for in an embedded device.      That said the term embedded is misused everywhere even in 6' large 19" rack sun systems driving some industrial application, which is far from embedded in my vocabulary.

[WarSim]

Until 64bit uC are made  

Thanks for the smiley because I really, really would not know what to use a 64 bit address space for in an embedded device.      That said the term embedded is misused everywhere even in 6' large 19" rack sun systems driving some industrial application, which is far from embedded in my vocabulary.

Yes, but it is part of a "System".  The quintessential over used word.   

Don't laugh (too much) we still used Solaris 9 on some of our special purpose computers. 

[westfw]

Wait until you start using pointers

Well, pointers to functions or data in Harvard "code space" can be interesting on an architecture where pointers are normally only 16 bits, but there is more than 64k of flash.  Compilers will do most of the work, most of the time, but they start to violate expectations of straightforward operation.  (avr-gcc has "trampolines."  Whee!)

Smaller PICs have trouble with data structures bigger than "some" of a bank size, because actual data memory isn't contiguous; each bank has some IO registers and some general purpose ram.

Many languages get a bit grumpy when you violate their core assumptions by having more than one address space (harvard architecture) or having pointers to different types of objects be different sizes.  (C on a PDP10 was interesting, because it was word-addressable.  Pointers to strings were an entirely different "thing.")

This is more of an argument about matching compilers to architectures and problems, rather than an 8bit vs 32bit argument, technically speaking.  But non-technically, "use a 32bit cpu because its architecture is more directly suited to running code written in a modern language" *is* part of the overall argument.

It can be "educational" to go back and look at some of the shared C software from the early days of the IBM/PC, when C libraries were less standardized, and there was CP/M plus several versions of unix floating around as well.  The amount of conditional compilation was ... horrifying!

[andyturk]

I used code collection method when programming for mini-computers and PCs.  When I started with AI programming in 90's I changed methodologies.  It was all IP locked down, everything I did was essentially original.  Later in 00 when programming uC I found I preferred the deconstruction methodology for these tasks as well. 

I'm not totally clear on the distinction between "code collection" and "deconstruction", but it sounds reasonable. There's quite a lot of open "source" out there now, and it often makes sense to use someone else's code (if it works) rather than writing it yourself. It used to be build vs. buy, but now it's more like build vs. fork. Is that what you mean by "code collection"?

BTW, it sounds like we're contemporaries. My first job was writing Z80 assembly code and FORTRAN in the early 80s.

[AndyC_772]

I've had an interesting couple of days trying to see how I might port a PIC18 design from a couple of years ago onto a faster processor.

The PIC in question was a particularly good fit for the design at the time, not because of the core (which was too slow, and the fragmented memory map was a PITA) but with the other peripherals integrated onto the die. Aside from the voltage regulator to power it, the PIC was about the only active component on the board.

The peripheral set in question? Two analogue comparators, three PWM outputs, an RTC, and some true, byte addressable EEPROM. Plus the usual Flash, RAM, timers and so on which just about every microcontroller has.

I'd hoped that with there being so many ARM Cortex M0 and M0+ micros out there, finding one to replace my PIC would have been easy, but no. EEPROM in particular seems quite rare, which is a great shame because the design really does need to store and update a few bytes at a time at fairly regular intervals. I'm fairly sure it's down to process limitations at the wafer fab... whatever process can make the core for pennies isn't so well suited to fabricating EEPROM cells.

Maybe this particular project is just a bit of an oddball in terms of its requirements?

The other thing which came out of my research is the difference in code space required. The original project fits (just!) into a 32k PIC18. Rewrite it for an STM32 part using the ST peripheral libraries - which, with hindsight, was probably more trouble than it's worth - and it won't fit into a 64k device without optimisation. Flash capacity would appear not to be directly comparable between the families, despite the fact that the Cortex M0 uses 16 bit (Thumb) instructions to improve code density. It's not a particularly I/O intensive project, most of the code is application level and stored bitmap graphics, so the impact of the more complex peripherals is minimal.

If anyone has any suggestions for a device with the necessary peripherals but about, say, twice the performance of a PIC18 @ 64 MHz, I'd be genuinely appreciative. If it's a similar price, so much the better!

[WarSim]

I used code collection method when programming for mini-computers and PCs.  When I started with AI programming in 90's I changed methodologies.  It was all IP locked down, everything I did was essentially original.  Later in 00 when programming uC I found I preferred the deconstruction methodology for these tasks as well. 

I'm not totally clear on the distinction between "code collection" and "deconstruction", but it sounds reasonable. There's quite a lot of open "source" out there now, and it often makes sense to use someone else's code (if it works) rather than writing it yourself. It used to be build vs. buy, but now it's more like build vs. fork. Is that what you mean by "code collection"?

BTW, it sounds like we're contemporaries. My first job was writing Z80 assembly code and FORTRAN in the early 80s.

No it doesn't imply borrowed code.  All the code can be original.  The distinction is by when in the programming process that functional blocks are implemented.
As I said I may have the names wrong. 

All programming problems are broken down in phases.  Starting at concept ending at working code, and extended by revision. 
The least used method method is story board is when the concept deconstruction diverts to code generation after info and data flow charting is done.  Fourth was the first attempt the bridge the gap.  Delphi was a half step between this and the next methodology. 

Code collection continues the process through process control and end point identification.  This methodology can have archive shorter development time through the use of existing libraries.  The negative effect is every architecture change can involve huge increases in conditional compile blocks.  In a perfect scenario the only code specifically created is the glue code to connect the parts together.  Another restriction is this method only gain it's full benefit if the process components have been generated before by the last methodology. 

Deconstruction continues the process through scope charts, convention controls and instance plans.  At this stage all that is left is code each task block.  Heave use of code snippets enables increased programming speed or just type at over 180wpm.  I can only do 120wpm so I use code snippets, allot of my peers are really fast typers.  Advantages are no IP costs and not preexisting code dependant.  Disadvantage longer pre-code planing. 

I hope this explains what I was referring to.  Even if I got the methodology names wrong. 

I was taught that keying in should only be 20% of the effort and if you have to recompile a third time you failed.  Yes this is old school it no longer takes a week to compile a complete project.  Obviously code for a uC could take more than 30min to compile.  My last major computer based project took a very fast PC 8 hrs to compile.  So this point was more significant then than now. 

Almost all my coding these days follows the deconstruction methodology not because it is better but because it is necessary.  At work I get assigned the tasks others don't want to tackle.  I get the project just before it goes back out the door as unable to implement.  The bean counters get the excuse to bid high and the job comes back and I get the work. 

Seems I find glueing libraries together boring, I don't do it as a hobby.  My last 5 DIY of my last 7 projects I did was to prove the that something can be done.  I really annoys me when people say something can't be done when it can.  I do it to prove to myself they are wrong no prove to them they are wrong.  The other projects because I could not find what I wanted for sale anywhere. 

[dannyf]

twice the performance of a PIC18 @ 64 MHz,

I don't know if you can run this particular pic at 64Mhz but what "performance" are you talking about? In certain cases, an ARM-based chip can be multitude faster than the PIC, and in others not so or just comparable. So without defining what "performance" you are looking for, it is hard to tell you specifically if an ARM chip will do.

I do say that in IO-intensive applications, an ARM chip can be considerably faster (and in some cases 3x faster) giving that many of them allow masked read / writes, or bitbanding. For math-intensive applications, the ones with FPUs are considerably faster but not so much on 8-bit types (other than division).

I do think your observation on code space is spot on and consistent with mine. The exception can be those chips with onboard ROM.

As to eeprom, Freescale, NXP and TI offer many such chips. Unfortunately, those happen to the high-end vendors too.

[Rufus]

If anyone has any suggestions for a device with the necessary peripherals but about, say, twice the performance of a PIC18 @ 64 MHz, I'd be genuinely appreciative. If it's a similar price, so much the better!

PIC24FV32KA304 maybe.