Back
[03:54:09] <Dreamer3_> http://pastie.org/10258038#19-26 anyone know what's going on here?
[04:31:28] <DKordic`> Dreamer3_: I guess it is procedure prologue. Decrementing SP by 8 (bytes) (line 21) for local variables. Saving SREG in r0. Restoring SREG @line 25 because it was modified @line 21. I think there is some GCC option for 'verbose assembly'.
[04:31:42] <Dreamer3_> DKordic`: yeah i figured it out :)
[04:31:48] <Dreamer3_> saving space for variables
[04:32:01] <Dreamer3_> too many variables :)
[04:33:44] <DKordic`> There is also GCC option to refactor prologue epilogue into procedures, sacrificeing speed for FLASH.
[04:37:00] <LeoNerd> gcc is usually terrible at working out what needs to be in prologue/epilogue
[04:37:33] <LeoNerd> I've seen it push r0, r1, zero out r1, make a single move instruction to set a flag in memory elsewhere, pop r1, pop r0
[04:42:20] <Dreamer3_> yeah
[06:13:34] <Dreamer3_> can anyone help mer understand the registers affected docs in the instruction set PDF?
[06:14:37] <Dreamer3_> ok it's talkin about bits
[06:14:42] <Dreamer3_> but why label them R7
[06:14:44] <Dreamer3_> R6
[06:22:23] <LeoNerd> Mmm?
[06:30:10] <Lambda_Aurigae> Dreamer3_, more specifics?
[06:30:13] <Lambda_Aurigae> what instruction?
[06:30:22] <Dreamer3_> i figured it out
[06:30:27] <Dreamer3_> R* is talking about bits
[06:30:32] <Dreamer3_> but i don't know why they put R in front
[06:30:53] <Dreamer3_> http://d.pr/i/bGPw
[06:31:14] <Dreamer3_> R for result i guess
[06:31:38] <Lambda_Aurigae> R: result after instruction is executed.
[06:31:45] <Lambda_Aurigae> first page of the instruction set document.
[06:32:18] <Dreamer3_> it also says Rr: Source register in the Register File
[06:32:23] <Dreamer3_> not very clear to me
[06:32:28] <Dreamer3_> but i get it now
[06:32:39] <Lambda_Aurigae> register file is the first 32 bytes of ram.
[06:32:50] <Dreamer3_> yeah
[06:33:04] <Xark> Dreamer3_: Even on TST page it says "R (Result) equals Rd."
[06:33:05] <Dreamer3_> can you write them with ST?
[06:33:28] <Dreamer3_> yeah i get it now
[06:36:17] <Lambda_Aurigae> yeah...st can write to the entire 64K of sram...however, the register section I believe is actually separate and there is actual ram hidden under it...
[06:36:47] <Lambda_Aurigae> I've run into that before and don't remember what it was that worked and/or didn't....it's been years.
[06:37:36] <Xark> Dreamer3_: Yes. It mentions you can (e.g.) index any GPR with X, Y or Z.
[06:37:49] <Lambda_Aurigae> but, yes, it can write to the register space...first paragraph of the description.
[06:38:23] <Xark> Dreamer3_: Some tiny AVRs have no SRAM, just registers. :)
[06:38:31] <Dreamer3_> whoa
[06:38:34] <Dreamer3_> which ones?
[06:38:39] <Lambda_Aurigae> the little bitty ones.
[06:38:49] <Dreamer3_> tiny9 has ram
[06:38:59] <Dreamer3_> can ya give me one example of a tiny tiny one?
[06:39:11] <Xark> Dreamer3_: Like this one. :)
http://www.linusakesson.net/scene/craft/
[06:39:50] <Xark> Oops...wrong project (but that is cool tool).
[06:39:59] <Dreamer3_> really?
[06:39:59] <Dreamer3_> http://www.atmel.com/devices/ATMEGA88.aspx
[06:40:03] <Dreamer3_> 1kb sram
[06:41:33] <Lambda_Aurigae> attiny 4, 5, 9, 10
[06:41:42] <Dreamer3_> tiny4 has 32b
[06:41:43] <Lambda_Aurigae> all have 32bytes of internal ram..which is the register section.
[06:41:49] <Dreamer3_> hmmm
[06:42:04] <Dreamer3_> does that mean the 2.5kb on the 32u4 includes 32 registers?
[06:42:09] <Lambda_Aurigae> yup.
[06:42:30] <Lambda_Aurigae> and the i/o space actually overlays part of that too.
[06:42:41] <Dreamer3_> doesn't found right
[06:42:42] <Dreamer3_> one sec
[06:43:06] <Xark> Dreamer3_: Here is the one I was thinking of ->
http://www.linusakesson.net/scene/bitbanger/index.php
[06:43:16] <Dreamer3_> http://d.pr/i/1gYOj
[06:43:27] <Xark> ATTiny15, 1K flash and 32 bytes of "registers". :)
[06:43:35] <Dreamer3_> it's in the adress space, yes, but the RAM is separate
[06:43:47] <Dreamer3_> let me pull up the tiny4 PDF for comparison
[06:44:20] <Xark> Hmm, actually I think the registers are in addition to the SRAM (last address is +0x100 vs 2.5K IIRC).
[06:44:31] <hunior> @dreamer3 looks like ISR to me
[06:45:01] <Xark> (plus there are the GPRIO registers that are like SRAM)
[06:45:44] <Lambda_Aurigae> hmm..seems you are right.
[06:46:15] <Lambda_Aurigae> aahh..I remember where I ran into it now...atmega128 with external ram.
[06:46:26] <Lambda_Aurigae> that overlayed everything when I did it wrong/right..
[06:46:34] <Dreamer3_> interesting
[06:46:40] <Dreamer3_> tiny9 doesn't put regsiters in address space
[06:46:54] <Dreamer3_> tiny15
[06:46:58] <Dreamer3_> that sounds tiny
[06:48:17] <Dreamer3_> that's old :)
[06:48:20] <Dreamer3_> replaced by tiny25
[06:48:39] <Dreamer3_> 128b ram
[06:48:56] <Lambda_Aurigae> I prefer the bigger chips...atmega1284p is my favorite.
[06:49:02] <Dreamer3_> crazy no ram
[06:49:05] <Dreamer3_> has eeprom though
[06:49:23] <Dreamer3_> 32 /1kb actually isn't terrible ratio
[06:50:10] <Dreamer3_> ram is just slow :)
[06:50:15] <Dreamer3_> just remove it!
[06:52:18] <Xark> Dreamer3_: When all you need to do is control a few LEDs and a dishwasher door latch, (or whatever), it can work. :)
[06:52:37] <Xark> (Getting a video demo, is "extra credit") :)
[06:58:13] <Lambda_Aurigae> I need to get my AVRs back out just for practice.
[06:58:20] <Lambda_Aurigae> been doing too much PIC32 these days.
[06:58:28] <hunior> allocating an 8 byte stackframe or something?
[06:59:31] <hunior> forget my ISR remark.
[07:00:11] <Dreamer3_> Xark: is there some bettery way to write inline without all this \n quote bullshit nonsense?
[07:02:27] <DKordic`> Dreamer3_: Good question. I guess not.
[07:28:28] <Xark> Dreamer3_: Not really.
[07:28:45] <Dreamer3_> silly, this is why we have computers
[07:29:06] <Dreamer3_> so we don't have to do dumb repetitive things, like end every line with \n"
[07:29:15] <Xark> Dreamer3_: You can put each instruction in its own asm(""), but then you have to write a zillion in out clobber (but lets the compiler reorder things etc.)
[07:29:54] <Xark> Dreamer3_: As I mentioned you can use a .S file and write pure assembler.
[07:30:14] <Xark> Dreamer3_: Not a bad way to go when you don't need to be inline.
[07:30:32] <Dreamer3_> then i'd have to laern how to link it back to C, name functions, etc
[07:30:50] <Dreamer3_> really wouldn't be hard for the compiler to have better syntax for inline
[07:31:20] <Xark> Dreamer3_: If you use Arduino IDE and are making a library, it will automagically assemble it. You just declare it extern "C" function(...) to call it from C/C++.
[07:31:47] <Xark> Dreamer3_: The compiler just passes the string (with \n's and all) to the assembler (with some regs replaced).
[07:34:18] <Dreamer3_> .s files are pretty yucky to parse
[07:34:31] <Dreamer3_> from that argument you gave me
[07:34:46] <DKordic`> Dreamer3_: What do You mean?
[07:34:53] <Dreamer3_> i think all i need for now is inline, just ranting about the ugly code
[07:35:02] <Dreamer3_> DKordic`: the intermedia files, all the NOAPP junk
[07:36:33] <DKordic`> Dreamer3_: OK. There is a difference between '.s' and '.S'. '.S' will invoke CPP first.
[07:37:56] <DKordic`> I agree, such a garbage. BF doesn't seem strange any more.
[07:38:08] <Xark> Dreamer3_: The compiler doesn't try to make "good looking" .s files (although, I think there is -fverbose-asm).
[07:40:06] <Xark> Dreamer3_: For comparison, here is a .S file that I made (6502 emulator).
http://hastebin.com/ujehudigep.avrasm
[07:40:51] <Xark> ...and here it is again without FUBAR'd tabs ->
http://hastebin.com/uvavesevik.avrasm :)
[07:42:17] <Xark> Dreamer3_: For your relatively small function, inline asm might be fine (but it is a bit "ugly"). :)
[07:43:55] <Dreamer3_> The result of these combinations is undefined:
[07:43:56] <Dreamer3_> LPM r30, Z+ LPM r31, Z+
[07:43:56] <Dreamer3_> lol
[07:44:21] <Xark> Dreamer3_: Yes, it is even documented "don't do that".
[07:44:41] <Xark> I think it is OK without +...
[07:45:00] <Dreamer3_> i'd guess + would load it then increment the new value
[07:45:04] <Dreamer3_> but that'd be just a guess :)
[07:45:10] <Xark> (so you can load one into temp reg, then load the other properly then move temp into other half)
[07:45:43] <Xark> Dreamer3_: Well, it may just as well ignore loaded value and increment previous value. :)
[07:46:06] <Xark> Or it may format your hard drive. :)
[07:46:14] <Xark> The point is, don't do it. :)
[07:46:45] * Dreamer3_ does it
[07:46:53] <Dreamer3_> omg, chip exploded
[07:47:48] <Xark> Dreamer3_: It may be unreliable, or different on different AVRs (or even odd address or whatever).
[07:47:59] <Dreamer3_> yeah i understand
[07:48:04] <Dreamer3_> i just found it funny :)
[07:48:10] <Dreamer3_> i see why it would be ambiguous
[07:48:15] <Dreamer3_> or something prone to change across chips
[07:48:42] <Xark> Similar to
http://orig13.deviantart.net/fb39/f/2013/101/3/7/divide_by_zero_by_spartanassassin-d61dgg9.jpg
[07:49:12] <Dreamer3_> rofl
[07:49:15] <Dreamer3_> love it
[07:49:17] * Xark waves goodnight (birds chirping outside...)
[07:51:54] <Thrashbarg> heh
[08:41:36] <Dreamer3_> can you not use Y at all with inline assembler?
[08:41:46] <Dreamer3_> (well, not reserve it that is)
[11:01:42] <blathijs> Hey folks. Anyone here who understands the purpose of the SE (sleep enable) bit on AVR processors? It is motivated as a measure to prevent the CPU from going to sleep when the programmer did not intend this, but since sleeping is done using a sleep instruction, that could only happen when there are random instructions in your flash, or perhaps you are randomly jumping to a piece of flash that contains data
[11:01:44] <blathijs> instead of instructions. If either happens, you'll have bigger problems to worry about I'd think?
[11:02:16] <LeoNerd> Yah.. can't honestly say I understand it myself...
[11:02:41] <LeoNerd> Unlike, say, the config-protect bits that turn up from place to place. Those protect against a write into the wrong address, which is far easier to do accidentally
[11:05:58] <blathijs> LeoNerd: Exactly
[11:06:19] <LeoNerd> That said, Atmel do a lot of odd things IMHO
[11:06:42] <LeoNerd> E.g. look at the PORTs on a 32U4. PORTE and PORTF have just two bits in each; some other ports are missing acouple of bits.
[11:06:44] <LeoNerd> Why not just merge them?
[11:07:34] <blathijs> LeoNerd: Perhaps for compatibility with other devices? E.g. some special functions that are commonly on either PORTE or PORTF?
[11:07:43] <LeoNerd> Ooh.. hrm
[11:08:01] <LeoNerd> Might that also explain then why most of the ATmega chips lack a PORTA?
[11:08:15] <LeoNerd> E.g. the good ol 48/88/168/328 have PORTB/PORTC/PORTD but no A
[11:14:07] <LeoNerd> Hmm.. some chatter on stackoverflow that suggests the lack of PORTA might come from the history of mega16 -> mega8 -> mega{4,8,16,32}8
[12:23:46] <blathijs> LeoNerd: Yeah, I think that's the reason (but I'm not sure if I ever read that, or just theorized myself)
[12:23:59] * LeoNerd nod
[15:36:54] <blathijs> Hm, I'm confused by external interrupts and sleeping, perhaps someone can clarify.
[15:37:37] <blathijs> I used to think that external interrupts (unlike PCINT) only supported waking up on low level interrupts, not edge interrupts. This is confirmed by the sleep mode section of the 328 datasheet.
[15:38:51] <blathijs> Now, I accidentally left my interrupt set to the falling edge instead of low level in my code, and it just worked as well, which suggests that a falling interrupt can also wake up the avr.
[15:39:45] <blathijs> The section on external interrupts in the 328 datasheet says "Low level interrupts and the edge interrupt on INT2:0 are detected asynchronously [and can wake up]"
[15:40:49] <blathijs> I'm a bit doubtful about that sentence, since 328 doesn't have INT2, but well. Some doc from Atmel suggests that INT0:INT3 can do edge waking, but INT4:INT7 cannot (which also sounds familiar from the 256rfr2 datasheet)
[15:41:19] <blathijs> Anyone to shine a bit of light on this? Is it safe to assume that all/most AVR parts can do edge-wakeup on their INT0-INT3?
