#avr Logs

Feb 19 2020

12:04 AM day__ is now known as day
12:35 AM nuxil: check the asm output
12:38 AM nuxil: you got 6 longs there. i bet there is some pushing/poping on the stack that gets screwed up.
12:38 AM nuxil: what chip are you trying this on ?
12:49 AM rue_mohr: mega8
12:49 AM rue_mohr: I think the compiler pairs it down a lot
02:27 AM day: compiler error vs rue error ..hmmm
03:29 AM Thrashbarg_ is now known as Thrashbarg
06:30 AM davor_ is now known as davor
06:44 AM Thrashbarg_ is now known as Thrashbarg
08:32 AM rue_bed: I think its optimizing A/100*10
08:32 AM rue_bed: to A/10, which in this case is not the same beause it doesn't clear the lower place
08:45 AM Fuchikoma: Will using ( ) prevent that?
08:57 AM rue_mohr: I did better, I made them different variables
08:57 AM rue_mohr: and no
08:58 AM Fuchikoma: huh
08:58 AM Fuchikoma: I'd have thought compilers would obey order of operations and not optimise around them
08:59 AM rue_mohr: go ahead, compile printf("%d\n" 900/10*4);
09:23 AM Fuchikoma: But should A/B*C be optimised differently than (A/B)*C or A/(B*C)
09:23 AM Fuchikoma: I don't code in C so I have no idea how that works
09:26 AM rue_mohr: ah, I know how it works,
09:26 AM rue_mohr: I'm being lazy and can debug this
09:26 AM rue_mohr: I started with an error in coding the process I came up with
09:27 AM rue_mohr: sloppy notes,
10:05 AM vmt: rue_mohr: you make *mistakes*?
10:06 AM Fuchikoma: Programming is an art, and as any artist will tell you, it's all about knowing which mistakes to keep
10:08 AM vmt: what, no. that's his argument against having debuggers. -> don't make mistakes
11:04 AM merethan_w: If an xmega has i2c/twi master/slave enabled, does configuring the pins they´re on make any difference?
11:08 AM Fuchikoma: It changes what pins they use
11:09 AM Fuchikoma: I'd have to check the datasheet but I presume you could chnge the pin config *after* they're enabled and it should work, but that's not necessarily the case
11:36 AM merethan_w: Manual says they are open-collector wired-and, pull-up resistors are the only external need to make it work.
11:36 AM Fuchikoma: Yes
11:37 AM merethan_w: My curiosity here is, can I change the open-collector setting without breaking stuff?
11:37 AM Fuchikoma: I guess maybe I didn't understand the question?
11:37 AM merethan_w: Or will it even change at all.
11:37 AM Fuchikoma: Oh, no that will make it not work
11:37 AM Fuchikoma: You need external pullups
11:37 AM merethan_w: I have them.
11:38 AM Fuchikoma: Then I'm lost again
11:38 AM merethan_w: My evil plan here is to make SDA have an extra pull-up, internal to the MCU.
11:38 AM Fuchikoma: That seems uncessary and won't work anyway
11:39 AM merethan_w: I have this nasty issue of SDA and SCL rising at the same rate, and the race is sometimes won by SCL. meaning SDA changes from 0 to 1 then SCL is already 1. Which is a bus stop condition.
11:40 AM merethan_w: I´m hoping to find a trick to make SDA rise faster or make SCL rise slower.
11:40 AM Fuchikoma: And you're using the built in I2C hardware for this?
11:40 AM merethan_w: Yes.
11:40 AM Fuchikoma: You have some other problem, then
11:41 AM merethan_w: There´s a design shortcoming in Atmel twi hw. They lack a method of retarding this SCL rise.
11:41 AM Fuchikoma: First I'm hearing of it
11:41 AM merethan_w: NXP hw has an extra timer to counter this.
11:42 AM Fuchikoma: You can try mismatching the external resistors I suppose
11:43 AM merethan_w: Recent NXP hw allows you to set a delay to SCL rise if the first bit to go on SDA is 1. (Which can make the bus fail. If your first bit to go on SDA is 0, youŕe good.)
11:43 AM merethan_w: Yes mismatching the resistors is one way to solve this. My problem is already having a shitload of hardware in the field.
11:43 AM merethan_w: All I can change is fw.
11:44 AM Fuchikoma: Welp, implement your own I2C code then :D
11:44 AM merethan_w: I have. I already fixed the slave end.
11:44 AM Fuchikoma: Problem solved, then
11:45 AM merethan_w: But the fw update I can do in the field is the master end xD
11:45 AM Fuchikoma: "TWI, the minimum I2C SCL low time could be violated in Master Read mode"
11:46 AM Fuchikoma: Welp there it is I guess
11:46 AM merethan_w: This timing issue only exists on the slave end when sending. Detecting the bus stop condition is discrete logic in the master and hence can´t be fixed.
11:47 AM Fuchikoma: If you write your own software I2C routine yuo can control that though
11:47 AM Fuchikoma: As in don't use the hardware TWI interface at all
11:50 AM merethan_w: It is not about the minimum I2C SCL low time, it is about SDA & SCL changing simultaneously. And when you´re unlucky, SCL wins.
11:50 AM davor_ is now known as davor
11:50 AM Fuchikoma: Which relates to minimum SCL time 'cause it's not waiting an appropriate amount of time
11:51 AM merethan_w: Ah, yes, if read in that way it is indeed about that.
11:51 AM merethan_w: My goal is to change the pull-up rate on either SCL or SDA just enough to avoid this condition.
11:51 AM merethan_w: Either by slowing SCL or speeding SDA.
11:52 AM merethan_w: Next hw revision will also solve this with extra resistors, but can´t update deployed hw :(
11:52 AM merethan_w: Can only update the fw on them. (Well, the piece acting as master, that is.)
11:52 AM Fuchikoma: Tweak firmware to use fully software driven I2C
11:54 AM merethan_w: Writing software is expensive. It will take me a lot of time, a lot of testing, and a lot of new bugs.
11:55 AM Fuchikoma: Life sucks and then you die :D
11:56 AM Fuchikoma: There's seems to be nothing you can do port config wise that will fix this problem. Your options are you bite the bullet and recall/replace/fix-in-field deployed hardware with revised hardware, or bite the other bullet and rewrite the firmware.
11:57 AM Fuchikoma: You can blame whoever was responsible for testing this design prior to manufacture, assuming it wasn't you
11:58 AM merethan_w: Hardware was designed before I joined in on the party ;)
11:59 AM Fuchikoma: Perfect, that SOB isn't even around to defend themselves
12:01 PM merethan_w: Well can´t blame them really. I consider this a lack of functionality in the discrete logic.
12:01 PM merethan_w: NXP has it. Atmel does not.
12:01 PM Fuchikoma: *shrug*
07:08 PM rue_mohr: vmt, yes, actually, I'v been writing this one like a monkey throwing mud at a wall
07:08 PM rue_mohr: I need to sit down and work it out properly
07:09 PM rue_mohr: the code is close, I have a variable and a factor of 10 mixed up or something
09:17 PM rue_shop1: it was a bug in the interface board library I was using
10:34 PM * nuxil sips some morning coffee.
10:35 PM nuxil: rue_shop1, what is it you are making?
10:54 PM PoppaVic: well, monkeys, mud and walls: it's called "a mess".
10:55 PM PoppaVic: PS: the monkeys more likely throw poop.. So...
11:22 PM rue_shop1: turns out
11:22 PM rue_shop1: it wasn't my code
11:22 PM nuxil: rue_mohr> go ahead, compile printf("%d\n" 900/10*4); ???? are you getting different result using different optimation level? which makes no sense. i dont need to compile it to know its going to be 360 :p ,alway left to right when doing the arithmetic operator. mul & div have the same precedence (3) in C+ you got no parentheses there.
11:22 PM rue_shop1: it was the library I was using
11:22 PM rue_shop1: it "smudges" the button presses
11:22 PM rue_shop1: I put a bandaid on it
11:23 PM nuxil: oh. 3rd party code
11:24 PM nuxil: but. what are you makeing? you posed this rollDigit fnc, maing some random num gen?
11:24 PM nuxil: *making