Back
[10:43:57] <swente> hello. i assume some of you are familiar with 'avrdude', and some even with 'avrispmkii'? my question is if passing the serial-number of the avrispmkii is the only supported way to address a specific avrispmkii?
[10:44:53] <Tom_itx> they should have unique USB id's
[10:44:57] <Tom_itx> i would think
[10:45:24] <Tom_itx> how you would access them separately, i'm not sure
[10:46:27] <swente> na, "unique" is just their internal serial-number. i'd need to address them by their path in usb's tree or similar, as parallel programmers seem to interfere as there's always all devices queried for their serial - which breaks while they're busy
[10:47:15] <swente> and for other programmers 'avrdude' supports passing bus/device-numbers :-]
[10:49:05] <LeoNerd> Um, silly question: do you really have multiple programming devices?
[10:49:17] <swente> currently 5, yes.
[10:49:36] <swente> and they all shall work at once :)
[10:49:54] <LeoNerd> Hm.. See in that situation I'd connect each via some sort of USB-attached port thingy, and refer to them by that named port
[10:50:59] <swente> the system has just one usb-bus. so i'm not sure if i could "separate" them
[10:51:16] <LeoNerd> Hrm?
[10:51:23] <swente> (talking about a raspi using kindof virtualization vm-per-programmer is not really .. practiable)
[10:51:30] <LeoNerd> 5 USB-attached UARTs will each have their own name.. or parallel ports, or whatever
[10:51:49] <swente> if it would be uart, i wouldn't have this problem -- they're USB themselves.
[10:52:18] <swente> (of course changing programmers might be an option.. *sigh*)
[10:52:30] <LeoNerd> Ooh. I see.
[10:52:35] <LeoNerd> Trickier
[10:53:04] <swente> yep. not that there wouldn't be already 16 uarts in the end -- attached on usb, too. funny setup.
[11:51:52] <sim642> I was compiling some code for atmega32u2 with avr-gcc and encountered a weird problem: when compiled to .o and then linked together the resulting code would not run as intended but when compiled directly with one shell command, it would. Any ideas why doing it in multiple steps would not work nicely? I have two .c files btw.
[13:43:57] <Jartza> sim642: share some code and commands how you compile it
[13:44:07] <Jartza> like with pastie.org or similar
[13:47:11] <sim642> the code is here:
https://github.com/sim642/Cryptex/tree/wheelmod/WheelMod
[13:47:31] <sim642> I'm not really familiar with most of it since I didn't write it, just modify some parts
[13:47:40] <sim642> avr-gcc -g -Os -mmcu=atmega32u2 -o flash.elf wheelmod.c usb_serial.c
[13:47:48] <sim642> that's what I use to compile it, which works
[13:48:17] <sim642> but if I compile it partially like: avr-gcc -g -Os -mmcu=atmega32u2 -c wheelmod.c -o wheelmod.o
[13:48:22] <sim642> same for usb_serial
[13:48:57] <sim642> and then link them together with : avr-gcc -o wheelmod.elf wheelmod.o usb_serial.o -mmcu=atmega32u2
[13:49:07] <sim642> then the resulting .elf is what doesn't run properly
[13:49:50] <sim642> really, the part-by-part compilation is what my IDE (Codeblocks) does, but it doesn't work when I manually try to do the same way
[13:50:07] <sim642> I don't really understand why there would be any functional difference
[13:50:43] <sim642> I understand that direct vs via .o compilation might produce a not exactly the same flash
[13:50:54] <sim642> but they differ in practical use too
[13:51:18] <sim642> I can't tell how exactly but the .o compiled one doesn't seem to do anything
[13:52:41] <sim642> What I can tell about it is that there is supposedly a heartbeat LED on the board this is supposed to run on
[13:52:58] <sim642> the .o compiled not-working code causes it to flash considerably slower than the working one
[13:53:52] <sim642> avr-gcc version 4.8.1 if that matters
[14:59:02] <Jartza> hmmh
[14:59:32] <Jartza> that sounds weird
[15:03:36] <Xark> sim642: Possible argument order "matters"? E.g., put -mmcu option before input files.
[15:04:37] <Jartza> vslid point
[15:04:39] <Jartza> valid
[15:04:50] <sim642> Xark, you mean in the linking command?
[15:05:08] <Xark> sim642: Yes. In general order matters for gcc.
[15:05:31] <Jartza> ohh.. and you say it's slower?
[15:05:50] <Jartza> that might be F_CPU not defined
[15:05:51] <sim642> I am aware but I didn't think there was much difference, also it's how the IDE put it so I hoped it'd be right
[15:05:55] <sim642> Jartza, definitely defined
[15:06:04] <Jartza> for all files?
[15:06:06] <sim642> both in the code and from command line too if I compile from codeblocks
[15:07:41] <sim642> I can't really test this thing right now but I can try changing the gcc option order when multi-step compiling to see if it makes any difference
[15:08:59] <Jartza> usually the options should be first and then the files
[15:09:14] <Jartza> or that's the safest way
[15:09:38] <Xark> sim642: You can also try adding "-save-temps" to the working and non-working compile and compare the intermediate files to see the problem.
[15:14:46] <sim642> Alright, will try to give it another look later
[16:21:58] <rue_mohr> trying harder yet?
[16:23:17] <Emil_> Has anyone had success trying to flash the Atmels own dfu bootloader into the avrs?
[16:23:32] <Emil_> Do I need to use some spesific fuses?
[16:23:44] <rue_mohr> never tried
[16:23:58] <Emil_> And what is the command to use with avrdude if flashing through usb?
[16:24:13] <rue_mohr> with which programmer?
[16:24:30] <rue_mohr> I dont know if I have that posted
[16:24:31] <Emil_> Because either dfu-programmer doesn't work or I can't seem to flash the bootloader image into the avrs
[16:24:42] <rue_mohr> I dont think I'v posted avr stuff since I switched to usb
[16:25:02] <rue_mohr> maybe your boot flags are just wrong
[16:25:33] <Emil_> Which should I set?
[16:25:38] <Emil_> For atmega32u4
[16:26:08] <Emil_> I tried setting the correct size and so on but either I did it wrong or I'm just stupid
[16:26:22] <LeoNerd> I prefer the Arduino 32U4 bootloader, as it plays nicely with the autoreset feature
[16:26:27] <LeoNerd> Means you don't have to touch the programming button
[16:26:56] <Emil_> LeoNerd: Yeah I figured I might just change to that one
[16:27:10] <Emil_> Isn't it just for uploading new code?
[16:27:15] <LeoNerd> Yup
[16:27:24] <Emil_> Like, it doesn't do anything silly with interrupts or anything?
[16:27:39] <LeoNerd> Nono.. the bootloader isn't runnign after the main code is up
[16:27:51] <Emil_> LeoNerd: you never know what's happening with Arduino :D
[16:28:17] <Emil_> Anycase which arduino bootloader have you flashed? I heard the sparkfun one is better than the arduino one
[16:28:19] <LeoNerd> To make proper use of it you do need to use Arduino's (or an appropriately patched) USB-CDC driver though
[16:28:34] <Emil_> LeoNerd: shouldn't avrdude work?
[16:28:52] <LeoNerd> Yes, I use avrdude
[16:29:09] <LeoNerd> I mean the code running on the AVR
[16:29:41] <Emil_> LeoNerd: so the process is like this:
[16:29:44] <Emil_> Set up fuses
[16:30:03] <Emil_> Write the bootloader (which commands to use?)
[16:30:14] <Emil_> Use avrdude (which parameters?)
[16:30:40] <LeoNerd> Write the bootloader using whatever... I usually use avrdude on my USBasp
[16:31:22] <Emil_> LeoNerd: Yeah but which command to use?
[16:31:31] <LeoNerd> Whatever is appropriate to you
[16:31:35] <LeoNerd> I don't know your setup
[16:31:54] <Emil_> I suppose avrdude -c usbasp -p m32u4 -U flash:w:firmware.hex:i
[16:31:56] <Emil_> ?
[16:32:00] <Emil_> Oh Debian
[16:32:07] <LeoNerd> Looks reasonable
[16:32:26] <Emil_> LeoNerd: which fuses did you set?
[16:32:27] <LeoNerd> Though that can be shortened to -U firmware.hex as the flash:w:$FILE:i parts are implied if there's no colon
[16:32:37] <LeoNerd> I didn't; mine came already set up
[16:32:40] <Emil_> That's nice to know
[16:32:45] <Emil_> Could you readback your fuses?
[16:34:11] <LeoNerd> Not terribly easily rightnow, no....
[16:34:20] <LeoNerd> It should be relatively easy to find online somewhere
[16:34:21] <Emil_> Damn
[16:44:34] <sim642> Checked out my compilation difference thing, putting -mmcu first in every avr-gcc call seemed to produce an identical file, so it seems that was it
[16:44:51] <sim642> Now to figure out how to fix my IDE to make it do it right as well
[16:57:09] <theBear> how you mean putting it "first" ?
[16:57:15] <theBear> oh, just before compilation ?
[17:08:01] <Jartza> wow. the moon is looking very funky.
[17:12:01] <antto> u had enough of the funny pills for today
[17:12:51] <theBear> never enough
[17:29:00] <sim642> I'm gonna go crazy over this issue
[17:29:16] <sim642> Now I got my IDE to put the -mmcu flag in the right place which seems great
[17:29:56] <sim642> Except it still seems to somehow do the linking incorrectly
[17:37:27] <sim642> wow, it seems like the order of the .o files in the linking command changes the result
[17:51:48] <theBear> hmm... /me considers if that sounds like it should happen
[17:51:52] <theBear> what ide yer using ?
[17:52:29] <sim642> codeblocks
[17:52:51] <sim642> Luckily there's a way to prioritize files to get the desired order
[17:53:10] <sim642> and that's the entire thing which affects the result
[17:53:51] <sim642> by simply forcing different order of objects for the linker, I can get the exact same working binary I got earlier from command line
[17:54:04] <sim642> which apparently worked correctly on just pure luck
[17:56:10] <theBear> just regular sensible avr-gcc with no silly pluses or anything ?
[17:58:52] <sim642> my IDE likes to use avr-g++ for linking but I tried both and that made no difference
[18:01:03] <theBear> g++ for linking, just for the hell of it ? that sounds careless
[18:03:45] <sim642> probably for the C++ support
[18:03:52] <sim642> as I said, it makes no difference in this case
[18:05:36] <sim642> I am extremely curious as to why it would make such a difference though
[18:06:21] <sim642> Because I've never had problems caused by incorrect object file linking order with gcc
[18:11:08] <theBear> mmmm, i learned in an age before multi-file linkey style builds happpened so i always a bit hazy on this area.... just trying to think how a standard cmdline build decides the build order when there multiple non-headers that rely on each other
[18:16:37] <sim642> the stuff I read right now says that it's simply left to right
[18:18:22] <sim642> but really, I've let my IDE do all the linking ever before and this has never caused any issues whatsoever
[18:18:35] <sim642> so I'm simply stunned how this would affect anything
[18:41:13] <Xark> Yes, left to right. If you have circular dependencies, you can list a .o files twice. If it is really complicated you can use GNU ld option Wl,--start-group -Wl,--end-group to have linker try multiple times on a group of libraries or .o files.
[18:58:17] <theBear> i can't remember listing .o's (for example in my recent lufa project, my only remotely recent project that is :) at all, just thought all the c's got kinda auto rounded up and punched together magically somehow
[18:59:24] <Xark> theBear: If you do gcc foo.c -o myprog it will compile and link in one step (you could list several source files too).
[20:08:54] <Getty> wow interesting... a memory value that i didnt set to zero actually had the same value it had before reboot, fascinating
[20:12:31] <Lambda_Aurigae> Getty, that will happen but don't count on it....also, it likely won't happen after a power off/power on.
[20:12:42] <Getty> LOL i am for sure not counting on black magic
[20:13:05] <Getty> i never had set it to zero but it was always zero by random
[20:13:15] <Getty> only through me trying something new i found out this "problem"
[20:13:21] <Getty> so actually the black magic annoyed me ;)
[20:14:20] <Lambda_Aurigae> Jartza, any go on that blog yet?
[22:22:29] <Getty> god, are C errors annoying.. or lets say the NON errors ;)
[22:22:44] <Getty> i used the memset variables in wrong order... LOOKED FINE AT FIRST ;)
[22:32:47] <kre10s_> for ultra low power applications is it recommended to use, for example, the power supplies enable pin to turn off an avr when not needed?
[22:33:30] <Casper> define ultra low power
[22:33:53] <Casper> some avr have a sleep power consumption in the few µA range
[22:35:23] <Getty> well he has like that version 1 ark reactors.. you know, ultra low power ;)
[22:35:28] <kre10s_> yea. It would probably make more sense to use sleep mode an low clock speed than to mess with power cycling the chip.
[22:36:07] <Casper> sleep mode will turn off the clock
[22:36:45] <Casper> then when you awaken it, you may want to experiment with fast clock/higher consumption/shorter time vs lower clock
[22:37:17] <kre10s_> I'm doing power harvesting. The harvester has an LDO and seperate vout with enable. I'm thinking about using an RTC on the LDO to control the enable with its interrupt pin.
[22:37:37] <Casper> depending on the type of work, sometime higher consumption is actually less energy (the energy per cycle usually goes down as the speed increase, but you lose the gain if your device have to wait)
[22:38:00] <Casper> why a low dropout? that.. sound wastefull
[22:41:33] <kre10s_> I want to use LTC3109 for harvesting. It has two Vouts, so i don't need to use the LDO, that's probably better.
[22:44:11] <kre10s_> ahh. forget it, sleep mode is more than enough. I'm trying too hard.
[22:44:55] <kre10s_> If I run off of the internal 32khz osc. can I switch to the 8Mhz one temporarily?
[22:47:46] <Casper> that I am unsure of, read the datasheet... never had to use low power yet
[22:47:54] <Casper> so didn't do much researches
[23:26:42] <gorroth> i think to make life easier, i'm just going to get UART going so that the pins are separated from the high resolution PWM
[23:26:59] <gorroth> that way i don't have to write more complicated code right now, and i can already be on my way to getting and xbee working whenever i buy one
[23:54:01] <rue_mohr> I have atmega32 code for a serial io slave, it does pin io, adc, and pwm
[23:59:03] <Casper> ... so?