I will have a atmega2560 acting as a DMX encoder/decoder connected to a Onion omega2 (a small Linux computer). Is there any cons except longer startup time with programming the atmega every time the device starts up? This would make updating the firmware on the atmega really easy as I simply could replace the image and reboot
-
5From the front page of the datasheet: Write/Erase Cycles:10,000 Flash. So you should expect it to stop working some time after its booted for the 10,000th time. – brhans Jan 16 '17 at 19:19
-
I feel stupid now... I thought i had checked the datasheet, but must have missed it somehow. Thanks for pointing it out to me – Pownyan Jan 16 '17 at 19:21
-
I don't know ATMegas very well, but it's also possible that you could use them with external memory instead of the integrated flash; if that is the case, your Omega2 might act as that memory. But that sounds like it's just an overly complicated scheme. – Marcus Müller Jan 16 '17 at 19:33
-
that could maybe be done, but it sounds like to much work for the gain. I'll just write code for the Omega2 to update it when needed instead of all the time – Pownyan Jan 16 '17 at 19:35
-
@brhans Of course, that metric is a bound determined by an initial small sampling of which not all cells need be tested (often only a few blocks at maximum cycles), so while it's likely it'll reach 10k on all, it's not truly fully guaranteed by the process and most would suggest data protection schemes if you know you'll reach beyond half the manufacturer stated cycle count, if even possible. – Asmyldof Jan 16 '17 at 19:41
-
2@Pownyan it's, by the way, not that rare that one loads software across some kind of link from a different device into the microcontroller's RAM and then jumps into that. Fun fact: you could use an ARM MPU that has SWD, "marionette" that from your Orion2 to write the software into RAM and then point execution to it through that debugging interface, and then let it run. In fact, you can also simply marionette all IO that way, typically (and use it as a cheap, versatile IO extender instead of an independent MCU). PoC||GTFO 0x10 has an article on p. 66. – Marcus Müller Jan 16 '17 at 19:53
-
@MarcusMüller the reason i want a independent MCU is so i can run 4 serial connections at 250k baud in real time, which makes the atmega2560 quite handy as it has enough RAM for all of the buffers I need. I definitely see the point of having only a marionette for the io for other use cases, but i can't trust the linux scheduler to be fast and consistent enough – Pownyan Jan 16 '17 at 20:27
-
@Pownyan 4x 250kBaud really doesn't sound that scary for the linux kernel, to be honest. – Marcus Müller Jan 16 '17 at 20:43
-
1@MarcusMüller: The ATMega, and most other small microcontrollers, cannot run programs from RAM. The RAM and Flash memories occupy separate address spaces, and instructions can only be fetched from Flash. – Peter Bennett Jan 16 '17 at 21:21
-
@PeterBennett Ah, I see, ATMega is a (mod.) Harvard arch; well, the smallest (and most probably, most prolific) Cortex-M0 microcontrollers (which typically come in much cheaper than ATMegas) are in fact Von Neumann-architectures (Cortex-M3/M4/M7, however, are Harvard architectures, as far as I know. I don't know why, however. It doesn't feel "right" in terms of memory layout) – Marcus Müller Jan 16 '17 at 22:04
-
@MarcusMüller it's not scary in general if you just want to read sequentially , but it's harder when you reliably need to detect short breaks (88us) in real time (tried it and had problems with the scheduler not cooperating) – Pownyan Jan 16 '17 at 22:06
-
@Pownyan I can see that; without hardware support by your Orions' CPU (which is that, by the way?) you'll have a hard time.If you really only need 4 UARTs w. DMA to RAM +some watchdog logic, I don't think a 10€ ATMega w. 2KB RAM is the cheapest or easiest choice :) For example, ST has microprocessors with 5+ U(S)ARTs and this 32 kB RAM model sets you back only 6€. – Marcus Müller Jan 16 '17 at 22:20
-
@MarcusMüller here is a link to the Omega 2 https://www.kickstarter.com/projects/onion/omega2-5-iot-computer-with-wi-fi-powered-by-linux I'm aware that the atmega won't be the cheapest solution, but i have a few arduinos at home i can play around with while developing, and i managed to get all the code to it working in a afternoon. I will look into the STM32 processors, should be quite simple to swap them if i can make them do the same as i'm only communicating via UART. I really appreciate the tips! – Pownyan Jan 16 '17 at 22:28
-
@MarcusMüller. The ST MCU executes normally from Flash, although it can execute from Ram. The problem with Ram based code is you need some bootloader which is invariably in Flash to startup. So there seems nothing to be gained by using a processor that runs from Ram (unless their is a speed gain) when you still need a Flash bootloader to start it. – Jack Creasey Jan 17 '17 at 01:29
-
@JackCreasey only that the devices usually come with one built-in :) but your point, this not really being much help if you essentially got static firmware is still true. the vendor bootloader is often limited to doing things like writing the flash. Still, I know of applications where your µC contains "stock" firmware and ways to check for availability of externally loadable firmware, and chooses the latter if possible. Very handy for firmware updates in complex embedded systems in the field! – Marcus Müller Jan 17 '17 at 09:35
-
@MarcusMüller would i be able to use the STM32F100 discovery board (based on the STM32F100RB chip https://www.elfa.se/Web/Downloads/nu/al/STM32_discovery_eng_manual.pdf?mime=application%2Fpdf) to test code and then use the code on the STM32F100RD chip that has 5 U(S)ART (the f100rb chip only has 3)? – Pownyan Jan 17 '17 at 12:00
-
@Pownyan I really think this is a good question and an interesting project, so I'd say: this is worth asking in a separate, dedicated electronics.stackexchange.com question rather than discussing it in comments :) – Marcus Müller Jan 17 '17 at 12:34
2 Answers
Other than the time, the main drawback is that the program memory will eventually get worn out. Flash memory has a limited number of lifetimes writes and erases. Check the datasheet to see how many your device is specified for.
Some microcontrollers I've used have only been specified for 1000 program memory writes. That's plenty for initial production and occasional field updates of the firmware.
However, that limit isn't hard to hit if one of these 1000 writes gets used up every time the device is turned on. If it happens once a day, then the program memory is only good for 2 years 9 months. Twice a day results in 1 year 4½ months. Once every hour yields 42 days operational life.
- 172,781
- 17
- 234
- 402
- 313,258
- 36
- 434
- 925
-
I think it's very common to just program a bootloader into your microcontroller and "ask" for proper firmware over some link (e.g. SPI, I²C) from an external device/memory/controller. The bootloader just loads that firmware into a RAM region and jumps into it. I think this is one for Olin: You can "abuse" SWD-capable ARM-based MPUs very easily as "marionettes", either by doing the bootloading through the SWD interface,or by completely controlling the (typically memory-mapped)peripherals. Fun article on doing exactly that:PoC||GTFO p.66f – Marcus Müller Jan 16 '17 at 19:58
-
1@MarcusMüller having a device load a full program into RAM may not be an option - flash memory is more abundant than RAM in most of these small controllers. Their architecture may not allow running programs from RAM either.. – KyranF Jan 16 '17 at 20:14
-
1@KyranF as said in the comments to the question, I'm not versed with ATMegas. ARMs tend to be able to do anything from anywhere in the memory space, which combines RAM, ROM, Flash, and peripherals. – Marcus Müller Jan 16 '17 at 20:42
-
@Marcus: I don't know what "SWD" is. In any case, lots of micros don't have any RAM that instructions can be executed from. For example, of all the PICs only some of the PIC 32 have this capability. I am not familiar with the micro the OP is asking about. – Olin Lathrop Jan 16 '17 at 22:22
-
@OlinLathrop SWD is "Single Wire Debug". Think of it as a slim JTAG for ARM cores. I just looked OP's MCU up - the ATMega is a harvard arch, so yeah, bad luck. – Marcus Müller Jan 16 '17 at 22:30
It's not a good idea to flash a new image every time your board boots up. The program memory will eventually get worn out.
Flash memory has a limited number of lifetimes writes and erases. You can find numbers in datasheet of your controller.
I will suggest you to write a bootloader for your board. Every time your board boots up, boot loader should try to communicate with your master board (your Linux board). The master board should present hash or digest of image or firmware it has. The boot loader should have precalculated digest of the firmware it has in it's flash. By comparing the digest, it can decide upon whether to initiate the flashing procedure. After that, it can jump to application.
- 952
- 1
- 12
- 37