#avr Logs

Jan 14 2019

10:15 AM merethan_w: Am I being an idiot here?
10:19 AM merethan_w: ADCA.CAL = (nvm_read_production_signature_row(offsetof(NVM_PROD_SIGNATURES_t, ADCACAL0)) << 8) | (nvm_read_production_signature_row(offsetof(NVM_PROD_SIGNATURES_t, ADCACAL1)) << 0);
10:19 AM merethan_w: Well, a collegue of mine that is.
10:19 AM merethan_w: Because to me it seems the most significant byte of the calibration ends up in the spot of the least significant byte here. And vice-versa.
10:28 AM merethan_w: C++ is Hindu–Arabic numeral (or big endian, because our human numbering presents the most-significant digit first when reading left to right) so << shifts to a higher significance. Yet ADCACAL0 is supposed to be the lesser significant byte and ADCACAL1 the more significant byte, is it not?
10:28 AM day: merethan_w: why the << 0
10:28 AM merethan_w: Or am I overlooking something here?
10:28 AM merethan_w: I have no idea day, I did niot wrote it :P
10:29 AM LeoNerd: Your code above is presuming CAL0 is MSB and CAL1 is LSB
10:32 AM day: LeoNerd: the lsb would be save cal1, but the msb would be OR'd with CAL1, wouldnt it?
10:33 AM LeoNerd: ?
10:33 AM day: XXXX 0000 | XXXX XXXX
10:33 AM day: that would be <<4 not <<8
10:34 AM LeoNerd: << 8 is 8 bits; i.e. 1 byte
10:34 AM day: yeah but both could be short (2byte) from the beginning
10:34 AM day: ive no clue what nvm_read_production... does
10:35 AM merethan_w: Reading nvm memory.
10:35 AM day: what type does it return?
10:36 AM merethan_w: uint8
10:36 AM day: and ADCA.CAL is?
10:37 AM day: ADCA.CAL = (uint << 8) | (uint)
10:37 AM LeoNerd: hibyte << 8 | lobyte don't forget
10:38 AM day: assuming adca can store 2bytes than adca would simply become CAL0 -> MSB, CAL1 -> LSB, as earlier stated by someone else
10:39 AM merethan_w: My collegue screwed up.
10:43 AM merethan_w: Ah man this sucks because the scientific instruments with this bug are already everywhere.
10:45 AM cehteh: LeoNerd: you are on linux? i am try to get gcc floating for the 328pb's
10:46 AM cehteh: avr-gcc: error: cannot access device-specs for ‘atmega328pb’ expected at ‘Atmel.ATmega_DFP.1.3.300/gcc/dev/atmega328pb/device-specs/specs-atmega328pb’
10:46 AM cehteh: and strace gcc shows:
10:46 AM LeoNerd: "gcc floating" ?
10:46 AM cehteh: 21259 access("Atmel.ATmega_DFP.1.3.300/gcc/dev/atmega328pb/device-specs", R_OK) = 0
10:46 AM cehteh: 21259 write(2, "avr-gcc: error: cannot access de"..., 159) = 159
10:46 AM cehteh: wtf
10:53 AM cehteh: maybe my gcc is just too old
10:53 AM LeoNerd: I can compile for 328PB just fine
10:54 AM cehteh: what versions gcc/avr-libc ?
10:54 AM cehteh: and distro
10:55 AM LeoNerd: debian/testing; avr-libc 1:2.0.0+Atmel3.6.1-1
10:55 AM cehteh: ah ok
10:55 AM cehteh: i am on debian stale :)
10:55 AM cehteh: just upping a VM and see
12:06 PM day: is anyone here working on an opensource hardware project?
07:05 PM rue_mohr: I post most of the source I work on
10:33 PM rue_shop3: hmm tiny26 serial code, but its unlike me to write something like this witout there being...
10:33 PM rue_shop3: oh
10:33 PM rue_shop3: https://paste.debian.net/1060551/
10:33 PM rue_shop3: a state machine
10:34 PM cehteh: reduced state machine :D
10:34 PM rue_shop3: ??? who can see the bug
10:35 PM rue_shop3: oh nope, its covered, never mind
10:35 PM cehteh: i dont even know what its good for
10:35 PM rue_shop3: it does the bits of a serial transmitt
10:36 PM cehteh: softserial?
10:36 PM rue_shop3: yea
10:36 PM rue_shop3: tiny26
10:37 PM cehteh: as long you get the masks reliably initialized (starting with status == 10) should be ok
10:37 PM cehteh: and whats the 'default' good for
10:37 PM rue_shop3: it stops the machine from progressing past done
10:37 PM cehteh: should never happen
10:37 PM cehteh: ah
10:37 PM rue_shop3: the decrement is after it
10:37 PM rue_shop3: it prevents the machine from going below 0
10:38 PM rue_shop3: I wasn't sure if I wrote it or not for a bit
10:38 PM cehteh: dunno how its called, but cant/shouldnt that be handled outside else you run into a busy loop
10:38 PM rue_shop3: but the state machine sinks it, its mine.
10:38 PM rue_shop3: its done on an interrupt
10:39 PM rue_shop3: timer
10:39 PM rue_shop3: a bit timer
10:39 PM rue_shop3: for whatever baud rate ya set up
10:39 PM cehteh: so when the byte is send it just keeps spinning?
10:40 PM rue_shop3: iirc doing rx on the tiny13 was harder
10:40 PM rue_shop3: yea, the timer is always going
10:41 PM cehteh: yeah rx is harder beacuse you want ideally sample twice as fast or need to account for aliasing somehow
10:41 PM rue_shop3: no
10:42 PM rue_shop3: I just watch the edges
10:42 PM cehteh: thats the "somehow" part
10:42 PM cehteh: pcint? input capture?
10:43 PM rue_shop3: on this one, I used the adc as the base timer
10:43 PM cehteh: urgs :D
10:43 PM cehteh: well whatever lift it
10:43 PM rue_shop3: https://paste.debian.net/1060553/
10:44 PM cehteh: i dont like softserial much
10:44 PM cehteh: take too much cpu and programming space
10:44 PM rue_shop3: no choice on a t13
10:44 PM cehteh: well the choice would be not to use the t13 :)
10:45 PM rue_shop3: yes, if money isn't an issue
10:45 PM rue_shop3: but its cool
10:45 PM cehteh: how many devices do oyu want to produce?
10:45 PM rue_shop3: on any non-startbit edge, it resets the timer to half a bittime
10:45 PM rue_shop3: I have a drawr of avrs, there is only one way I can afford that
10:45 PM cehteh: has the t13 a usi?
10:46 PM rue_shop3: I dont make money off any of it
10:46 PM rue_shop3: no
10:46 PM rue_shop3: the usi sucks anyhow
10:46 PM rue_shop3: better off bitbanging it
10:46 PM cehteh: never tried it for normal serial
10:46 PM rue_shop3: SUCKS
10:46 PM cehteh: but when you talk usi <-> usi it should be fine
10:47 PM cehteh: otherwise flipping bytes isnt fun either
10:47 PM rue_shop3: yea, if your doing synchronous serial its fine
10:47 PM rue_shop3: i2c is MORE work than bitbanging
11:59 PM day__ is now known as day