#avr Logs

Oct 03 2019

03:41 AM julius: morning
03:46 AM julius: why would a temp sensor that has vcc, gnc, 1 wire data need a "Port output register address" ? there are some eample code lines here: https://github.com/Jacajack/avr-ds18b20 and the description for the function is here: https://github.com/Jacajack/avr-ds18b20/wiki
03:46 AM julius: ds18b20convert( &PORTB, &DDRB, &PINB, ( 1 << 0 ), NULL ); <- from all these parameters all he really needs is the information where to find te sensor?
03:46 AM julius: and the ROM matching thing,whatever that is
05:13 AM cehteh: julius: strange driver which takes that for each function call, but the driver is bitbanging onewire protocol and needs to store 'somewhere' where the sensors are connected
05:14 AM cehteh: also each sensor has an unique address, you can somewhat ignore that when you have only one sensor, but its possible to connect mcuh more sensors on that single pin
07:11 AM Fuchikoma: julius: Taking a quick look, I think only the person who wrote the code can tell you why it was done that way.
07:12 AM Fuchikoma: Though really, " the information where to find the sensor" is exactly what those parameters are
09:01 AM julius: Fuchikoma, genius
09:11 AM Fuchikoma: Just sayin', you can't address a uC pin by pin alone. You need to adderss it by port:pin
09:12 AM Fuchikoma: So their function takes both a port and a pin as arguments
09:14 AM joakimk: I'm having problems using Timer1 on an ATMEGA16 to blink LEDs on PORTB: https://pastebin.com/GcFc8ub7
09:15 AM joakimk: I'm using Timer0 to communicate with an ESP8266 module
09:18 AM joakimk: As can (hopefully) be seen in the paste (setupTimerISR), I'm trying to configure Timer1 in CTC mode, and the plan is to change the blink frequency by changing the value in OCR1A
09:18 AM joakimk: But setupTimerISR is crashing my AVR
09:19 AM joakimk: (meaning, if I comment it out, the program/main loop runs as it should -- communicating with the ESP etc)
09:19 AM joakimk: (but with no LEDs :)
09:21 AM Fuchikoma: Just spitballing but is there a conflict between the timer and uart interrupts?
09:24 AM joakimk: Don't know... But, if you look at ISR (USART_RXC_vect) (line 2-12) you can see I'm taking care to stop interrupts (cli), and "restore" the setup when restarting it (by taking a backup of SREG)
09:24 AM joakimk: right?
09:25 AM joakimk: this is to avoid interrupts while handling incoming serial data. Since I do SREG=oldsrg, rather than just sei(), I'm not messing up the setup for Timer1...??
09:25 AM joakimk: this is, at least, my understanding
09:25 AM joakimk: the ISR for timer1 doesn't need such special care, since it's triggered periodically
09:26 AM Fuchikoma: http://maxembedded.com/2011/07/avr-timers-ctc-mode/
09:26 AM joakimk: (so long as the rate never exceeds the number of instructions of "stepping" the program and blinking the LEDs)
09:30 AM joakimk: Yes, I have studied that post :) However, looking through it again and comparing to my code, I see I'm maybe using the wrong ISR "event handler"??
09:30 AM joakimk: I've been using ISR (TIMER1_OVF_vect), whereas, in CTC-mode, I should be using ISR (TIMER1_COMPA_vect)?
09:31 AM joakimk: Could that be it?
09:32 AM Fuchikoma: Worth a try
09:33 AM Fuchikoma: Honestly it's been so long since I've done anything with timers and I've never used C anyway I'm a bit rusty
09:49 AM joakimk: Yeah, changing the ISR (signature) didn't work
09:51 AM joakimk: Probably need to set up a separate project, just doing timer1 and blinking leds. Try to make it work there, or otherwise isolate the problem
10:16 AM djph: julius: TIMER1_OVF_VECT is the overflow vector, whereas _COMPA_VECT is the comparison of TCCR0A (IIRC, I always goof the timer bits)
10:17 AM djph: essentially, you use TCCR0A (??) as a "lower overflow value", if you need that.
04:14 PM vmt: julius: yes what skz said
05:59 PM julius: in here https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf it says that the sensor could output a max number of: 1111 1111 1111 1111 = 65535 but they also say that its highest mode is 12bits?
06:10 PM julius: anyway, starting with this code: https://github.com/Jacajack/avr-ds18b20 i added: char buf[10]; itoa(temp, buf, 10); and then im transmitting the result in buf via a hc05. but the data received from the hc05 is nonsense, the bluetooth terminal app shows some weird chars. so something is wrong with the conversion
06:12 PM vmt: julius: fig 4, you can find the explanation right above it
06:13 PM vmt: and i'm not going to go through your code unless you paste/link the actual, relevant parts
06:16 PM vmt: in any case, long story short. it transmits 16 bits every time, and the details tell you which bits to mask given your chosen configuration of, 9-12 bit operating mode
06:16 PM julius: youre right, need to clean my code first
06:16 PM julius: thats why i didnt paste it
06:16 PM vmt: really defeats the purpose of linking it in the first place, then
06:17 PM julius: i did use the example code
06:18 PM vmt: oh so that's not yours. well, in any case, not going to go over the example code either unless you can point me to the actual problem
06:20 PM vmt: and oh wait, i didn't read the datasheet that well. i mean apparently you read two regs for msb and lsb and there's your data as given in fig.4
06:21 PM julius: since im using a library i hope it takes care of that
06:22 PM julius: but the library example writes it data to a single int variable, no clue how it would like me to find out if its positive or negative
06:23 PM vmt: i would imagine the sign bit would be set correctly, in that case
06:23 PM vmt: though... libraries.
06:24 PM julius: ah, right
06:24 PM julius: https://bpaste.net/show/wD4C
06:24 PM julius: thats my code
06:25 PM julius: 128-135 < the problem is probably in that region, the usart communication works
06:28 PM vmt: you can rule out the issue being in that section very easily
06:29 PM vmt: however, what you most likely want is just to send the value out rather than all 10 bytes
06:29 PM julius: yes i did start with 5, but that didnt work either
06:30 PM julius: 5 since thats the length of 65535
06:30 PM vmt: so for (char *p = buf; p; p++) { // send data }
06:31 PM vmt: for(char *p = buf; p; p++) { USART_transmit(p); }
06:33 PM vmt: though you should still get something reasonable out otherwise, too, just mixed in with garbage...
06:33 PM julius: ok, have to read up about pointers
06:34 PM vmt: you can just replace your send loop with that, anyway
06:35 PM vmt: and 9.5/10 "pointers 101 for dummies" are horseshit because they fail to address the basics of memory properly and they will just leave you more confused than what you began with
06:36 PM vmt: you should read something like memory 101 for dummies and then proceed to pointers
06:38 PM vmt: USART_transmit(*p); that is, sorry
06:47 PM julius: uh, jesus. thats a wall of text that is transmitted
06:49 PM vmt: for (char *p = buf; *p; p++) { USART_transmit(*p); } rather.
06:49 PM vmt: i seem to be missing asterisks all over the place.
06:50 PM vmt: maybe something to do with sleep deprivation and reflecting on these mistakes i think i ought to hit the sack
06:51 PM julius: no problem :)
06:51 PM julius: at least the wall of text stopped, now its sending 0 in each interation
06:52 PM julius: i dont have a reference besides a local weather services via the intenret, it should be around 9 degree
06:53 PM vmt: well let's see that library then
06:54 PM julius: https://github.com/Jacajack/avr-ds18b20/wiki
06:55 PM julius: could be a communication error with the chip, i will output that via a led
06:59 PM vmt: err
06:59 PM vmt: which pin is the sensor connected to?
07:08 PM julius: you wanna check the obvious first?
07:08 PM julius: one sec
07:10 PM julius: PA0
07:12 PM vmt: and you've got a pullup on the data line?
07:17 PM julius: no
07:17 PM julius: yeah forgot about that
07:22 PM julius: ok its transmitting 346 now
07:22 PM julius: and it should be around 15 degrees celsius in here
07:24 PM julius: is 346 like 34.6 degree?
07:25 PM vmt: https://github.com/Jacajack/avr-ds18b20/blob/master/src/ds18b20.c#L166
07:25 PM julius: i know that the sensor outputs degree celsius, so its not fahrenheit
07:25 PM vmt: not sure if that's relevant or not
07:26 PM vmt: let me see here..
07:26 PM julius: yes, divided by 16 its 21.6
07:26 PM julius: that could be the right temperature
07:29 PM vmt: well this library is fucking dumb and i don't see a reason to use it
07:30 PM julius: true
07:30 PM julius: maybe not the best choice
07:30 PM julius: so theres no real reason to multiply the result by 16?
07:31 PM vmt: well
07:31 PM vmt: the datasheet fig 4 shots bits 0 through 3 are 2^4...2^-1, respectively
07:33 PM vmt: so in order to mask out the decimal places you right shift the data by 4
07:33 PM vmt: which effectively divides by 16, and this is why the author says "returns data x16"
07:33 PM vmt: well in order to remove the decimal places, rather. masking is a bit of a wrong word.
07:34 PM vmt: i think i'm done doing your work here, though
07:35 PM julius: thank you
07:35 PM julius: its not work, its play
07:36 PM vmt: all play no work makes me a poor man
07:41 PM vmt: well... the explanation isn't exactly good and i'm gonna head off right now. refer to fig 4.
07:41 PM vmt: have a good one
07:49 PM julius: vmt good night, its almost 3 in the morning here in germany
08:56 PM Thrashbarg_ is now known as Thrashbarg
11:47 PM day__ is now known as day