#avr Logs
Sep 29 2017
#avr Calendar
12:33 AM day__ is now known as daey
01:06 AM JanC_ is now known as JanC
07:52 AM mmfood: what is better performance wise in principal; setting a bit only after checking if it is not already set. Or just set it nomatter what? Trying to learn some idioms here ")
07:52 AM LeoNerd: Those are different operations
07:53 AM LeoNerd: They might actually do different things depending on the situation. Eg. bit operations on actual peripheral registers
07:55 AM mmfood: well the scenario is to make sure an LED is turned on after returning from another mode of operation where the LED was blinking
07:56 AM mmfood: so should I do PORTC |= (1 << LED_pin) or is it better to put that in an if statement ?
07:56 AM LeoNerd: Well in this case a PORT register isn't dynamic on reads
07:56 AM LeoNerd: You can just set that anyway
07:57 AM Cracki_: mmfood, if it's memory, it's a load, modify, store. check out what the compiler actually does. iirc it was like 5 instructions
07:57 AM LeoNerd: setting bits on PORT registers is a single instruction
07:57 AM LeoNerd: A conditional test / maybe-skip / set is at least 3
07:57 AM Cracki_: if it's an actual "port" (lower 32 addrs), there are assembly instructions, 1 cycle, for setting/clearing bits. the compiler chooses those if it can and you did the 1<<foo thing
07:58 AM Cracki_: also: if you test before modifying, an ISR can crash your party
07:58 AM Cracki_: it's not atomic...
07:58 AM Cracki_: and you might write back outdated bits
07:58 AM mmfood: ok, so better to skip the if conditional then
07:58 AM Cracki_: so if it's important, make sure you know who all is writing that address
07:58 AM polprog: of course it's faster to set it no matter what. you can peek at output assembly if you wanna see why
07:58 AM Cracki_: ya skip the test
07:58 AM LeoNerd: I usually keep a clear separation of zones, where I touch any particular peripheral
07:58 AM LeoNerd: Usually ISRs don't get to touch anything
07:59 AM Cracki_: "zones" meaning either ISRs or main program
07:59 AM LeoNerd: Occasionally I might decide that some timer or PORT or whatever is allowed in one interrupt, but then main doesn't get it
07:59 AM LeoNerd: Yah
07:59 AM Cracki_: you can guard using util/atomic.h
08:00 AM LeoNerd: Eh, no
08:00 AM Cracki_: ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {}
08:00 AM LeoNerd: Oh, in that sense
08:00 AM LeoNerd: Yeah, that's still not perfect though
08:00 AM Cracki_: it's cli and restoring sreg
08:00 AM Cracki_: that makes it atomic
08:00 AM LeoNerd: E.g. that won't help you fiddle with the I²C module if you're using an interrupt to wait for completion
08:00 AM LeoNerd: Yes, that makes operations *atomic*
08:00 AM LeoNerd: That won't in itself make it safe to fiddle with a peripheral
08:00 AM Cracki_: huh
08:00 AM Cracki_: well then encapsulate the peripheral :P
08:00 AM Cracki_: command queues and stuff :P whatever you need
08:03 AM mmfood: so instead of doing bit operations in the ISR I should have them set some volatile variable which would then be checked in the main loop?
08:04 AM polprog: yeah
08:04 AM polprog: that would be the best way
08:05 AM mmfood: what about pin reads (&) ? are they as bad?
08:05 AM polprog: if you are penny pinching every cycle then learn assembly, otherwise, let the compiler optimize it
08:06 AM LeoNerd: ???
08:06 AM LeoNerd: There's nothing wrong with interacting with peripherals inside an ISR
08:06 AM LeoNerd: The problem comes if you do that in an ISR *and* elsewhere for the same peripheral. It starts to get tricky to manage the locking nicely
08:06 AM mmfood: ok
08:06 AM LeoNerd: But e.g. inside a PCINT ISR it's quite common to read the associated PIN register to work out what happened
08:07 AM Emil: mmfood: you are hurting your learning by adhering to "never do x" or "you must always do it like this"
08:07 AM LeoNerd: I quite often keep a 'static uint8_t was_pin' inside those too, so I can compare to last time and detect rising/falling edges
08:08 AM polprog: i remember i did that in one of my asm programs
08:09 AM polprog: i had a .equ'd (kindof like #define macro) a memory location adress for use with st and ld :D
08:10 AM mmfood: Emil: I guess that is true, but should be good to have some basic strats though?
08:11 AM polprog: r e a d t h e s h e e t
08:12 AM mmfood: polprog: what sheet would that be? the mcu datasheet?
08:12 AM polprog: yeah
08:12 AM mmfood: it is a biig sheet though ") I didn't think it would mention programming specifics like this. Does it?
08:13 AM polprog: generally there's always two or more ways to do something in programming, and neither is best, because it depends on the circumstances
08:13 AM polprog: in most cases there are code examples in C and assembly
08:13 AM mmfood: polprog: allright, I'll have a look
08:19 AM Emil: polprog: actually
08:19 AM Emil: well
08:20 AM Emil: the libc and the datashit
08:20 AM Emil: Both
08:20 AM Emil: But like polprog said, with microcontrollers and high performance computing you need to tailor your program to the situation
08:22 AM polprog: just by writing in C you would be on average 30x faster than the same thing implemented in Arduino :P
08:24 AM LeoNerd: HAH
08:24 AM LeoNerd: Yes, well.. :)
08:40 AM noHitW_work: hi
09:04 AM Cracki_: check out what digitalwrite does in arduino
09:04 AM Cracki_: it disables any timers that could touch the pin
09:04 AM Cracki_: sets direction and all
09:05 AM Cracki_: it's user friendly, but not efficient
09:06 AM Cracki_: same as poking gpios on a pi via proc fs
09:10 AM noHitW_work: yes arduino is meant for hobby projects so user-friendlyness is more important than performance
09:11 AM polprog: yes
09:12 AM LeoNerd: Arduino is fine if you treat it like Lego. It's a good teaching toy to play and learn with some fundamental building blocks
09:12 AM LeoNerd: But real engineers don't build real buildings out of Lego :)
09:18 AM noHitW_work: you can also use it as usb-uart bridge, or config it to be a i2c slave for testing for example
09:25 AM noHitW_work: i used to hate android studio but now im really starting to like it since im not a complete noob with it anymore
09:26 AM noHitW_work: it gives me useful coding tips
09:27 AM rue_: an arduino is, however the least expensive carrier board for an avr
09:27 AM tpw_rules: ^
09:27 AM rue_: most of the time, an arduino is cheaper than the avr thats on it
09:29 AM LeoNerd: Yah; the Nano and Mini boards are nicely cheap for what they are
09:29 AM LeoNerd: I still have mixed opinions of the Micro, aka the board carrying the 32U4. It has several of the pins missing
09:29 AM rue_: yes, but its got the crystal and reset circuit, and a minimal voltage regulator if you want
09:30 AM LeoNerd: Yah but so do other better 32U4 boards
09:30 AM LeoNerd: E.g. Adafruit make a nice one
09:31 AM tpw_rules: those cost more than $2 tho
09:31 AM LeoNerd: With the 328P-based Arduinos, the pin mapping is easy and makes sense. What they call D0 to D7 are just PD0 to PD7, then D8 to D13 are PB0 to PB5, then A0 to A5 are PC0 to PC5
09:31 AM LeoNerd: Whereas, the 32U4-based Micro has a totally bizarre pin mapping that appears to make no sense whatsoever until you realise they tried a bit to put similar peripherals in similar places
09:32 AM LeoNerd: If you get a non-Arduino 32U4 breakout board, you tend to get all the pins and the pin names make sense
09:33 AM noHitW_work: this is nice board with 328PB http://www.mouser.fi/ProductDetail/Microchip-Technology-Atmel/ATMEGA328PB-XMINI/?qs=sGAEpiMZZMuo%252b9%2fB%2fzhRUsjcQCddc5OuUMgIW%252bZMxMfvqohCNMkSUg%3d%3d
09:33 AM noHitW_work: and cheap
09:34 AM LeoNerd: Huge though
09:34 AM noHitW_work: huge?
09:34 AM LeoNerd: The ones I make are much smaller ;)
09:34 AM noHitW_work: its quite small
09:35 AM LeoNerd: https://www.tindie.com/products/leonerd/atmega328pb-development-board/ mine
09:35 AM rue_: I used to make my own generic avr carrier baords, so, arduinos have been handy that way
09:35 AM LeoNerd: Though I'll admit they have me at a cost advantage
09:35 AM noHitW_work: if i had known, i would have bought yours
09:36 AM rue_: http://ruemohr.org/~ircjunk/avr/babyboard_mk3/babyboard_III.html
09:36 AM noHitW_work: but it doesnt matter anymore since we changed mcu, since they are not available
09:36 AM rue_: yea, $22 vs $2.20
09:37 AM rue_: the 328P isn't available anymorte?
09:37 AM noHitW_work: pb
09:37 AM rue_: ah
09:37 AM noHitW_work: nice board LeoNerd
09:38 AM LeoNerd: The PB has stock flow issues currently
09:38 AM rue_: china wont let anyone else have any?
09:39 AM LeoNerd: No idea. It's quite a new chip; could be that they underestimated demand for the initial production run
09:39 AM rue_: all the M8u* were like that too
09:39 AM rue_: m8?
09:39 AM LeoNerd: https://www.mouser.co.uk/Search/Refine.aspx?Keyword=atmega328pb mouser have *nothing*
09:39 AM rue_: m32u*?
09:44 AM mmfood: this might be the wrong way of doin it, but why wouldn't this work?
09:44 AM mmfood: #define LED_min PD7
09:44 AM mmfood: #define LED_sec PB2
09:44 AM mmfood: #define flip_pin(port,pin) (PORT##port ^= (1 << pin))
09:44 AM mmfood: #define blink_min (flip_pin(D, LED_min))
09:44 AM LeoNerd: Ahhh pasting :)
09:45 AM LeoNerd: You _can_ do it but you need an additional layer of macro for seemingly-no apparent reason
09:45 AM LeoNerd: Define yourself a #define PASTE(a,b) a##b and use -that- in the other one
09:46 AM rue_: I wonder how many times I need to paste set and clear bit macros before someone gets them
09:46 AM rue_: I should go back to posting common macros every day
09:46 AM mmfood: ^^
09:47 AM rue_: mmfood, if its a newer avr, you can toggle the pin by
09:47 AM rue_: writing a 1 to the PIN register
09:48 AM LeoNerd: Hah.. ohyes, that
09:48 AM mmfood: rue_: you mean just substituting PORT for PIN basically? why would that matter though?
09:48 AM LeoNerd: If it's an xmega you can toggle the pin by writing to its toggle register because those are not batshit-crazy
09:49 AM rue_: you dont have to use ^= and it dosn't ahve to read-modify-write using instructions
09:50 AM noHitW_work: https://www.tindie.com/products/leonerd/atmega328pb-isolated-application-board/
09:50 AM noHitW_work: 3$?
09:51 AM noHitW_work: how can this be so cheap
09:51 AM LeoNerd: That's $3 for the bare PCB
09:51 AM LeoNerd: See the dropdown on the righthand side. If you want me to stick components on it it'll cost more :)
09:52 AM rue_: volume
09:52 AM LeoNerd: It's slightly annoying the way Tindie's page works which means if there's a choice it defaults to showing the price for the absence of having made a decision yet
09:52 AM rue_: ah
09:53 AM LeoNerd: second+third photos show what just the bare PCB looks like
10:19 AM polprog: should i define a struct in the .c, .h or both files?
10:20 AM LeoNerd: Not both, surely.
10:20 AM LeoNerd: If it needs to be visible to other, the .h. If not, the .c.
10:20 AM polprog: ok
10:23 AM bss36504: Always typedef your structs too
12:19 PM antto: -std=c++11 ;P~
12:52 PM polprog: oh shit... done for today
12:53 PM polprog: the best part is when you hunt a bug for an hour and it turns out you forgot to add a delay between slave select and data transfer, heh
12:54 PM polprog: learned a lot
01:03 PM HighInBC: polprog: race conditions are notoriously hard to diagnose
01:03 PM HighInBC: did it work sometimes but not always?
01:03 PM polprog: no, it never worked
01:04 PM polprog: the scope definitely helped
01:04 PM HighInBC: scope's are great
01:04 PM HighInBC: not having a multimeter is like being blind, having a multimeter but not having a scope is like seeing only in still images
01:04 PM polprog: having a bus pirate is like being able to talk
01:07 PM Lambda_Aurigae: I like my logic pirate clone
01:10 PM polprog: yeah, it looks nice.
01:10 PM polprog: i wonder if that java app would work with the saelae clone i have. pulse view is sometimes cumbersome
02:27 PM Lambda_Aurigae: not sure.
02:27 PM Lambda_Aurigae: one way to find out...try it!
02:27 PM Lambda_Aurigae: off to the doctor...
03:48 PM Cracki_: PV will work with saleae clones of the fx2(lp) kind, and some others
03:48 PM Cracki_: join #sigrok and ask
04:28 PM polprog: yeah, i know
04:28 PM polprog: all im sayin is that it needs just a bit more tweaking
04:28 PM polprog: a dark background + phosphor like traces theme would be sweet too
04:51 PM polprog: http://blog.presentandcorrect.com/27986-2
04:52 PM polprog: actually, that would be sweet as hell. Green, tektronix blue and amber for LA traces
05:22 PM mmfood: https://pastebin.com/nhY8XZqu
05:22 PM mmfood: I am having issues with the set_mode variable being changed, seemingly arbitrarily at times (on button press). And not following the pattern 0 -> 1 - > 2 -> 0 ...
05:22 PM mmfood: And also the LED_min and LED_sec is not blinking consistently when in mode 1 vs mode 2 respectively. It is merely alternating between full brightness and a bit faded or sometimes from 0V to a little brighter. Then seemingly it starts to work as expected but after toggling and returning to the same mode again it is acting up again. It might be a bit much to ask for a complete code review but maybe someone could notice something faulty. It doesn'seem to be a
05:22 PM mmfood: hardware issue since bridging the pin to 5V gives full power.
05:23 PM mmfood: I'm thinking that the LED_xxx ports are being set somewhere else in the code which would effectively act as pwm I guess. But I can't find a line where that would occur.
05:30 PM mmfood: https://pastebin.com/y6N9FmHP
05:30 PM mmfood: I guess these macros from the header file could be of use
09:00 PM Snert: bum link
09:01 PM Snert: times out after way too short :)
11:54 PM Tom_itx is now known as Tom_L