Back
[04:49:07] <mux_> abcminiuser: I have good news
[04:49:35] <abcminiuser> Oh?
[04:50:14] <mux_> mass storage bootloader is functional on xmega, I kept the code fairly general but I did use sp_driver.h instead of a modified boot.h
[04:50:31] <abcminiuser> Oh sweet!
[04:50:31] <abcminiuser> I'
[04:50:43] <abcminiuser> *I'm actually looking at that now, another bug report from a user
[04:50:53] <abcminiuser> Except I can't get the darn thing to work on my USBKEY at the moment
[04:51:02] <mux_> I can clean up my code and mail it to you
[04:51:26] <mux_> it's atmel studio based so not quite compatible with your workflow, but it should be good
[04:51:38] <abcminiuser> I can hammer it into place
[04:52:33] <mux_> also, I've done some performance tuning on CDC
[04:52:46] <mux_> I needed high bandwidth for my application
[04:52:57] <mux_> I'm getting just a tad under 500kiB/s
[04:53:08] <mux_> which is about as fast as bulk transfers can go over full-speed
[04:54:01] <abcminiuser> Sweet!
[04:54:13] <abcminiuser> I tip my novelty light up hat to you, good sir.
[04:54:35] <mux_> well, I was actually just about to say you're super awesome for making lufa this great
[04:54:42] <mux_> because ASF doesn't hold a candle to that
[04:55:14] <abcminiuser> (I currently can't get the bootlaoder to work on my development kit, so hold your adulations for now :S)
[04:59:33] <mux_> alright I chopped it down and verified that it compiles
[05:00:42] <mux_> sent
[05:01:10] <mux_> hm, I just realized that I kept my descriptors and device class in, you'll need to change that back to yourself and lufa-lib.org respectively
[05:01:42] <mux_> note: this compiles to >6kB
[05:02:12] <abcminiuser> Balls
[05:02:37] <abcminiuser> 140302 reference bootloader from my site works, one tagged in Git doesn't
[05:02:43] <abcminiuser> So my toolchain's horking it
[05:02:48] <mux_> poopoo
[05:04:57] <abcminiuser> What version of Studio are you using?
[05:05:01] <mux_> 6.2
[05:05:05] <abcminiuser> dang
[05:05:12] <mux_> should work with 6.0+
[05:05:20] <mux_> but not advised to use <6.1 because of programmer woes
[05:05:38] <abcminiuser> I know the toolchain from 6.1 works, I upgraded to 6.2 and that has a new version of the toolchain
[05:05:58] <mux_> there are known issues on the issue tracker for some stuff
[05:06:19] <mux_> I have workarounds for that in the code so it should work fine
[05:06:46] <mux_> e.g. .bootloader or .boot directives don't automatically work anymore, you have to put the .text in the bootloader address
[05:07:43] <mux_> and switch-case jump tables are borked for some reason (they get put in the wrong location and called with the wrong extended calls - EIND is not properly set) so you have to compile with fno-jump-tables
[05:08:05] <abcminiuser> Wish I'd archived the toolchain now to test
[05:08:33] <mux_> you can re-download the previous version and install it next to 6.2
[05:08:45] <abcminiuser> Yeah I know (was an Atmel Apps engineer remember :P)
[05:08:48] <abcminiuser> Low on SSD space
[05:08:48] <mux_> oh right
[05:09:12] <mux_> well why didn't you fix everything while you were at Atmel then? :P
[05:35:47] <mux_> abcminiuser: I did have one other question of future relevance
[05:36:15] <abcminiuser> Shoot
[05:36:29] <mux_> I understand from the datasheet that xmega supports endpoint sizes up to 1023 bytes, but only with isochronous transfers
[05:37:06] <mux_> do you plan on putting support for isochronous RX/TX endpoints for xmega in LUFA?
[05:38:39] <abcminiuser> Not any time soon, for it to work correctly I need ping-pong mode, which means a rearchitect
[05:38:49] <mux_> right
[05:38:59] <mux_> I thought there must be more to it
[05:39:13] <abcminiuser> Balls, it *is* the toolchain
[05:39:24] <mux_> I found out that xmega supports fast re-send, so it's not nearly as relevant on xmega as it is on avr8
[05:39:58] <mux_> you can get almost full bandwidth with 64 byte bulk endpoints on xmega, whereas on avr8 you will only ever be able to get about 64 kB/s with such an endpoint
[05:40:46] <mux_> what error messages do you get?
[05:41:06] <mux_> it might be deprecated flag names... they switched to a new version of gcc
[05:46:30] <abcminiuser> No errors, just doesn't run
[05:46:38] <abcminiuser> Gets part way through enumeration then resets
[05:46:57] <mux_> have you tried -fno-jump-tables?
[05:48:02] <abcminiuser> Bugger me that worked
[05:48:08] <mux_> there is a switch-case statement during enumeration that compiles to a jump table, which is incorrectly addressed in this version
[05:48:10] <mux_> I TOLD YOU SO
[05:48:21] <mux_> VICTORY
[05:48:27] <abcminiuser> One internet to you
[05:48:28] <mux_> I will have my internet points now
[05:48:41] <abcminiuser> Haven't been following GCC development recently, didn't know they broke it
[05:48:53] <mux_> it's only broken for avr-gcc
[05:49:08] <mux_> I know too little about compilers to file a bug report
[05:49:34] <mux_> although I saw one report where it was marked as WAI, as the compiler is expected to NEVER change EIND
[05:49:39] <mux_> which is what causes the problem
[05:49:57] <mux_> if you look at the .lss it compiles to an eijmp (or eicall? I forgot)
[05:50:05] <abcminiuser> Chatting to an Atmel engineer here - got a link?
[05:50:19] <mux_> god... let me see if it's still in my history
[05:51:58] <mux_> I cannot find it for the life of me
[05:52:16] <mux_> it is somewhere in my ~10k page loads since last week...
[05:53:11] <mux_> sorry, no, it's nowhere to be found
[06:00:03] <abcminiuser> Damn
[06:00:12] <abcminiuser> Well that certainly fixes it
[06:00:34] <abcminiuser> LSS doesn't show anything suspicious however, just a minor jump table in one place
[06:01:02] <mux_> the problem is that it tries to jump into application memory because EIND is not properly set
[06:01:28] <mux_> at least that is what my lss implied
[06:01:36] <mux_> (with an xmega128a4u)
[06:01:53] <mux_> this is also a problem for some trampolines, btw
[06:02:05] <abcminiuser> AT90USB1287 here
[06:03:48] <mux_> easy fix: remove all switch-case statements and use branching instead...
[06:04:23] <Valen> can't....tell...if....srs
[06:04:39] <Thrashbarg> srs airbags
[06:04:44] <mux_> hard fix: convince GCC to remove switch-case from the language :P
[06:04:49] <Lambda_Aurigae> Valen, just go jump on your trampoline
[06:04:57] <Valen> ok
[06:05:01] * Valen runs offf
[06:05:23] <soul-d> :D i just dedusted my lufa board last weekend currently running "130303" probably a bit behind ;) donno if it's great idea to try and upgrade at this moment :P
[06:06:10] <abcminiuser> soul-d, you'll be fine :P
[06:06:31] <abcminiuser> Just use a non 6.2 toolchain to add -fno-jump-tables to CFLAGS
[06:06:53] <soul-d> linux + eclipse user so usally a bit of horror at the start
[06:07:59] <soul-d> but the old version worked fine so far so don't expect to much problems
[06:08:19] <mux_> I wrestled with the code for a week before I found the jump table stuff
[06:08:34] <Lambda_Aurigae> never had the patience to deal with eclipse here...just vim and console.
[06:08:35] <mux_> but I couldn't afford to go back to my also-working '13 code, as it compiled too large
[06:08:49] <mux_> lufa '14 is super awesome in that respect
[06:09:11] <mux_> like, 12 vs 7kiB
[06:09:13] <abcminiuser> Goddam mux_ you're right on the money
[06:09:25] <abcminiuser> The main request dispatch switch gets turned into a bad jump
[06:09:41] <soul-d> mmm thats a big diffrence :D
[06:09:51] <mux_> I lost sleep over this :P
[06:10:09] <soul-d> you got the satifaction of figuring it out though
[06:10:25] <abcminiuser> IJMP to 0xFFFF probably won't yield fun times...
[06:11:03] <mux_> soul-d: yeah, and it was a very important part of my codebase, I NEEDED a mass storage bootloader for a whole generation of sensor boards
[06:11:31] <soul-d> yah and yopu probably where thinking what you where doing wrong or did and when
[06:11:39] <abcminiuser> At least on a Venn diagram the circle of screwup isn't overlapping me
[06:12:09] <mux_> I am always doing stuff wrong, I am not a good embedded programmer, I'm a hardware guy
[06:12:21] <Lambda_Aurigae> when compiling lufa, would a -j 8 break things?
[06:12:47] <abcminiuser> Nope, and it's fun to do
[06:12:53] <Lambda_Aurigae> ok.
[06:12:54] <abcminiuser> AHA! mux_ wins another cookie
[06:13:01] <Lambda_Aurigae> some stuff doesn't compile properly with multiple threads.
[06:13:03] <mux_> cookies AND internet points
[06:13:16] <abcminiuser> It's turned into a jump table with LPM only, which doesn't work in a relocated bootloader space on a 128KB device
[06:15:05] <abcminiuser> So basically the same as the XMEGA EIND problem
[06:15:50] <mux_> kind of strange though
[06:16:01] <mux_> that is definitely a regression on avr8
[06:16:16] <mux_> I used jump tables before in bootloaders on a 128kB device and it worked fine
[06:16:32] <abcminiuser> Jupp
[06:17:11] <mux_> xmega is 'different' in that EIND and RAMPZ are explicitly set-once-then-forget registers in general use
[06:31:13] <abcminiuser> mux_, name for the changelog?
[06:31:38] <mux_> eh, what do you mean?
[06:32:34] <mux_> you need my proper name for the LUFA changelog?
[06:32:43] <abcminiuser> I'm adding that flag to the LUFA build system so it doesn't catch other people up, need a contributor name for the changelog
[06:32:51] <abcminiuser> Jupp or whatever name you'd prefer
[06:33:35] <mux_> I am on github as demultiplexer (e.nijssen at google's email service dot com)
[06:33:51] <mux_> github.com/users/demultiplexer
[06:35:32] <abcminiuser> * - Patched the LUFA build system to work around a GCC code generation bug in newer toolchains when building for larger
[06:35:32] <abcminiuser> FLASH memory devices (thanks to demultiplexer)
[06:35:36] <abcminiuser> Ok for you?
[06:35:44] <mux_> sure, thanks for attributing
[06:36:37] <abcminiuser> Credit where it's due
[06:36:47] <abcminiuser> That was a head scratcher I wouldn't have found in a hurry
[06:37:39] <mux_> I'm just happy to have figured this out
[06:37:52] <abcminiuser> Now I can test the actual Mass Storage bootloader patch I was given :P
[06:38:47] <abcminiuser> I'm told I'm bad at 12-bit math
[07:03:10] * Tom_itx thought lufa was covered with cobwebs
[07:04:52] <abcminiuser> And spiders
[07:06:22] <Tom_itx> those Au spiders are nasty too i hear
[07:10:33] <abcminiuser> I thought I'd relax from debugging all day by testing a user contrib patch
[07:10:42] <abcminiuser> And two hours later, here I am ready to test it
[07:11:09] <mux_> two and a half hours :P
[07:13:37] <Roklobsta> debugging light bulbs again?
[07:13:50] <mux_> I mean, how many people can it take to...
[07:14:13] <mux_> (has this joke been made before?)
[07:18:17] <abcminiuser> &%$*^&$
[07:18:24] <mux_> what's wrong
[07:18:37] <Tom_itx> mouse ran across his kbd
[07:19:50] <mux_> has anyone here ever sent stuff to Dave Jones (EEVBlog)?
[07:41:54] <Roklobsta> i watched one eeblog video once, the shrillness cracked my LCD.
[08:22:35] <Celerity> I like EEVBlog videos
[08:22:49] <Celerity> very helpful for people who have no idea about electronics
[08:26:30] <Jartza> yes, like for me ;)
[08:31:12] <antto> my cat watches it too
[08:31:38] <twnqx> lol
[08:33:08] <homeflux_> i hate his voice
[08:33:29] <antto> he talks like the crocodile man
[08:33:55] <antto> sort of
[11:36:58] <hetii> Hey :)
[11:38:20] <hetii> I play with v4l api and image capturing. I can set there how many frames i will capture before save image. The point is that i don`t see differents when i capture one frame or 100, just my buffer is bigger and resulting file
[11:39:06] <hetii> So is there any reason why i should capture more frames when want to make a picture ?
[11:50:17] <soul-d> well it might com in handy if you want to do stuff with image in buffer also stacking images for better quality is a method that exists often used in astronomy so i think that option is just their for people that want to do on the fly processing
[11:55:50] <hetii> It will be used to take a face picture and i do it on embedded device so the time processing and size of final file is important for me
[11:56:03] <hetii> Also another interesting fact is about the time that need top be consumed by my application when i set different resolution, whatever if i set 320x240 or 1080x768 the execution time is always from 1.55s till 2.3s
[12:44:31] <noa> :)
[13:18:52] <tunixbsd> how i put the adress of a function in the Z register ?
[13:28:01] <ivanshmakov> tunixbsd: You mean, something like the following? ldi r31, (0377 & (name >> 8)) ; ldi r30 (0377 & name)
[13:28:26] <ivanshmakov> s/ldi r30 /ldi r30, /.
[16:49:09] <jeremyabel> http://www.atmel.com/Images/Atmel-8011-8-bit-AVR-Microcontroller-ATmega164P-324P-644P_datasheet.pdf why did they put INT0 and INT1 on the same pin as RXD1 and TXD1?
[16:49:18] <jeremyabel> I want both of those things!
[16:50:59] <jeremyabel> oh wait I get an INT2 up there
[16:51:06] <jeremyabel> on PB2
[17:15:40] <Getty> jeremyabel: ETOOMANYPINS ;)
[17:30:35] <jeremyabel> Getty: yeah but they could have put them somewhere that was less-used than an RX/TX line!
[17:31:03] <jeremyabel> I dunno maybe on one of the ADC lines
[17:31:19] <jeremyabel> lord knows I've never used one of those on an AVR before
[17:31:51] <jeremyabel> I found one on PB2 though
[17:32:29] <jeremyabel> problem is, I have it triggering on rising edge, but it's triggering 3 times where when I had it on a PCINT pin it was triggering twice (once for each edge)
[17:35:38] <jeremyabel> and according to my scope, my signal is presteenly debounced
[17:39:06] <jeremyabel> or I'm just an idiot
[19:21:26] <Lambda_Aurigae> http://www.seeedstudio.com/depot/WiFi-Serial-Transceiver-Module-w-ESP8266-p-1994.html
[22:23:21] <Xark> Lambda_Aurigae: Out of stock... :(