#avr Logs

Apr 03 2019

12:57 AM rue_bed: --
03:44 AM Maya-sama is now known as Miyu
11:18 AM horohoro: hello everyone
11:34 AM nohit: hello
11:40 AM polprog: hello
12:38 PM gsi__ is now known as gsi_
01:44 PM paulo_ is now known as Guest4458
04:57 PM HelloShitty: Hello peeps
04:58 PM HelloShitty: When writing a basic code for a TWI device, for reading and writing data, etc,
04:58 PM HelloShitty: what is a common procedure for when a NACK is acknowledge byt the master device?
04:59 PM HelloShitty: Let's say I send the slave address from the master to the bus, then I want to get an ACK bit... If an ACK bit is received, then we read/write the data packet
04:59 PM HelloShitty: but what if a NACK e received?
04:59 PM HelloShitty: Do we try to repeat the previous action? If so, for how many times? If not, what should be done?
05:00 PM cehteh: i guess that depends on the device and use case
05:01 PM cehteh: aka leave that open to the user, provide an api to handle both cases
05:06 PM cehteh: .o(do slaves even send nack back when ack is expected?)
05:09 PM HelloShitty: cehteh: I'm not sure what to provide to the user
05:09 PM cehteh: https://www.nxp.com/docs/en/user-guide/UM10204.pdf page 10
05:10 PM HelloShitty: This is just a simple case of a temp sensor sending values (or these values being read) by the master device
05:10 PM HelloShitty: and for some reason if a read operation fails
05:10 PM HelloShitty: what should the code do
05:10 PM cehteh: depends on the use case, i did sometihng with onewire sensors and a oven
05:11 PM cehteh: since i dont want the oven to overheat i just use the old value + x (where x is 1°C iirc)
05:12 PM cehteh: so when there is one error it wont matter much i can just ignore that
05:12 PM HelloShitty: So the procedure in this case, could be to try to readthe value again, no?
05:12 PM cehteh: but when the sensor constantly fails the controller thinks the temperature is rising and eventually goes into an overtemperature alarm
05:13 PM cehteh: sure you can try to read again
05:13 PM cehteh: or just ignore
05:13 PM HelloShitty: Like, to use an infinite loop until a read operation is successeful
05:13 PM cehteh: think about what error modes and consequneces you have
05:13 PM HelloShitty: I have 4 situations I think
05:13 PM cehteh: like fails rarely, fails some times in a row, is permanent defect
05:13 PM HelloShitty: which are held by BUSSTATE macro/register
05:14 PM HelloShitty: but even if there is a permanent defect, what should a code do? Nothing, right? Just try to read values for ever, no?
05:14 PM HelloShitty: For instance, in my case
05:14 PM cehteh: do you have some PID control loop for example ...PID's need either constant time or you have to integrate the time into the pid controller
05:15 PM cehteh: i dont know what your application is, best case would be to pass an error up
05:15 PM HelloShitty: the situation could be read a vaçlue and sent it to a database or to some screen/LCD, doesn't matter
05:16 PM HelloShitty: and if 100 errors reading temp values is detected, then send a message to the database or the LCD or whatever the output is saying a possible permanent damage might be taking place
05:16 PM HelloShitty: to inform the user that the hardware might need replacement
05:16 PM HelloShitty: I don't have PID control
05:16 PM cehteh: maybe i'd already send the very first error
05:16 PM HelloShitty: This is just an AVR chip with a temp sensor (AVR IoT WG dev board)
05:17 PM cehteh: make it as dumb as possible, store errors in the database
05:17 PM HelloShitty: but 1 error might be electrical interference
05:17 PM HelloShitty: or something else
05:17 PM cehteh: and?
05:17 PM HelloShitty: 1 error or 2 or 5 errors might be ok to ignore
05:17 PM cehteh: even if, you can later filter the database, ignore errors, average/interpolate,
05:17 PM HelloShitty: because electrical interference might be occasional
05:18 PM cehteh: thats what databases are good for, why put incorrect data into the database in the first place
05:18 PM cehteh: even if, then you can scan the database and see if you need better cabeling
05:18 PM HelloShitty: I might be misunderstanding your point
05:18 PM HelloShitty: or explaning myself poorly
05:19 PM HelloShitty: A single read operation error might not be an hardware permanent fault
05:19 PM cehteh: do you send every value to the database or do you sample/average some reads and send only infrequently to the database
05:19 PM HelloShitty: might be something occasional and might never happen again
05:19 PM HelloShitty: sure, only like 1 value a second or so
05:20 PM HelloShitty: I have not thought about that yet
05:20 PM HelloShitty: but probably an average value could be a good option
05:20 PM HelloShitty: I have done a VSWR meter for my school project and used 200 values and averaged them to do math later in the code
05:21 PM cehteh: to makes things perfect i'd prolly make the sensor little bit smarter, oversampling a few sensor reasings, sampling faster than sending to the database *and* also keep track of the 'quality' of the signal
05:21 PM HelloShitty: hum, that might be done in a later stage
05:21 PM HelloShitty: I'm just learning about to use TWI interface and understanding parameters, settings, etc
05:22 PM cehteh: so for example sample 16 times a second, average all 'good' reads, count the error .. then store that average + number of errors in the database
05:22 PM HelloShitty: I'm not an experienced user
05:22 PM HelloShitty: otherwise I wouldn't be making such questions here
05:22 PM HelloShitty: :)
05:22 PM HelloShitty: yeah, good approach
05:22 PM HelloShitty: I like it
05:22 PM cehteh: looping indefinitely is certainly not a good idea, when errors happen, just deal with them as approbiate
05:23 PM HelloShitty: yeah, I have now a better idea of what can be done
05:23 PM cehteh: doing stoic/timed sensor polls
05:23 PM HelloShitty: going to try to put it on code
05:23 PM HelloShitty: but I'm still trying to learn about TWI and how this 4808 chip header files are written
05:23 PM cehteh: also i usually do a rolling average, thats simple simple to implement as well
05:23 PM HelloShitty: yeah
05:24 PM HelloShitty: But for now I want to have my TWI code minimally running
05:24 PM HelloShitty: so I'm going to work on that first
05:24 PM HelloShitty: and then, worry about math and logic of the whole code
05:24 PM cehteh: valule +=value/16 + read_sensor(); ....
05:24 PM cehteh: err
05:24 PM HelloShitty: when to do things, why and how to do them, etc etc
05:25 PM cehteh: wrong .. well anyway i am busy
05:26 PM cehteh: either way, when errors happen its good not to hide them up top the top where something uses the data, at that point it might be more sensible how to handle them
05:26 PM HelloShitty: no problem... I think I understood what to do about when errors occur
05:26 PM HelloShitty: indeed
05:26 PM cehteh: of course there can be exceptions, when you make your sensor smarter or its more critical and it can instantly turn off the heating or whatever
05:29 PM HelloShitty: yeah, but for now I just want to make my TWI to be functional
11:48 PM day_ is now known as day