Freeware ARM toolchains may be far ahead of MPLAB turd, but still I consider many freeware ARM toolchains useless crap - due to mostly their crap debug support. And hell NO, I will not debug a 200MHz cortex M7 peripherals by manually counting bits into 8digit hex numbers, bcs the damn toolchain does not support SVD files fully.
For advanced debug, there comes those professional toolchains like Keil MDK ARM, IAR Workbench, maybe Atolic Truestudio,...
BTW, Keil is free up to 32kB of code, and STM32F0 (Cortex M0 line) should be completely without restrictions in Keil, as ST has already pre-payed the license for you.
EDIT: It is also for STM32L0 product line, here:
http://www2.keil.com/stmicroelectronics-stm32/mdk
Freeware ARM toolchains may be far ahead of MPLAB turd, but still I consider many freeware ARM toolchains useless crap - due to mostly their crap debug support. And hell NO, I will not debug a 200MHz cortex M7 peripherals by manually counting bits into 8digit hex numbers, bcs the damn toolchain does not support SVD files fully.
For advanced debug, there comes those professional toolchains like Keil MDK ARM, IAR Workbench, maybe Atolic Truestudio,...
BTW, Keil is free up to 32kB of code, and STM32F0 (Cortex M0 line) should be completely without restrictions in Keil, as ST has already pre-payed the license for you.
EDIT: It is also for STM32L0 product line, here: http://www2.keil.com/stmicroelectronics-stm32/mdk
Hi
Compared to the non-existant debug support in all the other free toolchains, ARM is doing fine in that respect. That said, yes, there are a *lot* of reasons to use Keil. Debug and profiling are two big ones. It's not cheap to get the full setup, but if you are doing this for a living, it's probably worth it. Less time spent completing the project and more time spent at the beach.....
Bob
BTW, Keil is free up to 32kB of code
which is pretty useless unless you're using cortex m0 instead of an 8 bit uC.
Keil or IAR should sell a decently priced license to non-commercial users, instead IAR offers you a whopping 10% discount
missing the point completely.
There is still the possibility to use some medication...
BTW, Keil is free up to 32kB of code
which is pretty useless unless you're using cortex m0 instead of an 8 bit uC.
Keil or IAR should sell a decently priced license to non-commercial users, instead IAR offers you a whopping 10% discount missing the point completely.
Hi
There are indeed work arounds for that limitation. They become a bit impractical once you go above about 256M of flash.
Bob
why don't you implement eeprom checksum change detection code? that might help you get less nervous while using eeprom
why don't you implement eeprom checksum change detection code? that might help you get less nervous while using eeprom
Hi
The thing I've run into doing that is the wear on the check sum bytes. Whenever a bit is changed in the block, the whole checksum for that block also gets re-done. You either do a check sum per "erase page" (with CRC to correct) and have a lot of space in check bits or you have a lot of wear on a central CRC location.
Bob
why don't you implement eeprom checksum change detection code? that might help you get less nervous while using eeprom
Hi
The thing I've run into doing that is the wear on the check sum bytes. Whenever a bit is changed in the block, the whole checksum for that block also gets re-done. You either do a check sum per "erase page" (with CRC to correct) and have a lot of space in check bits or you have a lot of wear on a central CRC location.
Bob
ignore the addresses that gets changed often or make them external, like battery backed up ram, or sd card or eeprom on zif slot
the idea is to check whether there is faliure in important addresses, if there is, output error
the idea is to check whether there is faliure in important addresses, if there is, output error
meaning the device is end of life, hence buy new, back to square one... it can be usefull for functional integrity but doesnt do anything with the device's longevity. wear levelling or other different technique may be used for longevity purpose. like a simpler method of a write counter, along with the real data. shift to next location for saving, when the counter is reached. i believe it has been mentioned earlier... both methods of integrity and longevity may be used if one is paranoia about the longevity or service life of a particular device.
but even without those contingency techniques, we may take an educated guess of how long a device will be in operational. say worst case write to eeprom (save user settings) will take place 10 times a day. so (100K / 10) = 10 Kdays before the device failed, thats (10K / 365) = 27 years, quite alot compared to most devices life, professional or unprofessional devices... and that assumed you constantly boot up and close down your device 10 times a day the whole 27 years including weekend. i believe 27 years or more can be a realistic figure. with wear levelling technique, we may extend that to say 10X? = 270 years, not something even the biggest company may put their bet on, considering cash flow cycle they need in order to survive...
If anyone wants to use/take a look at the code I just finished. Some of it has been tested extensively, others like structure.c are hot off the press and barely tested and probably still up for more optimization. The only rule is that you must call StructureLoad() to setup some pointers before calling StructureSave(), but then you can call StructureSave over and over again to keep updating.
This does not deal with a single variable in EEPROM being read or written, but a group of variables in a structure. It protects them with a crc16 and does wear leveling on them automatically. It also does mirroring so it has two structures to recover from if necessary.
Even if you don't want the structure load/save code, you will find AVR tiny/mega eeprom functions that wear each location minimally as well as i2c implementations that use the tiny/mega twi peripheral or i2c bitbang. Let me know if you have any questions or see any bugs.
Just for the young players:
With wear leveling you should read the datasheet a couple of times.
There are devices out there where if you write one byte location the whole page is updated, ergo the wearleveling should be done on a per page basis.
Just for the young players:
With wear leveling you should read the datasheet a couple of times.
There are devices out there where if you write one byte location the whole page is updated, ergo the wearleveling should be done on a per page basis.
This is good advice, the ST Micro eeprom's I like to use have a 4 byte "block" that has ECC protection, so if you change one byte, the entire 4 byte block has to be rewritten.
The 64K ones also have a 128 byte page write size so you can write 128 bytes during a single write cycle - my code above will handle that transparently. If you cross a page, it will stop the i2c transaction, wait for the write cycle, and then start a new i2c transaction in the new write page.