#avr Logs

Jun 03 2020

11:54 AM d3bian: Hello, could anyone link me to resources regarding extending an avr chip's (like atmega8) application flash storage? Or is it not possible?
12:02 PM LeoNerd: A few AVR chips allow external RAM for data storage, but none I'm aware of allow anything external for application program
12:02 PM cehteh: you can add external ram/rom/flash of some sorts, but you cant execute machine code. thus when you can manage to externalize only data then it might be ok
12:02 PM cehteh: yeah havard arch limit
12:03 PM cehteh: you could load some small interpreter, a forth or so and then drive that with programs you load externally, but thats prolly a bit much to do for little gains
12:04 PM cehteh: there are bigger+cheap+faster mcu anyway, when AVR's dont do the job then you shouldnt use them
12:05 PM nohit: harvard arch limit ?
12:06 PM cehteh: well the way its implemented on the AVR's
12:07 PM d3bian: LeoNerd: wouldn't it be possible to load executable code from eeprom f.e. into external ram and execute it from ram
12:07 PM LeoNerd: No
12:07 PM nohit: not with AVRs
12:07 PM cehteh: you dont have and external bus for the program memory
12:08 PM cehteh: you cant execute code from ram either
12:08 PM d3bian: i see, if avr were a von neumann arch it should be possible right? atleast with external ram support
12:08 PM cehteh: so advantage is that the code is etched in stone ,, cant be changed ... disadvantage is that the code is etched in stone ... :)
12:09 PM cehteh: some havard implementations have external busses for the prgramm memory as well, sometimes just muxed with a single pin
12:10 PM cehteh: m68k was that way iirc
12:10 PM cehteh: what exactly do you want to do?
12:10 PM cehteh: is a tiny DSL interpreter feasible? to do you really need to load machine code?
12:11 PM cehteh: the former is pretty doable, i almost always add some kind of commandline interface that kindof does that, the later is not possible
12:11 PM d3bian: no I was just wondering whether it was possible, I've ordered a few atmega chips with 8K flash and thought it would be nice if I could extend it somehow
12:12 PM cehteh: nope :D
12:12 PM d3bian: I'm planning on doing an interpreter tho
12:12 PM d3bian: I'm currently working on an aot-translator that generates C from Java
12:12 PM d3bian: but it's focused on esp8266
12:12 PM d3bian: which has 1MB > flash
12:13 PM d3bian: might work on an atmega2560 but it's not a goal atm
12:13 PM cehteh: yeah AVR's are proly the lower end of mcu's in use
12:13 PM cehteh: (still not outdated, but they have their limits)
12:14 PM d3bian: I'm planning on making something similar to this though, https://dmitry.gr/?r=05.Projects&proj=12.%20uJ%20-%20a%20micro%20JVM
12:14 PM cehteh: well microchip is working hard to annoy developers :D
12:14 PM d3bian: once I've finished my aot project
12:14 PM d3bian: a fully off-disk jvm
12:14 PM cehteh: why would one want java on a µC :D
12:14 PM d3bian: then I can run program code from sd cards
12:14 PM * cehteh barfs
12:14 PM d3bian: just for fun
12:15 PM cehteh: doesnt sound like fun to me :)
12:15 PM d3bian: that guy is a genius tho, he got linux working on an 8-bit avr chip
12:15 PM d3bian: in another project
12:15 PM d3bian: wrote a software mmu
12:15 PM cehteh: yeah i know
12:15 PM d3bian: java might not that interesting to use on a uC but something like kotlin would be
12:15 PM d3bian: or other jvm languages
12:16 PM d3bian: especially using a dsl from kotlin
12:16 PM d3bian: scala is not possible i think due to it's heavily bloated runtime
12:16 PM cehteh: i ever wanted to try something forth alike, not a full forth, just a subset to extend programs by some custom logic and math formulas
12:17 PM cehteh: java will suck because of its rather unusual memory model
12:17 PM d3bian: you could probably find an existing forth interpreter and modify it
12:17 PM cehteh: anything doing dynamic allocation is already a nogo .. but then add java and its memory model and gc and it becomes royal shit
12:18 PM d3bian: depends on the gc algo you use and what ur project requirements are
12:18 PM d3bian: i've implemented a gc for another jvm and it worked fine
12:18 PM d3bian: on the esp8266
12:18 PM d3bian: gc pauses didn't exceed 1ms
12:18 PM d3bian: but i had no realtime requirements, was just a temperature logger
12:19 PM d3bian: even with realtime its do-able, there are papers on it
12:19 PM d3bian: you cant use mark-sweep gc tho, most use reference counting
12:19 PM d3bian: which has its overhead
12:20 PM cehteh: in theory refcounting on avr shouldnt be so bad
12:20 PM cehteh: because avr's are already bad enoguh .. haha :)
12:20 PM d3bian: it was total crap on the esp8266, cause it has no cpu cache
12:21 PM cehteh: no caches, no cache coherency, :)
12:22 PM cehteh: on modern multicore you need to sycnronize accesses over cores, which is pretty expensive when data is shared (which should be avoided anyway)
12:22 PM d3bian: how's caching on most avr chips? atmega8, atmega328p
12:22 PM cehteh: none
12:22 PM cehteh: there is a kindof 2 stage pipleine for code and nothign else
12:23 PM cehteh: back to predictable execution timing :)
12:24 PM d3bian: any idea how the external flash sits with other mcus? like arm cortex m0
12:24 PM cehteh: uhm you need to read datasheets, iirc there are different implementations
12:24 PM cehteh: rue_mohr may know more
12:25 PM cehteh: anyway these are v Neuman and often you load code into ram instead executing in place in flash because ram is faster
12:26 PM cehteh: (but not always because... ahh ..)
12:26 PM cehteh: as far i remeber these map everything into the address space, except if its some flash thats over i2c or spi or so
12:30 PM d3bian: esp8266 stores the whole program on an external flash chip, it has 32kB of memory reserved as a cache for the program code
01:01 PM twnqx: cehteh: many arms have execute in place even for SPI flash
01:05 PM cehteh: twnqx: yes, but depending on implementation and how the flash is connected it may be faster or slower
01:05 PM twnqx: obviously
01:05 PM cehteh: faster because it can operate on both busses in parallel, slower because flash is slower than ram
01:05 PM twnqx: even 52mhz qspi is below 20MB/s
01:06 PM cehteh: but when you have to shovel data and code over the same bus then there is some performance impact as well
01:06 PM cehteh: boils down to quite complex details
01:06 PM twnqx: if your cpu core runs at hundreds of MHz, feeding it instructions at this rate will be... well
02:13 PM rue_mohr: I might
02:13 PM rue_mohr: about what?
02:18 PM vishwin60 is now known as vishwin
11:42 PM rue_mohr: ruemohr.org/~ircjunk/projects/resistorbox/
11:42 PM rue_mohr: dropping links cause of lack of channel life :)
11:54 PM day_ is now known as day