#avr Logs

Nov 19 2020

01:38 AM rue_bed: TyrMactire, did you get the answer you were looking for?
01:44 AM rue_bed: too many people would use an ARM to flash an led
01:44 AM rue_bed: if a tiny13 has to code space, I say go for it
05:26 AM Sjors: Hi all!
05:27 AM Sjors: I read that on AVRs before 1-series, you could access the contents of registers through data space access
05:27 AM Sjors: e.g.
05:27 AM Sjors: ldi r20, 0x55
05:27 AM Sjors: ldi YL, 20
05:27 AM Sjors: ldi YH, 0
05:27 AM Sjors: ld r24, y
05:28 AM Sjors: r24 would now contain "0x55" as Y points to address 20, which is r20, and r20 contains 0x55
05:28 AM Sjors: however, when I try this on my attiny1614 (1-series), r24 contains 0 after this
05:29 AM Sjors: looking at the datasheet, it seems only I/O registers are mapped into the data space, not the general purpose registers
05:29 AM Sjors: but I'm not really sure whether I'm reading that correctly, and also not 100% sure about the difference between general purpose registers and I/O registers
05:30 AM Sjors: so, blanket question: is it still possible to read general purpose registers, such as r20, through loading from the pointer registers XYZ?
05:30 AM Sjors: if so, could someone perhaps give a small example that shows how it should work, so I can continue from there?
06:03 AM nohit: are you sure loading X/Y/Z with a register is/has ever been valid ?
06:04 AM nohit: its been a while since i studied these things
06:10 AM nohit: well if they are memory mapped then i guess there's no problem with that
07:40 AM Sjors: nohit: yeah supposedly this assembly code I found works on older AVRs, but not the one I have
07:41 AM Sjors: nohit: I checked the avr-gcc header files and they confirm what I read in the datasheet of the attiny1614 I have: VPORTA is mapped at 0x0000, VPORTB at 0x0004, VPORTC at 0x0008 and then nothing until I-don't-remember-what is mapped at 0x0050
07:41 AM Sjors: so no mapping of general purpose registers anymore
07:41 AM Sjors: luckily, the code I found wasn't hard to modify: it just used loading register values from Y as a tiny optimization
07:42 AM Sjors: elsewhere, the same instructions are called where Y actually does point to a buffer in sram
07:42 AM Sjors: so I just allocated a single byte in sram, pointed Y at it, copied the register to *Y and called into the same code
07:43 AM Sjors: now, Y points at that byte instead of at that register, but it has the same value, so everything works out
07:43 AM Sjors: too bad you can't directly address registers anymore. I quite liked that feature when I first read about it
07:43 AM nohit: okay good to know
08:04 AM TyrMactire: rue_bed2, uh not really. hehe. basically i'm curious, when working so close to the hawrdware.... does it make sense add the extra logic to check if the value changed is necessary or if i should just write the same value to the Timer register every second and not bother checking...
08:04 AM TyrMactire: https://github.com/tyrm/stack-k3s/blob/develop/fan-control-avr/main.c#L44
08:06 AM TyrMactire: it's not really specific to the tiny13
08:51 AM rue_mohr: same value?
08:51 AM rue_mohr: if its the same value, you only need to write it once...
08:53 AM TyrMactire: yeah, i think i'm just trying to overoptimize my code for smallness
08:53 AM rue_mohr: you can just repeatedly write values, the timer is buffered and will ignore updates that dont apply
08:54 AM rue_mohr: and, its got more room than you think
08:54 AM rue_mohr: in C, you can do a lot in 1k
08:54 AM TyrMactire: yeah, this is also my first forte into C so it's all pretty new, thanks for the info :)
08:55 AM rue_mohr: does you compiler setup show you how much space you used?
08:56 AM TyrMactire: yes 492 bytes
09:10 AM rue_mohr: what else do you want to do?
09:10 AM rue_mohr: initialization is a big chunk
09:11 AM rue_mohr: just dont throw in any floating point and it should be fine
09:11 AM TyrMactire: oh nothing. that's the whole program. it's basically just pwm controlled by a 3-bit parallel output
09:12 AM TyrMactire: it's going on a raspberry pi hat because the pi's pwm is SUPER unreliable
09:12 AM rue_mohr: oh yea your fine
09:12 AM rue_mohr: nobody cares how much space is left over :)
09:13 AM rue_mohr: where does the 3 bits come from?
09:14 AM TyrMactire: the pi's GPIO, would have gone with something more serial-y but the tiny13 didn't support it, and i really wanted an 8 pin chip
09:14 AM rue_mohr: The pwm doesn't take any overhead, so you can do software serial
09:15 AM TyrMactire: interesting, i'll have to look into that
09:15 AM TyrMactire: so far i've read the make AVR book
09:15 AM rue_mohr: I have some code for asynchronous serial, writing something up for synchronous would be easy
09:15 AM rue_mohr: is the interrupt pin still free?
09:16 AM TyrMactire: pcint1 is free
09:16 AM rue_mohr: ok
09:17 AM rue_mohr: so, target writing a rising edge interrupt handler
09:17 AM rue_mohr: when you see the rising edge, shift the data bit (choose a pin) into a register
09:17 AM rue_mohr: after 8, use the value to set the pwm
09:17 AM TyrMactire: oh yeah, i could make a shift register in there....
09:17 AM rue_mohr: use a pin change interrupt to reset the clock interrupt for synchronization
09:18 AM rue_mohr: give it a go
09:22 AM TyrMactire: will do, thanks :)
09:22 AM rue_mohr: ISR(INT0_vect) {}
09:22 AM rue_mohr: if you need to, you can use the ADC as a timer, every conversion is a fixed number of cycles
09:23 AM rue_mohr: and you can configure the clock source for it to be divided like a timer
09:24 AM TyrMactire: neat
02:17 PM TyrMactire: heh hey rue_mohr random question. what do i make my main loop do while waiting for interrupts? heh
02:18 PM cehteh: TyrMactire: nothing, ideally you go into sleep_idle
02:21 PM TyrMactire: will have to look into how to do that, the book i read didn't cover sleeps
07:17 PM rue_mohr: 10 goto 10
07:17 PM rue_mohr: er, I mean
07:17 PM rue_mohr: while(1);
11:27 PM day_ is now known as day