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!
PIC24FV32KA304 maybe.Microchip give their products such catchy names. I'm sure there's some logic to it.
Eeprom can be written millions of times,
Quotetwice 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.
As to eeprom, Freescale, NXP and TI offer many such chips. Unfortunately, those happen to the high-end vendors too.
PIC24FV32KA304 maybe.
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).
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.
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.
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.
there's a reason why there's a market for commercial development tools even with four figure price tags.
QuoteOn 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.
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.
QuoteOn 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.
QuoteOn 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.
Quotethere'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.
it doesn't matter where you do the math.
problems downloading code to my target board using CoIDE
"I know what I'm doing" are the most famous last words in the history of the world.
doesn't help.
In this case I know what the nature of the input signal is like and where the time critical paths are
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?
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.
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.
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.
But then again most microcontrollers support nested interrupts.
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.QuoteYou 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.Quote from: nctnicoA 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.Quote from: nctnicoBut 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
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.
Quote from: nctnicoA 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.Quote from: nctnicoBut 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.
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.