Back
[03:34:22] <jadew> Casper, no idea, I did notice however that the ones that have it on display, they mention a delivery delay
[03:52:07] <megal0maniac_afk> Good grief, the scrollback is particularly bad today. NSFW even :/
[04:19:35] <theBear> woah, totally !
[05:18:01] <w|zzy> wow
[09:29:53] <rue_house> how is it we have 8051 stuff comming up in here?
[09:52:06] <megal0maniac_afk> We do?
[10:07:25] <ircnoob1337> Did anyone test current in power-down on mega128 family with async timer running ?
[13:42:41] <sre-su_> Fornaxian: Hey
[13:43:17] <sre-su_> Fornaxian: Could you suggest for AT89C2051 as well?
[14:05:04] <blathijs> Does anyone know if I can somehow tell gcc to be smart about saving registers when calling a function?
[14:05:40] <blathijs> I'm calling function from an interrupt handler, which cause the interrupt handler to save _all_ call-clobbered registers AFAICS, even though the function called only actually clobbers one
[14:06:10] <blathijs> It's just a single function and I'm using -fwhole-program, so gcc could deduce this fact and only save this one register, but I can't quite figure out how
[14:06:27] <blathijs> how to get gcc to be that smart, that is
[14:07:20] <blathijs> I can use -fcall-saved-rxx to make all registers call-saved, but that's really messy
[14:08:02] <blathijs> the avr-gcc page says some builtin functions show exactly that behaviour (referred to as "exceptions to the calling convention"), but it seems those are asm functions that explicitly specify their clobber list
[14:08:48] <blathijs> I was hoping I could somehow tell gcc to simply disregard the standard calling convention for the function called and instead use a calling convention based on the actual code generated for the called function, but I couldn't find any attributes or options for that...
[14:26:21] <RikusW> megal0maniac_afk: hi
[14:27:43] <megal0maniac> Hey
[14:27:51] <codyps> blathijs: ya, I'm not sure gcc knows how to do that. It would be something between "inline" and "just a normal function" in the optimization range, and gcc's inlining (wrt stack size managment) is questionable
[14:28:18] <megal0maniac> RikusW: Good timing
[14:28:43] <RikusW> megal0maniac: I got mki debugging to work on 324A and 32u4 :)
[14:28:48] <codyps> I'd imagine an attribute would be uneeded: if the cost of calling the function was high enough, and the function was local to a single compilation unit (or we're using lto), it would make quite a bit of sense
[14:28:59] <megal0maniac> Nice :) Congrats
[14:29:08] <blathijs> codyps: GCC isn't inlining the function now, so I guess it's too big for that. Also, I might be using it in a few more places, so then inlining will make things worse...
[14:29:13] <RikusW> did you try the dll I emailed you ?
[14:29:26] <megal0maniac> I did, I even replied. Convinced it's the flash size
[14:29:42] <RikusW> ugh
[14:29:49] <RikusW> did you enable OCDEN ?
[14:30:00] <megal0maniac> Yip, it's factory enabled but I checked anyway
[14:30:07] <megal0maniac> And JTAGEN
[14:30:27] <RikusW> try getting a 324A, that should work
[14:30:48] <codyps> blathijs: yep, there is definitely a case for this optimization. I wonder if it falls under function speciallization (though that is typically used for functions that are called with the same constants a number of times, so it may be at the wrong layer)
[14:30:49] <ryan-c> I'm working on a USB composite device with LUFA. Must HID InterfaceNumbers be consecutive?
[14:30:58] <RikusW> OCDEN is off by default...
[14:31:33] <megal0maniac> Well it was on, and I wouldn't have touched it. I don't think...
[14:31:33] <RikusW> Is anyone interested in the default FLIP bootloader for mega32U2 or U4 ?
[14:31:34] <blathijs> codyps: I'd say it is related to calling conventions more than specialization
[14:32:08] <blathijs> codyps: But to work properly, the calling convention for such a function can only be determined after generating code for it, which might not work with the gcc model, dunno
[14:32:09] <megal0maniac> No, but I think my xmega needs one. I also wiped the one on the AVR32, but got it back
[14:32:32] <RikusW> megal0maniac: and you did Debug->Select Platform too ?
[14:32:46] <megal0maniac> Yip. And changed the COM port to COM2
[14:32:56] <megal0maniac> Because it was on 5, and it seemed to like 1-4
[14:33:35] <RikusW> megal0maniac: do you know the lockbit values on the teensy ?
[14:33:50] <RikusW> there might be a way to get that bootloader out of it
[14:34:06] <RikusW> if the boot LPM is is not set, its possible
[14:34:09] <megal0maniac> My guess is that it's limited to 32kb. Even the Dragon, which is a newer debugger, was initially limited to 32kb
[14:34:34] <megal0maniac> RikusW: I'm almost 100% that the boot LPM bit will be set. Along with every other lockbit possible
[14:34:39] <RikusW> mki had no limits, it is supposed to work on m128
[14:34:53] <megal0maniac> I haven't checked, but Paul is no fool
[14:35:50] <RikusW> I could mail you my bootloader, thats compiled to run in app space, then you can look at the fuses, you'll have to connect the u2s to the teensy serial port
[14:36:32] <RikusW> (just upload the hex with the teensy bootloader)
[14:36:32] <RikusW> does the teensy use a 16MHz crystal ?
[14:36:34] <megal0maniac> It's chilled, I'll just use a programmer like a normal person :P
[14:36:52] <megal0maniac> Yip
[14:37:05] <blathijs> codyps: I guess I'll see if I can redesign the structure of my program instead... Thanks for thinking along :-)
[14:37:48] <RikusW> ah ofc, a normal programmer can read fuses even if lockbits are set :)
[14:38:21] <RikusW> I just used my bootloader hack to get the 32u4 flip bootloader
[14:38:34] <RikusW> LPM bit isn't set
[14:38:58] <RikusW> *wasn't
[14:40:43] <vsync_> any suggestions for a decoder chip for mp3's, that would do flacs aswell?
[14:42:16] <megal0maniac> RikusW: LPM_SPM_DISABLED
[14:42:23] <megal0maniac> PROG_VER_DISABLED
[14:42:32] <megal0maniac> BLB0 has no lock
[14:45:30] <megal0maniac> And he also has CKDIV8 enabled. Is is possible to detect VCC using bandgap as a reference and set the prescalar to 1 or 2 in the bootloader dependant on 5V or 3v3 VCC?
[15:17:14] <RikusW> I guess
[15:17:33] * RikusW got caught up in the XP vbox
[15:31:25] <megal0maniac> s/XP vbox/Matrix
[15:31:41] <megal0maniac> You've been gone for days!
[15:31:48] <megal0maniac> Weeks!!
[17:58:38] <marvinalone> oh sweet, an avr channel
[17:58:52] <Casper> yup
[17:59:54] <marvinalone> i'm trying to do something that's apparently too simple to google for. all i want to know is if incrementing an integer on an avr32 is atomic
[18:00:51] <jadew> marvinalone, any 1 instruction is atomic
[18:01:01] <marvinalone> i'm not worried about disabling interrupts or any of that stuff. i figure it would be just one instruction, so it ought to be uninterruptible.
[18:01:27] <specing> is it one instruction?
[18:01:32] <specing> if so, it is atomic
[18:02:27] <marvinalone> well … what if the compiler generates a move from there to here, increment, and then move it from here back to there
[18:02:44] <specing> look at the sauce, luke
[18:02:50] <specing> the disassembly sauce
[18:03:17] <swart> or just write your critical code in asm
[18:03:18] <marvinalone> specing: i don't want to write the code such that it depends on compiler flags whether it'll work
[18:03:46] <jadew> marvinalone, if your variable is not bind to a specific register, it what you just said it will always happen
[18:03:48] <swart> do you care for every array iteration, or is it just for a special case?
[18:04:14] <marvinalone> swart: so that's the way to make sure. with an iar compiler, are there macros or libraries to help with that kind of thing?
[18:04:45] <marvinalone> swart: hundreds of times per second, but not more
[18:05:02] <specing> IAR?
[18:05:03] <swart> my google-fu found this
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
[18:05:06] <specing> we do GCC here
[18:06:20] <marvinalone> gcc only? okay :-/ i guess the iar compiler isn't that popular
[18:06:28] <swart> people like free
[18:07:37] <marvinalone> swart: i like free too. this is a customer's demand, though.
[18:07:51] <swart> vendor should have support
[18:08:18] <swart> if they charge you make sure the customer pays for it
[18:11:02] <marvinalone> swart: they pay for the time i spend futzing aroung with inline asm :-)
[18:15:04] <swart> well if they don't have a support contract, then they'll just have to pay more for the extra time it takes you to figure it out :)