Back
[00:34:23] <Casper> Valen: not sure it have any usefullness, but it's as you want I guess :D
[00:35:03] <Valen> I'm making a board to be somewhat "general purpose" so I'm hoping to have it be reconfigurable
[06:23:39] <megal0maniac_afk> < GargantuaSauce_> yes or a cosmic ray could have flipped a bit in sram and caused the crash too
[06:23:44] <megal0maniac_afk> ^^ :)
[06:28:11] <Valen> that's what I blame for stuff
[07:40:11] <megal0maniac_afk> Good grief. Page 65 - 331 of the xmega256a3u datasheet is packaging information and electrical spec
[09:03:07] <RikusW> Does the UCap 1uF and UVcc 10uF caps need to be tantalum or will ceramic work as well ?
[09:03:25] <RikusW> I used Tantalum caps on a previous project
[09:13:29] <ambro718> I suppose there is no instruction which will load the sign bit of a register into C, without modifying the register?
[09:15:40] <RikusW> how about using T ? or does it need to be C ?
[09:16:21] <Joggl> yeah, just completed my U/I-Meter with atmega32u4 :D
[09:16:33] <ambro718> it needs to be C because then I can use "sbc r,r" to set r to either 0x00 or 0xFF
[09:18:52] <RikusW> sbrs ldi sbrc ldi
[09:19:02] <RikusW> 4 clocks
[09:19:45] <RikusW> mov t,r lsl t
[09:19:55] <RikusW> sbc
[09:20:04] <RikusW> 3 clocks
[09:20:27] <RikusW> err, you'll need ldi 0x00 too so 4
[09:21:13] <RikusW> x86 SALC would've been handy, though its undocumented...
[09:21:19] <RikusW> Set AL carry
[09:22:46] <ambro718> yeah doesn't seem like I can do better than mov+lsl
[09:25:06] <jadew> Casper, has your scope arrived?
[09:39:18] <GargantuaSauce_> http://workman-industries.net/images/radiobridge.jpg
[09:39:28] <GargantuaSauce_> some day i'll advance past making shitty perfboards
[09:39:45] <twnqx> lol
[09:47:57] <learath> GargantuaSauce_: on to making shitty printed boards? :)
[09:48:15] <GargantuaSauce_> soon
[09:55:33] <Casper> jadew: no, export release delayed
[09:55:45] <jadew> damn it
[09:56:26] <Casper> I wonder... if it really is export delayed or they import airmail from china
[09:56:43] <jadew> heh
[11:04:12] <megal0maniac_afk> I miss RichardCavell. Being right about everything all the time. That was fun
[11:05:28] <Tom_itx> he's still here from time to time
[11:06:33] <N1njaneer> Good morning! Time for more fun! AVR is synonymous with AdVentuRe!
[11:18:07] <megal0maniac_afk> Wish I could agree with you
[11:31:50] <N1njaneer> About the morning part, or the adventure part? :)
[11:33:46] <megal0maniac_afk> The fun part. I'm studying electromagnetism and maths
[11:33:59] <megal0maniac_afk> The morning part too, though :)
[11:38:53] <N1njaneer> Thankfully Maxwell found that stuff interesting, else we'd be really lost! :D
[11:40:36] <megal0maniac_afk> AC theory too. Maxwell can keep his stuff, we do not have this interest in common.
[11:50:42] <Casper> jadew: still no change in the order and no reply to my shipping adress change email grrrr
[11:51:19] <Casper> which mean it can be a big place, or a tiny place... (too busy, or too lazy)
[12:50:39] <jadew> Casper, any chances it will arrive today?
[12:53:09] <jadew> I think if you make a nice vide review you'll get tons of views, cuz there's no review out yet
[12:54:11] * hackman is away: I'm busy
[13:06:11] <Casper> jadew: zero
[13:06:27] <jadew> too bad, I was looking forward for some pictures
[13:06:30] <Casper> Good morning,
[13:06:30] <Casper> Thank you for contacting us. Please kindly note your order is scheduled to ship in approximately 4-5 business days, once the RIGOL DS1104Z unit arrives at our warehouse.
[13:06:52] <jadew> ah
[13:06:58] <jadew> so probably next week
[13:07:43] <Casper> ya
[16:00:45] <zmo> hi!
[16:01:54] <zmo> I'm just asking for something that one may know without looking at the doc: what is the #ifdef I can do to check the AVR architecture?
[16:02:02] <zmo> i.e.: I want to make 32u4 specific code
[16:02:36] <zmo> (I'm googling, but for such simple queries, it's hard to find the right query..)
[16:06:18] <N1njaneer> Look inside of include/avr/io.h, all flavors of MCU target are listed :)
[16:06:53] <N1njaneer> You probably want "(__AVR_ATmega32U4__)"
[16:07:47] <zmo> damn, I should have grep -i ...
[16:07:55] <zmo> I looked for 32u4 not 32U4
[16:07:58] <zmo> thank you N1njaneer
[16:12:25] <zmo> actually I just patched a lib where you got the documentation saying "do this and that when you use a leonardo, do this and that when you use an uno... or a 2560..."
[17:31:11] <ambro718> if I flash a bootloader, then flash normal software (with a programmer), what happens to the bootloader?
[17:32:20] <antto> you'd most likely erase it
[17:33:33] <antto> ambro718 i suggest this: put bootloader, then use the bootloader to put the other stuff on
[17:33:51] <antto> and THEN, use the programmer again to make a full flash dump
[17:34:08] <antto> the result should contain everything at once (lazy style)
[17:34:19] <N1njaneer> Or program the bootloader, then use the programmer to load on the application with "Erase Device First" disabled.
[17:34:19] <ambro718> well, I don't really need the bootloader because the programmer is faster, I just like to know exactly what's happening ;)
[17:37:09] <N1njaneer> But yes, as antto suggests once you have them both loaded (via either method) then just read back the flash memory for the entire device, then you can just program it in one go in the future.
[17:38:52] <antto> yeah, and if you flash such "combined" hex at one go - *do* use verification
[17:38:56] <antto> don't skip it
[19:43:38] <ollebe> Hello
[19:43:52] <ollebe> I have two questions that make me very confused. I have googled
[19:44:28] <Fornaxian> if you only have 2 questions that make you confused then you should be king of the world.
[19:44:42] <ollebe> 1. Is it possible to trigger an interrupt from using GDB's avr simulator or using simavr as a backend?
[19:45:38] <ollebe> 2. According to the data sheet, each "slot" in the interrupt vector is only 2 bytes in total. But GCC compiles interrupt vectors where each slot is 4 bytes.
[19:45:48] <ollebe> The AVR is an Atmega328p
[19:46:41] <ollebe> I can't test this with real hardware right now, but I suspect those two vectors cannot be compatible
[19:46:49] <ollebe> What's causing GCC to do this?
[19:47:25] <ollebe> Thanks in advance
[19:47:36] <Fornaxian> those would be for the gurus here...I'm just comedic relief.
[19:48:14] <Fornaxian> can't say as I've ever looked closely at the asm output for any of my avr projects.
[19:48:21] <Fornaxian> and I've never used simavr or gdb.
[19:48:41] <ollebe> Entertainment is fine too
[19:49:44] <Fornaxian> wait a bit and I'm sure someone will pipe up with an answer.
[19:51:42] <ollebe> It's 2:30 in the morning here, so I'll probably lurk here for an hour or so and then idle during the night
[19:54:43] <ollebe> One solution to the question 1 could be to research exactly how the CPU does an interrupt and try to mimic that in gdb
[19:55:09] <ollebe> That would mean pushing pc to the stack and jump to the vector
[19:55:33] <ollebe> But it seems like a clumsy solution. Can't find any "push" or "pop" command in gdb
[19:55:49] <Fornaxian> does the table contain a jump command as well as the address?
[19:56:43] <ollebe> This is as per the data sheet:
[19:56:46] <ollebe> 0x0000 jmp RESET ; Reset Handler
[19:56:48] <ollebe> 0x0002 jmp EXT_INT0 ; IRQ0 Handler
[19:56:55] <ollebe> So, yes
[19:57:57] <Fornaxian> Each interrupt vector must hold a jump command to the respective interrupt service routine. The typical program sequence at the beginning is like follow
[19:58:02] <Fornaxian> yup.
[19:58:05] <Fornaxian> that's why it's 2 bytes.
[19:58:11] <Fornaxian> err.
[19:58:13] <Fornaxian> 4 bytes.
[19:58:43] <Fornaxian> http://www.avr-asm-tutorial.net/avr_en/beginner/JUMP.html
[19:58:50] <Fornaxian> search for Interrupt Vector
[20:00:58] <Fornaxian> appears to be done that way so you can manually call interrupt routines without knowing where they are in memory.
[20:04:29] <Fornaxian> I think.
[20:04:38] <Fornaxian> I could be totally out in left field drinking a slurpee too.
[20:08:42] <ollebe> I don't really see how that answers my question
[20:09:15] <ollebe> The data sheet seems quite clear that a correct vector has just two bytes for each interrupt type
[20:10:13] <ollebe> Given that the address space is small, it seems reasonable that two byte is enough for a jmp
[20:10:19] <ollebe> I have to read about jumps...
[20:11:58] <ollebe> So, data sheet says 2 bytes, GCC seems to say 4 bytes, and the result is that the address where GCC places the interrupt vector for say TIMER_COMPARE_1A on the wrong address
[20:12:04] <Casper> Fornaxian: 1 word per vector, so 2 bytes
[20:12:17] <Casper> iirc...
[20:12:36] <ollebe> Maybe I'm doing something terribly wrong here that makes GCC do this. Then I need to figure out the correct way
[20:22:15] <codyps> ollebe: testcase?
[20:23:28] <ollebe> Hang on a few minutes, i'll create a small testcase
[20:33:11] <ollebe> hello.c:
http://pastebin.com/2RN9b1dy
[20:33:22] <ollebe> Makefile:
http://pastebin.com/gfx3T8wH
[20:33:47] <ollebe> make hello and optionally make hex
[20:34:41] <ollebe> Oops, wrong file name in makefile
[20:37:35] <ollebe> Corrected makefile:
http://pastebin.com/0DYxxmG3
[20:37:54] <ollebe> codyps:
[20:38:45] * DagoRed looks
[20:39:08] <DagoRed> ollebe: use a different site other than pastebin
[20:39:47] <ollebe> What site do you want me to use?
[20:40:15] <DagoRed> http://codepad.org/
[20:41:30] <ollebe> hello.c:
http://codepad.org/iE8BUZai
[20:42:10] <ollebe> Makefile:
http://codepad.org/bsRx6kfx
[20:44:25] <codyps> ollebe:
[20:44:25] <codyps> avr-objcopy -O ihex -R .eeprom hello hello.hex
[20:44:25] <codyps> avr-objcopy: 'hello': No such file
[20:44:25] <codyps> make: *** [hex] Error 1
[20:46:05] <ollebe> You could run "make hello" first
[20:46:08] <codyps> this is after '$ make'
[20:46:14] <ollebe> Improved makefile:
http://codepad.org/Iv0L8lbQ
[20:48:29] <ollebe> Then, after building:
[20:48:32] <ollebe> avr-gdb
[20:48:53] <ollebe> (gdb) set architecture avr:5
[20:49:12] <ollebe> (gdb) target sim
[20:50:54] <ollebe> (gdb) symbol-file hello
[20:51:00] <ollebe> (gdb) load hello.hex
[20:51:07] <ollebe> (gdb) disassemble 0
[21:14:53] <codyps> ollebe: atmega328p's datasheet says "2 instruction words/vector". so 4 bytes makes snese here.
[21:15:28] <codyps> (I used objdump -D instead of gdb to disassemble)
[21:21:58] <ollebe> codyps: Where in the datasheet?
[21:23:23] <ollebe> Ok, could be section 2.2
[21:23:29] <codyps> ollebe: yep
[21:23:54] <ollebe> I'm looking at 12.4 "Interrupt Vectors in ATmega328 and ATmega328P"
[21:26:39] <codyps> yep, that does look wrong. Unless they have some funny definition for "Program Address"
[21:27:29] <codyps> my guess is the "Program Address" is taken in 16bit pieces
[21:28:00] <codyps> rather, the program memory is only 16bit addressable, not 8bit addressable.
[21:29:23] <codyps> from the data sheet: "each program memory address contains a 16- or 32-bit instruction"
[21:30:21] <codyps> also from the data sheet: "the flash is organized as 2/4/8/16K x 16"
[21:30:42] <ollebe> That's an awsome explanation
[21:30:50] <ollebe> Thank you
[21:31:50] <codyps> the memory maps and PC bit widths listed in section 8.2 also make it more clear
[21:33:24] <ollebe> Good find
[21:33:26] <ollebe> So, neither GCC nor the data sheet is broken, and I didn't run GCC wrong
[21:34:53] <ollebe> But that raises another question. If PC is only 14 bits wide at most, then why cannot a jump instruction (or an interrupt vector slot) fit into 16 bits?
[21:35:14] <ollebe> Why use 32 bits wide interrupt vectors?
[21:38:20] <codyps> well, that would sacrifice quite a bit of instruction encoding space. And I expect they wanted to reuse the same instruction encoding on many chips, meaning some might have 16 bit PCs. Which would not fit in an 16 bit instruction (unless the only opcode the processor had was "jump")
[21:39:29] <ollebe> Ok
[21:41:09] <ollebe> Thanks everyone, I think I'll try get some sleep now
[22:13:55] <gkwhc> Hi, might anyone know what Static Memory Controller is in ATSAM3Us? is it for RAM expansion?
[22:15:03] <Casper> isn'T the sam series for security stuff?
[22:17:08] <gkwhc> i think the SAM series is ARM based
[22:35:51] <N1njaneer> SAM is ARM, yes :)
[22:47:37] <DagoRed> N1njaneer: it's complicated but yes.
[22:49:31] <N1njaneer> What's complicated?
[22:49:58] <N1njaneer> SAM is Atmel's SoC series based around the ARM architecture.
[22:50:55] <DagoRed> ARM is complicated. All ARM's are not alike.
[22:51:52] <N1njaneer> ARM architecture is ARM architecture. Same op-code set, different implementations of the processor features and compliment of on-chips peripherals.
[22:56:53] <N1njaneer> Most of the Atmel SAM stuff is generally ARMv7 or ARMv9 depending on the series of the processor.
[23:19:16] <jadew> why is ARM so popular anyway?
[23:21:49] <Xark> jadew: Low power, decent architecture and ARM provides HDL spec to "paste" into your SoC (and MIPS dropped the ball). :)
[23:24:01] <N1njaneer> ARM is also a fantastic RISC architecture that performs extremely well and is made avalible as IP for many vendors to integrate a proven design for very reasonable prices.
[23:25:00] <Casper> cheap, efficient, fast, low power, well supported
[23:25:09] <Casper> that sum it up
[23:25:16] <N1njaneer> Most people also don't realize that it spun out of Acorn
[23:26:59] <N1njaneer> I have been very pleased developing with ARM9 stuff.
[23:29:12] <Xark> I also enjoy working with ARM using Thumb2 and NEON. Quite a decent chip (I especially like the if/then/else opcode in Thumb2).
[23:29:16] <N1njaneer> Atmel also dumped a half-dozen SAM dev boards on me which I'm slowly working through for some new designs :)
[23:30:30] <N1njaneer> Xark: Gotta really love architectures where EVERY op-code can be conditional so you can avoid all of the branching. TI's DSPs do that as well on a massive scale with the fetch packets :)
[23:30:41] <jadew> interresting, I never worked with ARM before
[23:31:09] <Xark> N1njaneer: Well, actually I think that is a waste of opcode bits. I would rather ARM32 had had larger constants etc. :) In thumb2 I think they got the balance right (with ITE).
[23:32:21] <Xark> N1njaneer: It is a neat idea, but not really worth 4 bits per opcode in practice.
[23:33:01] <N1njaneer> Yeah, but I would hazard to guess the overall execution speed based on conditioal opcode bits FAR outweighs the extra instruction or two you need for loading massive constants. I would also hazard to guess that, for most code, many constants that would appear in-line with an instruction are going to tend to be a bit on the smaller size anyhow.
[23:33:36] <Xark> N1njaneer: Well, apparently not to ARM, since they ditched that idea in Thumb1/2 and now in the new 64-bit ARM.
[23:34:23] * Xark notes the new 64-bit ARM is looking more and more like MIPS. :)
[23:34:47] <N1njaneer> Things always progress. But the major market-share seems to be ARM7/9 and they are absolutely DOMINATING the market right now. So clearly they made some good descisions :)
[23:35:32] <Xark> N1njaneer: Sure. However, most new code is Thumb2 I think. Much smaller size and (generally) negligible slowdown vs ARM32.
[23:35:43] <N1njaneer> I've certainly worked with a fair number of architectures thus far, and I am very impressed by what ARM has to offer. Not only in the silicon, but also overall support, tools, mature compilers, etc.
[23:36:50] <N1njaneer> But really at the end of the day, if the solution solves your problem, it really doesn't matter what you use.
[23:37:23] <learath> anyone have example atmel studio code that pushes out EEPROM?
[23:37:45] <N1njaneer> Atmel has the AVR series at the lower end, and is now pushing most of their emphasis to the SAM series for embedded applications that need more horsepower.
[23:37:55] <N1njaneer> learth: What specifically do you need to do?
[23:38:17] <learath> N1njaneer: what I'd like to do is set defaults for user reconfigureable eeprom bits
[23:38:58] <learath> does that make sense?
[23:39:06] <N1njaneer> http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html is a good place to start if you want to do it programatically
[23:39:28] <learath> already using those, I don't exactly want to do it programatically
[23:39:58] <learath> I guess I can just set them manually, then image the eeprom
[23:40:11] <learath> but I thought there was a way to .. uhm define the contents of eeprom
[23:40:25] <learath> I may be wrong, or saying it badly
[23:40:29] <N1njaneer> Then I would just use avr-objcopy to convert a binary file you create in a hex editor over to a .hex to program :)
[23:40:47] <learath> or the always fun, "wrong *and* saying it wrong"
[23:40:58] <N1njaneer> eeprom is just a blob of binary bytes - you need to define how your implementation will use it, which is entirely up to you.
[23:41:20] <learath> yeah, already done that. Even put it in a spreadsheet so I don't forget and fuck it up :)
[23:41:43] <N1njaneer> So then you just need to set a default set of values?
[23:41:59] <learath> Yeah, to be programmed when the chip is intitially programmed
[23:43:04] <N1njaneer> Then I'd probably use your hex editor of choice (I prefer HxD) and then use avr-objcopy to convert the binary file in to a .hex s-rec and program that :)
[23:43:42] <learath> what about a .eeprom section?
[23:43:46] <learath> or am I misunderstanding what that does?
[23:43:49] <learath> the docs.. uh
[23:43:50] <learath> suck
[23:44:54] <N1njaneer> You can also use the .eeprom section if you want to generate an .elf and program that. I find it more straightforward, however, to generally just generate and program the EEPROM data seperately. But that's just me. :)
[23:45:39] <learath> I'm honestly thinking more of clarity than ease
[23:46:11] <learath> And I was hoping I could just use a list of offsets
[23:46:50] <N1njaneer> If your spreadsheet-macro-foo is strong, you could get the spreadsheet to do that for you :)
[23:47:14] <learath> hah, that I could
[23:48:36] <N1njaneer> Or write a simple script in your language of choice that bumps the spreadsheet exported at a .CSV in to a binary. Or in the S-REC file if you are particularly adventurous, but avr-objcopy does most of the heavy lifting there for you with regard to proper formatting, checksums, and offsets :)
[23:49:21] <learath> ohh
[23:49:28] <learath> N1njaneer: I may cheat. uint8_t EEMEM NonVolatileChar;
[23:49:28] <learath> uint16_t EEMEM NonVolatileInt;
[23:49:29] <learath> uint8_t EEMEM NonVolatileString[10];
[23:49:44] <learath> then I just use bad-person-global-vars :)
[23:50:52] <learath> hmm. that gets me halfway there
[23:50:54] <N1njaneer> Just make sure you verify that they pack together in proper order.
[23:51:13] <learath> TBH, as I access them individually, I don't care :)
[23:51:35] <learath> hm. though if I image the eeprom I do need to know if they are ordered consistantly
[23:52:02] <N1njaneer> Alternatively, you can also put all of that in to one neat struct {} and just do a block read inside your code. Then at least you can address things like "eeprom.someVariable" or such.
[23:52:10] <learath> yeah, and I can set them via uint8_t EEMEM SomeVariable = 12;
[23:52:12] <learath> that's perfect
[23:52:35] <learath> what's the advantage to that?
[23:53:14] <N1njaneer> That would also work. Just make sure you generate and program as an .elf file, as you would need two seperate .hex files otherwise.
[23:54:26] <N1njaneer> Partially readibility, as well as the advantage of being able to block-read and block-write the non-volatile data in a single line of code. This assumes you are going to change the values at some point, somehow, else there's not much point in putting them in to non-volatile memory in the first place.
[23:54:33] <N1njaneer> ALSO --
[23:56:09] <N1njaneer> If you are using EEPROM, you must ABSOLUTELY set the Brown Out Detection on the device if you want absolute long-term stability. It's good practice all around, but EEPROM can be particularly vulnerable to transients causing the processor to execute indeterminate code. To a lesser-extent flash program memory as well.
[23:56:44] <N1njaneer> It may power-cycle 10,000 times, and on the 10,001th time you'll suddenly see corrupt values in flash.
[23:58:23] <learath> Good to know, thanks!
[23:58:25] <N1njaneer> We spent quite a while chasing that one. Learn from my sleepless nights :)
[23:58:28] <learath> though I am cheating. CRC per value :)
[23:58:33] <learath> char EEMEM send_string_label_6[16] = "Blank";
[23:58:33] <learath> uint8_t EEMEM send_string_6[64] = NULL;
[23:58:34] <learath> uint8_t EEMEM send_string_crc_6 = NULL; // need to compute this correctly
[23:58:46] <learath> a simple 8 bit, but given the strings I'm not terribly worried
[23:59:04] <N1njaneer> CRC will only tell you there is corruption, not necessarily recover from it, though.
[23:59:15] <learath> In this case I'm fine with that.
[23:59:39] <learath> I'm working on the sparkfun SPI Shortcut
https://www.sparkfun.com/products/9235
[23:59:40] <N1njaneer> I would just do a summation CRC if you need something simple.
[23:59:47] <learath> I bought one and... uh... it kinds sucks ass
[23:59:59] <learath> it's turned out to be quite a good learning project
