#avr Logs

Jul 25 2020

12:08 AM day_ is now known as day
07:47 AM aborazmeh_ is now known as aborazmeh
04:43 PM landau: hello..I have a c code that I upload on a ATMEGA8535. now it looks like the code does not go through an if, but if I add a delay of 2 ms just before the if, the code performs as expected...do you have an idea of why this happens? Here is the code https://github.com/richardroscoe/KAP140/blob/master/fsbus_rcv.c#L97 at line 97
04:46 PM cehteh_: delay is evil :D
04:47 PM cehteh_: looks like you have some kind of race conditon
04:47 PM landau: yes I know :( that's why I'm asking
04:47 PM cehteh_: does that use interrupts somewhere (in the driver?)
04:48 PM cehteh_: i am too lazy to read all your code :D
05:41 PM landau: hello..I have a c code that I upload on a ATMEGA8535. now it looks like the code does not go through an if, but if I add a delay of 2 ms just before the if, the code performs as expected...do you have an idea of why this happens? here is the code https://github.com/richardroscoe/KAP140/blob/master/fsbus_rcv.c
05:43 PM cehteh_: you dont need to repeat :D
05:52 PM cehteh_: did you read and check my remark earlier?
05:55 PM landau: cehteh_ no I'm sorry I closed the chat by mistake
05:55 PM landau: could you tell me again please?
05:56 PM landau: thank you
05:57 PM cehteh_: [23:38] <cehteh_> does that use interrupts somewhere (in the driver?)
05:58 PM cehteh_: try to figure out where the race is, is 'blk' modified somewhere else?
05:58 PM landau: the only interrupt I see is the UART
06:00 PM landau: blk is modified by the function, fsbus_rcv_dio but it is modified in several calls
06:00 PM landau: I usually receive 2 bytes...the first byte is stored in the if (c & FS_DF_START) part
06:01 PM cehteh_: well you dont have multithreading i guess, so the only way its modified can be via interrupts
06:01 PM cehteh_: do the uart interrupts modify it for examle?
06:01 PM landau: blk is assigned accordin to the UART data
06:02 PM landau: first UART byte goes to some parts of blk, as the second one does
06:02 PM cehteh_: looks like thats the problem
06:03 PM landau: ohh really? any idea of how to fix it?
06:03 PM cehteh_: i am only guessing, i dont want to debug your code, but you call the 'if' to check for something that hasnt happend yet, thus delay fixes it because then the data got recevied meanwhile
06:04 PM landau: yes
06:04 PM landau: I guess the same too
06:04 PM cehteh_: which is somwhat a crappy/fragile design, well figure out if this guess is correct
06:05 PM landau: the if should be accessed only if all the data has arrived and stored
06:05 PM cehteh_: i'd prolly do things completely different, asynchronous with a callback when the data is received
06:06 PM landau: there is a callback function
06:06 PM landau: (*blk->fs_callback)(blk);
06:06 PM cehteh_: i dontk now that coode, no do i know when its called
06:06 PM landau: however I have no idea about how this thing works..
06:06 PM landau: ok
06:07 PM cehteh_: read the source
06:07 PM cehteh_: or docs
06:07 PM landau: ok
06:07 PM cehteh_: could be that that callback is what you need
06:07 PM landau: ok
06:08 PM cehteh_: in my OS i can also wait for some condition to become true, for expected (with minimal chance of failure) things in very short time this could be a solution, but prolly not in your codebase
06:09 PM landau: ok
06:09 PM cehteh_: wait() will schedule other pending jobs until the condition becomes true ... but you have no scheduler there :D
06:09 PM landau: no :(
06:10 PM cehteh_: you could do a while(!condition) /*do nothing*/; when you are 100% sure the thing will become true eventually
06:10 PM landau: ok I will try that too... many thanks
06:10 PM cehteh_: but for IO thats not really going to work, some transmision error/unplugged cable and your firmware hangs :D
06:11 PM cehteh_: could pair that with a timeoout ... but its just a busy loop, that sux
06:11 PM landau: mmm ok
06:11 PM cehteh_: possibly the correct way is to ise the callback, just rtfm