[En-Nut-Discussion] Killing Processes and malloc

[Moritz Struebe]

Alain M. schrieb:
> Moritz Struebe escreveu:
>   
>> I'm taking care of the "if anything changes" problem doing some 
>> crc32-checks.
>>     
>
> The real problem is not "knowing" if anything changes, but changing the 
> base parte it it does...
>   

The "base/kernel" knows it's crc. Baically I link the Kernel with the 
crc32 set 0. Then I calculate the crc32 and pass the crc to the linker 
via symbols. A bit messy but works fine. If the kernel changes, all 
installed applications are invalid, of course (they know the kernel crc 
they were built for) and you have to reinstall them. But how often do 
you update you nut/OS libs?

>   
>> I'm not sure about the incremental linking, but it's probably not going 
>> to work. (The linked stuff must not be touched, the data section must 
>> not be changed (the memory is part of the heap and may contain data), etc).
>>     
>
> The description matches very closely your requirements, but changing 
> without restarting is the big problem.
>   
Adding applications is working nicely. The next step is replacing the 
kernel, but this shouldn't be too big a deal either. If you replace the 
kernel you do have to reboot though. But at least you can use a big lib 
(like BT with multihop) to receive the new Kernel. (After writing the 
new Kernel to flash you reboot, the bootloader does CRC32 checking on 
the new Kernel and if it is ok it replaces the old one. If anything goes 
wrong it will notice that on the next boot and will continue to 
overwrite the old Kernel.)

>   
>> The multi-boot approach is interesting but isn't reasonable on an AVR.
>>     
>
> Could you briefly explain why? I imagined that specialy the AVR had good 
> support for that...
>   
You'll run into trouble with the interrupt vectors. These live at 0x00 
or if you wish in the bootloader section. Therefore you either need 
quite a bit of abstraction, using static interrupt handlers which then 
jump to some address saved in sram or overwrite the interrupt vectors. 
Both solutions are full of pitfalls. (I thought of this solution to 
avoid to move whole Kernel from Flash to Flash but then discarded it.)
BTW: Flashing the bootloader section via the bootloader is a bad idea. 
There is so much that can go wrong and then you end up with a corrupted 
bootloader.
Also multiboot isn't what I'm looking for. I wan't to add and remove 
applications during runtime. Therefore the other threads keep on 
running. The only real disadvantage is that I have to turn off the 
interrupts during programming. But there is no way to avoid that.

Recovering data from SRAM after a reboot is another topic I'm working 
on. ;-)

Cheers
Morty