Back
[08:42:14] <hje841> How do I use <util/atomic.h> with C11? avr-gcc complains that ATOMIC_BLOCK() is only valid for C99. How do I do similar things with C11?
[08:43:10] <LeoNerd> I don't tend to bother with C-level atomic stuff; just do the cli() ... trick
[08:43:28] <LeoNerd> { char saved_SREG = SREG; cli(); do atomic things here... SREG = saved_SREG; }
[08:46:49] <hje841> LeoNerd, Thanks. :) I guess that could be the way to save a value in one ISR and then read the same value in another ISR
[08:47:02] <LeoNerd> That's how I do it
[08:47:45] <LeoNerd> The saved_SREG trick incidentally, is so that the code doesn't disturb the I flag if it was already disabled. Means the above block can be called from both SEI and CLI-like contexts
[08:48:35] <hje841> what's the difference between SEI() and CLI()?
[08:49:14] <LeoNerd> Er..?
[08:49:19] <LeoNerd> Surely... whether interrupts are enabled :)
[08:49:49] <LeoNerd> What I mean is that theabove code doesn't -change- the state of interrupts by the end... whereas if you just did { cli(); ... sei(); } you might enable interrupts as a side-effect if they weren't enabled before you started
[08:51:45] <hje841> LeoNerd, ahh, I see. that makes sense. I'll put that snippet in my 'notebook' :)
[08:53:03] <LeoNerd> I have a little structure similar to that which I use in most of my tiny code; it basically implements a ppoll()-like interface
[08:58:27] <hje841> Here's a snippet from my current project
http://paste.debian.net/148894/ and I'm looking for the best way to ensure atomic r/w of the global variable
[08:59:45] <LeoNerd> Oh.. that's sufficient
[09:00:16] <LeoNerd> ISRs run with interrupts blocked; unless you specifically reënable interrupts again by doing sei() inside one, no ISR will ever interrupt another one
[09:00:43] <hje841> even with the different levels?
[09:00:46] <LeoNerd> If you read/write that variable *outside* of an ISR, then you'll have to protect it
[09:01:00] <LeoNerd> Yes, the levels just select which ISR runs first
[09:01:07] <LeoNerd> If multiple are pending
[09:01:46] <hje841> that helps a lot :)
[09:02:05] <hje841> I was worried they would cause nested execution
[09:02:21] <LeoNerd> Only if you ask for it, by doing sei()
[09:03:20] <hje841> that makes ISR's so much easier to deal with :)
[09:03:27] <LeoNerd> Mhmmm
[09:03:34] <LeoNerd> Though also means they should be short...
[09:03:55] <LeoNerd> I usually just do a very minimal fetching of some registers, poking flags and whatnot, then leave most of the real work to my main event loop
[09:06:12] <hje841> I can understand that. I'm looking into the examples on the avr-libc website. They seem to have most of the code in ISR's and then only a while(true){} loop in the main function
[09:06:33] <LeoNerd> Yeah, I dislike that style
[09:08:10] <Tom_itx> best to get in and out of ISRs asap
[09:10:39] <hje841> I agree.
[09:20:39] <Lambda-Aurigae> values that need to change in an isr need to be declared volatile.
[09:26:45] <ecilop> or _memoryBarrier
[09:26:49] <Lambda-Aurigae> also, isn't OCR1A an 8bit value?
[09:27:01] <Lambda-Aurigae> just sayin,,,
[09:27:25] <Lambda-Aurigae> oh
[09:27:26] <Lambda-Aurigae> guess not.
[09:27:29] <Lambda-Aurigae> there is a high and low.
[09:27:40] <ecilop> T1 is 16bit
[09:27:58] <Lambda-Aurigae> yeah...
[09:28:01] <Lambda-Aurigae> it's too early yet.
[09:28:07] <Lambda-Aurigae> not noon...I haven't had lunch.
[09:28:23] <Lambda-Aurigae> and I'm suffering from drywall dust inhalation this morning.
[09:28:39] <Lambda-Aurigae> wifey has made me w*rk this morning.
[09:30:28] <Tom_itx> awww
[09:31:04] <Tom_itx> that's a 4 letter word ya know
[09:31:06] <Lambda-Aurigae> yeah..it's terrible.
[09:31:10] <Lambda-Aurigae> hence the *
[09:31:17] <malinus> I hope you are not using drywall as a building material in a area with a lot of wind, just to complain when you house flys away.
[09:31:25] <malinus> *your
[09:31:30] <Lambda-Aurigae> don't want to get banned for cursing.
[09:31:36] <Lambda-Aurigae> malinus, inside non-structural wall.
[09:31:48] <Lambda-Aurigae> this flippin house is sooooo not square.
[09:31:56] <Lambda-Aurigae> having to cut and paste bits to fill in gaps.
[09:32:08] <Tom_itx> i sometimes wonder if new ones are anymore
[09:32:20] <Lambda-Aurigae> the old section of the house is over 100 years old.
[09:32:50] <Lambda-Aurigae> and it was moved 6 miles up the road about 80 years ago...the owner at the time got mad at his neighbors and moved it with a team of mules.
[09:32:56] <Tom_itx> mine's ~70-80
[09:33:27] <Tom_itx> try driving a modern 16 into those studs
[09:33:44] <Lambda-Aurigae> took out a pseudo-wall between old dining room and old living room..it had some columns and very very old trim..
[09:33:56] <Lambda-Aurigae> wanted to save the trim and all but it just splintered sooo bad when I pulled it off.
[09:34:21] <Lambda-Aurigae> 1x8 trim
[09:34:29] <Lambda-Aurigae> matching it is gonna be a pain.
[09:34:40] <Lambda-Aurigae> the old walls are lath and plaster..
[09:34:49] <Tom_itx> i removed all that in mine
[09:35:12] <Lambda-Aurigae> I took out the columns and left the 1.5 feet of wall on either end then built a frame up in the opening even with the surface of the plaster...
[09:35:14] <Tom_itx> easier than patching all the cracks
[09:35:24] <Lambda-Aurigae> drywall is up and just patching the gaps today.
[09:35:39] <Lambda-Aurigae> also put a pocket door in...homemade all the way.
[09:36:24] <Lambda-Aurigae> my steel C channel and bearing rollers are stronger than the kits at the hardware store.
[09:37:14] <Tom_itx> if i were to make one i'd probably use garage door guide
[09:37:35] <Lambda-Aurigae> I used some odd C channel I found...it's more like G channel really.
[09:38:34] <Lambda-Aurigae> and used some heavy duty bearings out of an old copier for the rollers.
[09:38:56] <Lambda-Aurigae> and a piece of L shaped iron along the top of the door to bolt the bearing/rollers to.
[09:39:13] <Lambda-Aurigae> the door will rot away and that track and rollers will still be there.
[10:03:27] <tpw_rules> help. i'm dumb. i can't add two 9-bit signed numbers in assembly
[10:04:40] <tpw_rules> i'm adding the two 8 bit components using 'add'
[10:04:50] <tpw_rules> then i add the signs by putting them in bit 0 and using aedc
[10:04:52] <tpw_rules> adc*
[10:06:23] <tpw_rules> but where is the new sign bit? is it in bit 0 of the second result? that's not working correctly it seems
[10:20:44] <Lambda-Aurigae> http://www.avr-asm-tutorial.net/avr_en/beginner/CALC.html
[10:21:47] <Lambda-Aurigae> actually, I think your math is a bit off there.
[10:22:01] <Lambda-Aurigae> you can't just add the two 8bit components..because one of them might be negative.
[10:22:29] <Lambda-Aurigae> but the last 8bits of a 9 bit signed integer will always be positive..the 9th bit determines if it is positive or negative.
[10:23:30] <Lambda-Aurigae> you will have to determine whether each is positive or negative first by testing the 9th bits of both...then determine whether to add one to the other, subtract one from two or subtract two from one.
[10:48:21] <tpw_rules> Lambda-Aurigae: i'm so far trying to sign extend them and add as 16 bit
[12:31:22] <Jartza> hmmh
[12:31:31] <Jartza> avr-gcc / avr-libc doesn't have support for attiny841?
[12:33:15] <LeoNerd> If it's new enough it should be fine
[12:33:18] <LeoNerd> I write for tiny841
[12:33:43] <LeoNerd> It is quite a new chip though, so maybe older installations might not notice. avrdude doesn't ship with config for it, but it's easy enough to add
[12:34:43] <Jartza> yeah, avrdude now shows the chip
[12:34:52] <Jartza> gcc version 4.9.2 (GCC)
[12:35:25] <Jartza> and avr-libc seems to be 1.8.1
[12:39:49] <Jartza> I used this
https://github.com/WeAreLeka/homebrew-avr
[12:39:54] <Jartza> as I'm using mac
[12:45:33] <rue_more> LeoNerd, you should paste us the section for it!
[12:46:01] <LeoNerd> Eh.. I just copied it from something online
[12:48:22] <Jartza> http://www.ve7xen.com/blog/2014/03/07/programming-the-attiny841-with-avrdude/
[12:48:23] <Jartza> there
[12:48:33] <Jartza> but doesn't really help me as the compiler can't compile :)
[12:49:06] <LeoNerd> ii gcc-avr 1:4.8.1+Atme amd64 GNU C compiler (cross compiler fo
[12:49:10] <LeoNerd> ^-- is the version I use. That knows it
[12:49:12] <Jartza> but hmm. avr-libc 1.8.1 is the latest
[12:49:21] <LeoNerd> ii avr-libc 1:1.8.0+Atme all Standard C library for Atmel AVR
[12:49:51] <Jartza> well. avr-gcc 4.9.2 does not recognize :o
[12:50:08] <Jartza> http://pastebin.com/3pUZJmgz
[12:50:58] <LeoNerd> Weird. Mine works fine; avr-gcc -std=gnu99 -Wall -Os -DPRIMARY_stklone -DF_CPU=14745600 -mmcu=attiny841 ...
[12:52:09] <Jartza> maybe it's some kind of patched version
[12:53:21] <Jartza> oh... you're using the "atmel avr toolchain"
[12:53:26] <Jartza> which is not available for osx :(
[12:54:20] <LeoNerd> Ah
[12:54:36] <Jartza> sad
[12:54:41] <Jartza> because the attiny841 is very nice package
[12:54:52] <Jartza> there are few nice features
[12:55:01] <LeoNerd> Yup. I'm already using it
[12:55:11] <Jartza> I really like the separate pull-up register
[12:55:37] <LeoNerd> Oh? I hadn't noticed that
[12:55:58] <Jartza> yeah. pull-ups can be also enabled even if using pin for output
[12:56:21] <Jartza> which makes it easy to switch pin from output to input in one clock, without caring about enabling pull-up
[12:56:53] <LeoNerd> Ooohyes, PUEA/PUEB
[12:57:12] <LeoNerd> I remember being confused that the attiny84 didn't know PUEB so just presumed I must have imagined it
[12:57:31] <Jartza> also the differential adc has x100 gain
[12:57:40] <LeoNerd> Yes this seems much nicer than reusing the PORTx register for pullup enable
[12:57:45] <Jartza> yep
[12:57:58] <LeoNerd> My main interest in the '841 is that it's a small tiny with a UART
[12:58:05] <Jartza> yeah
[12:58:08] <Jartza> that too
[12:58:16] <LeoNerd> I'm using it for my STK500 clone to do HVSP
[12:58:17] <Jartza> the only strangeness is the i2c
[12:58:20] <Jartza> it's only slave :D
[12:58:38] <LeoNerd> Yeeeees
[12:58:39] <LeoNerd> Most weird
[12:58:48] <LeoNerd> I mean, it's not *that* hard to bitbang I2C as a master
[13:05:51] <vsync> question, asf's spi driver for arm - when you set the module up for transfering lsb first
[13:06:17] <vsync> when you do a read, will it be lsb or msb
[13:06:32] <vsync> the result it stores in the buffer
[13:25:17] <rue_more> http://www.robot-electronics.co.uk/acatalog/I2C_Tutorial.html
[13:25:26] <Jartza> mmmkay. I need to bake my own recipe for homebrew
[13:25:27] <Jartza> https://github.com/fmfi-svt-gate/avr-toolchain-patches
[13:25:34] <Jartza> there are patches
[17:37:44] <zerowidth> how do i get avr-objdump to include source along with the assembly? -S doesn't do anything, what am i missing?
[17:38:07] <tpw_rules> what do you mean?
[17:38:09] <zerowidth> i'm using the crosspack-avr makefile, which compiles with `avr-gcc -Wall -MMD -Os -DF_CPU=$(CLOCK) -mmcu=$(DEVICE)`
[17:38:14] <tpw_rules> it can't make C source out of thin air
[17:38:24] <tpw_rules> objdump will only ever give you the disassembly
[17:38:43] <zerowidth> i'm talking about the --source argument, which will (if the right debug info is available?) intermix the source
[17:39:04] <tpw_rules> oh. then i'm not sure. you might have to compile an elf but pass -g to avr-gcc
[17:39:07] <zerowidth> but it seems i don't have the necessary debug in my .elf file (or even the .o file?)
[17:39:13] <zerowidth> ah, -g, i'll look at that
[17:40:08] <zerowidth> oh! perfect!
[17:40:10] <zerowidth> that worked, thanks!
[17:40:33] <tpw_rules> that embeds debugging symbols and stuff
[17:42:57] <zerowidth> got it. nice! this helps a ton
[19:17:36] <zerowidth> is there an easy way to get avr-gcc to use OUT to write to e.g. PORTA instead of using LDI and ST? i'm using the PORTA |= _BV(...) style, but PORTA is wrapped with a _SFR_IO8 macro so it has 0x20 added and it falls outside the address space for the OUT command. should i just switch to inline assembly?
[19:24:51] <zerowidth> different -Os versus -O3 doesn't matter. hmm.
[19:31:38] <Casper> if it do not use the OUT it mean it's out of range, unless there is a bug
[19:31:55] <Casper> double check to be sure that you really can use OUT...
[19:34:24] <zerowidth> according to the datasheet, OUT can operate on addresses up to 0x3F, and PORTB is 0x1B
[19:34:29] <zerowidth> on the attiny84a
[19:36:29] <zerowidth> seems the PORTA being defined with _SFR_IO8 means it has 0x20 added to it since the register's memory-mapped which makes it accessible to instructions that operate on normal memory
[19:40:42] <zerowidth> pretty sure it should work, just not sure how to get the compiler to generate it. i'll figure out how to do inline asm and try that instead.
[19:45:05] <zerowidth> even 0x1B + 0x20 is 0x3B, which should also still work with OUT
[21:28:19] <zerowidth> ah, if you tell GCC not to optimize something, it turns out it won't