#avr Logs

Aug 24 2021

06:18 AM thement is now known as me
02:38 PM mniip_ is now known as mniip
04:01 PM joakimk: I'm working with some ESP8266, from an ATMEGA16 avr, through AT commands. I'm having difficulties parsing the response "strings" from the ESP though... They are read like `'+', 'I', 'P', 'D', ',', '0', ',', '3', ':', 0x04, 0x01, 'f', '+', 'I', 'P', 'D', ',', '1', '9', ',', '6', ':', 0x01, 0x04, 'f', 'i', 's', 'k'`
04:01 PM joakimk: I mean, as in `unsigned char tmp[50] = {'+', 'I', 'P', 'D', ',', /*'0', ',',*/ '3', ':', 0x04, 0x01, 'f', '+', 'I', 'P', 'D', ',', /*'1', '9', ',',*/ '6', ':', 0x01, 0x04, 'f', 'i', 's', 'k' };`
04:02 PM joakimk: sorry, `unsigned char tmp[50] = {'+', 'I', 'P', 'D', ',', '0', ',', '3', ':', 0x04, 0x01, 'f', '+', 'I', 'P', 'D', ',', '1', '9', ',', '6', ':', 0x01, 0x04, 'f', 'i', 's', 'k' };`
04:03 PM joakimk: this is my test case :) So +IPD is the "header", followed by channel ID, then data length (N), and a comma and the actual N bytes of data
04:04 PM exp: what are you struggling with?
04:04 PM joakimk: I set up a simple test program to parse the string (here, two consecutive "packets" of data): https://onlinegdb.com/_v4CpZgJA This runs fine on my PC
04:04 PM joakimk: However, compiling this into the AVR, it crashes on line 79
04:05 PM joakimk: on `strncpy(payload, pbuffer_len+1, dLengde);`
04:05 PM joakimk: please forgive the norwegian comments and variable names
04:06 PM joakimk: of course, this (the paste) is not the actual AVR software (firmware) -- this is an extract
04:06 PM joakimk: if the scenario here is understandable, why does this piece of code work on my PC but not in the AVR?
04:08 PM exp: i understand, i don't have the time to read through the code at the second, but if nobody else does i will look tomorrow morning
04:08 PM joakimk: :)
04:08 PM exp: when you say 'crashes'
04:08 PM exp: can you be more specific?
04:08 PM joakimk: the AVR restarts
04:09 PM exp: right, and you have no PDI or JTAG or anything to debug it with?
04:09 PM joakimk: if I comment out lines 79 - 89, it keeps running
04:09 PM twnqx: what lnguage is that? normally i'd have guessed durch...
04:10 PM joakimk: norwegian ;)
04:10 PM joakimk: well... I do have an ATMEL ICE which I bought, but I just have not had the guts to take out of the box...
04:10 PM exp: they're straightforward to use
04:10 PM twnqx: dutch* anyway
04:10 PM exp: i use one for PDI and it's been a life saver in figuring out what was broken on USB
04:11 PM twnqx: hm, can sscanf with %d parse hex?
04:12 PM LeoNerd: No, that's what %x is for
04:12 PM joakimk: so.... `sscanf(token, "%x", &dLengde);`
04:13 PM joakimk: twnqx but why does this work in the onlinegdb env?
04:13 PM qu1j0t3: maybe your test data doesn't exercise that bug?
04:13 PM twnqx: you'r reading the 3, right? that's nox hex, i am xonfused by your example, sorry
04:15 PM twnqx: you could check the return values of both sscanf (you expect 1 if it works), and of strok (non-null)
04:15 PM joakimk: as in, `if (sscanf(token, "%d", &dLengde)) strncpy(payload, pbuffer_len+1, dLengde);` or something?
04:17 PM joakimk: so +IPD,0,3: `0x04` `0x01` f is sort of, the payload is "command" `4` followed by "lenght" `1`, and then the actual one byte of data "f"
04:19 PM joakimk: 3 bytes of data from the ESP, where 4-1-f is my "packet". The "f" is the byte I want to work on. Command 4 is what I used to interpret the byte "f"
04:19 PM joakimk: this is hard even to explain :D
04:20 PM joakimk: the second thing received/read from the ESP (the second +IPD "package") should be 1-4-fisk, where the command is 1, and 4 bytes of data (fisk)
04:21 PM joakimk: the command bytes, as such, are "raw" numbers (if you see what I mean), not ascii 4 but the actual byte `0x04`
04:29 PM twnqx: mh. i can't say i would write it like that (any 0 returned will break your strcpy, you probably want memcpy)
04:32 PM twnqx: but i can't see an immediate error either
05:01 PM joakimk: Allright, well thanks for the help :) I'll check back tomorrow afternoon (european time)