Back
[01:47:36] <rue_shop2> anyone know the diff between a mega88 and a mega88pa ?
[01:55:13] <rue_shop2> how about this, can anyone tell me if a new copy of avrdude supports more than one type of atmega88?
[02:01:46] <rue_shop2> I think its to do with memeory programming
[02:01:51] <rue_shop2> read-while-write
[04:32:04] <NicoHood> does anyone know how i can reserve a fixed ram pointer address without extra cimpiler flags?
[04:32:22] <NicoHood> i want that address 0280 is never used, since its a bootloader key
[04:37:46] <Jartza> NicoHood: no way without extra flags for linker
[04:38:17] <NicoHood> Jartza: okay. is there any way to find a ram address that is possibly not used?
[04:38:27] <Jartza> but you can do something like: char key[8] __attribute__((section(".bootkey")));
[04:38:37] <NicoHood> yeah i did that
[04:38:39] <Jartza> (I just supposed it's 8 chars, but it can be whatever)
[04:38:47] <NicoHood> but i cannot do this in arduino environment
[04:39:18] <Jartza> yes, then while linking, you have to use --section-start .bootkey=0x800xxxx
[04:39:30] <Jartza> (the memory starts at offset 0x8000000)
[04:39:37] <NicoHood> i somehow need a place in ram that i can simply overwrite without worrying to destroy the program
[04:40:08] <NicoHood> isnt the offset 0x100??
[04:40:38] <Jartza> no, RAM offset is 0x8000000 for linker.
[04:40:53] <Jartza> if you place it in 0x100 it will end up in program flash
[04:41:00] <NicoHood> what? o.o
[04:41:06] <NicoHood> it was working with 0x280
[04:41:19] <Jartza> http://www.nongnu.org/avr-libc/user-manual/mem_sections.html
[04:42:36] <Jartza> in your code the address will be 0x280 yes
[04:42:42] <Jartza> but for linker, no.
[04:43:19] <NicoHood> my problem is: the program writes a bootloader key to the ram that tells the bootloader to execute after a watchdog reset. but the program can reverse this bootloader execution so i dont want to "kill" any important ram values. so i need a fixed ram address i think. or is there any other way?
https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/CDC.cpp#L94-L108
[04:43:57] <Jartza> maybe use eeprom?
[04:44:06] <NicoHood> hm might be an idea
[04:44:17] <NicoHood> but well.. nah
[04:44:55] <NicoHood> cant i manually set a watchdog reset flag for usb reset and abuse this?
[04:45:35] <NicoHood> or is there any address in ram that is very unlikely used at any time? an address that is only used if the ram is completely full?
[04:47:16] <Jartza> in my knowledge you can only clear the watchdog reset flag
[04:47:19] <Jartza> and not set it
[04:47:51] <Jartza> you shouldn't just trust that there will be any address that's not used.
[04:48:05] <NicoHood> okay so then i have to use ram. but what address? I also dont wanna fragment the ram with this stupid key.
[04:48:19] <NicoHood> can i use 0x100 and pass this to the compiler to not use it?
[04:48:33] <Jartza> you can specify the address of variable in linker
[04:48:34] <NicoHood> that would suit to any avr and not fragment ram, correct?
[04:49:05] <NicoHood> thats my bootloder compiler flag thats working fine: LD_FLAGS = -Wl,--section-start=.text=$(BOOT_START_OFFSET) $(BOOT_API_LD_FLAGS) -Wl,--section-start=.blkey=0x280
[04:49:33] <Jartza> no, not 0x280
[04:49:46] <NicoHood> what else?
[04:49:46] <Jartza> "Because of the Harvard architecture of the AVR devices, you must manually add 0x800000 to the address you pass to the linker as the start of the section. Otherwise, the linker thinks you want to put the .noinit section into the .text section instead of .data/.bss and will complain.
[04:50:16] <Jartza> so, if you want to use 0x280, it must be 0x800280
[04:50:18] <NicoHood> wait. that was the error i got in the IDE. somehow its still working with my bootloader makefile
[04:50:22] <NicoHood> i will add this
[04:50:26] <NicoHood> gimme a seconds
[04:51:39] <Jartza> the Harvard architecture means you have different memories
[04:51:51] <Jartza> the code is executed from flash, but the data the code uses comes from ram
[04:52:17] <Jartza> so you need to offset ram because otherwise it would be unclear will the 0x280 be in flash or ram?
[04:52:33] <NicoHood> avrdude: reading input file "C:\Users\Testuser\Dropbox\Arduino\sketchbook\hardware\HoodLoader2\avr/bootloaders/../../HoodLoader2.hex"
[04:52:33] <NicoHood> avrdude: ERROR: address 0x800281 out of range at line 253 of C:\Users\Testuser\Dropbox\Arduino\sketchbook\hardware\HoodLoader2\avr/bootloaders/../../HoodLoader2.hex
[04:55:30] <Jartza> try using .noinit section name
[04:55:43] <Jartza> that section contains variables that are not initialized during start
[04:55:55] <Jartza> although I'd still use eeprom :)
[04:58:26] <NicoHood> the thing is: the bootloader AND the program need to know where the address is located,. it has to be equal
[04:59:07] <Jartza> sure
[04:59:10] <NicoHood> will this work? also i have problems with telling the arduino IDE the linker flag. with my bootloader makefile its working fine. but i am developing bootloader and program api
[04:59:47] <NicoHood> and how do i use this .noinit section? how can i ensure that the bootloader puts the variable to the same spot?
[05:00:19] <Jartza> same way, just change the .blkey to .noinit
[05:00:44] <Jartza> and use the same attribute and linker flags in both codes
[05:01:16] <NicoHood> do i need compiler flags for the .noinit or is this automatic generated?
[05:01:41] <NicoHood> by attribute you mean?
[05:02:14] <Jartza> uint16_t bootkey __attribute__((section(".noinit")));
[05:03:15] <Jartza> -Wl,--section-start=.noinit=0x800280
[05:03:46] <NicoHood> and whats different? the name?
[05:04:02] <Jartza> yes
[05:04:14] <NicoHood> and how should this help?
[05:04:18] <Jartza> http://www.nongnu.org/avr-libc/user-manual/mem_sections.html
[05:04:26] <Jartza> the explanation is there :)
[05:04:36] <NicoHood> okay ill read this first
[05:05:02] <Jartza> "What makes the .noinit section special is that variables which are defined will not be initialized to zero during startup as would normal .bss data"
[05:06:07] <Jartza> I still think using eeprom would be easier :)
[05:06:28] <NicoHood> the real problem is that i cannot add compiler flags the the arduino ide. or at least its not working X_x
[05:06:44] <NicoHood> lets say the bootloader only has one variable in the noinit section. but the program has 10 values. why can i ensure that they are both at the same spot and not randomly at 1 out of the 10 spots?
[05:08:35] <Jartza> only with commpiler flags ;)
[05:08:43] <Jartza> but if you use eeprom, you can use static address if you wish
[05:08:59] <Jartza> and the data will stay there
[05:09:03] <NicoHood> but i dont know what the user will do with eeprom
[05:09:26] <NicoHood> i know its only 1 byte but... yeah
[05:09:47] <NicoHood> and maybe this would increase the size. i only hav 70 bytes left of flash for the bootloader
[05:11:01] <Jartza> I hate arduino ide because it hides all and doesn't provide ways to do "normal things developers do" ;)
[05:11:19] <Jartza> like setting the compiler flags :P
[05:12:22] <NicoHood> yeah
[05:12:34] <NicoHood> well i like it but its always beta
[05:12:42] <NicoHood> they didnt think about that problem
[05:13:00] <NicoHood> i am using a MCU with less ram where i have to think about this error
[05:13:09] <NicoHood> and it can still occur on the bigger mcu
[05:13:41] <NicoHood> i think i will use address 0x280 because its simply working.
[05:14:06] <NicoHood> not sure what it would break if the reset is reversed but i cannot change this
[05:14:23] <NicoHood> 0x280 is very close to the stack, or even in the sketch, right?
[05:14:30] <NicoHood> *stack
[05:15:30] <twnqx> that depends where you put the stack,.
[05:15:52] <NicoHood> haha okay
[05:16:01] <NicoHood> i will give that up now
[05:16:43] <NicoHood> its working, the bug is filed on github, if they dont change it i cannot do anything. its working so i should just note it somehwere, the problem
[05:17:40] <NicoHood> Jartza: i am also using -Wl,--section-start=.blkey=0x280 and its working. otherwise avrdude complains
[05:21:34] <NicoHood> lets pretend the stack is at the end, 0x2ff, will this cause problems even if the linker passed the .blkey section properly?
[05:24:09] <Jartza> yes
[05:24:28] <Jartza> that address is in flash ;)
[05:27:05] <NicoHood> and why the hell is my bootloader working? and why is avrdude complaining?
[06:48:50] <Lambda_Aurigae> rue_more, difference is power. the PA has a new lower power core and one more sleep mode.
[06:56:31] <Lambda_Aurigae> http://www.atmel.com/Images/doc8035.pdf migrating from atmega88 to atmega88p
[06:56:47] <Lambda_Aurigae> http://www.atmel.com/Images/doc8196.pdf migrating from atmega88p to atmega88pa
[07:03:17] <Lambda_Aurigae> also note that the atmega88, atmega88A, and atmega88PA all have different signature bytes.
[07:03:44] <Lambda_Aurigae> hmmm.
[07:03:46] <Lambda_Aurigae> almost.
[07:03:58] <Lambda_Aurigae> atmega88 and atmega88A are the same...atmega88PA is different.
[07:04:39] <Lambda_Aurigae> it appears the A is a reduced core drop in replacement for the first series and the PA is the picopower version.
[07:10:10] <hypermagic> :)
[07:10:26] <hypermagic> why not just replace them ?
[07:10:35] <hypermagic> they share same instruction set
[07:14:17] <Lambda_Aurigae> no clue.
[07:14:26] <Lambda_Aurigae> I just got that info from the datasheets.
[07:14:46] <Lambda_Aurigae> the atmega88A is a replacement for the atmega88....atmega88 isn't produced anymore I believe.
[07:15:12] <Lambda_Aurigae> atmega88PA is the picopower version. not sure if picopower core limits the chip in other ways or not though.
[07:23:09] <hypermagic> i already had pa last year... no problem
[07:23:20] <hypermagic> consumes less
[07:23:32] <hypermagic> care must be taken not to overvolt them
[07:24:42] <Lambda_Aurigae> I suspect they don't do so well with overclocking either.
[08:09:00] <malinus> I just
[08:12:57] <LeoNerd> Does anyone know of a database somewhere, that somehow represents AVR fuse information in a vaguely machine-readable way..?
[08:13:36] <LeoNerd> My original 'tinyfuse' program I wrote for my HVSP burner only copes with tiny84. I want to add 85, 13, 841, etc... any of the other HVSP chips. Rather than hand-write lots of custom logic, I wonder if there's something standard I can reuse somehow
[08:13:51] <LeoNerd> Failing that, I guess I may just have volunteered to create it ;)
[08:23:26] <Lambda_Aurigae> LeoNerd, I think there is a data file in avrstudio that has it all in it.
[08:23:29] <Lambda_Aurigae> I think.
[08:25:02] <Lambda_Aurigae> http://www.engbedded.com/fusecalc/ check with the guy who made this.
[08:25:25] <Lambda_Aurigae> http://eleccelerator.com/fusecalc/ or this.
[08:27:08] <LeoNerd> I'm aware of ready-made tools, yes. But I want to make my own tool, for talking to the HVSP board
[08:27:15] <LeoNerd> That means I need the data machine-readable
[08:27:23] <Lambda_Aurigae> talk to the guys who wrote those.
[08:27:28] <Lambda_Aurigae> they have the data.
[08:27:29] <LeoNerd> Ohwait, I see what you said. ;) Yes... good plan
[08:27:37] <Lambda_Aurigae> or can tell you where to find it.
[08:27:48] <Lambda_Aurigae> I'm betting it is in the atmel studio files somewhere.
[08:28:09] <Lambda_Aurigae> it appears to be an xml file.
[08:52:29] <Casper> LeoNerd: one of those fusecalc online talked about an xml file available on their site or the atmel site... look for it
[08:52:40] <LeoNerd> Ah OK
[08:53:06] <LeoNerd> "All information based on database ATtiny84.xml build 82." says one page. That looks hopeful
[08:54:06] <LeoNerd> Oooh.. and they do lock bits too. I hadn't considered those
[08:54:43] <Lambda_Aurigae> locks are part of the fuses really.
[08:55:03] <LeoNerd> Conceptually, if not physically...
[08:55:26] <Lambda_Aurigae> I bet they are implemented the same way physically.
[08:55:30] <LeoNerd> Butyeah, I have a little TUI app for doing these. Looks like
http://home.leonerd.org.uk/local/screenie/tinyfuse.png currently
[08:55:36] <LeoNerd> But that's all hardcoded to a tiny84
[10:30:18] <LeoNerd> Righty. It seems all the online fuse calculators use the XML parts descriptino files, from AVR Studio
[10:30:37] <LeoNerd> Does anyone know where I might get hold of those easily, preferrably without downloading the entire ~200MiB AVR Studio blob and unpacking it
[10:34:45] <LeoNerd> huh.. :( I can't connect to
http://atmel.com today
[10:40:04] <Tulitomaatti> try www.atmel.com
[10:40:29] <LeoNerd> Huh.. OK that's fine
[10:41:38] <Tulitomaatti> there's rarely a good reason not to have www.domain.tld and domain.tld go to the same place, but still many companies don't configure it so.
[11:00:32] <Tom_itx> LeoNerd, what do you want with them?
[11:01:04] <LeoNerd> Tom_itx: I want to pull out the HVSP params and fuse descriptions
[11:01:17] <Tom_itx> i _could_ upload them
[11:03:42] <Tom_itx> or i _could_ zip them first then upload them
[11:05:01] <Lambda_Aurigae> need a good 12 pass encryption system first.
[11:07:02] <Tom_itx> let's see how long it takes for him to figure out where i put it
[11:07:16] <Lambda_Aurigae> only a few billion IPs
[11:15:49] <Tom_itx> he could check his pm too
[11:23:43] <LeoNerd> <register caption="Port A Data Register" name="PORTA" offset="0x3B" size="1" mask="0xFF"/>
[11:23:47] <LeoNerd> <register caption="Data Register, Port B" name="PORTB" offset="0x38" size="1" mask="0x0F"/>
[11:23:53] <LeoNerd> Nothing like consistency, is there? ;)
[11:30:34] <tpw_rules> is the stack pointer its own register or is it aliased to something else
[11:30:49] <Tom_itx> own i would think
[11:30:57] <LeoNerd> SPL/SPH
[11:31:14] <tpw_rules> oh right
[11:31:16] <tpw_rules> hm
[11:31:22] * tpw_rules forgot he had to set that
[12:22:12] <tpw_rules> ah excellent, it seeems that (for now) having a latch happen while the keyboard interrupt is running isn't a problem
[12:22:33] <tpw_rules> oh sorry, you guys probably don't care about that
[13:29:43] <apo> Hi guys
[13:31:31] <apo> Trying to make a MIDI pedal using LUFA and an ATmega32u4 (on an Arduino Leonardo), I've pretty much copy/pasted the MIDI class example and set it to just send control change events every few ms, and even though it does toggle its LEDs happily, I don't seem to be getting any MIDI events
[13:31:48] <apo> Here's my MIDI.c file,
http://p.0au.de/621f773e/MIDI.c
[13:32:13] <apo> http://p.0au.de/49696979/midi.tar.bz2 or the whole project
[13:32:44] <apo> I'm monitoring with wireshark, and don't see any packets after the initialization
[13:32:59] <apo> if somebody could take a look and maybe check if they're getting the same results, that'd be great :)
[14:18:14] <LeoNerd> Does anyone here know much about the contents of the AVR Studio part info XML files, or know where I can read more about them?
[14:18:48] <LeoNerd> E.g. I'm noticing that on an ATtiny84, it defines a module called USI which has an instance called USI, which has a register group called USI and name-in-module of USI. That's the same name four times :)
[14:20:54] <Lambda_Aurigae> never looked at the files myself.
[14:21:10] <Lambda_Aurigae> I kind of avoid atmel studio being as it is windows based and all.
[14:21:25] <LeoNerd> Ah... hrm. I should look at a larger example. The ATtiny chips all have one instance of every module, but some of the Xmega chips have multiple of some. So that gives a clue
[14:21:42] <LeoNerd> Yah - I'm not running the Studio, I'm just using the XML files as an excellent source of lots of information about the chips
[14:21:48] <Lambda_Aurigae> atmega1284p has dual usarts.
[14:22:12] <Lambda_Aurigae> and lots of ports and stuff.
[14:22:24] <LeoNerd> Hrm.. yeah but that defines two modules of USART0 and USART1 :(
[14:22:32] <LeoNerd> Similar PORTB PORTC PORTD
[14:28:50] <Lambda_Aurigae> you will have to learn to parse the xml file which means figuring out the schema.
[15:33:44] <LeoNerd> http://pastie.org/private/tlu50lpq4tu0aizk6b03la <== random snippet of data parsed from these device XML files
[15:33:48] <LeoNerd> I'm quite happy with this :)
[16:15:16] <LeoNerd> GAHHHH THIS DATABASE IS INSANE
[16:15:59] <LeoNerd> They store the 'value' field of enumerated bitfield choices in a weird way. The 'value' stores a bitmask 0, 1, 2, 3, ... onwards even if those aren't legal values implied by the 'mask' of the bitfield
[16:16:21] <LeoNerd> So you have to take the mask into account and shift it appropriately. Except -even- that isn't right, if the mask is discontiguous bits
[16:16:37] <LeoNerd> Such as the 'WDP' field of WATCHDOG, which uses bits 0,1,2,5.
[17:55:19] <spillere> does anyone knows it would work to compile the .hex in the arduino IDE and upload it using avrdude to an atmega without the bootloader?
[17:55:55] <LeoNerd> avrdude -c whatever -p whatever ... -U foo.hex
[17:58:24] * Tom_itx holds his hand up
[17:58:27] <Tom_itx> i know i know!!
[17:58:33] <Lambda_Aurigae> spillere, you need to make sure your atmega meets the specifications or board settings in your arduino ide...specially frequency if you are doing any kind of communications via usart or anything that is timer critical.
[17:58:40] <spillere> hehe
[17:59:48] <spillere> i know
[18:00:38] <spillere> in compiling the .hex using an arduino ide with the same clock speed 16mhz and chip. but then the speed gets weird. if I make the code in plain C it works perfectly, but I already have a big code in arduino :)
[18:01:07] <Tom_itx> so rewrite it
[18:01:39] <spillere> im almost thinking on it :(
[18:03:18] <malinus> spillere: check which board you have checked under the board options. Then check the boards.txt, and see what the FCPU is there.
[18:03:25] <malinus> spillere: it can't be anything else
[18:03:55] <spillere> i know, it should work! pro5v328.build.f_cpu=16000000L
[18:04:25] <Lambda_Aurigae> and you have an external crystal attached and the fuses are set to use external crystal?
[18:04:59] <spillere> yes
[18:05:52] <spillere> oho, not its working
[18:06:09] <spillere> nevermind, seems to be working now! :D
[18:06:20] <spillere> I don't know what was going wrong before
[18:07:51] <spillere> thanks guys
[18:15:15] <Jartza> hi
[18:15:35] <Jartza> I promised to release the specs to my Tagsu modem quite some time ago
[18:15:50] <Jartza> here is finally the blog post, and the code:
http://labs.rakettitiede.com/?p=87
[18:15:57] <Jartza> hope someone finds it useful
[18:16:03] <Jartza> if you do, please share ;)
[18:16:21] <Lambda_Aurigae> thanks Jartza
[18:19:41] <Jartza> you're welcome
[18:19:50] <Jartza> it's so simple it _still_ hurts :D
[18:20:07] <Jartza> but works great
[22:03:56] <Shavik> Could anyone take a look at my SMPS design and see if they see any issues?
[22:05:41] <Shavik> http://i.imgur.com/DzV3FHK.png
[22:32:18] <Casper> shavik: without looking into the parts specs, that seems like a normal buck with internal fets
