#avr Logs

Jul 16 2019

01:17 AM Maya-sama is now known as Miyu
04:11 AM Thrashbarg_ is now known as Thrashbarg
05:21 AM day__ is now known as day
05:33 AM day__ is now known as day
07:11 AM day__ is now known as day
07:24 AM N2TOH_ZZz: hello
07:24 AM N2TOH_ZZz is now known as N2TOH
07:27 AM cehteh: hi
07:29 AM N2TOH: has anyone written a virtual machine for the AVR ?
07:30 AM cehteh: as in simulator?
07:30 AM N2TOH: no
07:30 AM N2TOH: a virtual machine to run on the AVR chip itself
07:30 AM N2TOH: like the way you can run a VM on a PC
07:31 AM cehteh: thats ben done to boot linux
07:31 AM cehteh: but usually its pretty pointless excep for the fun factor
07:31 AM N2TOH: yes that was my inspiration, the "Worst Linux PC ever"
07:32 AM cehteh: unless you call small interpreters a vm already
07:32 AM polprog: well, anything that emulates a machine with registers and stuff could be called a VM
07:32 AM N2TOH: yes this is why I'm interestd in an AVR VM that runs unaltered AVR code
07:32 AM polprog: or stack
07:32 AM polprog: you mean AVR on AVR?
07:32 AM N2TOH: yes
07:32 AM polprog: hmm
07:33 AM polprog: never seen that, its not impossible though
07:33 AM cehteh: the later, i do frequently, but that are not turing machines but small special porpose interpreters
07:33 AM N2TOH: it permits one to sidestep the limitation of only running code from the internam flash
07:33 AM N2TOH: *internal flash
07:33 AM cehteh: http://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit
07:33 AM N2TOH: I find the prospect of runing code from an external storage device very interesting
07:34 AM polprog: well once you get linux running on an AVR, there is simavr
07:34 AM polprog: :P
07:34 AM N2TOH: yeah I know of that project it emulaes an ARM cpu
07:34 AM cehteh: its just waaaay to slow to be practical for any serious purpose
07:35 AM N2TOH: I was thinking of something simpler like porting AT&T system 5 unix
07:35 AM cehteh: have fun
07:35 AM polprog: thats nt feasible really
07:35 AM N2TOH: that originally ran on a DEC PDP11 with a tiny amount of RAM
07:35 AM polprog: maybe except for the very first unix that had no memory protection
07:36 AM cehteh: and strange addressing modes etc
07:36 AM N2TOH: uCLinux has the MMU gutted from it
07:36 AM polprog: yeah, that could be ran too
07:36 AM day__ is now known as day
07:36 AM polprog: look into Punix, its unix on a TI-92
07:37 AM N2TOH: is that the one that has the 68k cpu in it?
07:37 AM polprog: yeah
07:41 AM polprog: anyway if you were asking seriously, then one of the early unices is a good one to pick
07:41 AM Kliment: N2TOH: If you want to run code from elsewhere why not just copy it to flash and jump to it?
07:42 AM N2TOH: the time delay to flash the time is annoying
07:42 AM polprog: wasnt there forth for avrs ?
07:42 AM N2TOH: I think there is
07:43 AM N2TOH: my interest is in seeing if the AVR emulator can run on an AVR
07:44 AM Kliment: N2TOH: The problem is you need to dynamically remap registers
07:45 AM Kliment: N2TOH: because if you are emulating the same part, your emulator state needs to be somewhere
07:45 AM N2TOH: *nod nod*
07:46 AM Kliment: N2TOH: So you'd have the virtual registers in memory, and then you need to, for each instruction, load the state, run the instruction, and write the state back
07:46 AM N2TOH: well we have 32 registers + the GPIO registers
07:46 AM Kliment: N2TOH: And then fix the PC so the program doesn't escape the emulator
07:46 AM cehteh: since the avr instructionsei is simple and relatively orthogonal you could just port an avr similator directly
07:46 AM N2TOH: I also plan to connecy external SRAM
07:47 AM cehteh: but yoi need some kinds of external memory for sure
07:47 AM cehteh: and it will run insanely slow
07:47 AM Kliment: I think 30-40x slowdown is to be expected, if it's an extremely efficient implementation
07:48 AM cehteh: my bets are rather on the 300x - 400x side
07:48 AM Kliment: Of course you could consider another architecture where you can execute code from any memory region
07:48 AM N2TOH: the 68008?
07:49 AM cehteh: because you are still bound on the avr's limitations, and have to emulate lots of things
07:50 AM Kliment: N2TOH: I'd go for arm m-series myself
07:50 AM cehteh: i'd go for risc-v
07:51 AM N2TOH: another question I have is of finding a method to execute code from a source other than the FLASH
07:51 AM cehteh: impossible
07:51 AM Kliment: Impossible on split-addressing archs
07:51 AM Kliment: Like PIC and AVR
07:51 AM cehteh: unless you write some emulator, which needs to reside in flash
07:52 AM Kliment: But most parts support self-programming so you can always write code to flash and jump to it
07:52 AM N2TOH: or repachage the chip to expose the other bus...
07:52 AM cehteh: do these -0 ab -1 series map memory together?
07:53 AM cehteh: still i presume only on the data bus, not instruction bus
07:53 AM Kliment: It's the same architecture as the xmega, cehteh
07:53 AM N2TOH: I know there is a way to store program data in flash
07:53 AM Kliment: So split memory
07:53 AM cehteh: yes but i know eeprom is mapped for reading
07:53 AM Kliment: cehteh: oh, it's all memory-mapped
07:54 AM cehteh: i dont say it becomes possible there
07:54 AM Kliment: cehteh: but you still can't execute it
07:54 AM cehteh: yes because its mapped on the data bus side
07:54 AM cehteh: so no way
07:54 AM Kliment: N2TOH: I'm actually writing something along those lines - a firmware update bootloader
07:55 AM Kliment: N2TOH: So the main application writes a new application image to flash, and an update routine
07:55 AM Kliment: N2TOH: And then jumps to the update routine, which overwrites the main application and jumps to it
07:55 AM N2TOH: that basically what the Arduino stuff is
07:55 AM Kliment: N2TOH: No, the arduino stuff is a standalone bootloader
07:56 AM Kliment: N2TOH: I'm talking about doing this while the application is still running
07:57 AM N2TOH: interesting
07:57 AM Kliment: N2TOH: So you have an application with a communication interface, and you can send it a new firmware image through that interface, it gets written to an unused area of flash
07:58 AM Kliment: N2TOH: Then you send it some code it needs to execute, which gets written to yet another area, and jumped to
07:58 AM Kliment: N2TOH: This way you can do integrity checks on the new image before overwriting it
07:58 AM cehteh: how about wasting your time on something practical :P
07:58 AM Kliment: cehteh: This is for a customer project
07:58 AM Kliment: cehteh: I've implemented a similar thing on PIC18 before
07:59 AM cehteh: i meant N2TOH
07:59 AM N2TOH: practical would be a 2560 on a 16 bit ISA board for industrial use
08:34 AM nohit: Kliment: you really should join #avrs , antto there is an expert on bootloaders
08:34 AM nohit: and N2TOH too
09:08 AM Kliment: nohit: I'm somewhat of a bootloader expert myself by now I guess
09:08 AM nohit: oh
09:08 AM nohit: cool
09:27 AM Kliment: nohit: Yeah, I've implemented bootloaders on quite a few architectures :)
09:28 AM nohit: nice
09:29 AM Kliment: nohit: PIC, AVR, several varieties of ARM, including one weird fpga+dsp+arm thing where we also needed to remote-upgrade the FPGA fabric
09:29 AM nohit: cool
09:30 AM Kliment: In this case, we have a communication module serial-attached to an at90usb1286, and we want to not break the default usb-only bootloader
09:31 AM Kliment: So the application is actually calling into the stock bootloader functions to modify flash, because they decided that only code running from the bootloader area can execute writes
09:32 AM Kliment: Of course the stock bootloader is closed and read-protected :)
09:32 AM Kliment: funt imes
09:32 AM Kliment: fun times*
09:34 AM nohit: :D
09:35 AM nohit: fun times is what makes a good engineer
09:42 AM Kliment: I've actually got most of it figured out
09:42 AM Kliment: Just need to design a protocol for the data transfer
09:42 AM Kliment: The writing to flash and copying data from page to page and jumping to a freshly written routine works
09:45 AM skz81: <N2TOH> I also plan to connecy external SRAM >>> https://skz81.wordpress.com/2016/07/07/playing-with-an-old-sram/
09:46 AM skz81: Just a quick & dirty fun project :]
10:27 AM rue_mohr: are you writing a bootloader?>
10:30 AM Kliment: rue_mohr: I am
10:30 AM skz81: rue_mohr, who are you asking to ?
10:30 AM skz81: nevermind
10:32 AM rue_mohr: why?
10:32 AM rue_mohr: there are ... so many...?
10:34 AM Kliment: rue_mohr: see above
10:35 AM Kliment: rue_mohr: I need application integration, and it needs to not break the stock bootloader on the device
04:22 PM markweston: hello
04:24 PM cehteh: hi
04:25 PM cehteh: markweston: better stay withj
04:25 PM cehteh: within c as much as possible
04:25 PM cehteh: learn how to usew the chip pheripirals
04:29 PM nohit: hi
05:17 PM markweston: so my arduino nano has 4 LEDs on it: RX, TX, POW, L. As I understand I cannot control POW. I want to light up the rest of them. I set all the pins to output (DDRB=0xFF;DDRC=0xFF;DDRD=0xFF;) and then turn them all on (PORTB=0xFF;PORTC=0xFF;PORTD=0xFF) but only the L LED lights up, even though to my understanding RX and TX should too because they're basically D0 and D1. What's wrong?
05:24 PM polprog: what gpio pins are they on? a peripheral could be active that overrides PORTx stuff. they can also be low or highs side driven
05:42 PM cehteh: better binnect some leds to free ports for playin
05:43 PM cehteh: leave the serial port for bootloader control and debugging
05:43 PM cehteh: err gone
06:09 PM LeoNerd: markweston: TX and RX are active-low; you'll need to set those pins to low to make the LED light
06:26 PM Jan-: hihi avr people
06:27 PM Jan-: on the mega328, I need to stop a pin change interrupt firing based on potential stored past events when I enable it with PCMSK1 |= (1<<PCINT9)
06:27 PM Jan-: presumably I need to zero a flags register somewhere
06:27 PM Jan-: but it's sort of hard to google as the results are swamped with general pin change interrupt tutorials, so any pointers?
06:28 PM LeoNerd: I don't know if there are flags for individual pins are there? Just the bank as a whole
06:28 PM Jan-: I guess the question may be "what's the appropriate interrupt flag register called"
06:28 PM Jan-: yeah it'll be per bank
06:28 PM Jan-: so the number 1 bank
06:29 PM LeoNerd: PCIFR
06:29 PM Jan-: tankies
06:30 PM LeoNerd: I've mostly been using the new AVR 1-series chips lately, so I had to look that up
06:30 PM Jan-: I've not come across those
06:30 PM Jan-: what are they like
06:31 PM LeoNerd: Nice :)
06:31 PM Jan-: I might be running this avr out of grunt
06:31 PM LeoNerd: A couple of minor downward steps as compared the older chips, but overall very much improvement
06:31 PM Jan-: it is small and plucky but it is not exactly hench
06:31 PM LeoNerd: I have a list of notes, I'm gonna turn it into a blog post soon
06:31 PM Jan-: and I would rather not go to stm32
06:32 PM * Jan- is a bit scared of stm32
06:32 PM * Jan- genuflects the sign of the AVR logo
06:49 PM nohit: hi Jan-
06:50 PM nohit: dont be scared of stm32
06:51 PM nohit: the tools are great imo
06:53 PM * Jan- hides from stm32 behind the sofa
09:22 PM rue_bed2: its like going from BASIC to C
09:22 PM rue_bed2: there is more overhead, but lots more you can do
09:23 PM salcedo: using ST HAL is not much different than arduino
09:24 PM salcedo: stm32cubemx -> Makefile -> edit Src/main.c
09:24 PM rue_bed2: ugh, hal
09:24 PM salcedo: yeah a lot of folks rip on hal
09:24 PM salcedo: i'm so noob at stm32 right now, it's all i know.
09:24 PM rue_bed2: hal is bloatware
09:25 PM rue_bed2: I'm going it from opencm3
09:25 PM salcedo: it did allow me to quickly get into the swing of things thoug
09:26 PM Jan-: why does this only work very intermittently: if(UCSR0A & (1<<RXC0)){...}
09:26 PM Jan-: I'm polling rapidly in a busy loop
09:27 PM Jan-: expecting it to fire every time I send a serial character
09:27 PM Jan-: but it only does very infrequently
09:45 PM ephemer0l is now known as GeneralDiscourse
11:26 PM day__ is now known as day