Back
[00:18:35] <rue_house> that schaematic totally lacks information about which pin of porta and portb goes to the encoders
[06:54:50] <AllinYourhead> ohoy! AS6 question here: My project can be built for three different devices but they differ in a few #define's and are otherwise identical. Is it possible to make AS6 automatically build three outputs that each is using its own #defines (maybe placed in separate header)?
[07:09:59] <v0kehc> AllinYourhead: ifdef the defines
[07:10:09] <v0kehc> and includes
[08:00:44] <yunta> OndraSter: my usb pairs look like this
http://picpaste.com/pics/NewFile6.1386596456.png (this is xmega->host part. other way around bits are beautiful). is that normal? are yours prettier?
[09:45:46] <OndraSter> yunta, I don't have a digital scope so I can't capture mine
[09:51:36] <yunta> damn...
[10:25:28] <beaky> hello
[10:38:10] <megal0maniac_afk> yunta: I could check with a logic analyzer, but that would be much prettier since it has 1bit resolution
[10:38:17] <megal0maniac_afk> So that would be silly
[10:39:03] <megal0maniac> Hi beaky
[10:43:53] <beaky> helo
[10:44:23] <beaky> is it normal for uart receiver to get garbage data?
[10:44:43] <megal0maniac> If the pin is floating, then yes
[10:44:47] <beaky> i sent perfectly formated json in ascii, but my arduino uart rx gets garbage
[10:44:55] <beaky> ah i will check if things are floating
[10:45:05] <megal0maniac> Then your baud rate is probably wrong
[10:45:17] <megal0maniac> Or your logic levels are wrong
[10:45:26] <beaky> yeah i am using 5v for the tx, and 3.3v for the rx
[10:45:32] <beaky> how do i fix that
[10:45:49] <megal0maniac> Logic level translator. But that should be alright
[10:46:00] <beaky> right i guess baud rate is the bigest suspect
[10:46:10] <beaky> (can avr handle 5v at 3.3v?)
[10:46:10] <megal0maniac> Yip
[10:46:22] <megal0maniac> Good question. I don't know
[10:47:22] <beaky> i have to check electrical ratings section
[10:47:27] <beaky> of my datashet
[11:10:42] <beaky> yeah avr pins isn't 5v tolerant
[11:24:02] <OndraSter> beaky, read datasheet. Inputs can be +0.6V above Vcc
[11:24:08] <OndraSter> then it starts clamping
[11:30:38] <beaky> clamping?
[11:30:47] <beaky> what is that
[11:37:48] <OndraSter> it starts "putting the GPIO pin's voltage on the vcc line"
[11:37:51] <OndraSter> to prevent from damage
[11:38:00] <OndraSter> huh my english is today absolutely broken
[11:38:21] <megal0maniac> My czech is worse
[11:41:38] <learath> it starts by putting the gpios on it's skin?
[13:22:11] <braincracker> beaky yes, normal, a few C rise for an avr also it heats up more if you run at higher freq
[13:22:12] <braincracker> :)
[13:22:46] <braincracker> also higher supply voltage makes a difference in core temperature, measured it using mega168PA internal sensor
[13:42:53] <beaky> i love voltage
[13:43:36] <twnqx> beaky :(
[13:43:43] <twnqx> i didn't find a shop for my needs :(
[13:44:05] <twnqx> but i do understand now why you say that avr stuff is so expensive here
[13:44:07] <braincracker> twnqx hemp ?
[13:44:28] <beaky> twnqx: yes they are disapointingly steep price
[13:44:54] <beaky> and they will look at you funny when you ask for anything not common
[13:45:11] <beaky> still beats waiting months for an avr to come from ebay :D
[13:45:19] <braincracker> like i want to see girls in bikinis playing in the snow ?
[13:45:21] <twnqx> guess so...
[13:46:01] <twnqx> but i realised i'd need more than just an avr. programmer, soldering stuff, power supply... so i postponed it
[13:46:52] <braincracker> they use iris scanners in dubai aairport ?
[13:47:09] <twnqx> sometimes
[13:47:23] <braincracker> if you are suspected of terrorism?
[13:47:32] <twnqx> i think they used them on me when i entered by road from saudi arabia
[13:47:46] <twnqx> and they do when you get there for a work visa
[13:48:06] <braincracker> oh i think they can iris scan from a distance nowadays
[13:48:17] <braincracker> it is not just the red laser thing seen on films
[13:48:32] <braincracker> but 3Gpixel camera
[13:48:46] <Casper> dosen'T seems to be that high resolution
[13:48:49] <Casper> from what I read
[13:48:54] <Casper> however
[13:49:02] <braincracker> they use these in military
[13:49:09] <beaky> avr-powered iris scaners?
[13:49:14] <Casper> some readers also check for the dillatation of the blood vessel in the eyes
[13:49:21] <Casper> which mean it need a video recording
[13:49:39] <braincracker> you can have 10Mpixels as a civilian, they can have x amount like 1000x more ;)
[13:50:20] <braincracker> makes sense anyway no ?
[13:50:31] <twnqx> no
[13:50:37] <braincracker> why ?
[13:50:46] <braincracker> gov wants control over civilians.
[13:50:50] <beaky> why can avr have such a wide operating voltage
[13:50:50] <twnqx> itÄs easier to tell people to look into something
[13:51:12] <twnqx> gpix cameras are too expensive to be worth it for this scenario
[13:51:15] <braincracker> you don't give everything you have to those who you want control over.
[13:51:39] <braincracker> expensive ? :) gov makes it free from your tax money
[13:51:51] <twnqx> there are next to no taxes here...
[13:52:04] <braincracker> you mean in Dubai ?
[13:52:09] <twnqx> yes
[13:52:12] <braincracker> no need, so much oil is sold
[13:52:17] <twnqx> nope
[13:52:24] <twnqx> there's no oil either :P
[13:53:15] <braincracker> where do all that gold come from ?
[13:53:50] <twnqx> service charges
[13:54:18] <braincracker> beaky<= because mosfets operate with a wide range of gate source voltage
[13:54:45] <Casper> grrr
[13:54:46] <braincracker> the smaller, faster ones though will not survive even 1.9V
[13:54:51] <Casper> where's my dremel cutting wheels?
[13:55:00] <Casper> need to fix a short on that perfboard :(
[13:55:06] <beaky> i love mosfets
[13:55:09] <braincracker> i have some, diamond powdered
[13:55:31] <beaky> wow diamond perfboard?
[13:56:15] <braincracker> no, diamond sintered cutting discs :)
[13:56:22] <yunta> megal0maniac_afk: it could actually make sense, if your time resolution is high enough, and 1/0 threshold lies significantly below or above 1.65V, then you should at least notice that ones and zeros are of different length. but it's too much effort to be worth it, I'll just ask abcmini when he gets here.
[14:05:04] <twnqx> ah well... good night folks
[14:08:10] <Casper> grrr will go buy some cutting wheels
[14:10:51] <beaky> i love avr
[14:11:00] <beaky> it is so cheap
[14:11:14] <beaky> or are there cheaper and better ucs than avr
[14:11:19] <braincracker> gold is better
[14:11:47] <beaky> gold?
[14:11:55] <braincracker> Casper<= you mean the small ones for dremels and such ,? i have 5
[14:12:11] <Casper> yes the small ones
[14:12:19] <braincracker> it was 3 euros
[14:12:26] <Casper> not the new style, but old style (yeah, harder to find)
[14:12:26] <braincracker> for 5
[14:12:43] <braincracker> and diamond wheels
[14:13:04] <braincracker> crazy chinese eh ?:)
[14:13:19] <Casper> bbl
[14:13:29] <Casper> need to fight the white flakes...
[14:14:19] <braincracker> beaky<= yeah gold is better to buy than avrs
[14:15:29] <braincracker> it will hold its value
[14:15:44] <beaky> but gold isnt a uc it is a comodity
[14:15:59] <braincracker> and gold is no food :)
[14:16:04] <braincracker> and no water
[14:16:30] <braincracker> still many prefer to gather/store gold instead
[14:18:09] <beaky> there is gold inside avr
[14:18:13] <beaky> bond wire
[14:18:18] <beaky> (or is it silver?)
[14:18:19] <braincracker> :) not much...
[14:18:25] <braincracker> eerm, is there gold ?
[14:18:36] <beaky> yes open one and you find gold bond wire
[14:18:39] <braincracker> they can use aluminium and copper too
[14:18:43] <beaky> oh
[14:18:50] <braincracker> also silver...
[14:20:06] <braincracker> i saw aluminium bondwires and ceramic pcb used in automotive hirel control circuits
[14:20:53] <braincracker> it would have been easy to solder them if the were silver, but...
[15:40:05] <jerkey> beaky do you love the IXDD604PI
[15:57:33] <kdehl> Hrm. So $35 is the cheapest CC3000 breakout board I can find...
[15:58:00] <kdehl> I thought those chips were less than $10. So why hasn't any Chinese person started building breakout boards for $11 ?
[15:58:44] <Casper> probably due to the arduino fever
[15:59:15] <kdehl> What do you mean?
[15:59:36] <kdehl> They can maky an arduino version for me, that's fine. As long as I get a breakout board.
[16:05:36] <kdehl> Meh. The chip itself only takes 1.8 V.
[16:07:53] <kdehl> Maybe I suddenly have a reason to play with an 1.8 V AVR.
[16:10:37] <kdehl> I guess it kinda makes sense to have low voltage on a chip that's designed to be used on portable devices...
[16:10:43] * kdehl bakes some bread
[16:18:40] * kdehl requests a sample
[16:21:39] <kdehl> Madsoft is legit. So is the company's address: dose.se
[16:52:14] <kdehl> Anyone tried any other cheap wifi chip for an AVR?
[18:06:37] <kdehl> Huh. O'Reilly has a great book on XBee/ZigBee.
[18:24:35] <ambro718> is it possible to check from an interrupt whether there are any other interrupts pending?
[18:24:50] <ambro718> other than checking interrupt-specific flags
[18:26:27] <Valen> not that I know of, why would you want to though?
[18:26:46] <ambro718> I'm running out of timer interrupts with low priority
[18:27:08] <Valen> how do you mean?
[18:27:27] <ambro718> I have rather demanding tasks to do in timer interrupts, but because the interrupt priority is higher than usart rx interrupt, it's causing lost bytes on usard
[18:27:51] <ambro718> if those timer interrupts had higher priority the problem wouldn't exist
[18:28:34] <ambro718> a possible fix is to, at the beginning of the timer interrupt, check whether usart rx is pending, and if it is, reschedule the timer and return quickly
[18:28:57] <Valen> if you can do that, why not shift the stuff you are doing in the timer into main loop and poll it?
[18:29:21] <ambro718> it's still time sensitive, just not as much as receiving on usart
[18:30:22] <Valen> the issue is doing that would resolve the issue if they both happen simultaniously, but if rx is set one clock later your still boned
[18:31:34] <Valen> I'd look at parcelling up your main loop so it can be executed in chunks small enough to not bother your time sensitive thing and then doing it in the main loop, that way your isr's can work as expected
[18:31:35] <ambro718> what needs to be considered it how many clocks it takes from when usart is pending to when it executes. Any pending interrupt with higher priority at that time will work against serving the rx in time.
[18:31:38] <Valen> what are you actually doing?
[18:32:04] <ambro718> the timers are driving steppers
[18:32:23] <Valen> so you shouldn't need any heavy lifting there, just setting some pins
[18:32:44] <ambro718> there is calculation of next step time which is hard
[18:32:56] <Valen> that should be fine to go into main loop
[18:33:11] <ambro718> the buffering overhead would be too much overhead
[18:33:12] <Valen> well one presumes
[18:33:19] <Valen> whats the application?
[18:33:29] <ambro718> ... it doesn't matter....
[18:33:34] <ambro718> 3d printer
[18:34:10] <Valen> well you should be able to run your motion planning well in advance of the actual stepping then
[18:34:25] <Valen> http://www.youtube.com/watch?v=Ttg909231zc is a stepper based thing I did recently ;->
[18:34:52] <ambro718> I do, but I don't calculate the individual step times. I calculate "commands" which specify second order (constant acceleration) motion, and those get buffered and consumed by the timers.
[18:35:29] <Valen> I'd suggest perhaps taking a look at the code behind the other mcu based g-code stepper things
[18:35:43] <ambro718> from time to time when a timer completes a command it fetches the next one from the buffer (but any single command can take lots of steps)
[18:36:36] <ambro718> I have... they use a different algorithm....
[18:36:57] <ambro718> I still believe I can hack around the interrupt priorities
[18:37:13] <Valen> it just is feeling like you are solving the problem the wrong way around
[18:37:32] <Valen> have you checked to see if you can fit your timer servicing code in at max step rate?
[18:37:42] <ambro718> of course
[18:38:07] <Valen> I know on mine it was getting under 400 cycles per step
[18:38:24] <ambro718> mine has about 600
[18:38:30] <Valen> I do zero actual step processing in the ISR, but I do only care about speed, not position
[18:39:02] <Valen> I'm just using the PWM out to drive the step output, then i control the top value from my regular "clock" timer interrupt
[18:39:04] <ambro718> I know. I do it differently. I step all axes individually, and I calculate step times with quadratic formula.
[18:39:58] <Valen> because the only way to do what you want is to poll the crap out of the usart register during your isr
[18:40:17] <ambro718> it's a bit more precise because the steps happen when they should, as opposed to steps of all other steppers being limited to happening at the same time as steps for highest-distance stepper
[18:40:50] <Valen> there is no reason for the steps to happen at the same time in mine, I just use 2x 16 bit timers, one per stepper
[18:41:12] <ambro718> how do you make sure they don't get out of sync in time?
[18:42:04] <Valen> in mine i don't need to, the target application is speed not position, but you can close the loop by having the timer ISR just add one to a counter
[18:42:15] <Valen> IE run it more like a servo system
[18:42:30] <ambro718> yeah that seems easier
[18:42:54] <ambro718> that is not having to deal with position
[18:43:08] <Valen> you could still do it open loop by just doing the maths
[18:43:44] <ambro718> I think I'll go with "polling the crap out of" ;)
[18:44:14] <Valen> I feel you are still going to have issues, and if you add anything else to it they are just going to get bigger
[18:44:28] <Valen> I mean don't get me wrong, I'm a big fan of doing stuff in the ISR
[18:44:30] <ambro718> anything like what?
[18:44:38] <Valen> I did a floating point PID loop in an ISR
[18:44:47] <Valen> i mean if you expand your project at all
[18:45:01] <ambro718> it's already pretty expanded lol
[18:45:08] <ambro718> https://github.com/ambrop72/aprinter
[18:45:40] <ambro718> I just don't think there's anything truly as time sensitive as usart rx
[18:46:47] <Valen> http://pastebin.com/Vt0tDEia
[18:46:59] <ambro718> it works pretty well on atmega2560 where I can use TC4/5 for the steppers (which have low priority), but on 1284p there's only 1 TC with low priority
[18:46:59] <Valen> I'd say generally usart rx is fairly insensitive
[18:47:14] <Valen> how many clocks do you have per byte?
[18:47:35] <Valen> thats the code for my spinning disk thing
[18:47:47] <ambro718> 2*16MHz/(25000/s) = 1280 cycles in worst case for serving the ISR
[18:48:13] <ambro718> so from when the rx isr is pending it needs to be served in that time, or hardware buffer overflows
[18:48:23] <Valen> see thats quite a few instructions really
[18:48:32] <ambro718> 2* because the avr hardware has 2 bytes buffer
[18:48:33] <Valen> and less than the 600 your isr needs to run in
[18:49:01] <Valen> brb
[18:50:22] <Valen> back
[18:50:49] <ambro718> sure, but I have one isr for each of 4 steppers. On the 1284p, I have two steppers on low-priority isrs, and two on high-priority isrs. This means when rx becomes pending, in the worst case, one of the low-priority isrs has just begun execution, and both of the high-priority isrs go pending right at that time. So it takes 3*600 cycles for the rx to be served.
[18:51:40] <ambro718> that is the current low-priority isr needs to complete, and the two high-priority isrs both need to start and complete
[18:51:59] <Valen> you are running overloaded though
[18:52:19] <ambro718> huh?
[18:52:29] <ambro718> you mean baud rate?
[18:52:32] <Valen> your ISR takes 600 clocks to execute?
[18:52:43] <Valen> for the stepper
[18:52:46] <ambro718> well 560 or something, don't know the exact count
[18:53:06] <Valen> right, and at fastest speed you have 600 clocks between interrupts?
[18:53:18] <ambro718> much of this is squaere root and division (both hand-written in assembly)
[18:53:29] <ambro718> yeah
[18:53:41] <Valen> you cant then have 2 of these isr's running
[18:53:52] <Valen> there arent enough clocks
[18:54:05] <ambro718> the planning code limits speed based on sum of all steppers
[18:54:23] <ambro718> so the total step frequency never exceeds a given constant
[18:56:30] <ambro718> so if you tell it to move X as fast as possible, it will go very fast, but if you tell it to move X and Y at the same time, each axis only goes half that fast
[18:56:46] <Valen> that'll slow your rapids somewhat
[18:57:13] <ambro718> it's really only a problem with extruder retractions, those could be a bit faster, otherwise it's ok
[18:59:31] <ambro718> I've been experimenting with "multiplexing" a timer to expose two or more virtual timers, but the overhead is too great
[19:00:07] <ambro718> so that I could use one low priority ISR for stepping two axes, then I wouldn't run out of low priority ISRs for stepping
[19:01:10] <ambro718> i.e. set it to fire at min time
[19:02:15] <Valen> you know I'm of the opinion you really are overthinking it, you know that right ;->
[19:02:27] <ambro718> yeah lots of people say that lol
[19:02:51] <ambro718> it's easy to say when you haven't actually been dealing with the problem for a few months ;)
[19:03:06] <Valen> i mean what is the error you are going to introduce doing the stepping in a more "sane" way ;->
[19:03:39] <Valen> I only ask because we run a CnC mill
[19:03:44] <ambro718> I don't know, I have yet to try alternative ways.
[19:03:45] <Valen> running EMC
[19:05:53] <Valen> https://www.youtube.com/watch?v=R_udQwy1hJk
[19:06:18] <Valen> we run 0.001mm glass scales and hit around .005 positioning
[19:06:40] <ambro718> nice
[19:08:08] <ambro718> ok thanks for the suggestions, I'll be trying out more stuff :)
[20:10:08] <kdehl> Okay, I've read the entire datasheet of the 28F020. In order to program it, all I need to do is to feed Vpp 12 volts, pull WE low, OE high (sounds weird, but... okay) and then I can use it write data to it just like an SRAM chip. Did I get that right?
[20:27:48] <Epsilon-Auriga> kdehl: ummm....no.
[20:29:21] <Epsilon-Auriga> page 14 of the datasheet shows the programming algorithm.
[20:29:40] <Epsilon-Auriga> and, remember, for flash, you have to erase it before you can program it.
[20:29:54] <Epsilon-Auriga> page by page generally...haven't gotten there in the datasheet yet..
[20:30:08] <kdehl> Epsilon-Auriga: Damn, you're fast.
[20:30:25] <Epsilon-Auriga> page 15 shows the erase system.
[20:30:27] <Epsilon-Auriga> fast?
[20:30:57] <kdehl> Ah. I didn't get you had to erase it first...
[20:31:03] <kdehl> Epsilon-Auriga: Yeah, reading the datasheet. :)
[20:31:08] <Epsilon-Auriga> that's standard for all flash.
[20:31:24] <Epsilon-Auriga> flash has to be erased to 0xFF or all ones or whatever first.
[20:31:34] <Epsilon-Auriga> then programming it unsets any 0 bits.
[20:31:54] <kdehl> Okay, I understand.
[20:32:48] <Epsilon-Auriga> you can, in theory, program already programmed flash(unless that particular chip locks it out) but all you can do is toggle any 1 bits to 0...can't toggle 0 bits back to 1 without an erase.
[20:33:02] <kdehl> Yeah.
[20:33:03] <kdehl> Heh.
[20:33:23] <Epsilon-Auriga> what is it you are using this for?
[20:33:28] <Epsilon-Auriga> there might be a better solution.
[20:34:00] <kdehl> It's for a NES.
[20:34:09] <kdehl> So I don't think I have any other option.
[20:34:17] <Epsilon-Auriga> aahh.
[20:34:26] <Epsilon-Auriga> making your own cartridges?
[20:34:34] <kdehl> And besides, I'd like to learn how to program an EEPROM.
[20:34:36] <kdehl> Yeah.
[20:34:43] <Epsilon-Auriga> that's not an eeprom
[20:34:48] <Epsilon-Auriga> that's a flash prom
[20:34:57] <kdehl> Oh. I thought flash was a type of eeprom.
[20:35:03] <Epsilon-Auriga> eeprom is a different world entirely.
[20:35:04] <kdehl> Heh. There's so much I have to learn.
[20:35:06] <kdehl> Okay.
[20:35:32] <kdehl> Been cheating with a pre-made flash cartridge for too long. It's time to make my own. :)
[20:35:42] <kdehl> And I'd like to add a port as well, so that I can communicate with it.
[20:35:53] <kdehl> A memory mapped port.
[20:37:14] <Epsilon-Auriga> http://www.atmel.com/devices/AT28HC256.aspx
[20:37:27] <Epsilon-Auriga> there's a 32k * 8bit parallel eeprom.
[20:38:31] <kdehl> Ah, cool.
[20:38:36] <kdehl> Mine's 2 Mbit.
[20:38:38] <kdehl> uh.
[20:38:41] <kdehl> Like you know.
[20:38:42] <kdehl> Heh.
[20:39:36] <Epsilon-Auriga> yeah.
[20:39:44] <Epsilon-Auriga> that's just the first I found in a nice dip package.
[20:42:20] <Epsilon-Auriga> http://www.atmel.com/devices/AT28C040.aspx
[20:42:25] <Epsilon-Auriga> 4mbit
[20:43:24] <Epsilon-Auriga> The AT28C040 is accessed like a static RAM for the read or write cycle without the
[20:43:24] <Epsilon-Auriga> need for external components.
[20:43:50] <kdehl> Cool.
[20:43:59] <N2TOH> what's it for the AT28C04 that is?
[20:44:08] <kdehl> But I think I want to stick to these anyway.
[20:44:22] <kdehl> I'd like to learn this part too.
[20:46:48] <Epsilon-Auriga> N2TOH: what is what?
[20:46:59] <Epsilon-Auriga> the at28c04 is old and I don't think it's used anymore.
[20:47:08] <Epsilon-Auriga> err...made anymore.
[20:48:06] <kdehl> Okay, so first I program the whole memory to 0x00, using the Quick-Pulse Programming Algorithm. And then I can use Quick-Erase Algorithm to erase it back to 0xFF?
[20:48:22] <Epsilon-Auriga> kdehl: yeah.
[20:48:35] <N2TOH> the AT28C040 can't be all that old as ATMEL has it listeed
[20:48:46] <Epsilon-Auriga> you said at28c04
[20:48:57] <Epsilon-Auriga> at28c040 is a different chip.
[20:48:58] <kdehl> Epsilon-Auriga: Great, thanks.
[20:49:19] * N2TOH has made a typo it happens...
[20:49:28] <Epsilon-Auriga> hehe.
[20:49:52] <Epsilon-Auriga> so, you asked "what's it"...what is what?
[20:50:49] * N2TOH encourages the application of real thinking as such, consider bad typing skills before ripping into people :P
[20:51:45] <N2TOH> or questionable Internet links...
[20:51:47] <Epsilon-Auriga> wasn't ripping...just trying to understand your question...and the at28c04 is a valid part as is the at28c040.
[20:51:58] <N2TOH> kk
[20:52:29] <N2TOH> back to my initial question, what is the AT28C040 intended for?
[20:52:49] <Epsilon-Auriga> no clue. it is a 4mbit eeprom.
[20:53:00] <N2TOH> uh, OK
[20:53:09] <Epsilon-Auriga> was just showing kdehl the difference between flash and eeprom.
[20:53:20] <N2TOH> ah kk
[20:53:29] <Epsilon-Auriga> wherein some eeproms are accessed, read and write, just like sram.
[20:53:53] <Epsilon-Auriga> and flash has to be erased before written to.
[20:54:02] <N2TOH> it cought my attention of things old, during my quest to learn the ancient PDP-11 systems
[20:54:07] <jerkey> N2TOH i think it was used as the BIOS ROM for some desktop computers probably
[23:31:44] <Essobi> What's the cheapest usb hid emulated chip I can get into?
[23:37:33] <Essobi> Hmm... AT90USB162?
[23:43:11] <N2TOH> there is code to bitbang USB HID and other devices on common AVR hardware
[23:43:53] <N2TOH> it needs 12MHZ or faster system clock speeds...
[23:47:23] <Casper> but software one don't let much ressources left for actual program
[23:48:13] <N2TOH> perhaps
[23:48:43] <N2TOH> I'm not say it is a good/bad idea. only that it can be done
[23:49:06] <Essobi> I'd rather have plenty left over for software...
[23:52:27] <Essobi> Perhaps I should rephrase that..
[23:54:39] <Essobi> What would be a decent chip to proxy USB hid devices through?
[23:54:58] <Essobi> AT90USB162 Hmmm... ATmega32U2?
[23:55:27] <N2TOH> use another chip, have you looked at the other chips the soft USB stack supports?
[23:55:46] <Essobi> Nope..
[23:56:34] <N2TOH> there are dedicated USB chips, and AVR bit bang solutions, why not just double up on the same parts?
