#avr Logs
Sep 16 2017
#avr Calendar
12:10 AM day__ is now known as daey
12:42 AM enh: https://pastebin.com/DqKqATtg
12:42 AM enh: I implemented a basic interlock
12:43 AM enh: this fucntion is called by the 20ms timer interrupt
12:43 AM enh: it enables the PCA output and sets the timer comparator to 2 more ms
12:44 AM enh: after which it disables the PCS output
12:44 AM enh: PCA
12:44 AM enh: If no communcation comes from the main module in 3 windows, it cannot enable the PCA output.
12:44 AM enh: all servos are shutdown
12:50 AM enh: https://pastebin.com/BiSGE5MW
03:00 AM day__ is now known as daey
05:05 AM day__ is now known as daey
06:21 AM polprog: https://sites.google.com/view/energy-efficiency-languages/results
06:22 AM polprog: interesting
06:22 AM polprog: C kicks ass
06:23 AM polprog: Rust is the 2nd in most cases
06:26 AM thardin: fortran not doing quite as well as I'd expect
06:27 AM polprog: it's pretty good in memory usage, as you'd expect
06:32 AM thardin: well, you can write fortran in any language as the saying goes
08:38 AM mmfood: Hi I am trying to create a simple program for a 4 digit, 7-segment LED clock. So I started with #define zero 0x3f ... for each number 0-9, I then wanted to create an array of this like char number[10] = {one, two, ....., 9} and in the main function just test it with PORTD = number[0]; etc.... but it only work with the macros, not if it is stored as a variable or in an array. I guess this has something to do with how C is typecasting the values when inserting them
08:38 AM mmfood: to memory or something like that. But I can't seem to find a good source of information on this.
08:39 AM mmfood: I mean that it works with PORTD = one, but not with PORTD = number[1]
08:42 AM polprog: that's odd
08:43 AM polprog: can you paste the code somewhere?
08:43 AM mmfood: sure just a sec
08:50 AM mmfood: https://gist.github.com/mmFooD/973acfc8ca434f86df71e03ac6a8fb3d
08:51 AM mmfood: polprog: sorry, took longer than expected. Pasting from vim to clipboard only works in gvim, it turns out ^^
08:56 AM mmfood: I'm using avrdude for compiling
08:56 AM polprog: you're using avrdude for uploading
08:56 AM polprog: also, i suspect the problem is the for loop right?
08:57 AM polprog: because you're using sizeof() wrong
08:57 AM mmfood: ok, yes, the for loop is also a problem. But the las writing of the PORTD below is also not working
08:59 AM polprog: try replacing unsigned char with uint8_t
08:59 AM polprog: to be sure you're using an 8 bit datatype
08:59 AM * polprog wil be right back, dinner's ready
08:59 AM mmfood: if I write from the array it shows '8' on the display (meaning ut writes 0xff) no matter what index is used for 'number'
08:59 AM polprog: hmm
09:05 AM polprog: did you try using *uint8_t number = {0x3f, .... };
09:09 AM mmfood: https://gist.github.com/mmFooD/973acfc8ca434f86df71e03ac6a8fb3d
09:09 AM mmfood: I've updated the code
09:11 AM mmfood: yes, I am now using that assignment ( number[10] = {0x3f, ..., 0x65}) instead
09:11 AM mmfood: wait, what is the * ?
09:13 AM polprog: it's a pointer
09:14 AM mmfood: ok, do I refer to it by *number?
09:14 AM polprog: no
09:14 AM MrFahrenheit: to be clear, PORTD = two; works, but PORTD = number[2]; does not?
09:14 AM mmfood: MrFahrenheit: precisely
09:14 AM polprog: yea
09:16 AM mmfood: when using the * (and changing nothing else) I get compilation error
09:16 AM polprog: using * where
09:17 AM mmfood: before number declaration/initialisation
09:17 AM polprog: can you paste the line?
09:17 AM mmfood: *uint8_t number[10] = {
09:17 AM polprog: use *uint8_t number = { }
09:18 AM polprog: also what's the error
09:18 AM mmfood: expected identifier or '(' before uint8_t
09:19 AM mmfood: and 'number' undeclared before first use (l.59)
09:23 AM mmfood: is it fine to declare and initialize the array outside the main function? or do I have to do something in main() with it as well?
09:23 AM MrFahrenheit: it's possible you're data segment isn't being loaded to the avr properly
09:24 AM MrFahrenheit: not sure if an array like that would be placed in .data or .bss, but they might night make it to the avr depending on the compiler settings
09:25 AM MrFahrenheit: *your data segment, sorry about having to read that :P
09:26 AM MrFahrenheit: if my theory is correct, it won't work even without using an array, try declaring uint8_t var_two = 0xNN; and use PORTD = var_two;
09:27 AM MrFahrenheit: have a look at how you're converting your compiler output to a .hex file if you are
09:28 AM polprog: yes, how does your avr-objcopy invocation look like
09:28 AM polprog: assuming you're on linux since you mentioned vim
09:30 AM MrFahrenheit: avrdude supports elf files nowadays, so it's not strictly necessary to convert to hex, I believe
09:30 AM polprog: yes, but explicitly saying "i want X, Y, ans Z in my hex file" by running objcopy and flashing hex makes sure you have all the stuff in the avr at the end
09:31 AM mmfood: https://gist.github.com/mmFooD/a4fa5cb74accab3149d2d5107b89ce89
09:31 AM mmfood: makefile
09:31 AM MrFahrenheit: -j .data
09:31 AM MrFahrenheit: you're missing the dot
09:31 AM mmfood: MrFahrenheit: PORTD = var_two gave the same result as number[2]
09:31 AM polprog: it's the dot lol
09:32 AM polprog: in the future you can use avr-objdump to list sections, or disassemble etc
09:32 AM mmfood: L...O....L
09:32 AM polprog: you may awnt to add -j .bss too
09:32 AM polprog: just in case
09:32 AM mmfood: it works now ^^ thanks
09:33 AM mmfood: what is the bss?
09:33 AM MrFahrenheit: I don't think bss is needed since it's uninitialised data
09:33 AM polprog: Uninitialized global or static variables end up in the .bss section
09:33 AM polprog: http://www.atmel.com/webdoc/avrlibcreferencemanual/mem_sections.html
09:35 AM polprog: woohoo got vim on windows 7
09:35 AM polprog: gvim*
09:36 AM mmfood: thanks folks! appreciate the help
09:39 AM polprog: i like your tmux setup
09:43 AM mmfood: maybe you can answer a few more questions or point to relevant litterature: The clock is defined in the code with #define F_CPU 1000000UL Which I am guessing means 1 MHz. In the makefile however I am using -B8 flag. but it still seems to work with _delay_ms(). If I change the code to #define F_CPU 8MHz though it is 8x as slow. If I change the flag to -B1 the device isn't recognized by the programmer. This seems very confusing to me. Is F_CPU changing the fuse of
09:43 AM mmfood: the controller?
09:43 AM polprog: not at all
09:43 AM polprog: F_CPU is only used for calculations inside _delay_ms and _delay_us functions
09:44 AM mmfood: right, so F_CPU should then reflect the clock of the MCU
09:44 AM polprog: yeah, and the clock is set with the fuses
09:44 AM mmfood: for _delay_xs() to work correctly
09:44 AM polprog: exactly :)
09:45 AM mmfood: ok, and is the fuses set with the -B flag or no?
09:45 AM polprog: no
09:45 AM polprog: b sets the programming speed
09:45 AM mmfood: or is the -B flag essentially the same thing as the F_CPU but for the programmer/avrdude?
09:47 AM polprog: i never changed -B so i dont know, the documantation says it should be higher for slower targets
09:47 AM polprog: http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#Option-Descriptions
09:57 AM mmfood: polprog: seems like it was only a thing for ICE? removed it and it worked fine
10:10 AM enh: hi
10:15 AM MrFahrenheit: -B is only useful if your MCU is set to such a low clock that the normal programming speed is too fast for it
10:16 AM mmfood: ok
10:19 AM mmfood: for the atmega328, does PORTC need some code to set it to a normal digital port? I have the cathodes connected to them and I cannot seem to set them individually, setting PORTC = 0bxxxxxxxx only seems to dim the current for each pin, not actually turning them on and off?
10:19 AM MrFahrenheit: did you set the ddr?
10:20 AM mmfood: DDRC = 0xff
10:20 AM mmfood: they shouldn't be inputs, right?
10:21 AM MrFahrenheit: correct
10:21 AM day__ is now known as daey
10:22 AM MrFahrenheit: best to check the voltage with a multimeter to see what's happening
10:24 AM mmfood: I have the digits connected to PC0-3 which get a current of 1.9V with PORTC = 0b01010101; PC4 is 3.3V and pc5 is ~0V
10:27 AM enh: 1.9V is a voltage...
10:27 AM mmfood: sorry, yes of course, 1.9V voltage :)
10:28 AM mmfood: 0b11110000; gives 0.15V on pc0-3 and 4.10V on pc4-5
10:30 AM MrFahrenheit: can you show us the code
10:32 AM mmfood: https://gist.github.com/mmFooD/973acfc8ca434f86df71e03ac6a8fb3d
10:34 AM MrFahrenheit: looks fine, maybe your wiring is the issue then
11:04 AM polprog: you can show us the schem if you have one
11:05 AM mmfood: http://hackyourmind.org/public/images/display7seg_anim.gif
11:05 AM mmfood: it is basically that one, but without the transistors
11:06 AM polprog: umm
11:06 AM mmfood: Maybe it is a current sinking/sourcing issue
11:06 AM polprog: in this case you have to write 0 to light up a digit
11:06 AM mmfood: yes
11:08 AM mmfood: but no matter what value the individual bits are set to, every digit is lit but depending on the bits the segments are more or less bright
11:09 AM mmfood: you would think that 0b00000010 would lit the second digit and turn the others low, but it doesn't
11:09 AM mmfood: sorry 0b11111101
11:11 AM mmfood: 0b11111101 doest' seem to light them at all but I am guessing that it is just barely doing so
11:12 AM Thrashbarg: maybe try and get just one to light up, then work from there
11:14 AM Thrashbarg: also how have you wired it to need to pull down an output to make it activate a transistor?
11:14 AM mmfood: that is what I'm doing though. But no matter how I manipulate the 8bit sequence every digit is lit up
11:15 AM mmfood: I am not using the transistors
11:16 AM mmfood: are they necessary?
11:16 AM Thrashbarg: okay so you're trying to drive up to 7 LEDs off one pin?
11:16 AM Thrashbarg: I'd recommend using them, just because it'd reduce the load on the digital output. IIRC they can only sink up to 20ma
11:16 AM mmfood: hmm yeah, I guess
11:17 AM Thrashbarg: what value resistors are you using?
11:17 AM mmfood: what would the resistor values be for the base?
11:17 AM Thrashbarg: 10k approx
11:18 AM mmfood: for the anodes, 220R atm
11:19 AM Thrashbarg: okay good. Doesn't explain how you can't make them turn off...
11:19 AM mmfood: is it interchangable to use pnp with low output and npn with high output?
11:20 AM Thrashbarg: you'd need a common anode on the 7-seg displays to use a PNP
11:21 AM mmfood: right
11:25 AM mmfood: holy shit, I worry sometimes, I just put every connection on the digits in parallell omitting the dp and cathode, but I forgot to omit the SECOND CATHODE PIN! Such an idiot!! haha
11:41 AM polprog: umm, those cathodes are connected inside
11:42 AM polprog: what kind of transistors, what resistors at the base are you using
11:46 AM rue_house: hmm whats up?
11:47 AM polprog: we're trying to crack what's wrong with a 4x7 segment display
11:47 AM polprog: setup
11:47 AM rue_house: so its that array without the transistors
11:47 AM polprog: yea
11:47 AM rue_house: ok, do we get to see the code?
11:48 AM polprog: i think the transistors would be useful there
11:48 AM polprog: since his resistors are only 230R for the segments
11:48 AM rue_house: not neccissarily needed for an avr tho
11:48 AM mmfood: now it's with the transistors
11:48 AM rue_house: but I'd suggest about 330 to 470 ohms
11:48 AM polprog: using the transistor as a digital switch
11:49 AM polprog: i use 1k for leds... at vcc=5V
11:49 AM rue_house: one of the important tricks is, to turn off ALL the commons before you set up the next digit
11:49 AM rue_house: aka turn off commons 1-6, then set the new segments, then turn on the common you want
11:50 AM rue_house: otherwise the segments will "smear"
11:50 AM polprog: that makes sure you dont have any "ghosting" due to spare capacitance, and ill add a tiny delay
11:50 AM polprog: i would*
11:50 AM polprog: like 1ms
11:50 AM polprog: or 500u
11:50 AM rue_house: one nop with sort io timing
11:50 AM rue_house: who is doing it?
11:50 AM polprog: mmfood
11:51 AM rue_house: mmfood, can you post your code?
11:51 AM rue_house: OR tell me what pins you have connected and I can show you an example
11:54 AM Casper: ... https://i.imgur.com/vOuhTd5.jpg <=== how to diagnose a laptop power button issue please don't mind the mess and the trash...
11:55 AM polprog: Casper: mess..? trash? you should've seen my bench
11:55 AM polprog: :PP
11:55 AM rue_shop3: mmfood, ?
11:55 AM mmfood: the issue was I had connected the second anode pin for all digits. That is why everything would lite up at once. But I added the transistors anyway. So it was working as expected. A part from one of the digits not seeming to work
11:56 AM polprog: grab a meter and test the voltages
11:56 AM rue_shop3: mmfood, if its a pre-assembled array, that prolly means you accidently burned it out
11:56 AM mmfood: it isn't
11:57 AM rue_shop3: oh, one segment right across the display?
11:57 AM rue_shop3: mmfood, to really help ya, we need more into
11:57 AM rue_shop3: info even
11:57 AM polprog: told you take a meter
11:57 AM polprog: and measure the voltage at the segment pin
11:57 AM polprog: it's probably a loose cable/resistor
11:57 AM rue_shop3: or you fogot to set the io pin to be an output
11:58 AM polprog: nah, he sets the ddr to xFF
11:58 AM MrFahrenheit: Casper, we're doing similar things https://dl.dropbox.com/s/dviuwpcnwyzbv6n/2017-09-14%2018.29.02.jpg?dl=0
11:58 AM polprog: luckily there are test pads to tap into
11:58 AM polprog: :P
11:59 AM rue_shop3: MrFahrenheit, whats the protocol?
11:59 AM MrFahrenheit: I managed to figure out which was which using an ohm measurement, which was neat
11:59 AM MrFahrenheit: i2c + interrupt
11:59 AM rue_shop3: polprog, which ddr on what avr?
11:59 AM rue_shop3: its a touchpad eh?
11:59 AM rue_shop3: laptop
11:59 AM rue_shop3: ?
11:59 AM polprog: rue_shop3: in his code, both segment and cathode DDR
12:00 PM rue_shop3: polprog, is there source we can look at?
12:00 PM polprog: https://gist.github.com/mmFooD/973acfc8ca434f86df71e03ac6a8fb3d that's his code
12:00 PM mmfood: it is working now
12:00 PM MrFahrenheit: it's a touchpad yes, turned out it needed a ~30us delay before a repeated start to spit out data, and only a repeated start would work
12:01 PM polprog: MrFahrenheit: what did you expect in a laptop, most laptop guts use i2c or SMbus
12:01 PM polprog: most computers do
12:01 PM MrFahrenheit: turns out that in 2017 48mhz arm core chips need 30us to spit out a static 30 byte buffer, who knew *rolls eyes*
12:01 PM polprog: im surprised the touchpad isn't PS/2
12:01 PM Casper: the laptop is relativelly well built
12:01 PM Casper: except the power button
12:01 PM MrFahrenheit: it's i2c hid, but it's very liberal with the i2c part of the protocol, hence the issues
12:02 PM polprog: which make and model?
12:02 PM Casper: designed to fail
12:02 PM polprog: some hell i see
12:03 PM Casper: they designed it so there is a small cross that press the tiny recessed switch
12:03 PM rue_shop3: digiti select is wrong
12:03 PM Casper: if the switch have any defect it won't work, if the button have any wear it won't work
12:03 PM rue_shop3: should be FE FD FB F7
12:03 PM Casper: it's a 0.5x0.5mm pin that press the button....
12:03 PM polprog: for stuff like that it's better to use binary notation
12:06 PM rue_shop3: mmfood, hey
12:06 PM rue_shop3: you see that
12:07 PM rue_shop3: #define d1 0xfe
12:07 PM rue_shop3: #define d2 0xfd
12:07 PM rue_shop3: #define d3 0xfc
12:07 PM rue_shop3: #define d4 0xfb
12:07 PM rue_shop3: should be
12:07 PM mmfood: polprog: you where saying I was using the sizeof(digit) wrong?
12:07 PM rue_shop3: #define d1 0xFE
12:07 PM rue_shop3: #define d2 0xFD
12:07 PM polprog: mmfood: yeah you were sizeof'ing an array
12:07 PM rue_shop3: #define d3 0xFB
12:07 PM rue_shop3: #define d4 0xF7
12:08 PM mmfood: https://gist.github.com/mmFooD/973acfc8ca434f86df71e03ac6a8fb3d
12:08 PM mmfood: this is the code now
12:08 PM polprog: argh
12:08 PM polprog: you are sizeof'ing an array again
12:08 PM mmfood: https://stackoverflow.com/questions/37538/how-do-i-determine-the-size-of-my-array-in-c
12:08 PM MrFahrenheit: polprog, nothing wrong with that though
12:08 PM mmfood: oh
12:09 PM rue_shop3: mmfood, I suggest turning things off before switching
12:09 PM polprog: ah, my bad... it's sizeof'ing a pointer which is wrong ::P
12:11 PM rue_shop3: PORTC = number(a)
12:11 PM mmfood: rue_shop3: are you sure that uppercase is necessary=
12:11 PM polprog: yes
12:11 PM rue_shop3: its not, just a preference
12:11 PM polprog: oh
12:12 PM rue_shop3: mmfood, try this....
12:12 PM rue_shop3: for me
12:12 PM rue_shop3: https://paste.debian.net/986376/
12:14 PM rue_shop3: oh I think I have C and D backwards
12:14 PM rue_shop3: sorry no schematic :)
12:15 PM rue_shop3: mmfood, do I have it backwards?
12:15 PM rue_shop3: PORTC <-> PORTD
12:15 PM mmfood: rue_shop3: yes
12:15 PM rue_shop3: ok, if you change those 3 lines, does it work?
12:16 PM rue_shop3: https://paste.debian.net/986377/
12:16 PM mmfood: rue_shop3: the only thing you added was the nop() define and call?
12:17 PM rue_shop3: "yes"
12:17 PM rue_shop3: and you wrote to the wrong port
12:17 PM rue_shop3: see, you wrote both to PORTD
12:18 PM rue_shop3: https://gist.github.com/mmFooD/973acfc8ca434f86df71e03ac6a8fb3d
12:18 PM mmfood: yes it is kind of working now, the loop is working but the digit selects are messed up
12:18 PM rue_shop3: mmfood, did it work?
12:18 PM rue_shop3: out of order?
12:19 PM rue_shop3: if there are transistors, you MIGHT need a longer delay of off
12:19 PM rue_shop3: try 3 nops
12:19 PM rue_shop3: avrs are fast, and the transistors, driven like that, might not be able to keep up
12:20 PM mmfood: https://paste.debian.net/986380/
12:20 PM rue_shop3: oh!!!
12:20 PM rue_shop3: hahahaha
12:20 PM rue_shop3: mmfood,
12:20 PM rue_shop3: d1 is 1 ok
12:20 PM rue_shop3: d2 is 2, ok
12:20 PM rue_shop3: d3 should be 4
12:20 PM rue_shop3: and d4 should be 8
12:20 PM rue_shop3: hahahah
12:20 PM mmfood: *facepalm*
12:20 PM rue_shop3: shame on me for not catching that
12:21 PM mmfood: shame on me for writing it ^^
12:21 PM rue_shop3: do not use 1ms tho
12:21 PM rue_shop3: its tooo long
12:21 PM rue_shop3: will effect your brightness
12:21 PM rue_shop3: use the nop
12:21 PM rue_shop3: you prolly only need 1 or 2 nops
12:22 PM mmfood: ok, so now, what is the best way to make this a countdown timer in mm:ss :P
12:22 PM rue_shop3: you want real seconds or ya dont care?
12:22 PM rue_shop3: https://paste.debian.net/986381/
12:22 PM mmfood: it should be as accurate as possible
12:23 PM rue_shop3: right, so you making a bomb timer, ok
12:23 PM rue_shop3: so you want seconds, with a short beep to accomidate every second passing
12:23 PM mmfood: what is the difference between using delay_ms and nop ? I see it has something to do with assembly but what exactly
12:23 PM rue_shop3: you running at 1Mhz, hmm
12:24 PM polprog: additionally a wire which chut makes the time go faster
12:24 PM rue_shop3: the nop is WAAAAAY shorter
12:24 PM rue_shop3: yes, so there needs to be a 2x config pin
12:24 PM polprog: nop executes an empty instruction
12:24 PM polprog: it's the legnth of a single cpu clock
12:24 PM mmfood: polprog: wtf ^^
12:24 PM polprog: what
12:25 PM rue_shop3: the cpu does nothing once
12:25 PM rue_shop3: it takes time
12:25 PM polprog: https://en.wikipedia.org/wiki/NOP
12:26 PM rue_shop3: one ms is thousands of nops
12:26 PM mmfood: ok
12:29 PM rue_shop3: we have an argument as to what wire colour you need to use to disable the counter
12:29 PM polprog: red ofc
12:35 PM rue_shop3: mmfood, you need to get more complex, have a timer running with an interrupt every 10000 cycles and use an interrupt to divide that another 100 cycles and yo have your seconds
12:36 PM cehteh: mhm
12:36 PM rue_shop3: or 50 so you can get the half seconds you can use for the double rate config
12:36 PM cehteh: mmfood: when you want exact timing, then you start a timer and never touch it (stop, reset, readjust)
12:37 PM polprog: or use an rtc
12:37 PM cehteh: everything else done by interrupts, for extreme precision schedule a interrupt little early and do a busy wait for the exact time
12:38 PM cehteh: i was thinking about short timespans
12:44 PM mmfood: it shouldn't be less accurate than say half a second in 20 min
12:44 PM mmfood: I am really new to C programming ( guess you noticed that, huh) so I have to read up on the things you are mentioning
12:59 PM polprog: google is your friend
12:59 PM polprog: you can read some tutorials, there are a lot of them
12:59 PM polprog: there is*
01:00 PM mmfood: yep, I will
01:00 PM polprog: and general C programming could be useful, but in a limited way
01:00 PM polprog: since AVR libc is quite different from the usual libraries
01:00 PM polprog: it gives you standard stuff but not much else
01:00 PM cehteh: half a second in 20 minutes is a lot, still with cheap osc or buildin rcosc you get worse precision
01:01 PM enh: good afternoon
01:01 PM polprog: mmfood: what are you building after all
01:01 PM mmfood: but it is always handy to know what method is more precise than others, so as to not travel to far on the wrong road so to speak
01:01 PM polprog: hi enh
01:01 PM cehteh: if you can then syncronize with some external time source, RTC, GPS, or whatever you have, even mains frequency could be ok
01:01 PM enh: hi polprog
01:01 PM cehteh: also there are different things to consider, jitter, drift, etc
01:02 PM polprog: mains frequency is pretty accurate and stable :P many old DIY glue logic clocks used that as a reference :P
01:02 PM cehteh: yes, here in germany clocks operated with that for a long time, iirc it was even mandated by law to be syncronized with the official time
01:03 PM cehteh: often enough you only want to sync with something else, and dont care about real wall clock
01:03 PM polprog: if you are in europe you may thing about that german radio clock... i can remember the name but there are ready made modules for that
01:04 PM cehteh: for such things the internal RC oscillaor is nice too because you can tune the frequency (but quite coarsely)
01:04 PM cehteh: DCF77
01:04 PM polprog: yes!
01:04 PM cehteh: thats synced with the official atomic clocks
01:05 PM thardin: dcf77 is fun. gps is likely most practical
01:06 PM cehteh: dcf77 is cheaper and more precise when you are within its reception area
01:06 PM cehteh: (dcf77 carrier frequency is already syncronized with atomic clocks)
01:08 PM polprog: there were some casio watches that used dcf77 to keep time
01:10 PM mmfood: it is going to be a standalone unit powered from the wall socket
01:12 PM polprog: mmfood: so you're building a clock
01:12 PM polprog: right
01:12 PM polprog: ?
01:15 PM Emil: enh: if you dont care about perf or latency floats are fine
01:15 PM cehteh: RTC's can be pretty accurate
01:16 PM enh: I used int32_t, Emil
01:16 PM enh: banned floats all over
01:16 PM cehteh: :)
01:16 PM cehteh: you should go for stm32 with hardware fpu
01:16 PM enh: I will
01:17 PM Emil: enh: then you understand your figurarative crusification ;)
01:17 PM enh: designing a module fot STM32f303CC
01:17 PM enh: Almost finishing the data workflow, from sensors to servos. removing small bugs now.
01:19 PM enh: rue_shop3: What do you think of the solution we found for the PCA9685? Will it work with the timer set to 20ms and 500hz freq pwm?
01:20 PM Emil: cehteh: do you use arms?
01:20 PM enh: or hands?
01:20 PM enh: maybe even legs, cehteh?
01:20 PM enh: Do you use them?
01:21 PM cehteh: :D
01:27 PM enh: Sorry, Emil. Could not miss it.
01:28 PM enh: amazingly the whole thing compiled.
01:28 PM enh: Am I ready to test it?
02:03 PM mmfood: what is your best online source of information/reference for c programming? I'd like some thorough but introductory reading on the c language.
02:22 PM Casper: mmfood:
02:22 PM Casper: http://www.nongnu.org/avr-libc/user-manual/modules.html
02:22 PM Casper: check that, and bookmark it
02:29 PM Cracki_: any hints regarding execution tracing on atmegas (not xmegas)?
02:30 PM Cracki_: I was already thinking to crank up one uart to 2 Mbaud and instrument my code...
02:30 PM Cracki_: got a dragon, but singlestepping wouldn't be the best idea. I'd like to keep timing undisturbed
02:33 PM mmfood: Casper: Thanks, that is great! But I was maybe more thinking of something that talks about best practices and must-dos and things like that.
02:39 PM MrFahrenheit: touchpad works, but I can never speak of the horrors I have done to this i2c driver to make it work
02:45 PM polprog: MrFahrenheit: let it be only remembered in the code comments
02:45 PM polprog: "abandon all sanity ye who read this file"
02:45 PM polprog: Cracki_: i think if you want realtime debugging, just crank up the uart. you can spit two bytes almost immediately (uart is doule buffered)
02:49 PM Emil: 1Mbaud interrupt driven uart
02:49 PM Emil: You can push shit out plenty fast
02:50 PM Emil: also polprog
02:50 PM Emil: thanks
02:50 PM Emil: I always knew the fact that bytes from UDR are pushed onto the internal shift register freeing UDR almost instantly if there's no previously pending shift out
02:50 PM Emil: but
02:51 PM MrFahrenheit: polprog, the issue is that it's a linux core driver and the changes I made to it cannot be upstreamed... so I'll have to write a custom hid driver just for myself and this touchpad, and I'll hardcode the problematic transactions in it
02:51 PM Emil: for some reason it never occured to me that you can push out two bytes with minimum overhead :D
02:51 PM polprog: Emil: :)
02:51 PM Emil: Hmm
02:51 PM polprog: its even better if you have a 4 channel scope with protocol decoding
02:51 PM Emil: I wonder how many cycles it takes
02:51 PM Emil: I should test that
02:51 PM polprog: it takes to OUTs
02:52 PM Emil: polprog: no I mean at what point is UDR freed
02:52 PM Emil: Is it the same cycle
02:52 PM Emil: one cycle
02:52 PM Emil: or more
02:52 PM polprog: IIRC as soon as you write to UDR it's immediately copied to the tx buffer
02:52 PM Emil: Yeah but we should test it
02:52 PM Emil: because that's pretty kawaii
02:52 PM polprog: yeah
02:53 PM polprog: lemme test how many cycles do two UDR=x nvocations take
02:54 PM polprog: shit i should set up a blog
02:54 PM Emil: polprog: do it faggot
02:54 PM polprog: or make a video... i havent uploaded in 6 months
02:54 PM Emil: ayy
02:54 PM Emil: BUt your videos are like
02:54 PM Emil: educational and shit
02:54 PM polprog: i know
02:54 PM Emil: mine are just a random collection of things I do
02:54 PM Emil: Currently
02:55 PM polprog: water dripping from the pool on the roof, eh?
02:55 PM Emil: Never heard that sayinmg
02:55 PM polprog: it's from Hackers movie :PP
02:59 PM polprog: huh, avr-gcc is not using OUT for uart. It loads two bytes into Z and used STD instead
02:59 PM Lambda_Aurigae: STDs are evil!
02:59 PM polprog: just look at that
03:00 PM Lambda_Aurigae: STD=sexually transmitted disease
03:00 PM polprog: https://puu.sh/xBk5Z/8aba237b88.png
03:00 PM Cracki_: my uart-usb chip can do 2 Mbaud, so I've configured that for now. I'll see what kinda data I can smuggle out among the plaintext stuff :)
03:00 PM polprog: Cracki_: take a look at my screesnot
03:00 PM polprog: and if it's too slow, put some ASM in :P
03:00 PM Cracki_: huh good to know
03:01 PM Cracki_: it'll be slow anyway as I do it right now because I'm buffering the uart myself within freertos
03:01 PM polprog: 0x40 is where it starts, 0x4a is line 5 in C
03:01 PM Cracki_: it's reloading UDR using interrupt
03:03 PM Cracki_: might abuse the other uart for tracing tho... that's not used for anything while I develop
03:04 PM polprog: so... writing a hardcoce value to a register in C takes 6 cycles. (no optimisation)
03:04 PM polprog: hardcoded*
03:05 PM cehteh: depends on the value
03:05 PM polprog: but with -O3 it does an LDI and an OUT
03:05 PM Cracki_: anyone got a tiny protocol for tracing/instrumentation already? this is probably a task for pulseview
03:06 PM polprog: nice
03:06 PM Cracki_: O3 o.o thanks for reminding me I gotta update my toolchain. with O3, the linker disappears all the flash strings upwards of 64k
03:07 PM Cracki_: or at least the code won't read them properly anymore
03:07 PM polprog: huh
03:07 PM polprog: you sure the strings are there?
03:07 PM Cracki_: no, but I'm sure some garbage is printed instead of them
03:07 PM Cracki_: so I suspect it's messing up the RAMPZ
03:07 PM polprog: dont know what's ramps
03:07 PM Cracki_: with O2 it works without problem
03:07 PM polprog: rampz*
03:08 PM Cracki_: RAMPZ is bit 16, so you can address 128k of flash
03:08 PM polprog: ah
03:08 PM Cracki_: its own register
03:08 PM Emil: polprog: wat
03:08 PM Emil: you mean LDI reg val
03:08 PM Emil: or you mean LDI reg val, OUT per reg?
03:09 PM Emil: ah you said already
03:09 PM polprog: yes, with o3, UDR = 0x01 gives: ldi r24, 0x01; out 0x0c, r24
03:09 PM Emil: with -O0 it does?
03:10 PM polprog: no, with o0 it loads the byte to one reg, then loads the full 16 bit address to Z and then uses an ST to write to SRAM
03:10 PM polprog: k e k
03:10 PM polprog: optimize your stuff children
03:10 PM Cracki_: indeed
03:10 PM Emil: :D
03:10 PM Emil: t o p
03:10 PM Emil: k e k
03:11 PM Emil: W E W
03:11 PM Emil: E
03:11 PM Emil: W
03:11 PM polprog: with o3 it cant go any fatser eben in hand written assembly
03:11 PM Emil: Hey I could meme square on irc
03:11 PM polprog: but can you triforce
03:12 PM Emil: polprog: I don't think I've ever tried
03:12 PM Emil: polprog: show me how it's done
03:12 PM cehteh: when you want extreme tight timings and speeds read the datasheet exteme carefully
03:12 PM cehteh: some instructions and registers have some latch/delay which may cause troubles
03:12 PM Emil: cehteh: you don't even need to read it that carefully :D
03:12 PM Emil: cehteh: can you mention a few?
03:12 PM polprog: Emil: http://knowyourmeme.com/memes/newfags-cant-triforce
03:13 PM polprog: yeah, im curios which registers do that
03:13 PM cehteh: no i only remeber that i read about that
03:13 PM Emil: polprog: yeah but that since I've never tried
03:13 PM Emil: polprog: I'm no newfag
03:14 PM Emil: https://emil.fi/jako/kuvat/2017-09-16_22-42-58_ef2JXrrY.png
03:14 PM cehteh: sei/cli ... for example blocking interrupts is one cycle (instruction fetch) later iirc
03:14 PM Emil: this is UNACCEPTABLE
03:14 PM Emil: cehteh: hm?
03:14 PM cehteh: you need to be carefaul about memory barriers and stuff
03:15 PM cehteh: i cant remember the details (currently dont doing avr programming) but there where some nasty corners which may lead to races
03:39 PM day__ is now known as daey
03:43 PM mmfood: https://paste.debian.net/986407/
03:44 PM mmfood: ok so I created the function to print the time on the four 7 segment led's. But now I have to implement the timer
03:45 PM mmfood: this code ^--- generates an error for undesigned reference to clock and _CLOCKS_PER_SEC_
03:46 PM Emil: the fuck is that nop doing there?
03:46 PM polprog: rue told hit to add it for delay
03:46 PM mmfood: I was told to use it to avoid smearing the digits
03:47 PM polprog: mmfood: byt your #define does nothing
03:47 PM Emil: wat
03:47 PM Emil: Yeah I wouldn't listen to rue :D
03:47 PM polprog: that NOP() define is like his signature :PP
03:48 PM mmfood: ok, sounds logical though to use as small a delay as possible, no?
03:48 PM day__ is now known as daey
03:50 PM mmfood: is line 33 necessary?
03:51 PM mmfood: https://www.tutorialspoint.com/c_standard_library/c_function_clock.htm
03:51 PM mmfood: what does the first line of main() do in that tutorial?
03:53 PM MrFahrenheit: looks like it's declaring 3 badly named variables
03:53 PM MrFahrenheit: of type clock_t
03:53 PM MrFahrenheit: t in the variable name presumably standing for time, but it looks very confusing indeed
03:54 PM cehteh: note that the clock stuff on AVR-libc works slightly different
03:54 PM cehteh: (or not at all when you dont care for petting the timer)
04:03 PM polprog: mmfood: you can use regular (computer) c tutorials only to some extent
04:04 PM polprog: the queastiom is do you wanna learn "normal" C and then learn the quirks of avr-libc or go straight to avr-libc and then learn the quirks of "computer C"
04:07 PM mmfood: for now, the latter
04:07 PM Emil: Eh
04:08 PM Emil: "Computer C", where you have abundant resources, you just handle memory
04:08 PM Emil: With uc C, where you have limited resources you don't allocate memory
04:08 PM Emil: Otherwise they are identical pretty much
04:10 PM mmfood: Emil: ok, so do you know why https://paste.debian.net/986407/ doesn't work?
04:28 PM Emil: mmfood: "doesn't work" is pretty vague
04:28 PM Emil: do you have an error message?
04:29 PM polprog: #include <time.h>
04:29 PM polprog: what
04:29 PM Cracki_: there is no time.h in avr
04:30 PM polprog: the avr-libc time.h doesnt work like the usual one does i think...
04:30 PM Cracki_: not that I know of
04:30 PM polprog: ther is http://www.nongnu.org/avr-libc/user-manual/group__avr__time.html
04:30 PM Cracki_: if you want convenience, perhaps arduino :P
04:30 PM mmfood: error is "undefined reference to 'clock'" and "undefened reference to _CLOCKS_PER_SEC_"
04:30 PM polprog: i didnt believe that but lol
04:30 PM polprog: mmfood: well yeah since the avr's time.h doesnt have that
04:30 PM Cracki_: you need to set up a timer to be your clock
04:31 PM Cracki_: http://www.nongnu.org/avr-libc/user-manual/group__avr__time.html#ga15aea81a8985a4c3cc9c8b00a06f5d31
04:31 PM polprog: heh TIL
04:31 PM polprog: interesting
04:31 PM Cracki_: indeed
04:31 PM Cracki_: I just use freertos and use the scheduler tick
04:32 PM polprog: wow
04:32 PM polprog: that file is definitely what i need
04:32 PM polprog: holy shit
04:47 PM polprog: night
04:51 PM Emil: good night
05:15 PM mmfood: https://sites.google.com/site/qeewiki/books/avr-guide/timers-on-the-atmega328
05:17 PM mmfood: found this, and the first code example seems to be applicable (clock / prescaler * 1 second -1 = 1e6 / 64 * 1 - 1 = 15624 = 3d08) but where would I put the code to execute when the timer has reached the desired interval?
05:20 PM Cracki_: get the data sheet, if you haven't.
05:20 PM Cracki_: contains some code examples in assembly and C
05:21 PM Cracki_: but the definitive data for the whole chip
05:21 PM Lambda_Aurigae: mmfood, look up timer interrupt tutorials
05:21 PM Cracki_: what you ned is an ISR
05:21 PM Cracki_: interrupt service routine
05:22 PM Cracki_: you write ISR(...) { code here } and "..." is the name for the interrupt, such as TIMER1_OVF_vect
05:22 PM Cracki_: will vary depending on type of avr
05:25 PM Cracki_: to set up a timer, you'll touch the TCCR0A/B and maybe even C registers (timer0)
05:27 PM mmfood: so like the second example in that link essentially?
05:30 PM Cracki_: yes
05:31 PM Cracki_: understand the modes a timer can operate in (WGM bits)
05:31 PM Cracki_: also how the timer counts and when interrupts are flagged
05:31 PM Cracki_: for playing, it doesn't matter, but there are intricacies to know if you need to get it right
05:33 PM mmfood: https://paste.debian.net/986418/ did this, it is a bit fast =) but it kind of works :p
05:36 PM enh: http://www.avrfreaks.net/forum/tut-c-newbies-guide-avr-timers?page=all
05:40 PM enh: http://www.popsci.com/cassini-final-images-saturn?CMPID=ene091617&spMailingID=30631625&spUserID=ODY3MTA1ODU4NjMS1&spJobID=1121956579&spReportId=MTEyMTk1NjU3OQS2
05:42 PM mmfood: is the timer frequency connected to the clock frequency? meaning do I have to connect an external crystal at 16MHz to run timer1 (16MHz)?
05:43 PM Cracki_: as for timers are clocked at system freq
05:43 PM Cracki_: at least one timer can be clocked completely independently from anything else
05:43 PM Cracki_: as their name implies, they "count" pulses, also from pins
05:44 PM Cracki_: the two means of controlling a timer's speed are the prescaler and the TOP (?) value
05:49 PM enh: https://www.youtube.com/watch?v=ELG4wWESDC8
05:52 PM enh: First four modules talking to each other.
05:56 PM cehteh: Cracki_: correct
05:57 PM cehteh: Cracki_/mmfood: and watch out for race conditions when reading a timer, esp within other interrupts
05:57 PM Cracki_: within interrupts, doesn't matter.
05:58 PM cehteh: esp there it matters
05:58 PM Cracki_: outside of interrupts, be be aware that 16 bit reads are NOT atomic
05:58 PM Cracki_: so an ISR can crash your party while you read a 16 bit value
05:59 PM cehteh: when you are in a handler, the timer still spins and may overflow
05:59 PM Cracki_: a certain way of reading a 16 bit timer register ensures that both bytes are of the same point in time
05:59 PM cehteh: while the overflow isr is delayed because you are in a handler
05:59 PM Cracki_: eh, that, yes
05:59 PM cehteh: so you need to take the interrupt bit into account
06:00 PM cehteh: on the other hand, when you dont use interrupts every timer has one bit more precision than advertized, that overflow/interrupt bit
06:00 PM cehteh: but you have to read and clear it timely
06:00 PM Cracki_: use ISRs
06:01 PM Cracki_: I see little point in polling interrupt flags
06:01 PM Cracki_: it makes code simpler, true...
06:01 PM cehteh: i have some somewhat complex code which using a windowed priority queue to schedule events
06:02 PM cehteh: usually yes ISR's are the way to go, but sometimes they come into the way, when you need very short and precise timing
06:08 PM mmfood: https://paste.debian.net/986425/
06:08 PM mmfood: this is what I got now
06:09 PM mmfood: line 46 - 66 is where the magic is (not) happening
06:16 PM mmfood: as I understand it, when the timer is compared and matched to the set value, the ISR is called. But then what? continue where we left off, ie in the while loop? The next iteration of the while loop? or simply recall the main() functiojn?
06:16 PM enh: This is a nice article on timers and avrs http://www.avrfreaks.net/forum/tut-c-newbies-guide-avr-timers?page=all
06:18 PM Cracki_: that's a COMPare event. some timer modes continue counting until overflow, some reset the value.
06:19 PM Cracki_: 328p datasheet http://www.atmel.com/Images/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_datasheet.pdf
06:19 PM Cracki_: contains EVERYTHING
06:19 PM Cracki_: the pdf has bookmarks to all chapters, just jump in
06:20 PM Cracki_: timers have 2-3 compare registers and corresponding compare interrupts. they also have an overflow interrupt.
06:21 PM Cracki_: timers can be reset at compa value or at a configurable TOP value, or at a "natural" MAX value.
06:22 PM Cracki_: ICR (input capture register) can serve as a TOP value, you don't have to capture an input event
06:22 PM Cracki_: (icr means the counter runs and on some input event (edge on pin), the current timer value is copied to ICR and an interrupt is flagged)
06:31 PM mmfood: the datasheet says "When the AVR exits from an interrupt, it will always return to the main program and execute one more
06:31 PM mmfood: instruction before any pending interrupt is served" but my question is: where does it return?
06:31 PM Cracki_: to what was interrupted
06:32 PM Cracki_: an interrupt does this: save the program counter and jump to the ISR
06:32 PM Lambda_Aurigae: mmfood, wherever it was executing...main loop or some subroutine or wherever.
06:32 PM Cracki_: the ISR then is responsible for pushing any registers it's gonna touch, and restore them after it's done
06:32 PM mmfood: so if I run an infinite while loop, it will then jump back to continue that loop ?
06:32 PM Cracki_: right
06:32 PM Cracki_: as if nothing ever happened, except the ISR was executed
06:33 PM Lambda_Aurigae: the interrupt routine just stops what's happening in the main program and starts the interrupt..hence the name...interrupts what's going on...then returns back like it never happened,,mostly.
06:34 PM Lambda_Aurigae: interrupts just like on your PC....there's things called IRQ...interrupt request...
06:34 PM Cracki_: interrupt request queues actually (afaik)
06:34 PM Cracki_: avrs don't have that, they just have interrupt flags
06:34 PM Lambda_Aurigae: pretty much.
06:34 PM mmfood: ok so I put in a print_time() call in the ISR and it seems to be working as intended. So now it only remains to decrement the counter from within the ISR
06:35 PM Cracki_: and depending on interrupt enable flag (cli/sei), ISRs are executed as soon as an interrupt flag is set (well, an instruction later or so)
06:35 PM Lambda_Aurigae: but same effect...interrupt the main program and jump to a subroutine then return where it was.
06:36 PM mmfood: can I send a pointer as an argument to the ISR?
06:37 PM Cracki_: nope, there are no arguments. the ISR has access to global vars tho
06:38 PM Lambda_Aurigae: make sure those variables are declared volatile,,,if you need to change said variable in the ISR.
06:40 PM Cracki_: compilers try to be smart. if they think a variable can't change, they optimize and stop checking the variable all the time... volatile says to NOT be smart, and just do what the code says
06:40 PM Cracki_: because an ISR _could_ come in and touch the variable.
06:40 PM Lambda_Aurigae: remember to make your interrupts as small as possible.
06:40 PM Cracki_: rule of thumb. I have interrupts that take tens of microseconds because there's no alternative.
06:40 PM Lambda_Aurigae: update counters, set a register or three, set a flag variable, etc...then return.
06:41 PM Lambda_Aurigae: long interrupts run the risk of causing you to miss other interrupts..specially fast timers.
06:41 PM mmfood: https://paste.debian.net/986428/
06:41 PM Cracki_: 16-20 instructions per microsecond, depending on system clock
06:42 PM mmfood: I've set the volatile on current time, but decrementing it in the ISR doesn't work. It is flickering at about 1Hz though so I know it is entering the ISR
06:43 PM Cracki_: "doens't work"?
06:44 PM Cracki_: what's your F_CPU?
06:44 PM Cracki_: 16 mhz? less?
06:45 PM Cracki_: 1 mhz?
06:45 PM mmfood: I'm using only 1MHz I think
06:45 PM Cracki_: k
06:45 PM mmfood: 1M / 64 -1 = 3d08
06:45 PM Cracki_: yeah I checked that
06:45 PM Cracki_: ok so the ISR _should_ execute
06:46 PM Cracki_: you can check that by toggling an output pin on entry and exit of the ISR
06:46 PM Cracki_: just PORTx ^= _BV(bitnumber)
06:46 PM Cracki_: or perhaps only on entry
06:46 PM Cracki_: to verify the isr is active
06:46 PM mmfood: it is, verified by the flickering caused by the print_tim() command which is implementing a 20ms delay, enough to flicker the leds
06:46 PM Cracki_: ah ok
06:46 PM Cracki_: so what's happening? I'd expect current_time to decrement
06:47 PM mmfood: me too
06:47 PM mmfood: ^
06:47 PM mmfood: ^^
06:47 PM Cracki_: is print_time running as expected?
06:47 PM Cracki_: does the loop run?
06:48 PM mmfood: well the leds are showing the correct values
06:49 PM Cracki_: depends... that only says that _at least one_ call of print_time() succeeds
06:49 PM mmfood: print_time(1200) => 20:00 and changing it to 1199 => 11:59 and the loop is what is calling the fucntion, so it should be running
06:49 PM Cracki_: it may be the one in the ISR< or the one in the loop
06:49 PM Cracki_: the isr is also doing a print_time
06:49 PM mmfood: yes, but a different value
06:49 PM Cracki_: ah
06:50 PM Cracki_: uh
06:50 PM Cracki_: I'm a bit confused by that for a=0..3 loop
06:50 PM Cracki_: it writes a whole digit to the port
06:50 PM Cracki_: assuming you have 8 leds to that whole port attached
06:50 PM Cracki_: but then only waits 2 ms
06:51 PM Cracki_: I'm sure the port only displays the tens of minutes
06:51 PM Cracki_: and portc is always 0x08
06:51 PM Cracki_: well almost always
06:52 PM Cracki_: are you probing this with a logic analyzer, or do you see it with the naked eye?
06:52 PM mmfood: not 100% on what you mean but I've tried to print different values and it seems to be working
06:53 PM Cracki_: the behavior of that print function is on the order of milliseconds
06:53 PM mmfood: the digit[] array is declared in the top of the document
06:53 PM Cracki_: and it'll show the first 3 digits only very briefly
06:53 PM Cracki_: ah, a 7seg display?
06:54 PM Cracki_: ah! now i get it, portc is the digit selection
06:54 PM mmfood: If I call print_time(1200) where 1200 / 60 = 20 min 00 seconds I get 20:00, and print_time(1199) gives 11:59
06:54 PM mmfood: yesa ^^)
06:55 PM Cracki_: odd. I'd remove the print_time from the ISR
06:55 PM Cracki_: or put the there only
06:55 PM Cracki_: *it there
06:55 PM mmfood: yes, it is only there to indicate that it is entering the ISR at all
06:55 PM Cracki_: ic
06:55 PM Cracki_: ok try adding "register" to the current_time definition
06:55 PM Cracki_: if that works, volatile didn't work
06:56 PM Cracki_: ah lol
06:56 PM Cracki_: check where all you defined current_time
06:56 PM Cracki_: twice...
06:56 PM Cracki_: shadowed
06:56 PM Cracki_: crank up the compiler warnings
06:56 PM Cracki_: -Wall -Wextra
06:56 PM Cracki_: the isr gets the global var, the loop gets the local var
06:58 PM mmfood: dude, thanks!
06:58 PM mmfood: that is it!
07:00 PM Cracki_: -pedantic
07:00 PM Cracki_: -ansi
07:00 PM Cracki_: -masochistic
07:09 PM Lambda_Aurigae: -compilewhatIwantnotwhatItyped
07:09 PM Cracki_: -sammich
07:16 PM enh: -readmymind
09:59 PM rue_house: -keyboarddelay
10:44 PM Cracki: ugh freertos queue stuff takes too long. I can still receive at 115200, but at 1e6 the interrupt takes too long
10:45 PM Cracki: so either custom buffer before sending to queue, or live with fast uart that's send-only
11:37 PM day__ is now known as daey