AVR Freaks

You know about the paged nature of the flash and the fact that any particular page cannot be erased more than 10,000 times during the life of the app don't you? Does the code flash STILL look like a good choice?

 

Most people would add an external memory device - often an SD/MMC card.

 

For small amounts of data the EEPROM is a better choice than code flash (bytes not pages and 100,000 cycle not 10,000 cycle life)

No. Only from the boot program.

 

Those are cool chips. Thanks for the tip!

Bear in mind the 10,000 cycle life of the AVR. So if you only plan to do this every few days or something then that should be fine. But if it's every time the AVR is powered on then it could start to eat into the life.

Serial Bootloader though its context isn't this context.

Not many computer language interpreters for AVR; might consider MicroPython, Zerynth Python, MaixPy Python, or C# though likely not on an XMEGA128A1U.

A team I was on did similar on a DEC PDP-11/34 with FORTRAN on RT-11 (16-bit address space, paged object code from "large" spinning platters of iron oxide on aluminum) (real-time control of Test & Measurement with an operator interface)

 

---

AN_8390 AVR2054: SerialBootloader User Guide (IIRC, its source code is in Microchip Gallery | Home)

KLBasic for the Atmel AVR devices

Atto_Basic_V2)_Home

PyMite - Python Wiki

GitHub - dwhall/p14p: (INACTIVE) Python-on-a-Chip (p14p) : a tiny Python 2.6 vm (PyMite) for 8-bit and larger microcontrollers

Python for the 8bit AVR mocrocontroller · Issue #3699 · micropython/micropython · GitHub

 

https://github.com/micropython/micropython/tree/master/ports/pic16bit (dsPIC33FJ256GP506)

PIC24 EPMP can address 16MB SRAM, MRAM, or F-RAM.

dsPIC33C was announced northern summer'18 but doesn't have EPMP; the single-core dsPIC33CK has PMP, IIRC 128KB, so might still be considered.

PIC24FJ1024GA610 - 16-Bit - Microcontrollers and Digital Signal Controllers

via MAPS - MCUs & MPUs page (in the Parallel Port pull-down menu select EPMP)

 

MicroPython - Python for microcontrollers

Zerynth Supported Devices

MaixPy (Python on one instance of RISC-V)

nanoframework – Making it easy to write code for embedded systems. (C#)

 

https://en.wikipedia.org/wiki/PDP-11_architecture#Memory_expansion

 

edit :

Ch is a C/C++ interpreter though on MPU (starts at the level of SAMA5, Linux or QNX)

Embedded and embedding Ch | System Requirements

 

Bear in mind the 10,000 cycle life of the AVR.

I was thinking more of an application that was effectively single use, so this would not necessarily be repeated all that frequently.

 

.. and not bootloading per se, but "self" programming.

 

We would never do this, we would just ugrade.  But for something already launched it might have been an option. Like deleting log files.

 

I am aware of being able to "poke" parameter values into a subroutine, this would also be destructive, but periodic displacement of the subroutine as a kind of primitive wear levellling technique springs to mind. Minding that we may writing a page, so maybe duplicate the routine written to and also update a vector every x000 updates?  Easier to have the parameter in a register, no?

 

I have an IP powerboard (IP9258) that destructively tests a location in eeprom every boot, it is not rebooted that often.

 

My 14yo daughter for a project used command line Arduino from a Rasberry Pi Zero W to reprogram a nano.  (I know, rather than just using the RPi). Scripted download from GitHub. 

 

There is a parking meter I use in Tuggeranong (!) that has 7 AVR mcus surrounding embedded windows (!). One is just for the coin tray. Each mcu has versioned firmware. It will still theoretically last 20+ years if any are flashed once a day.

 

 

No disrespect but LMGTFY --> https://en.wikipedia.org/wiki/Self-modifying_code

 

See also --> http://ww1.microchip.com/downloads/en/Appnotes/Atmel-2575-C-Functions-for-Reading-and-Writing-to-Flash-Memory_ApplicationNote_AVR106.pdf

 

My question is:

 

Suitably located and padded (in a similar manner to incremental linking), could we not "swap out" entire subroutines that have served a purpose, for others, now required?

 

In other words overlay new code over old, with running application code.

This is why you would leave a gap. Hence my reference to incremental linking, which left gaps for changes in object modules in a statically linked product.

Although it follows that if you contracted enough of these gaps you would probably have room for conditionally executed code anyway.

 

I imagine we would only resort to this if there was a hardware constraint, such as re-engineering an existing device ala OpenWRT. plus our code would be displacing any real bootloader.