Back
[01:28:42] <idiot2> hello
[04:10:52] <idiot2> http://quinndunki.com/blondihacks/?p=1106 :) m4 macro asm
[08:37:47] <EI24> hi, how do i move the adress of a label into two registers?
[09:53:28] <LeoNerd> More AVR Assembly questions now: I see there's instructions for conditionally skipping the next instruction based on various conditions, like individual set bits in IO registers..
[09:54:12] <LeoNerd> But the status register isn't in the range those can see. There *are* conditional branches though. Am I right in thinking that a conditional branch based on some status register test (like T set/clear), to .+2 is going to effectively just conditionally skip the next instruction?
[09:54:33] <LeoNerd> And furthermore, therefore be constant time regardless of whether it executed or not, presuming the following instruction is a simple 1-word 1-cycle one..?
[10:07:38] <LeoNerd> Mmm... the silence of quiet contemplation, perhaps..? ;)
[10:17:16] <EI24> LeoNerd: the branch instructions for example, jump if induvidual bits in SREG is set OR cleared. BRNE(branch if not equal) for instance, jump if Z bit in SREG is NOT set. BREQ on the other hand jumps if Z bit is set
[10:17:44] <EI24> hope that answered your question
[10:18:01] <LeoNerd> Not really, no
[10:18:49] <jacekowski> LeoNerd: read the avr instruction manual
[10:19:06] <jacekowski> LeoNerd: most instructions are single clock cycle with some exceptions
[10:19:09] <LeoNerd> Yah
[10:19:13] <jacekowski> LeoNerd: and all of those are listed in there
[10:19:18] <LeoNerd> Yes, I'm aware
[10:19:30] <LeoNerd> It's more a matter of carefully double-checking all the various assumptions and implications
[10:20:02] <jacekowski> http://www.atmel.com/Images/Atmel-0856-AVR-Instruction-Set-Manual.pdf
[10:20:08] <LeoNerd> I have it, yes
[10:20:17] <jacekowski> one of the best manuals out there
[10:20:27] <jacekowski> not many other platforms have them as clear and nicely written
[10:21:10] <LeoNerd> OK concrete time: SBRS r24, 7; OUT PORTD, r22
[10:21:38] <LeoNerd> ^-- that pair of instructions will always execute in 2 cycles, with either no effect at all, or by outputting the r22 register to the port, depending on the set bit in r24
[10:21:46] <jacekowski> yes
[10:21:56] <LeoNerd> It is highly important to me that the sequence takes 2 cycles in *either* case.. it has to remain constant-time
[10:22:10] <jacekowski> yep
[10:22:27] <LeoNerd> Right: So my question now becomes: Given there is not a "SZS" (or Skip if Z Set) instruction, I have to use BRZ/BREQ for example.
[10:22:45] <LeoNerd> If I do BREQ .+2; OUT PORTD, r22 will that also have this constant-time property?
[10:23:27] <LeoNerd> And furthermore, since the 'out' instruction doesn't affect the flags, I could in fact continue doing more BREQ .+2; foo pairs of instructions, provided the 'foo' never modifies the flags
[10:23:42] <LeoNerd> And this entire chain would be constant-time
[10:24:14] <jacekowski> BREQ will take longer to execute
[10:25:01] <LeoNerd> BREQ says 1 cycle if false, 2 if true
[10:25:11] <jacekowski> yes
[10:25:19] <LeoNerd> ... which surely is exactly what I want?
[10:25:22] <jacekowski> actually, i've counted it again
[10:25:24] <LeoNerd> And thus achieves constant time
[10:25:44] <jacekowski> basically, if BREQ is false, 1st cycle BREQ, 2nd cycle instruction after it
[10:26:24] <jacekowski> BREQ is true, 1st cycle BREQ, 2nd cycle nothing (it is actually nothing as pipeline was flushed), 3rd cycle instruction that it branched to
[10:26:38] <LeoNerd> So that sounds constant-time to me
[10:26:57] <LeoNerd> Effectively that BREQ +2 is "Skip if EQ"
[10:27:11] <jacekowski> yes
[10:27:14] <LeoNerd> \o/
[10:27:49] <jacekowski> i'm not 100% now if you don't actually want to make that +1
[10:28:11] <LeoNerd> It's "+1 instruction", but since addresses are 16bit wide, it's +2 no?
[10:28:18] <LeoNerd> Oh.. maybe not
[10:28:47] <jacekowski> you want +1 there
[10:28:51] <jacekowski> it's in instructions
[10:28:53] <LeoNerd> Ah OK
[10:29:06] <jacekowski> PC itself is an address
[10:29:26] <LeoNerd> so for my next challenge: how to write simple UART buffer-management entirely without branches
[10:29:56] <LeoNerd> I think it involves lots of abuse of the T bit and some spare registers to store bitflags
[10:30:10] <jacekowski> but if you were coding the opcodes with k in bytes rather than instructions
[10:30:16] <jacekowski> you would waste that bit
[10:30:22] <jacekowski> as it always has to be 0
[10:30:25] <LeoNerd> Ahyes...
[10:31:08] <jacekowski> now, it's a very compiler specific
[10:31:33] <jacekowski> not on AVR, but i remember coding for a platform where it was automatically divided by the assembler
[10:31:40] <LeoNerd> That's OK, I'm not using a compiler here. ;) I'm hand-writing my assembly
[10:31:45] <LeoNerd> I don't know of any compiler that could write what I'm writing
[10:31:55] <LeoNerd> (Which is: two programs nested together inside each other's NOP slots)
[10:32:01] <jacekowski> so you were specifying address in bytes, and it would actually get divided by the assembler
[10:32:16] <jacekowski> LeoNerd: why do you have NOPs?
[10:32:41] <jacekowski> only case where avr-gcc would emit NOPs is when you are using sleep() functions
[10:33:01] <EI24> say im storing at a certain memory place: STS label , r16 . and i continue to store throughout the program, STS label+1 , r16(maybe label+1 is invalid). Is there any risk that i might overwrite some other part of the program?
[10:33:15] <jacekowski> also if you want strict timing, do it with timer interrupts
[10:33:42] <jacekowski> prepare data at your leisure somewhere else and then just send it out/set outputs in the timer interrupt
[10:33:52] <LeoNerd> jacekowski: The first program is a hand-written cycle-accurate WS2812 LED driver.
[10:34:02] <LeoNerd> jacekowski: The second program is a small UART buffer manager, to read DMX control bytes
[10:34:15] <LeoNerd> Hah.. "timer interrupts"
[10:34:29] <LeoNerd> My strict timing requirement is operations of either 6 or 9 cycles long
[10:34:42] <jacekowski> hmmmmmm
[10:34:52] <jacekowski> are you running with 32kHz crystal?
[10:35:15] <LeoNerd> Er.. no
[10:35:17] <LeoNerd> 16MHz
[10:35:22] <LeoNerd> http://pastie.org/10186867 <== this is the LED driver
[10:35:42] <LeoNerd> Into those NOP slots (where JMP .+0 is a 2-cycle NOP) I have to now add this UART management code
[10:35:45] <LeoNerd> Without upsetting the timing
[10:36:08] <jacekowski> hmmmm i don't see that working
[10:36:22] <LeoNerd> This code works just fine. I drove a string of 60 LEDs with it last night
[10:36:22] <jacekowski> hmmm
[10:36:23] <jacekowski> actually
[10:36:30] <jacekowski> i'm reading the manual
[10:36:42] <jacekowski> i didn't expect the LED to work that fast
[10:37:05] <LeoNerd> It's fast. :) And terribly annoying with its async thing
[10:37:17] <LeoNerd> Had I known about them before I started this project I'd have used APA-102s
[10:37:19] <jacekowski> but it seems to do 800Kbps
[10:37:22] <LeoNerd> Those just sit on an SPI chain
[10:37:28] <LeoNerd> Which means timing doesn't matter
[10:37:40] <jacekowski> you can still drive them slower
[10:37:47] <LeoNerd> Usually people drive these LEDs while doing not much of anything important. Except for me, I'm reading a DMX UART
[10:37:54] <jacekowski> as long as the relation between the 6/9 is constant
[10:38:07] <LeoNerd> The absolute speed doesn't matter to me
[10:38:15] <LeoNerd> It's the fact that I can't stop to handle the UART inbetween
[10:38:28] <jacekowski> so you can do it with timer interrupts
[10:38:46] <jacekowski> at slower speed
[10:38:49] <LeoNerd> But I can rely on some fun trickery here.. the UART line speed of 250kBaud means that it takes longer to receive one byte over DMX serial, than it takes to output one byte of LED
[10:38:59] <LeoNerd> Meaning: This LED driver loop only ever has to cope with one byte of input :)
[10:39:25] <LeoNerd> Yeah; I also want to drive 90 LEDs at a good 50fps or so, for animated effects
[10:39:26] <jacekowski> you can use SPI to output this stuff
[10:39:29] <jacekowski> cycle accurate
[10:39:30] <LeoNerd> So I can't do it *tooo* slowly
[10:40:48] <jacekowski> if you set your SPI to by /16, with 8 bits, that gives you 128 cycles for processing before you have to feed SPI with new data
[10:41:23] <LeoNerd> These aren't SPI LEDs
[10:41:32] <LeoNerd> (APA-102s are, these are WS2812)
[10:41:35] <jacekowski> doesn't matter
[10:41:38] <jacekowski> they don't have to be
[10:41:51] <jacekowski> you can still use SPI to just output raw serial data
[10:42:37] <LeoNerd> Yes, I'm aware of the technique to use SPI to do them, by outputting either 0xC0 or 0xFC or somesuch
[10:42:55] <LeoNerd> I'm not convinced it buys me all that much. It'd be about the same number of base cycles per bit (4) anyway
[10:43:17] <LeoNerd> If you look at the core of my driver, there's only 4 non-NOP instructions per bit of LED output.
[10:43:25] <jacekowski> you can set SPI to run slightly slower
[10:43:26] <LeoNerd> One SBRS, three OUTs
[10:43:31] <jacekowski> if you run SPI at 1MHz
[10:43:39] <jacekowski> hmm, actally you would have to run it even slower
[10:43:55] <LeoNerd> To invent the SPI scheme I think I'd need to burn 4 instructions per bit anyway
[10:44:00] <jacekowski> leds will not like 1MHz
[10:44:05] <jacekowski> 500kHz would be probably the max
[10:44:16] <jacekowski> that gives you 32 instructions per bit
[10:44:26] <jacekowski> and you only have to output data every 8 bits
[10:44:31] <jacekowski> so 256 instructions
[10:44:32] <LeoNerd> load [temp] with 0xC0; bittest the byte register => conditionally OR [temp] with 0x3C; OUT [temp] to SPI data
[10:44:36] <LeoNerd> Yeah.. that's 4 instructions per bit
[10:44:44] <LeoNerd> For the same line rate. So I don't save anything
[10:44:51] <jacekowski> no, 32 instructions per bit
[10:44:56] <LeoNerd> Hrm?
[10:45:00] <LeoNerd> The LED timing is fixed here
[10:45:11] <jacekowski> yes, it will run from SPI clock
[10:45:17] <LeoNerd> Nono.. the LEDs aren't SPI
[10:45:18] <jacekowski> AVR clock/32
[10:45:22] <LeoNerd> The LEDs require ABSOLUTE TIME
[10:45:35] <jacekowski> i know
[10:45:36] <LeoNerd> The cycle time of the LEDs is 1.25us per bit
[10:45:42] <jacekowski> but SPI can output raw serial
[10:46:05] <LeoNerd> 16:22 <jacekowski> no, 32 instructions per bit
[10:46:09] <LeoNerd> ^-- blatantly false
[10:46:20] <LeoNerd> I don't have 32 instructions of time, in 1.25us at 16MHz
[10:46:23] <LeoNerd> I have around 20.
[10:46:34] <jacekowski> from the manual i'm looking at, it doesn't have to be 1.25us
[10:46:37] <LeoNerd> Actually, I have exactly 20.
[10:47:04] <LeoNerd> The manual I have says 20, give or take a small error margin, that makes it somewhere between about 18 and 22 cycles.
[10:47:37] <LeoNerd> In any case I'm not entirely sure where this argument is currently going
[10:47:42] <LeoNerd> I say "It's fairly easy, look here I've done it."
[10:48:00] <LeoNerd> However hard /you/ think it is is immaterial, because I've done it and here's the demonstration :)
[10:48:13] <jacekowski> the manual i've got says that this is the fastest the LEDs will work
[10:48:35] <jacekowski> but it does not limit the slowest speed
[10:49:27] <LeoNerd> Ok
[10:49:37] <LeoNerd> Though in practice I still want to drive them as fast as I can :)
[10:49:41] <LeoNerd> 90 LEDs, 50 fps.
[10:50:15] <LeoNerd> That's 4500 LED writes/sec. 3 bytes per LED, is 13500 bytes/sec
[10:50:16] <jacekowski> that is, 24bits per LED, *50*90
[10:50:40] <jacekowski> 108000 bits/s
[10:51:05] <LeoNerd> OK so it seems I do have just over 9usec per bit
[10:51:10] <jacekowski> so with SPI configured so it bitbangs the raw serial
[10:51:13] <LeoNerd> But that then means I have no CPU time left :)
[10:51:17] <LeoNerd> GAHH
[10:51:30] <LeoNerd> You are goign to have to explain your statement QUITE a bit clearer if you want me to believe youknow what you're tlaking about there
[10:51:41] <LeoNerd> "so it bitbangs the raw serial" <== that's a meaningless statment here
[10:51:49] <jacekowski> you can configure SPI hardware so you feed it raw data bytes
[10:51:57] <LeoNerd> SPI outputs a SYNCHRONOUS serial data line, using a separate clock and data output
[10:52:14] <LeoNerd> WS2812 is an ASYNCHRONOUS serial signal using a per-bit NRZ clock recovery
[10:52:14] <jacekowski> and it will just output bit after bit on it's output
[10:52:50] <LeoNerd> If you are suggesting to use the standard trick of outputting 0xC0 or 0xFC to send a short or long pulse, as I said above I'll repeat my analysis: That doesn't buy me anything
[10:53:24] <jacekowski> ah fuck
[10:53:27] <LeoNerd> It's four instructions/bit to do it by SPI, or by raw bitbanging
[10:53:31] <jacekowski> i've just realised something
[10:53:38] <LeoNerd> So I might as well just bitbang it :)
[10:53:58] <jacekowski> you could send 2.666666 LED bits for every SPI byte
[10:54:09] <LeoNerd> Plus my current bitbanging loop happens to have no effect at all on the flags register; meaning I can use that myself for handling the UART driver.
[10:54:10] <jacekowski> not 8
[10:54:28] <LeoNerd> I *could* but that would then take me more CPU cycles to calculate how to pack more into it
[10:54:32] <LeoNerd> So again, I don't think I win :)
[10:54:51] <jacekowski> LeoNerd: i'm working here on assumption that you would run LEDs at minimum acceptable speed
[10:54:59] <LeoNerd> But I don't see why I would
[10:55:06] <LeoNerd> The thing I have *right now* works fine
[10:55:09] <jacekowski> becase you can
[10:55:15] <jacekowski> and it would make other things easier
[10:55:21] <LeoNerd> If you want to sell me on your idea, you'll have to explain what about your idea is better than mine
[10:55:56] <jacekowski> it offloads timing critical stuff to dedicated hardware
[10:56:16] <LeoNerd> I'm not sure that it does
[10:56:23] <LeoNerd> Given I'd have to keep the SPI module well-fed with data
[10:56:29] <LeoNerd> It doesn't have a FIFO so I can't preload it with lots
[10:56:48] <LeoNerd> Interrupt latency would be /wwaaaaaaayyy/ too slow to load it again every time it said it was finished
[10:56:51] <jacekowski> you can preload it with 2 and 2/3rds of LED bits
[10:56:58] <LeoNerd> Which is peanuts-tiny
[10:57:23] <jacekowski> and you have to send 108000 bits/s
[10:57:47] <jacekowski> that would mean 40500.10125025313 SPI bytes/s
[10:58:24] <jacekowski> which isn't that much
[10:58:39] <LeoNerd> Still far too much to interrupt-drive I feel
[10:58:45] <jacekowski> actually, no
[10:58:47] <LeoNerd> This way is nicely simple and self-contained
[10:58:52] <LeoNerd> Fewer moving parts
[10:58:54] <jacekowski> interrupt overhead on AVR is non existent
[10:59:05] <LeoNerd> Given it *HAS* to work by next weekend, I feel that better ;)
[10:59:18] <LeoNerd> I have about 6 days to make it work
[11:00:33] <aandrew> hmm
[11:00:46] <aandrew> avrdude 6.1 doesn't work with avrispmk2?
[11:01:23] <hackvana> Paging Dr. aandrew, paging Dr. aandrew, you're wanted over in ward #hackvana.
[11:01:29] <aandrew> haha
[11:01:40] <hackvana> (You aren't really, I just had the urge to say that)
[11:02:03] <aandrew> oh
[11:02:04] <aandrew> dammit
[11:02:06] <aandrew> ok
[11:02:21] <aandrew> it's dr azonenberg you need ot do that to, he's an official phd I think
[11:03:53] <EI24> ... up till now, i have thought the addresses above the IO regs, where flash.. ofc sts wont overite the program
[11:03:55] <EI24> ..
[11:04:17] <LeoNerd> ?
[11:04:37] <EI24> i asked before if STS could overwrite the program
[11:04:56] <LeoNerd> No, STS is for writing to RAM, not flash
[11:05:02] <LeoNerd> SPM is for writing to flash
[11:05:21] <EI24> yeah i got i all wrong
[11:23:33] <emtrac> Hi, I'm trying to use a ATTiny45
[11:24:50] <emtrac> I'm having trouble using the attiny's PB5 reset pin as an input. I've killed a few chips after setting RSTDIBL fuse, having only an ISP programemr. I still can't get the input to work. Is there anything special about that input. the docs meantion it is a "weak" input.
[11:25:02] <LeoNerd> Umm
[11:25:16] <LeoNerd> If you knock out RSTDIBL then you won't be able to continue programming it using ISP at all
[11:25:33] <LeoNerd> You'd have to be using HVSP at that point
[11:26:35] <emtrac> LeoNerd, yes. I have everything in my code working, except testing the jumper I have on the reset pin as an input to change polarity. Yet, I've set the RSTDISBL pin, and test, but it seems the input is not working. I don't have a HVSP so I just change the chip.
[11:27:07] <LeoNerd> .oO( You could jsut get an HVSP programmer.. ;) I do sell them... )
[11:27:44] <Jartza> anyone used Atmel-ICE with Mac?
[11:27:48] <Jartza> http://pastie.org/10186958
[11:28:04] <Jartza> can't really get it to work (trying to just connect to attiny85)
[11:28:11] <Jartza> avrdude just hangs there
[11:29:43] <emtrac> My voltage to that input seems fine, I was wondering what the docs about the reset pin being a "weak" input meant, as I can't figure out why the input reads the same regaurdles of ~4.5v and < 0.100V with the RSTDSBL fuse set.
[11:29:57] <LeoNerd> Er
[11:30:07] <LeoNerd> The fuse doesn't change the physical electrical properties of the pin
[11:30:29] <LeoNerd> It simply controls whether the CPU core will consider a logic low on that pin to be a request to enter reset/ICSP mode
[11:30:39] <emtrac> But the input isn't working, and of course wouldn't work without the fuse set.
[11:31:30] <LeoNerd> I'd suggest just writing a little tiny logical test program, that echoes the value of PB5 onto, say, PB0, and seeing if that works
[11:31:39] <LeoNerd> Ofcourse somewhat easier if you didn't have to waste another chip on it ;)
[11:33:11] <emtrac> I think I should try that. I'll have the soldier ladies whip me something up.
[11:55:45] <LeoNerd> Also, consider getting an HVSP programmer if you want to work with reset :) [totally blatant plug] like mine =>
https://www.tindie.com/products/leonerd/avr-hvsp-programming-bus-pirate-adapter :)
[12:06:17] <aandrew> heh
[12:06:24] <aandrew> I keep forgetting if you disable the reset pin you must use HVSP
[12:57:30] <twnqx> are the 8u2/16u2/32u2 also preprogrammed with an USB bootloader? the datasheet doesn't mention it
[12:59:59] <LeoNerd> Might depend how you obtain it. My Adafruit 32U4 breakout board has one, but that might be because Adafruit put it on
[13:02:27] <twnqx> all U4 have according to their datasheet
[13:02:32] <twnqx> the question is, do U2 as well
[13:05:48] <twnqx> ah well. time to hit the gym.
[13:25:27] <Lambda_Aurigae> you can put a bootloader on them.
[13:25:45] <Lambda_Aurigae> Tom_itx would know about the u2....he sells boards with them.
[14:47:33] <Tom_itx> they are
[14:47:52] <idiot2> hi
[15:08:21] <N1njaneer> Ugh. I am here, and the new pick and place is on the opposite coast. We need portal technology already!
[15:13:51] <idiot2> N1njaneer, that will cost
[15:15:07] <RikusW> well just teleport into the reserve bank :-P
[15:15:20] <idiot2> :)
[15:15:34] <idiot2> one way trip ?
[15:16:04] <idiot2> you cant eat gold or money
[15:20:30] <RikusW> or rather just open a portal beneath a stack of gold...
[15:28:01] <N1njaneer> True!
[15:28:34] <_methods> there's no gold in there
[15:28:40] <_methods> they gave it all away already
[15:29:00] <_methods> it's full of whiffle balls
[16:15:17] <aandrew> hm
[16:15:20] <aandrew> such trouble
[16:16:53] <aandrew> _delay_ms() seems to get "short circuited
[16:17:43] <Tom_itx> define F_CPU
[16:17:52] <aandrew> it is
[16:18:23] <aandrew> http://pastebin.com/AfSVRtdQ is the code... the green led (GLED5, which is RB0) sometimes briefly flickers, other times is on correctly
[16:18:39] <aandrew> #define F_CPU 1200000UL is at the top of the source file, only one file in this project
[16:19:50] <aandrew> it blows my mind that _delay_ms() takes a double, but the listing seems to suggest the builtin is doing something smarter and I'm not actually using floating point math
[16:20:33] <aandrew> avr-libc's documentation says "The maximal possible delay is 262.14 ms / F_CPU in MHz."
[16:20:48] <aandrew> I'm having trouble parsing that statement
[16:21:29] <aandrew> 262.14ms per F_CPU in MHz, so for 1.2MHz (9.6MHz internal osc / 8) the max delay is 262.14/1.2 or 218ms?
[16:22:46] <aandrew> the decreased resolution clause is fine for me, but it is inconsistent which is what's confusing
[16:38:27] <aandrew> got it
[16:38:38] <aandrew> had a bad connection on the only bypass cap on the board
[16:39:30] <Tom_itx> i'd rather blame the software
[18:50:46] <LeoNerd> Potentially silly question.. but how do I just read a register to reset a pending interrupt, without gcc complaining of an unused variable...?
[18:51:07] <aandrew> hm?
[18:51:31] <aandrew> you mean something like uint8_t foo = read_to_reset(FOO_REG);
[18:51:33] <aandrew> and foo is never used?
[18:51:49] <LeoNerd> Yah
[18:51:57] <LeoNerd> (void)UDR0; doesn't do it
[18:51:58] <aandrew> I use (void)read_to_reset(FOO_REG);
[18:52:01] <LeoNerd> I see no IN instruction
[18:52:02] <aandrew> yeah
[18:52:02] <LeoNerd> Ah
[18:52:05] <aandrew> that's the problem.. hm
[18:52:09] <LeoNerd> What's read_to_reset() ?
[18:52:28] <Lambda_Aurigae> If it's not on fire it's a software problem!
[18:52:45] <aandrew> that's a damn good question. UDR0 is probably defined something like *(uint8_t *)0x50 or someshit?
[18:52:55] <aandrew> as in it's not a funciton
[18:53:13] <LeoNerd> Indeedy
[18:53:14] <aandrew> you may have to make a function to do it and inline it to get a similar thing without a warning
[19:25:20] <LeoNerd> Oh.. huh. my mistake
[19:25:28] <LeoNerd> (void)UDR0; is enough to do it.
[19:25:43] <LeoNerd> Just the output doesn't use an IN instruction, because UDR0 is outside that range, so it's an LD
[19:25:59] <LeoNerd> Seems my bug is elsewhere.. I shall look for it tomorrow
[22:36:49] <blundar> anyone awake and around for an AVR assembly question?
[22:37:06] <blundar> I guess it's as much a question about hardware architecture as assembly...
[22:40:41] <aandrew> 1just ask and see who bites
[23:04:09] <blundar> ISR triggers, push r16; in r16; SREG, push r16 blahISR code blah pop r16; out SREG r16, pop r16; RETI
[23:04:47] <blundar> RETI is needed here to turn interrupts back on because interrupt flag in SREG was cleared by the interrupt being triggered so when you saved SREG, IE was already clear.
[23:04:50] <blundar> right?
[23:06:00] <blundar> so if in a function: push r16; in r16, SREG; pop r16 blahblah function blahblah pop r16; out SREG, r16; pop r16; ret
[23:06:16] <blundar> if IE is set in SREG (interrupts enabled)
[23:06:30] <blundar> and you execute cli in the middle of the function
[23:06:49] <blundar> interrupts will be enabled at the end when you out SREG, r16 from the stack, right?
[23:07:43] <blundar> and also if IE was cleared in SREG at the beginning of the function it will remain cleared at the end when SREG is popped back off the stack
[23:08:31] <blundar> I'm basically wondering if I need to independently track the state of IE or whether I can count on it being preserved by pushing and popping SREG off the stack as part of the entry and exit code in an assembly function
[23:08:42] <N1njaneer> RETI always sets the "I" on interrupt return, so yes, even if CLI'ing in the interrupt (which you shouldn't need to do, since interrupts will already be disabled upon entering the ISR) upon hitting RETI the I flag will be set.
[23:08:59] <N1njaneer> See page 116 in
http://www.atmel.com/images/doc0856.pdf
[23:09:42] <N1njaneer> Good question, though. I'd never really thought about it quite that in depth. :)
[23:11:31] <aandrew> hm, anyone used the 1.1V internal reference on the attiny devices?
[23:12:02] <N1njaneer> aandrew: I just did on a design today actually!
[23:12:08] <N1njaneer> On ATTINY24A
[23:16:26] <aandrew> It's working but I'm off by about 5ish counts at 710mV which is fine, but at 770mV it seems off by 15 counts
[23:16:51] <N1njaneer> Check the datasheet - there's quite a lot of information with regard to linearity and offset errors.
[23:16:53] <aandrew> it can be explained by the reference being off fo 1100mV
[23:17:09] <N1njaneer> They also give some compensation suggestions if ncessary.
[23:17:27] <aandrew> I'm using the adc noise reduction mode as well
[23:17:44] <N1njaneer> Most times I have usually used the ADCs for low battery detection and such, so less critical measurements. Haven't had any major problems, though.
[23:18:21] <aandrew> same here
[23:21:51] <aandrew> I'm also doing 16 conversions and averaging them too
[23:26:23] <aandrew> using the 1:128 prescaler for ADC clock, using 4.8MHz internal RC and /8 (600kHz system clock)... not sure what else I can do here besides try to characterize the reference which doesn't seem possible as on some other devices
[23:28:37] <aandrew> hm, I guess I might be running the ADC too slow
[23:28:52] <aandrew> the ADC characterization talks about 1Mhz and 200kHz
[23:29:08] <aandrew> yeah I'm way out of spec
[23:36:10] <aandrew> 50kHz-1MHz, I'm running at 600kHz/128 or about 5kHz. heh
[23:36:15] <aandrew> the input bandgap is specced at 1.1 with +/- 100mV
[23:36:48] <aandrew> even at 300kHz it's still the same
[23:38:08] <aandrew> I'm seeing 745 counts where I should be seeing 728
[23:38:22] <aandrew> (783mV)