Why are you still using 8 bit MCUs?

[nctnico]

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.

What kind of optimisation? You probably use GCC and if you don't specify the optimisation level it doesn't optimise at all (which is nice if you want to check the assembler output or run the program in a debugger). For microcontrollers I always use -Os to optimise for size. This gives you the most compact code. For one of my larger ARM projects no optimisation gives me a binary of 60072 bytes. With optimisation for size that number gets reduced to 26610 bytes. I'd also check the mapfile generated by the linker to see what happened with the graphics. Maybe they got aligned to 4 byte boundaries so they take way more space than they should.

edit: another thing to look for in the mapfile is whether large chunks of standard C libraries are being pulled in. It helps a lot to use a miniaturised C library to reduce size.

Regarding the EEPROM: on a flash based device you simply use one (or more) flash sectors to store data. The only difference is that you'll need to do a read-modify-write.

[Kjelt]

Watch out with substituting an eeprom with flash. You wrote several bytes at fairly regular intervals you should calculate how many cycles that will total upto in the desired lifetime of the product. Eeprom can be written millions of times, flash 100000 to 300000 (check datasheet) so you have to do a wear leveling algorithm or if there is no secrets use an external i2c or spi eeprom.

[ElectroIrradiator]

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!

I haven't used them myself, but check the ARM Kinetis family from Freescale. They seem to have combinations of every sensible peripheral under the Sun, including comparators and on-chip EEPROM by way of their FlexMemory functionality.

[Rufus]

PIC24FV32KA304 maybe.

Microchip give their products such catchy names. I'm sure there's some logic to it.

There is logic to some of it.

PIC24F is the main family
V indicates 5v supply with internal regulator
32 is K of program memory
K is some kind of sub-family
A3 is some kind of generation indicator - there may be B3 or A4 parts in the future
04 indicates 44 pins

[dannyf]

Eeprom can be written millions of times,

Typical endurance is 300 - 500K cycles. I have tried PICs for over 2 million cycles, without any errors - I stopped at that time.

[AndyC_772]

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.

The time-critical bit happens on an edge of an external signal, the frequency of which can vary. On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge. Much less frequently (a few times per second), the result of all these calculations are shown on an LCD display.

I'd expect a considerable speed improvement from an ARM Cortex M0 processor over and above a PIC18. The raw instruction rate is, say, 3x faster (comparing a 48 MHz STM32 vs a PIC18 running at Fosc/4 = 16 MHz). On top of that, the algorithm is performing arithmetic on 16-bit integers, so I'd expect the ARM to require fewer instructions per computation than the PIC. The additional overhead of talking to more a more complex timer should be minimal.

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

Usual suspects, then. Atmel and NXP look closest, though nothing quite hits the same well-matched feature set as the PIC18F66K22 I'm currently using. Looks like I'm going to end up with either an external EEPROM, or some complex wear-levelling EEPROM emulation code that I could well do without. Shame.

PIC24FV32KA304 maybe.

Thanks, it looks like a close match, though still only 16 MIPs... I'd have to get good value from the fact that it's a 16 bit device in order to be a worthwhile update.

What kind of optimisation? You probably use GCC and if you don't specify the optimisation level it doesn't optimise at all (which is nice if you want to check the assembler output or run the program in a debugger).

Any of the GCC optimisation levels will get it into 64k, so it's not like it strictly "won't fit" - just that I'd like to be able to debug it easily.

As far as detailed usage goes, I don't know yet because I've been struggling to find an IDE that works reliably and that I can install and use... I've invested more of my life than I care to admit in both Eclipse / Yagarto and then CoIDE, and decided that there's a reason why there's a market for commercial development tools even with four figure price tags. I have CrossWorks for ARM on eval right now, which is probably the route I'll be taking; it seems easy enough to drive, and gives quite a nice graphical display of memory usage. The cost is, I think, less than the value of my time which I may end up wasting otherwise.

I haven't used them myself, but check the ARM Kinetis family from Freescale. They seem to have combinations of every sensible peripheral under the Sun, including comparators and on-chip EEPROM by way of their FlexMemory functionality.

Agreed - I did find a part which would do the job (a KL30 IIRC), but it was a bit over-powered for the job and slightly more expensive than I'd ideally have liked. But since this is really just a learning and development exercise for me right now, I might well go down that route. Thanks for the suggestion.

[dannyf]

On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge.

It is usually a bad design to put extensive arithmetic operations into the isr for those chips.

The ARM will give you an edge in terms of integer math capabilities, re-entrancy, isr latency (if chained), higher master clock, and IO-latency (on AHB), and floating point math on certain ARM chips; The PIC will give you an edge in terms of IO-latency (vs. APB), and clock speed (if you indeed could run the PIC at 64Mhz).

[Rufus]

PIC24FV32KA304 maybe.

Thanks, it looks like a close match, though still only 16 MIPs... I'd have to get good value from the fact that it's a 16 bit device in order to be a worthwhile update.

Well you know the tools, the compiler does a good enough job in free mode. Compile something representative and count cycles or time it in the simulator.

You might browse here
http://www.eembc.org/coremark/index.php
there are a couple of PIC18 scores giving about 0.16 coremarks/MIP. The 16 bit PICs about 1.8, 32 bit PICs 3 to 3.5. I expect the benchmarks are more generous towards processor 'bits' than most real world applications. Be careful some of the results confuse processor clock frequency and actual instruction rate.

[dannyf]

there's a reason why there's a market for commercial development tools even with four figure price tags.

Mostly for the support that a commercial vendor brings.

Otherwise, those free tools do a decent job, for those chips that they support. CoIDE is an excellent platform, but with limited support for chips that I use.

[Kjelt]

On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge.

It is usually a bad design to put extensive arithmetic operations into the isr for those chips. 

+1 and I would say on any chip. Esp. if you have no guarantee when the next pulse comes in respect to the processing. Better design in my opinion would be to do the most necessary tasks only in the isr, in this case store the timer value in a queue. And process that queue data in the main loop, or better in a seperate task if running an RTOS.
Then do an extensive test for the processor load (or the idle time in RTOS) to be sure it can handle the dataflow over a long period.
That way the pulses are allowed to also come almost after eachother and you will never miss one.

[andersm]

You might browse here
http://www.eembc.org/coremark/index.php
there are a couple of PIC18 scores giving about 0.16 coremarks/MIP. The 16 bit PICs about 1.8, 32 bit PICs 3 to 3.5. I expect the benchmarks are more generous towards processor 'bits' than most real world applications. Be careful some of the results confuse processor clock frequency and actual instruction rate.

The MIPS-based PIC32s generally benchmark well, due to the large number of registers and compiler-friendly instruction set. However those same registers add to the interrupt latency and especially things like RTOS context switch times.

[Rufus]

On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge.

It is usually a bad design to put extensive arithmetic operations into the isr for those chips. 

+1 and I would say on any chip.

He said "have to be complete before the next edge" how does trying to offload the calculations to foreground execution help meet that requirement in any way?

PWM generating applications for things like motor and switch mode power supply control often require calculation of the duty of every PWM cycle, often based on the result of ADC conversions synchronised with PWM generation. You can't ask a 3 phase motor to wait a bit for the PWM sine waves you are generating because your foreground code was servicing a query on a serial port.

[nctnico]

On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge.

It is usually a bad design to put extensive arithmetic operations into the isr for those chips. 

+1 and I would say on any chip. Esp. if you have no guarantee when the next pulse comes in respect to the processing. Better design in my opinion would be to do the most necessary tasks only in the isr, in this case store the timer value in a queue. And process that queue data in the main loop, or better in a seperate task if running an RTOS.

The worst advice I've ever seen. The only reason to make an ISR short is when there is a chance another ISR can kick in which needs to be serviced. But then again most microcontrollers support nested interrupts. Sometimes I make DSP-ish applications. In those all the signal processing is done inside the ISR (sometimes 90% of the CPU time is spend in one interrupt). This saves a lot of hassle and overhead with transferring buffers to the main process (think semaphores!). The main process usually isn't designed to handle timing cricital stuff anyway.

A controller has X time to handle Y instructions. Moving calculations outside an ISR doesn't mean that X or Y changes so it doesn't matter where you do the math. You need to do it anyway.

[AndyC_772]

Oh, dear, I was afraid that mentioning how the software works would spark a debate!

I know perfectly well the "rule" about not spending "too much" time in an ISR, but as with all such "rules", they're there to be broken if you know what you're doing. In this case I know what the nature of the input signal is like and where the time critical paths are, and I'm satisfied that it's OK for the CPU to spend most of its time in the ISR.

The timer captures the exact instant at which the pulse arrives; if it's not actually processed until later then that's OK - the application is for monitoring and display, not real-time control.

there's a reason why there's a market for commercial development tools even with four figure price tags.

Mostly for the support that a commercial vendor brings.

Otherwise, those free tools do a decent job, for those chips that they support. CoIDE is an excellent platform, but with limited support for chips that I use.

Support is great to have, but first and foremost, the tool has to 'just work' in a majority of cases. Sadly my experience of CoIDE is that it doesn't.

I, along with a number of other users, have had problems downloading code to my target board using CoIDE, and although the most recent version worked OK with a small project, it broke again when I ported a larger one. The developers haven't been able to reproduce or fix the problem - certainly not in a timely manner - and that leaves me at an unacceptable dead end.

For a hobby project it might then be OK to post a support request on the forum and hope for the best, but that's no good if I have a customer waiting. I need the tools I use to have been put through the sort of thorough beta testing that open source and other free software rarely gets, and I'm a firm believer that the best technical support is the support you don't need in the first place.

[nctnico]

I standarised all my software development to use Eclipse. As far as my experience goes Eclipse beats any IDE I have used so far. But then again Eclipse is intended to be the best IDE there is. The amount of features and workflow do take some getting used to. For programming I use standalone programming software/tools like 'Flashmagic' (for the NXP controllers). I gave up on in-circuit debugging decades ago. It takes more time to set it up than it takes to just run the software through a PC based debugger.

[dannyf]

it doesn't matter where you do the math.

Having actual experience programming those mcus would be quite helpful here. Talking about programming those mcus can only take you so far.

problems downloading code to my target board using CoIDE

I don't know your specific issues but downloading / debugging in any ide is done with the help of 3rd party tools, which often require proprietary IP from the 3rd party tool vendors. For example, CoIDE has no support for lpc-link since they haven't worked out a deal with nxp.

You cannot blame the ide entirely for that.

[AndyC_772]

I don't care about assigning blame, I care about having a tool chain available to me which works reliably. With commercial software, it's someone's responsibility to ensure this is the case, and to help me resolve any problems I do encounter.

This isn't the case with the free / open source stuff. An indignant "it works for me", or "it's your environment that's wrong", or "blame the developer of xxxx", or no response at all, doesn't help.

"I know what I'm doing" are the most famous last words in the history of the world.

You're thinking of "Hold my beer and watch this!"

[dannyf]

doesn't help.

They don't need to help you. As a matter of fact, no one needs to help you in that case. You made the decision to use free tools and you should expect "free" support. It is lucky that a free tool worked for you - that's the right expectation.

[AndyC_772]

I completely agree.

[Kjelt]

Indeed its getting offtopic but great that everybody has an opinion  , the problem here are the requirements and if the input signals are known and predictable.
And luckily in this case they are:

In this case I know what the nature of the input signal is like and where the time critical paths are

In my own experience however I have seen a lot of accidents happen with ADC sampling and directly in the ISR calculating all the (sometimes very complex) math for results that are NOT directly necessary. For instance energyconsumption. The requirements state for instance that this should be accurate every few seconds, so in those cases you can store the results and postpone the final calculation or do this over time with averaging. Also this code grows over time, new requirements and SW engineers, putting the extra code on top of the existing (inside the ISR), failure waiting to happen.

He said "have to be complete before the next edge" how does trying to offload the calculations to foreground execution help meet that requirement in any way?

In this case it probably doesn't, it does help however porting to another microcontroller , platform and overall readability, all which become more important these days then making it work on a single platform.

You can't ask a 3 phase motor to wait a bit for the PWM sine waves you are generating because your foreground code was servicing a query on a serial port.

True that's a matter of prioritizing the tasks. In the given case the calculations should have higher priority over a slow serial port query.
However the query should still be processed at some time also otherwise your system seems to be dead from an outside point of view.

The worst advice I've ever seen. The only reason to make an ISR short is when there is a chance another ISR can kick in which needs to be serviced.

That was exactly my point that the exact same interrupt is not going to be handled because the ISR is still in the middle of its calculations. You loose events and valuable information that is not going to be processed because the timer value that needs to be stored is increasing with every instruction you waste in the mean time and the results will be false.

A controller has X time to handle Y instructions. Moving calculations outside an ISR doesn't mean that X or Y changes so it doesn't matter where you do the math. You need to do it anyway.

Depends on the requirements if you need to do it right away or it can be handled in between events or even delayed for some times.
I firmly believe ISRs need to be as small and simple as possible do what they need to do and return. Do the prioritizing of the tasks in your taskshandler, if you have an RTOS and else write it yourself.

But then again most microcontrollers support nested interrupts.

Hooray, good luck handling the exact same interrupt you are already handling.

But I think we mean the same thing, you will probably say you have to make sure that the computations are finished before the next event comes which is correct. That said you sometimes don't know when the next event comes. If the whole point of the interrupt and thus the ISR is to simply store the exact timervalue at the exact moment of the interrupt, you better make sure that that interrupt is getting handled immediately which means keep the ISR to it's minimum.

Anyone interested in ISR's should take a Rate Monotonic Analysis course, very worth while 

[WarSim]

Indeed its getting offtopic but great that everybody has an opinion  , the problem here are the requirements and if the input signals are known and predictable.
And luckily in this case they are:

In this case I know what the nature of the input signal is like and where the time critical paths are

In my own experience however I have seen a lot of accidents happen with ADC sampling and directly in the ISR calculating all the (sometimes very complex) math for results that are NOT directly necessary. For instance energyconsumption. The requirements state for instance that this should be accurate every few seconds, so in those cases you can store the results and postpone the final calculation or do this over time with averaging. Also this code grows over time, new requirements and SW engineers, putting the extra code on top of the existing (inside the ISR), failure waiting to happen.

He said "have to be complete before the next edge" how does trying to offload the calculations to foreground execution help meet that requirement in any way?

In this case it probably doesn't, it does help however porting to another microcontroller , platform and overall readability, all which become more important these days then making it work on a single platform.

You can't ask a 3 phase motor to wait a bit for the PWM sine waves you are generating because your foreground code was servicing a query on a serial port.

True that's a matter of prioritizing the tasks. In the given case the calculations should have higher priority over a slow serial port query.
However the query should still be processed at some time also otherwise your system seems to be dead from an outside point of view.

The worst advice I've ever seen. The only reason to make an ISR short is when there is a chance another ISR can kick in which needs to be serviced.

That was exactly my point that the exact same interrupt is not going to be handled because the ISR is still in the middle of its calculations. You loose events and valuable information that is not going to be processed because the timer value that needs to be stored is increasing with every instruction you waste in the mean time and the results will be false.

A controller has X time to handle Y instructions. Moving calculations outside an ISR doesn't mean that X or Y changes so it doesn't matter where you do the math. You need to do it anyway.

Depends on the requirements if you need to do it right away or it can be handled in between events or even delayed for some times.
I firmly believe ISRs need to be as small and simple as possible do what they need to do and return. Do the prioritizing of the tasks in your taskshandler, if you have an RTOS and else write it yourself.

But then again most microcontrollers support nested interrupts.

Hooray, good luck handling the exact same interrupt you are already handling.

But I think we mean the same thing, you will probably say you have to make sure that the computations are finished before the next event comes which is correct. That said you sometimes don't know when the next event comes. If the whole point of the interrupt and thus the ISR is to simply store the exact timervalue at the exact moment of the interrupt, you better make sure that that interrupt is getting handled immediately which means keep the ISR to it's minimum.

Anyone interested in ISR's should take a Rate Monotonic Analysis course, very worth while 

Isn't this covered with synchronous / asynchronous event charts and the time budget table?  Which is used to develop the timing sequence tree?  Aren't these used anymore to figure out these issues?  After all this is where these rules of thumb came from.     

Hmmm.  "Rate Monotonic Analysis course" if I take this course name literally, this suggest the this subject is covered in part in a separate courses.  Strange to have such and integral part itemized out into a separate subject or subjects.  Then again schools love breaking everything up into tinny pieces to make more money. 

[Rufus]

If you think this doesn't apply to you just remember that "I know what I'm doing" are the most famous last words in the history of the world.

When you don't know what you are doing claiming no one else does either will make you feel better about it.

[nctnico]

A controller has X time to handle Y instructions. Moving calculations outside an ISR doesn't mean that X or Y changes so it doesn't matter where you do the math. You need to do it anyway.

Depends on the requirements if you need to do it right away or it can be handled in between events or even delayed for some times.
I firmly believe ISRs need to be as small and simple as possible do what they need to do and return. Do the prioritizing of the tasks in your taskshandler, if you have an RTOS and else write it yourself.

But then again most microcontrollers support nested interrupts.

Hooray, good luck handling the exact same interrupt you are already handling.

But I think we mean the same thing, you will probably say you have to make sure that the computations are finished before the next event comes which is correct. That said you sometimes don't know when the next event comes. If the whole point of the interrupt and thus the ISR is to simply store the exact timervalue at the exact moment of the interrupt, you better make sure that that interrupt is getting handled immediately which means keep the ISR to it's minimum.

Sources of interrupts should always have a predictable behaviour: a minimum and maximum interval so you can determine the CPU load and the maximum time that can be spend inside the interrupt. Just accepting interrupts without any predictability (like from an unfiltered GPIO input) is asking for major problems. Over the years I have started to see interrupts as seperate processes where the interrupt controller is the task scheduler. Modern microcontrollers have lots of features in their interrupt controllers which allow for pretty specific task handling (prioritizing). Either way you'll need to make sure whether the CPU isn't loaded too much.

[AndyC_772]

In the specific example I mentioned earlier, the device generating the interrupts is a sensor on a rotating machine. The spacing from one pulse to the next depends on the rotational speed, so there's a definite mechanical limit on how close together they can occur. Noise filtering is done in hardware, independently of the microcontroller.

[WarSim]

In the specific example I mentioned earlier, the device generating the interrupts is a sensor on a rotating machine. The spacing from one pulse to the next depends on the rotational speed, so there's a definite mechanical limit on how close together they can occur. Noise filtering is done in hardware, independently of the microcontroller.

By what I understand from your explications this is a project needs a plan of separating the tasks into asynchronous event response and opportunistic code. 
Because you have concerns about the frequency deviation the of the edge events the ISR needs to be as small as possible or through higher speed at the task. 
If there is a time gain from buffering for opportunistic completion do it.  Micro controllers are made with ISR nesting but there is no support for re-entrant ISRs which will happen if the ISR takes longer than the shortest inter edge gap.  The buffering to the opportunistic code could be programmed re-enterent dispute no core support . 

You mentioned that some calculations are inter cycle constrained.  Yes these should fit in your smallest inter edge gap.  If you have extensive math that exceeds the time this is where you will need to use math replacement routines.  If you are not familiar with this I will explain what I mean.  A compiler has no way of knowing the limits, scope , or exception of external data or triggers.  Therefor a compiler of any caliber has to make code for every combination.  Because you know scope, limits and exceptions you can derive much faster math processes through derivation and proofs. Depending on core support will determine your options.  Many uC have an ALU of some sort.  For example on the chip I am working with now only integer math I need to avoid is divide and rotate n, all the others are single cycle within the ALU limits.  Through this process on a dynamic DSS project we gained a 1,500% speed boost from the fastest compiler selected math.  Of course you milage will vary depending on the math required, and the methods you know. 

Or liquid cool your processor and over clock it enough to get the job done.  .  Most people do the easy thing and just throw speed at the problem, then say it can't be done when there isn't a faster chip.  If more speed is your decision I for one won't challenge it, it's you project, I am only offering my solution.