#avr Logs

Nov 11 2021

12:15 AM rue_mohr: do you have to clear that one?
02:47 AM baltazar: rue_mohr: no, I'm just wondering where the race condition might be occuring
02:48 AM baltazar: all of my ISRs are blocking, so no other interrupt should happen while incrementing `timer0_ovf` or when reading out its value
02:50 AM baltazar: so the only thing I can imagine happening is that the OVF bit is already cleared but the reading interrupt gets run before the incrementing interrupt, or the incrementing interrupt finished but the OVF bit isn't cleared yet.
03:02 AM baltazar: now that I think about it, for the second case I could try manually clearing the OVF bit in the incrementing interrupt, so this problem can't happen
03:08 AM baltazar: well, the datasheet doesn't say too much
03:08 AM baltazar: > The bit TOV0 is set when an overflow occurs in Timer/Counter0. TOV0 is cleared by hardware when executing the corresponding interrupt handling vector. Alternatively, TOV0 is cleared by writing a logic one to the flag.
03:08 AM baltazar: either way, manually clearing it doesn't seem to help
05:08 AM LOVV is now known as lemmings
07:24 AM splud is now known as n2
07:24 AM n2 is now known as splud
07:57 AM nohit_ is now known as nohit
01:23 PM rue_mohr: did you post the code?
01:23 PM rue_mohr: dont know if I have a chance to go over code right now
01:23 PM rue_mohr: your doing avr video?
01:25 PM baltazar: rue_mohr: I'm trying to use an ultrasonic distance sensor
01:25 PM baltazar: and no, I didn't post any code yet
01:25 PM rue_mohr: oh
01:25 PM rue_mohr: does it demodulate for you?
01:29 PM baltazar: all it does is pulls a pin high after sending a pulse of sound, then pulls it down once it arrives back. all I have to do is measure the time it takes for the pin to do this cycle
01:34 PM rue_mohr: kinda
01:34 PM rue_mohr: does it do the blanking?
01:34 PM baltazar: not sure what you mean
01:35 PM rue_mohr: looking for a diagram
01:35 PM rue_mohr: you need to ignore the return signal for a period of time
01:37 PM rue_mohr: heh there are no good diagrams on the internet
01:37 PM rue_mohr: great
01:37 PM baltazar: sure, there might be some other complications, but but I'm fairly certain this is a problem with my code. I mean it's always off by exactly 256, which is most certainly due to how my get_elapsed_ticks function works
01:37 PM rue_mohr: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSUcWrKEey_ZTto6ye-49kPUVnsbGjV7VFV6Q&usqp=CAU
01:37 PM rue_mohr: thats not so bad
01:38 PM rue_mohr: there they call it "dead band" it prevents you from picking up echos that are too early from local reflections
01:38 PM rue_mohr: or noise
01:38 PM rue_mohr: ah
01:38 PM rue_mohr: k
01:38 PM rue_mohr: is t0 16 bits?
01:39 PM rue_mohr: dont recall
01:39 PM baltazar: 32, probably overkill tho
01:39 PM rue_mohr: 32? what you running on?
01:39 PM baltazar: atmega328p?
01:39 PM rue_mohr: no
01:39 PM rue_mohr: its not 32 bit
01:39 PM rue_mohr: its 8 or 16
01:40 PM baltazar: > static volatile uint32_t timer0_ovf;
01:40 PM rue_mohr: thats not a hardware timer
01:40 PM baltazar: ah
01:40 PM baltazar: then it's 8 bits
01:40 PM baltazar: TCNT0
01:40 PM rue_mohr: thats 32, but its done in software
01:40 PM rue_mohr: must be counting overflows
01:40 PM rue_mohr: this isn't arduino code is it?
01:41 PM baltazar: yea sorry, I thought you meant the size of the variable I'm using
01:41 PM rue_mohr: like, its not from an arduino library...
01:41 PM baltazar: no
01:41 PM rue_mohr: ok, those are always horribly messed up
01:41 PM rue_mohr: I need a shower and breakfast
01:45 PM baltazar: aight
03:50 PM evidlo: should an external crystal still oscillate if the micro is set to use the internal clock?
03:52 PM qu1j0t3: normally yes?
03:52 PM qu1j0t3: unless you stopped powering it
03:52 PM rue_mohr: no
03:52 PM rue_mohr: the system is turned off
03:55 PM qu1j0t3: it's driven by the mcu?
03:55 PM qu1j0t3: i guess i'm old fashioned nm
04:07 PM evidlo: also I shorted RESET to VCC accidentally for a long time. is there a chance my chip is broken because of this?
04:08 PM evidlo: actually, it shouldn't be. I see people tie that high
04:20 PM Player2: Hello!
04:21 PM Player2: Anyone tried those new AVR DA series? Are those still programmable with avrdude?
04:23 PM LeoNerd: They're UPDI chips.
04:24 PM LeoNerd: avrdude *still* doesn't talk UPDI-over-UART
04:24 PM LeoNerd: I use my avr-updi program for those
04:25 PM LeoNerd: But yes, the DA chips are nice
04:26 PM Player2: I still play around with those 168PV, 328P and 1284P.
04:26 PM LeoNerd: Aaaaancient chips
04:26 PM Player2: Not really satisfied with the AVR Dragon actually...
04:26 PM qu1j0t3: <3 328P <3 team 328P rep'in
04:26 PM LeoNerd: The newer ones are much nicer in basically every way
04:26 PM Player2: So I'm using an old RPi as AVR ISP/JTAG programmer.
04:27 PM Player2: I don't have HVPP there sadly.
04:27 PM LeoNerd: That's fie
04:27 PM LeoNerd: *fine
04:27 PM LeoNerd: Any serial port and a 1k resistor or a diode, can easily become a UPDI programmer
04:27 PM LeoNerd: It's just regular serial
04:30 PM evidlo: It seems like the XTAL inputs are just sitting at VCC on this atmega32u4RC I'm using
04:30 PM evidlo: trying to use. haven't been able to talk to it yet
04:30 PM Player2: You mean that XTAL1 is stuck at VCC?
04:33 PM evidlo: pin count is too high on those
04:35 PM evidlo: yes
04:35 PM evidlo: I'm not sure if it's just that the fuses are set to the internal oscillator
04:36 PM Player2: What about ~MCLR?
04:36 PM Player2: Or at least the programmer hardware you got still detects the AVR?
04:37 PM evidlo: no, I'm trying to read the fuses with 'avrdude -c usbasp -p ATmega32U4 -U lfuse:r:-:i -v' but getting nothing
04:37 PM Player2: Hmm... Maybe you can try to slow down speed first...
04:37 PM evidlo: I do have another working board of a different design using atmega32u4 to reference against
04:37 PM Player2: I don't know if it works with usbasp let me see...
04:38 PM evidlo: I've tried -B4 -B8 -B16
04:38 PM Player2: Try -B 100.
04:38 PM Player2: It sucks but it must give you some fuses at least.
04:39 PM evidlo: no dice
04:39 PM evidlo: I have scope pictures of MISO MOSI SCK and RST, too
04:40 PM Player2: And they seem perfectly normal right?
04:42 PM evidlo: I compared the working and not working boards. MISO is different
04:42 PM Player2: Is more "squared"?
04:43 PM Player2: Or actually the defective board lack MISO activity?
04:44 PM * evidlo uploaded an image: (98KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/BrBgqGMmNNwyqsHTlyiWzowt/IMG_20211111_160032.jpg >
04:44 PM evidlo: Top is non-working
04:45 PM evidlo: And here is SCK
04:45 PM * evidlo uploaded an image: (102KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/RMxlYbBrnnWXevChajQYMXJV/IMG_20211111_155747.jpg >
04:46 PM Player2: You should put labels on channels to make those pics a bit clearer.
04:47 PM Player2: I have an Agilent MSOX2004A so I guess you can do that too.
04:47 PM Player2: However, that slow rise time on MISO it's strange.
04:49 PM Player2: Ah, that's REF wave. Sorry...
04:54 PM evidlo: * IMG_20211111_155747.jpg
05:46 PM Iemmings is now known as lemmings
10:37 PM jmiehe1 is now known as jmiehe