Back
[00:00:29] <N1njaway> The nice thing with the callback structure is you can register a callback to a particular method of an object's class simply by doing something like "UtCallbackClass(classname, objectname, methodname);" and that's it
[00:01:21] <N1njaway> Which is something you can't normally do in C/C++ without doing static methods and custom casting and passing of the instance pointers around, which makes stuff ugly in no time flat.
[00:03:06] <jadew> is it a macro?
[00:04:50] <N1njaway> So for instance, in our system, you can register a callback to a button press by doing something like "guiButton1->eventSender.addListeer(UT_BUTTON_CLICK, UtCallbackClass(SomeClassName, object, doButtonPress);" -- and whenever Button1 generates a click event, it will automatically call object->doButtonPress(); and will pass any information related to that button press (or whatever the event is)
[00:04:50] <N1njaway> to that method automatically. You can also dynamically add or remove as many callback listeners as you want on the fly. This is AMAZINGLY useful for building dynamic GUI object-inspector windows that change based on whatever the object is that is selected.
[00:06:28] <N1njaway> jadew: Nope, it's an actual class called (in this case) UtCallbackClass -- Ut as the prefix for our user interface stuff. It is decended from a generic class that can be taylored to the type of callback. So for instance, I've created seperate callback classes for things like network and MIDI, that have their own requirements due to unique message structures.
[00:08:05] <N1njaway> jadew: It's a slight bit of (or more than just a slight bit!) of black magic that uses both class templating and vtable manipulation behind the scenes that is invisible on the front end. It's some of the more scary C++ code you'll see, but it works flawlessly, and has been tested on gcc on multiple platforms, MS Visual Studio, and Embarcadero/Borland and works great on all of them.
[00:09:53] <jadew> nice
[00:09:56] <N1njaway> But the end result is that it provides a super-clean way to effectively create a callback "object" that wraps the class name, the method, and the instance pointer neatly in to a single package. Couple that with the EventSender and DelayedEventSender (for multi-threading) classes, and you have some pretty awesome run-time coupling possibilities for message passing that make building powerful
[00:09:56] <N1njaway> interactions quite simple.
[00:10:54] <N1njaway> And since you are using message-passing for the stuff, it's easier to embrace the whole "favor composition over inheritence" design methodology, so code dependencies between classes naturally start to go way down.
[00:12:02] <N1njaway> Anyhow, I'm rambling. But yeah, we'd love to get more folks using it since we've spent the past 5-6 years of time developing this stuff out of the frustration with all the other (in our opinion) cumbersomoe ways of doing things :)
[00:12:48] <N1njaway> Ugh, guess I should get to heading home - gotta be back here relatively early again tomorrow.
[00:13:05] <N1njaway> Anyhow, good luck on your HID adventures, jadew!! Let us know how it turns out. :D
[00:13:33] <jadew> heh, thanks
[00:13:49] <jadew> I'll probably just use that library you linked
[00:14:10] <vsync_> ah, this 13 K/W heatsink on my 7805 is smexy...
[00:15:01] <vsync_> should be able to waste at least 6 watts as heat! oh yeah!
[00:15:23] <N1njaway> vsync: Don't know your applications, but CUI (et al) make some fantastic DC/DC switcher drop-ins for the 78xx series of stuff. I've used them on a lot of designs, and they're awesome. Very inexpensive, and then you can run like 6-36V in to your design without the headsink :)
[00:15:51] <N1njaway> Same 3-pin arrangement, too. Just a little potted box instead of a TO-220
[00:16:00] <vsync_> yep but yesterday i was thinking of going to get an smp
[00:16:16] <N1njaway> smp?
[00:16:27] <vsync_> switching mode reg
[00:16:42] <N1njaway> Yes, same thing :)
[00:16:53] <vsync_> but then i found this heatsink so take away pizza and stay in it was
[00:17:51] <N1njaway> Just make sure you add the input/output caps if you transition. I'd also HIGHLY reccomend using the potted ones, and the CUIs have never failed us. Some of the unpotted 'budget' ones are fine until you accidentally brush against the board with your fingers and suddenly the part decides to regulate out +24V instead of +5V and destroys your circuit :)
[00:18:19] <vsync_> of course always caps
[00:18:29] <vsync_> with smps you have to play with an inductor also
[00:18:37] <N1njaway> And don't use tantalums with them. Go cheap and use electrolytics. Expensive tants caused meltdowns in the field with a Recom.
[00:18:53] <Roklobsta> jadew: i was thinking of this
http://libhid.alioth.debian.org/ but it's old and smelly now
[00:18:58] <N1njaway> vsync: Just get an all-in-one module. It's already done. Just three pins :)
[00:19:20] <vsync_> meh :) it's done already!
[00:19:44] <jadew> Roklobsta, I think those are the only two hid libraries out there
[00:20:35] <Roklobsta> i did use libhid a loooooooooooooooooooong time ago with CM109 audio chips to change eeprom stuff i recall
[00:20:58] <vsync_> heatsinked the 7805, testing out a pam8403 later on today
[00:21:29] <N1njaway> Just watch your transients on the part. I went through several SMC chips and designs before we found one that was extremely robust to clean starts. Also be aware that some are EXTREMELY sensitive to any leakage current on to the VCC output rails through other items in the circuit. Like for instance, if you have RS485 connected to the device, just having the bit of leakage current through the RS485
[00:21:29] <N1njaway> chip in the unpowered state was enough to prevent some of the SMC's from powering on! THAT is bad to have happen in the field. X.x
[00:22:23] <N1njaway> Worst yet, it would be hit-or-miss on that sometimes. Even having some filtering caps on the VCC rail was enough to have the SMC act up. :)
[00:23:05] <N1njaway> Anyhow, just some things from my experience you may want to look at if you go that route. They can be easy, or they can be hell in my experience. :)
[00:24:20] <N1njaway> Okay, time for home for real now! Have a wonderful $PARTOFDAYITCURRENTLYISFORYOU!
[00:27:46] <vsync_> hah
[00:29:26] <theBear> people say tants are good, but sooner or later they ALL go dead short, and it sucks balls
[00:31:19] <Roklobsta> they are called tants because eventually they have TANTrums.
[00:45:31] <hugogee> im a avr noob, trying to learn. Its not clear to me yet which programmer i would serve me best. What is a decent programmer? should i make my own?
[00:46:19] <hugogee> short version. i need help choosing a programmer. -tanx
[00:46:47] <jadew> well, in order to make your own you need a programmer, unless you make a paralel bitbang programmer, but those tend to suck
[00:47:17] <hugogee> jadew, could i use an uno as the programmer? Do i need anything more to set fusebits...etc?
[00:47:54] <jadew> you probably can
[00:48:46] <hugogee> why do programmers exist then? is that a dumb question?
[00:50:06] <jadew> so you can program stand alone chips
[00:50:12] <jadew> or program them while they're in a circuit
[00:50:13] <GargantuaSauce> you can program an avr with two pushbuttons if you want
[00:50:16] <GargantuaSauce> they're for convenience
[00:50:48] <hugogee> hmm, but an uno can do anything a programmer can?
[00:51:48] <GargantuaSauce> a programmer is usually just another avr
[00:52:05] <hugogee> ugh, im a bit overwhelmed atm.
[00:53:21] <GargantuaSauce> http://arduino.cc/en/Tutorial/ArduinoISP
[00:53:29] <GargantuaSauce> that should tide you over until you get a dedicated one
[00:53:51] <hugogee> GargantuaSauce, thanks. Imma go do some reading.
[00:53:59] <GargantuaSauce> http://dx.com/p/148046 I use this one
[00:55:28] <hugogee> so the progammer writes a bootloader to the avr?
[00:55:58] <GargantuaSauce> if you want to program it afterwards over serial, yes
[00:56:02] <Roklobsta> hugogee just buy an AVRDragon
[00:56:05] <GargantuaSauce> otherwise you can just program it directly with the isp
[00:56:27] <Roklobsta> you get inline debugging AND programming
[00:56:41] <hugogee> Roklobsta, thats a fancy unit.
[00:56:52] <Roklobsta> arduino is death by 1000 cuts
[00:57:01] <Roklobsta> hugogee: it's not expensive and works well
[00:57:30] <hugogee> Roklobsta, 1000 cuts, meaning a 1000 ways to reach the same objective?
[00:57:56] <Roklobsta> it's a crappy way of doing things.
[00:58:12] <Roklobsta> ISP and AVRStudio is much better
[00:59:17] <hugogee> I guess ultimately i want something that will grow with me, that works welll with a variety of avrs and that works with lower level tools like avrdude, avr-gcc. i tend to enjoy understanding whats happening in the background.
[00:59:19] <Roklobsta> you can use all sorts of ISP's, one I have documented is:
http://helix.air.net.au/index.php/avrdude-and-ftdi-232h/
[00:59:35] <Roklobsta> Tom_itx sells some nice ISP units
[01:01:13] <Roklobsta> the fancier ISP units will program all the varieties of AVR
[01:01:26] <Roklobsta> there are different programming modes depending on the avr you use
[01:02:25] <hugogee> will mkll program xmegas?
[01:03:15] <hugogee> Roklobsta, thank you for the links i think some of these simple questions can be answered by DDG. I will check out some of the units you mention. -cheers
[01:03:50] <hugogee> Cheers All, g'nite!
[03:55:58] <DanFrederiksen> is it true that atmega8 pwm can't handle continuously changing the period while running?
[04:04:38] <Knaldgas> I would likt to add a Devantech USB-ISS to devices for avrdude. It communicates over a virtual serial port. It needs to be initialized, and the it is essentially an SPI-pass-through (with a SPI-command prefixed). What would be the easiest way to proceed?
[04:05:42] <Knaldgas> I started with a clone of stk500, but it seems overly complicated for this task.
[04:10:11] <Knaldgas> Hmm, perhaps the avr910 is a better starting point.
[05:29:07] <Valen> So I'm having a dreadful time trying to get this PCB working
[05:29:13] <Valen> Just trying to get to the bootloader
[05:29:19] <Valen> its a 32u4
[05:29:24] <Valen> here is the schematic
http://i.imgur.com/UL1bUd6.png
[05:29:30] <Valen> http://gerblook.org/pcb/5RwvWmD9AmA5oRYKk3Cb8n is the pcb
[05:29:54] <Valen> I keep getting read error, unable to enumerate device
[05:30:17] <Valen> I have tried the same board (well another copy) with a 16u4 with the same outcome
[05:30:22] <Valen> the xtal is 16mhz
[05:35:09] <RikusW> and that is a blank chip with only FLIP on it ?
[05:35:50] <Valen> dfu i presume as its fresh from atmel?
[05:36:13] <Valen> came out of the packet and onto the board
[05:36:50] <RikusW> DFU yes
[05:39:46] <Valen> i presume that there is something wrong in the schematic level of the design for it to be affecting 2 pcbs
[05:41:15] <RikusW> what kind of caps did you use for ucap and vcc ?
[05:42:42] <RikusW> you have to use a programmer to be able to use PF4-7
[05:42:53] <RikusW> JTAGEN must be disabled...
[05:43:48] <Valen> ceramics
[05:44:03] <RikusW> afaik its recommended to be tantalum
[05:44:17] <Valen> ucap and vcc are 1uf with a pair of 480nf's as well
[05:48:43] <RikusW> do you supply both vbus and vcc at the same time ?
[05:49:08] <RikusW> I have deadbug mounted a 32u4 and it works :-P
[05:49:29] <Valen> its not meant to be a bus powered device
[05:49:41] <Valen> you have steadier hands than me lol
[05:49:51] <Valen> did you see the schematic?
[05:50:39] <Valen> for reference, the 16u4 datasheet doesn't mention the word tantalum
[05:51:13] <Valen> and the only occourences of ceramic is in the resonator context
[05:53:27] <RikusW> I think low esr was mentioned
[05:53:35] <RikusW> I did see the schematic
[05:53:53] <RikusW> are you sure d+ d- are connected right ?
[05:54:38] <Valen> yeah, well i'm pretty sure at least lol
[05:54:47] <Valen> I soldered the wires on and did continuity checks
[05:56:59] <Valen> I have made boards similar to this in the past and they worked
[05:57:56] <RikusW> why do you use the bottom copper as vcc ?
[05:58:49] <Valen> it was handy
[05:59:02] <megal0maniac_afk> That's naughty
[05:59:05] <Valen> it was origionally a single sided board, then I went and got it made
[05:59:19] <Valen> so when it went to 2 sided i just ran power on the back
[05:59:27] <Valen> any paticular reason for it being naughty?
[05:59:47] <RikusW> unusual rather
[06:00:01] <Valen> that I'm ok with ;->
[06:00:22] <RikusW> on 4 layer boards its common to use the inner planes as vcc + gnd
[06:01:05] <RikusW> the thick/thin trace joints are unusual as well
[06:01:13] <Valen> yeah kicad does that
[06:01:29] <Valen> would be nice if it tapered them or something
[06:02:02] <RikusW> split traces like a Y at the joint ?
[06:02:17] <RikusW> or like the peace symbol
[06:03:00] <RikusW> Valen: I can't see anything obviously wrong
[06:03:49] <Valen> http://imgur.com/4K6cRgk is a photo of the pcb
[06:04:03] <Valen> I was *really* hoping i had done something stupid
[06:04:26] <Valen> its ugly because its been soldered on for ages trying to get the damn thing working
[06:15:37] <Valen> heres something weird
[06:15:53] <inflex> hiya folks
[06:16:13] <Valen> when i connected vbus to the +5v rail and then connected it to the usb it gave a whole bunch of port errors on the laptop
[06:16:17] <Valen> hey inflex
[06:16:28] <Valen> then sometimes the enumeration fail
[06:16:48] <inflex> Valen: interesting PCB
[06:17:04] <Valen> so i presume it was pulling too much current or something?, but when I hooked it up to the lab supply it is still only sucking <20ma
[06:17:07] <inflex> so what's a vapourforge... /me goes to the com site
[06:17:16] <Valen> inflex: you see the whole scrollback?
[06:17:28] * inflex goes and looks
[06:19:28] <inflex> never used the U series
[06:19:34] <RikusW> Valen: deadbug
http://imagebin.org/273719
[06:20:33] <RikusW> I stripped a piece of multicore wire and tinned the strands
[06:20:38] <Valen> RikusW: nutter ;->
[06:21:07] <RikusW> it works :)
[06:21:44] <inflex> evil d34dbug
[06:24:58] <RikusW> Valen: its recommended to put a 10uH coil between vcc and avcc
[06:25:16] <RikusW> and 100nF on avcc - gnd
[06:25:35] <RikusW> it seems the usb pll uses avcc
[06:30:15] <RikusW> not sure it thats really a problem though
[06:30:44] <RikusW> I have connected a wire jumper on one pcb before I had the inductors and it worked fine for 32u2
[06:34:48] <ambro718> anyone know why atmega2560 and similar chips only go to 16MHz (atmega1284p and friends go 20MHz)?
[06:35:26] <ambro718> anyone tried overclocking one of the former class chips to 20MHz?
[06:37:41] <Kev--> Did you even try googling it?
[06:37:58] <Kev--> There's hundreds of overclocking threads on avrfreaks and numerous other websites
[06:39:05] <Fornaxian> the older chips were made for 16MHz...newer ones were made for 20MHz
[06:39:28] <Fornaxian> I've overclocked atmega32 to 20MHz with varying results...most things worked but ADC had some issues.
[06:39:43] <Fornaxian> and have overclocked atmega1284p to 25MHz with no issues so far.
[06:42:00] <ambro718> the big 2560 chips are considered old?
[06:43:56] <Fornaxian> I think so.
[06:44:03] <Fornaxian> they are of the same age as the atmega32.
[06:44:52] <Fornaxian> I only overclocked mine because I could, not that I needed extra processing power really.
[06:45:01] <Fornaxian> if I need something faster then I go with another line of chips.
[06:45:55] <ambro718> it just sucks that the atmegas don't have a PLL to fine-tune the clock
[06:46:10] <Fornaxian> some do.
[06:46:16] <ambro718> which ones?
[06:46:18] <Fornaxian> newer attinys do anyhow.
[06:46:44] <Fornaxian> if you are running from the internal RC oscillator you can fine tune that with the oscal register.
[06:47:47] <Fornaxian> maybe it's just the attinys with the pll...no atmega apparently.
[06:48:00] <ambro718> yeah the attinys dont quite fit my use case ;)
[06:48:03] <Fornaxian> why are you needing to fine tune the clock?
[06:48:21] <ambro718> it's easier to overclock it, heh
[06:48:52] <Fornaxian> just put a 20MHz crystal on it.
[06:50:43] <Fornaxian> 16 year old kid in des moines was just arrested for attempted robbery....he tried to steal drugs from a drug dealer...
[06:51:50] <RikusW> bad move...
[06:52:17] <RikusW> he's lucky to be arrested
[06:53:27] <Fornaxian> yeah.
[06:53:32] <Fornaxian> kid shot at the dealer and missed.
[06:57:48] <Fornaxian> ok...time for to go to workish place.
[07:10:45] <Vutral> hm
[07:11:13] <Vutral> someone knows if avarice supports cheaper jtags yet ?
[07:12:30] <RikusW> which cheaper ones ?
[07:17:23] <DanFrederiksen> is it true that atmega8 pwm can't handle continuously changing the period while running?
[07:18:02] <DanFrederiksen> like for spread spectrum switching
[07:39:49] <Phinxy> &wc
[07:39:52] <Phinxy> &wc
[07:53:59] <Valen> the inductor is for noise canceling for the ADC's is my understanding, i dont think you need it if you don't care about ADC noise levels
[08:03:09] <Valen> but yes you are correct, avcc is used to feed the pll
[08:05:09] <Valen> hey Tom_itx you around?
[08:05:21] <Valen> !seen Tom_itx
[08:07:57] <Tom_itx> for a bit
[08:08:12] <Valen> did you see my earlier plea for help? ;->
[08:08:21] <Tom_itx> nope
[08:09:02] <Valen> So I'm having a dreadful time trying to get this PCB working, Just trying to get to the bootloader , its a 32u4. here is the schematic
http://i.imgur.com/UL1bUd6.png
[08:09:11] <Valen> http://gerblook.org/pcb/5RwvWmD9AmA5oRYKk3Cb8n is the pcb, I keep getting read error, unable to enumerate device
[08:09:44] <Valen> I have tried the same board (well another copy) with a 16u4 with the same outcome, the xtal is 16mhz
[08:10:09] <Valen> getting the same error on 2 boards I'm guessing its a schematic problem?
[08:10:23] <Valen> I tried swapping D+ and D- but then I just get nothing
[08:11:55] <Tom_itx> did you reflow all the usb side of the chip?
[08:12:11] <Valen> yeah, and again with the iron
[08:12:12] <Tom_itx> i would get that once in a while while soldering
[08:12:34] <Valen> http://imgur.com/4K6cRgk is a photo of the pcb
[08:12:55] <Valen> there is something wrong with the 32u4 at least
[08:13:06] <Valen> if I flex the board a certain way the oscilator stops ;->
[08:13:23] <Tom_itx> do you have a spy glass?
[08:13:35] <Tom_itx> check for bridges etc
[08:13:38] <Valen> big magnifying glass
[08:13:49] <Valen> thing is i have the exact same error on 2 boards
[08:13:55] <Tom_itx> i usually can manage to clear all my errors once i do that
[08:13:56] <Valen> 3 if you include the one we milled
[08:14:03] <Tom_itx> ahh
[08:14:14] <Valen> one with the 32u4 the other a 16u4
[08:14:33] <Valen> when I got this error on the milled one I put it down to the milled PCB sucking
[08:17:38] <Valen> I didn't get my order of .1 and .01uf caps, so i used 1uf mostly for "decoupling" think that could do it?
[08:17:52] <Tom_itx> i doubt it
[08:18:08] <Valen> also heres the really weird part, I was running it off the lab supply, and it sitting at ~13ma, 20 when usb is running which is about right
[08:18:41] <Valen> i took it off the lab supply, jumpered vbus to +5v on the board and the usb port started spewing lots of "port errors"
[08:19:17] <Valen> i presume its some kind of short, do the same thing through the lab supply (IE vbus and +5v jumpered) and it still pulls 13ma
[08:19:42] <Tom_itx> there's the schematic for my 32U4 breakout
[08:19:52] <Tom_itx> if it will help
[08:20:20] <Valen> yeah, i am comparing it pin by pin now
[08:21:29] <Tom_itx> another thing, check to make sure all the pins on the plug are stuck down
[08:21:37] <Tom_itx> i've had problems there before as well
[08:21:42] <Valen> its just wires soldered to the board
[08:21:48] <Valen> tried 3 usb cables cut up
[08:21:50] <Tom_itx> appear to be but aren't
[08:22:12] <Valen> you mean in the cable or on the board?
[08:22:25] <Tom_itx> where the plug is soldered to the board
[08:22:45] <Valen> ahh, none of that pesky business
[08:22:52] <Valen> did you see the board shot?
[08:22:57] <Tom_itx> ahh wait, i don't see a plug :)
[08:23:30] <Tom_itx> i know you need short traces to the usb from the chip
[08:23:42] <Tom_itx> if they are longer you may need to change the resistors
[08:23:45] <Valen> they are about 5cm long
[08:23:56] <Valen> with the resistors in the middle
[08:23:58] <Tom_itx> somewhere there are calculations for that for the impedance
[08:24:29] <Tom_itx> they should be the same length as well
[08:24:34] <Tom_itx> as much as possible
[08:24:42] <Valen> would be within a mm or so
[08:24:51] <Tom_itx> i don't see a problem there really
[08:24:52] <Valen> http://gerblook.org/pcb/5RwvWmD9AmA5oRYKk3Cb8n is the pcb
[08:25:11] <Valen> in layout type view
[08:25:33] <Tom_itx> i probably would have left the traces small from the chip out
[08:25:44] <Valen> yeah, probably should have
[08:26:36] <Tom_itx> i'm not sure how usb would respond with those fat solder pads
[08:26:45] <Tom_itx> whether it would introduce stray noise or not
[08:27:00] <Valen> I've used similar ones in the past
[08:27:30] <Valen> if it was noise you would expect it to work sometimes, or just be flaky not just totally dead?
[08:27:43] <Tom_itx> yeah i'd think so
[08:27:50] <Valen> I could try cutting the tracks and soldering just to the resistors
[08:27:59] <Valen> but its not feeling like the issue really
[08:28:07] <Valen> total cable length is ~30cm
[08:28:11] <Tom_itx> i would check for other stuff before you start hacking up the board
[08:28:26] <Valen> I have spent like 4 hours chasing this lol
[08:28:34] <Tom_itx> sry :(
[08:28:35] <Valen> i can't think of anything else to check really
[08:28:52] <Valen> open to any suggestions at all
[08:29:15] <Tom_itx> are you getting a signal at the xtal out?
[08:29:28] <Tom_itx> make sure the chip is alive
[08:29:31] <Valen> yeah, I checked the oscilator it seems to be running
[08:29:45] <Tom_itx> did you add those ESD things?
[08:29:46] <Valen> there is a problem with one of them if i flex the board it stops
[08:29:52] <Valen> no esd stuff
[08:29:58] <Tom_itx> it should work without those though
[08:30:16] <Tom_itx> i'm gonna have to go
[08:30:17] <Valen> I compared the clock with a working one and as far as i can tell they have the same period
[08:30:19] <Tom_itx> i'll be late
[08:30:20] <Valen> thanks anyway
[08:30:30] <Valen> its well past my bed time too
[08:31:05] <Valen> i bid you well in your endeavours
[08:31:23] <Tom_itx> sleep on it, maybe it'll work then
[08:31:50] <Valen> if not burn it with fire?
[08:31:56] <Tom_itx> naw
[08:32:15] <Valen> but we just got 4x butane cylinders from a friend?
[08:55:19] <Vutral> RikusW, clones ?
[08:55:28] <Vutral> RikusW, jtagice3?
[08:55:43] <Vutral> i mean their performance still sucks ^^ for the price
[08:55:43] <Vutral> lol
[08:57:02] <RikusW> clones are usually mki
[08:58:06] <RikusW> it seems Atmel studio is in part to blame for that
[08:58:20] <RikusW> I did custom mki firmware
[08:58:29] <RikusW> its slow in the AS4 programming dialog
[08:58:40] <RikusW> but much faster in my own software
[09:01:04] <Vutral> nah
[09:01:09] <Vutral> i want debugwire
[09:01:43] <Vutral> i saw some people tried reverse engineering it and avarice should support it on dragon and on the ice mk2
[09:03:35] <RikusW> I did some stuff on dW
[09:03:50] <RikusW> its rather simple actually
[09:04:12] <RikusW> http://www.ruemohr.org/docs/debugwire.html
[09:13:09] <Vutral> mhm
[09:30:10] <amee2k> hrm
[09:31:10] <amee2k> what are easy to find connector options to carry +/- 1000Vdc? (at 500mA tops, but lots of capacitance so instantaneous currents may be higher)
[09:31:53] <amee2k> ideally 3 pins to carry a dual supply with common ground
[09:32:10] <amee2k> i can live with single pin connectors though
[09:40:02] * Casper passes on recommendations
[09:43:49] <amee2k> i've considered powerpoles but at a quick look the "normal" ones only seem to be rated for 600V
[09:44:42] <amee2k> i've also considered 4mm "safety" jacks, but brand ones that have a good chance of actually having a legit type approval are kinda pricy
[09:45:11] <amee2k> and at 1000V there is no safety margin left within the rating anymore
[09:56:16] <tzanger> 1000VDC? you need to look at connectors with wider spacing. not sure if Phoenix has stuff like that (they're not necessarily cheap either0
[09:56:29] <ajd> when I use an avr as a spi-slave, does it expect to have logic high from the CS for the idle state
[09:56:32] <ajd> or logic low
[09:57:46] <amee2k> tzanger: i'm mainly concerned with ones that i can actually buy reasonably easy. *finding* connectors that go up to like 50kV isn't that difficult but noone wants to sell them
[09:57:56] <tzanger> right
[09:58:29] <tzanger> LCD displays that used CCFL backlights had small connectors, were they up near 1000VDC? maybe only a few hundred volts AC
[09:58:39] <amee2k> http://www.elmeso.de/index.php?page=1_0&ugId=32&lang=en
[09:59:57] <amee2k> i know these CCFL connectors, but they're internal connectors though. i wouldn't want to touch these while they're powered by a 1kV supply with a huge output filter capacitor
[10:05:07] <tzanger> oh I see you want somethign user-connectable at 1000VDC?
[10:06:43] <megal0maniac_afk> Use contactors?
[10:07:03] <tzanger> I'm sure regular old fastons would be fine, especially the insulated ones
[10:07:26] <tzanger> they're cheap, and they do come in shrouded varieties which should help prevent people from touching them
[10:07:57] <amee2k> it shouldn't be handled while powered up, but it should be safe to touch while the connector is inserted and have at least rudimentary protection in case it accidentially gets disconnected or there is residual charge in some filter capacitor
[10:10:37] <amee2k> parametric search is driving me crazy because it shows 5kV rated connectors and when i look at the datasheet it says "maximum hands-free voltage in controlled environment: 1000Vdc"
[10:22:17] <amee2k> tzanger: by faston, do you mean the shitty crimp ones that are used in cars everywhere?!
[10:23:07] <tzanger> yep
[10:23:22] <tzanger> nothing wrong with crimps either, only bad crimpers. :-)
[10:23:32] <amee2k> i know, thats not the problem
[10:23:46] <amee2k> but they have essentially no effective insulation
[10:23:46] <tzanger> in fact crimping is preferred to soldering in high reliability scenarios, which is something that surprised me
[10:23:57] <tzanger> amee2k: well there are insulated varieties
[10:23:59] <amee2k> at least none that i'd trust for more than the equivalent creepage distance
[10:24:11] <tzanger> and there are also shrouded ones for the boards themselves
[10:24:21] <tzanger> it's all a matter of what you want to work with and how much youw ant to spend
[10:24:30] <tzanger> I don't know what their ratings are though, you'd have to check it out
[10:24:53] <theBear> in some situations, like where vibration is present
[10:24:53] <tzanger> most wire insulation is rated 300VDC, so you're already looking at fancy wire to get 1000VDC
[10:27:04] <amee2k> i think i'll go for the shrouded 4mm lab connectors first
[10:29:17] <ajd> does atmega168a support i2c standard?
[10:29:48] <amee2k> yes but it is called TWI so they don't have to pay for the name
[10:31:01] <ajd> amee2k, thank you, I was not able to understand the difference :)
[10:32:11] <amee2k> it is the same principle, just check that you set it for a clock rate that is compatible with whatever devices you're communicating with
[10:32:50] <amee2k> you can set more or less arbitrary clock speeds with the atmega that are outside the official i2c specs
[10:32:58] <amee2k> doubly insulated high voltage cable up to like 10kV is relatively easy to find, although kinda expensive. what is driving me crazy is the connectors >_<
[10:33:16] <amee2k> http://www.pollin.de/shop/dt/MjExODM0OTk-/Haustechnik/Kabel_Draehte_Litzen/Kabel_Leitungen/Hochspannungskabel_20_kV_10_m.html
[10:38:24] <tzanger> I2C and TWI are synonymous. SMBus is a superset of I2C and there's another name they use for I2C like TWI... basically if it's a bidirectional data line, a clock line and open-collector I/O it's almost guaranteed to be I2C compatible
[10:46:05] <amee2k> yeah but if they used "i2c" in the documentation and marketing materials then iirc philips would want money from them :>
[12:44:15] <megal0maniac_afk> tzanger: How close is PS/2 to TWI/I2C?
[12:44:46] <megal0maniac_afk> I'm guessing it's single directional, so doesn't need open collector I/O
[12:45:18] <N1njaway> mega: PS/2 connections are bi-directional. Gotta be able to toggle your keyboard lights :)
[12:46:24] <N1njaway> There are some excellent resources on the web explaining PS/2 connections. What is your application?
[12:46:58] <N1njaway> These days it may be just as easy to simply use USB for connecting a mouse or keyboard to an Atmel
[12:50:31] <TechIsCool> SDA on twi should always be a signal correct it should not pause?
[12:57:04] <megal0maniac_afk> N1njaway: Actually I'm studying integration. I'm here reading the scrollback and procrastinating :)
[12:57:17] <megal0maniac_afk> So no application
[13:02:14] <floev22> hello
[13:02:47] <floev22> can somone help me with something?
[13:03:06] <bss36504> That's pretty vague. What's up?
[13:04:43] <floev22> bss36504 i'm struggling trying to communicate two attiny's. i simply cant get it working
[13:04:56] <bss36504> What communication protocol?
[13:05:00] <floev22> do you know somewhere to find a kind of hello world of attiny communication?
[13:05:22] <floev22> well, the standard is defined by the software, isnt it?
[13:05:43] <floev22> i mean, the protocol
[13:06:45] <bss36504> Which ATTiny? I'm not super familiar with their capabilities so i want to check a datasheet. But it really depends on what communication protocol you use. SPI is a master slave synchronous transfer, I2C is a bidirectional address type network, the list goes on.
[13:08:25] <floev22> what is the simpler? i actually achieved to write a byte to a shift register, just clock and byte lines.. i wanted to recieve a byte just as if it was read from a shift register
[13:08:44] <floev22> is attiny85, but all the tiny's are similar, in fact, the same datasheet.
[13:09:08] <floev22> i think it has a kind of integrated shift register, could it be?
[13:09:09] <bss36504> Ok, well SPI is basically that but done in the chip hardware. Lemme look at the datasheet real quck...
[13:09:21] <floev22> men, thanks
[13:09:27] <megal0maniac_afk> bss36504: The t85 only has USI
[13:09:37] <megal0maniac_afk> No hardware USART or SPI or TWI
[13:09:48] <N1njaway> bss: Probably need one of the upper-end TINY's - most don't have any comm hardware and you'd have to bitbang :)
[13:09:51] <bss36504> megal0maniac_afk: oh ok, I never use them.
[13:10:14] <bss36504> Yeah in that case i'd look at making or using an SPI bitbang library.
[13:10:19] <theBear> the tinies that used to be 90s series all got hw, not really sure why they changed them to tiny
[13:10:19] <bss36504> shouldnt be too difficult
[13:10:27] <floev22> aah, i see. i was kind of lost with the communiction protocols then
[13:10:29] <theBear> 2313 in both old and new series is a personal favourite
[13:10:44] <floev22> and atmega?
[13:10:52] <megal0maniac_afk> Use USI though. It isn't SPI, but it's half the work done for you and takes a load off the CPU
[13:11:27] <N1njaway> I'd vote for async if you just need very simple communications, since it can be done with a single wire for each direction.
[13:11:40] <theBear> mega are bigger, and were always called mega, tho as i recall the old series still had numbers like 90s8515 aka mega something
[13:12:02] <bss36504> yeah, i guess if they have some sort of internal comm unit and you're trying to link two similar parts, you may as well use what they have
[13:12:54] <floev22> yes. but i just couldnt get to make those hardware features working...
[13:13:28] <floev22> as i understand, usi is also clock and communications cable, isnt it?
[13:14:51] <floev22> i thought that with attiny's usi i'd be able to communicate as if it was a shift register.
[13:15:24] <floev22> isn't somewhere a dummie's intro to that attiny communication?
[13:15:45] <bss36504> I'd worry less about how it works at this stage and focus more on what the datasheet says about how to connect them and configure them.
[13:16:05] <N1njaway> It would also help to know what the application is, because if the ATTINYs are right next to each other on a board, why not just use a larger device? If they need to be seperated by a fair distance, then signals integrity and interconnect become a bigger problem that needs to be tackled first.
[13:16:38] <bss36504> option 3, this is just a learning exercise :)
[13:18:04] <floev22> yes, i wanted to make an array of intelligent objects that communicate, but they can be not there, so there should not be ACK's in the protocol
[13:18:13] <floev22> a kind of midi
[13:18:16] <N1njaway> bss: True. But it would still be useful to know the intent so that someone can garner maximum learning potential from people's suggestions :)
[13:19:22] <vsync_> googloids...
[13:19:31] <bss36504> N1njaway: Oh yeah, I totally agree with that part, application is always helpful. floev22: Step 1) make the interface work at all, Step 2) Now figure out the software protocol you want to use
[13:19:43] <N1njaway> floev22: If it's multiple objects, what is your plan to individualize each such that communication can be targeted to a specific object? Assuming there are more than two, each needs either a unique address, or each needs a fixed place in the comm topology that makes it identifiable spatially.
[13:20:40] <floev22> yes... once i cu
[13:20:46] <floev22> sorry...
[13:21:04] <N1njaway> floev22: The answer to that questions helps to narrow in which protocol/hardware comm you would want to consider selecting for the application
[13:21:05] <floev22> once i could get two things to communicate i then would add the id's things
[13:21:48] <N1njaway> Yes, but are they connected linearly? Are they connected star-topology, etc? All of that is important to consider which communication method to use.
[13:22:15] <floev22> the wiring would be same as the i2c's
[13:22:41] <bss36504> Personally, I would go with an addressing scheme, since it would be more adaptable later on, and you can just add more devices. you will have to find a way to avoid bus contention though whether that is by hardcoding all allowable device ids into the master, or trying to implement a complex multi master system where any node can take control of the bus.
[13:23:08] <N1njaway> SPI does linear great, and can kind of do star-topology, but it won't work well over distance and needs home-run lines. I2C can kind of be starred but does not need home-run lines. Async lets you do stars over distance with two wires and bidirectional, etc
[13:23:08] <bss36504> also, it wouldnt really be the same as I2C.
[13:23:54] <N1njaway> bss: You also have issues of enumeration unless you specifically assign a unique id to each device. If they are meant to be added "on the fly" that might not be trivial.
[13:24:25] <floev22> i thought a dynamic adress: each new object that enters the bus, asks for a id to the master
[13:24:40] <floev22> so the master then knows who are connected
[13:24:42] <bss36504> N1njaway: Yeah thats the point I was driving at towards the end, a hot-swap or on the fly system would be pretty tough software wise
[13:25:09] <floev22> yeah, is kind similar to i2c but i dont want ack's. they make programs get stuck
[13:26:30] <floev22> i usally am problem-less with software, but i always get stuck accessing these very precise things such as hardware usi
[13:26:56] <bss36504> So floev22, if you want to be able to add devices, that rules out spi since that would have to expect a certain number of bytes to shift to get through the chain. Now you have to do some sort of star topology with addresses. concerning the USI, I think probably async serial would be the best, then you dont have to worry about a single master clocking the whole network. However, like N1njaway and I mentioned, it is non-trivial to
[13:26:56] <bss36504> implement a multi-master sort of system.
[13:26:57] <N1njaway> floev22: I2C will probably do what you want if I understand your broad-stroke intention. You'll probably want to look in to some of the established I2C methods for doing broadcast messages, etc. You'll also need to store the addresses non-volatile, as any loss of power will result in everything coming back up on the bus at once and all requesting a new ID at once. Unless you have hard-burned unique
[13:26:57] <N1njaway> serials in each device and a binary search mechanism in place, there is no hope of reenumerating.
[13:28:36] <bss36504> You could have a reserved address, say 0, for a "fresh" device, that then gets assigned a new address by the master and saved in non-volatile memory. But like N1njaway said just now, you cant have them all try and enumerate at once.
[13:28:50] <N1njaway> bss: For async like that, the best established standard would probably be RS485 as you only need the transciever chip added to the Atmel to make it work (like a 75176 or LT1785) and then you get relatively high-speed bidirectional over twisted pair that can go hundreds of meters without a problem. You can easily do multi-master with that, and it's pretty easy to be able to do new device discovery
[13:28:50] <N1njaway> and enumeration.
[13:29:25] <bss36504> Thats a good idea
[13:29:52] <floev22> -rs485... i have never heard of that. i'll lookup
[13:30:16] <floev22> anyway, does anyone know a online tutorial for that?
[13:30:22] <N1njaway> RS485 "best practice" does need at least one node that properly biases the lines in to the marking state, however, when no one has control of the bus :)
[13:30:45] <N1njaway> floev22:
http://en.wikipedia.org/wiki/Rs485
[13:31:12] <floev22> Excellent! thank you guys very much.
[13:31:48] <N1njaway> floev22: RS485 is the physical signaling medium for the communications wires for sending async data. (Layer 1) Everything else higher up with regard to the protocol and implementation (Layer 2+) is something you would have to define.
[13:32:23] <N1njaway> floev22: You may also want to look in to CAN bus, as it will do some of the same kinds of things, and is supported natively on a number of the larger Atmels.
[13:32:40] <N1njaway> floev22:
http://en.wikipedia.org/wiki/CAN_bus
[13:33:23] <N1njaway> floev22: You might actually want to look at CAN first, as it defines both the electrical (Layer 1) and the protocol (Layer 2) implementations. It's also multi-master capable.
[13:35:08] <N1njaway> Whichever way you go, realize that what you are talking about implementing is a bit on the complex side. So either set it as your goal and be prepaired to fill in a lot of the gaps as you go and learn a bunch of stuff (which can be fun) or start with something really, really simple like doing simple async message passing from one micro to another by tying their TX/RX pins directly together with
[13:35:09] <N1njaway> two wires so you can get your feet wet. Get the fundamentals down first, else the fancy stuff will never work :)
[13:48:58] <jaldunate> I'm the same who was lost about communications between avr's... i was using irc in a friend's computer.
[13:49:16] <jaldunate> So, attiny is unable to recieve asynchronously
[13:51:38] <jaldunate> it isnt displayed in its datasheet at least...
[13:52:37] <theBear> yeah it is
[13:52:52] <theBear> and not just by not having a clock line attached to the serial section
[13:53:39] <jaldunate> ok. i'll see deeper and keep the fight. thanks again
[13:53:59] <N1njaway> jal: You can technically do bit-bang async with them, but you'll be severely limited by speed. Just jump up to a slightly heavier-weight part with a UART/USART if you want to do async seamlessly :)
[13:55:11] <theBear> tiny2313 has usart
[13:55:21] <N1njaway> jal: You'll also need an external crystal/resonator if you intend to do any significant speed for async
[13:55:59] <N1njaway> Yeah, I was going to suggest the 2313. I forgot they moved it in to the TINY series in recent years. That's the first part I started with about 12 years ago now :)
[13:56:32] <N1njaway> I think I have a few around here that are still marked AT90S2313 :)
[13:56:52] <theBear> i got a tube of 'em :)
[13:59:30] <jaldunate> i kind of like to see a lot of them in buch
[14:04:05] <bss36504> Alright I've got an odd problem. Using an Atmega32U2, the supply voltage is nominally 3.3V using a regulator from 5v (VUSB) to 3.3. I noticed that the 3.3v supply starts at 3.3, then creeps up around 4.5v then drops back down to 3.3-3.5 range over and over. Its as if VUSB is leaking into VCC, something I thought couldn't happen. Any thoughts? I've now removed the regulator and I'm supplying 3.3 via power supply and VUSB comes via
[14:04:05] <bss36504> USB cable.
[14:04:37] <theBear> protection diodes
[14:05:17] <jaldunate> at what kind of speed? visible on tester or on oscilloscope?
[14:07:51] <N1njaway> bss: Would have to see your schematic. Are you sure the VREG bits are set correctly in the Atmel? Also you can always use an external regulator if desired.
[14:09:07] <bss36504> No, I'm using an external regulator already. Are you saying that the chip can be powered via USB? I did not realize that....
[14:09:40] <N1njaway> bss: Yes, the chip and/or device can be powered by USB depending on current draw requirements.
[14:10:08] <bss36504> Blowing my mind right now N1njaway. This will be a real RTFM/Doh! moment if it's the problem.
[14:10:08] <jaldunate> Usb has quite a good current capability AFAIK
[14:10:12] <N1njaway> I also did a data-logger for a customer that is powered by a 3V lithium when the USB is disconnected, or the USB port when connected.
[14:10:26] <bss36504> 300ma, I use the usb to supply the regulator to supply the vcc on the MCU
[14:11:06] <theBear> usb pre v3 after negotiation can do 500mA per port
[14:11:27] <theBear> in reality it will do that without negotiation
[14:11:35] <bss36504> theBear: yes, but this device doesn't even come close to that, so either way, we're good.
[14:11:46] <N1njaway> jal: USB limit is 500mA on a standard port, but that's really sketchy from device to device, and also depends on how much load the hub has. I've seen the actual amount sourcable all over the map. Our nice little USB-LED device will draw just under 500mA when all LEDs are set to white, but there are a lot of hubs that will have issues and we had to dial it back in firmware a bit.
[14:11:53] <theBear> just had to mention :)
[14:12:18] <bss36504> N1njaway: Can you point me to what part of the datsheet discusses this? I just skimmed the power management section to no avail.
[14:12:38] <bss36504> Also, this is off a powered hub, so current is pretty irrelavent.
[14:12:38] <N1njaway> theBear: Yes, but a 10-port USB hub will generally not have a 5V @ 5A power supply, so unloaded yes, 500mA should be sourcible. But not for 10 x 500ma devices connected at once.
[14:13:27] <jadew> I think some MBs can negotiate up to several amps
[14:13:48] <N1njaway> bss: Section 20 under USB Controller
[14:14:15] <N1njaway> Page 185+ on this version of the datasheet
[14:14:17] <jadew> I remember reading that in my MBs manual, that I can enable something to allow tablets and other devices to get charged from the PC
[14:14:31] <theBear> jadew, not usb, tho many will supply that much
[14:14:40] <theBear> and by usb i mean within standard
[14:14:51] <N1njaway> jade: Yes, but that's a different part of the USB spec for chargers. Pull the docs from USB SIG (free) if you want details.
[14:15:13] <theBear> N1njaway, that's why there is negotiation
[14:15:48] <bss36504> N1njaway: Thanks. It appears I did not follow the app suggestions for a self powered device with I/O voltage of 3-3.6V.
[14:15:55] <theBear> N1njaway, and if the standard is truly followed, if somethign pulls 500ma without negotiating it first, it should be 'cut off' somehow
[14:16:02] * bss36504 Returns to soldering
[14:16:40] <jadew> woot, I just compiled boost in the complete build type config in under 20 minutes :D
[14:17:05] <N1njaway> theBear: There is a difference between negotiation of current draw when a device actually enumerates to the USB host, and a charger that has no electronics smarts and only tells the end device how much current can be drawn based on the resistors values that are set.
[14:17:53] <theBear> a charger isn't a usb port
[14:18:13] <theBear> and those resistor values are proprietry and device specific
[14:19:03] <theBear> tho you will find a lot of devices pull a lot more than 500mA if they don't see communication thru the datalines
[14:19:25] <theBear> regardless of voltage or pullup/down/inbetween resistors on those lines
[14:20:00] <theBear> then you see things like this here razr that changes what it does depending on what is connected to the 5th 'nothing' pin in a mini-usb or micro-usb port
[14:21:25] <N1njaway> There are a lot of devices which are also not USB compliant. :)
[14:21:51] <theBear> i didn't say there aren't, i just said what the rules say
[14:22:25] <vsync_> Should make mobos dishing out amps out of usb
[14:22:33] <vsync_> 500 mA lipo chargers, my ass
[14:22:44] <bss36504> Sorry to spark a debate, but thanks a million for the tip. I feel like a dummy for not reading that section thoroughly. And vsync_: YES.
[14:23:10] <vsync_> though, i charge my lipos with a proper charger, that does balancing and goes up to 10 amps
[14:23:14] <theBear> i dunno about everyone else, but i enjoy a good debate... but to be fair this was more listings of facts and figures
[14:23:31] <vsync_> but i have large lipos, so xP
[14:24:25] <N1njaway> theBear: Also, the USB Power Delivery Specification calls all of this out in excruciating detail, regarding how devices should correctly go about requesting current supply capacity beyond that which a normal USB port will supply. You can find all of this in
http://www.usb.org/developers/docs/
[14:24:50] <theBear> even pre usb3 ? wow, i'm behind
[14:25:05] <N1njaway> bss: Awesome, glad to help.
[14:25:13] <N1njaway> theBear: Yes, USB 2.0 had this in the standard.
[14:25:31] <vsync_> N1njaway: how far beyond
[14:25:45] <theBear> maybe i haven't read since 1.1 <grin> everything seems to take so long these days
[14:26:26] <N1njaway> Initial release of the USBPDS was July 5th, 2012 according to the current version of the document.
[14:26:34] <bss36504> N1njaway: Should I worry about anything being damaged? The MCU still programs ok, but this unaltered LUFA demo I'm using doesn't work yet.
[14:27:07] <theBear> 2012 ? pfft ! i'm at least 5 years behind
[14:27:40] <N1njaway> bss: I would surmize you haven't damaged anything. But make sure you have the proper clock crystal attached - there is a divider bit that needs to be changed if you are running 8 vs 16 clock. Also make sure you have a 1uf on UCAP
[14:28:37] <bss36504> I'm running the 8MHz internal RC. gotta double check that I configured F_CPU right, I just wanted to check. these little atmegas are pretty durable.
[14:28:43] <N1njaway> bss: There's a few other... oddities... I've found with the 32U2 and 32U4 that required a bit of experimenting with, as the datasheet was slightly vague in a few places. If you're still stuck later I can pull up some older schematics from some working and deployed designs to take a look at.
[14:30:06] <N1njaway> bss: I'm not 100% sure the internal 8Mhz RC will work for USB, at least reliably. I always just stick on an external 8Mhz resonator or quartz.
[14:30:30] <N1njaway> bss: Even the 32U2 and 32U4 that ship with Atmel's DFU bootloader expect an external clock crystal.
[14:31:03] <bss36504> alright cool. I'm actually using the 32U2 in my senior project design as well so I may call upon that. I am a little concerned the internal RC wont be accurate enough, but there isn't a spot on the layout. Future designs will have one for sure.
[14:31:27] <bss36504> But, at least power is stabilized now.
[14:31:49] <bss36504> If I need a crystal, I might just get creative with some soldering.
[14:32:17] <N1njaway> Dean helped clarify this -- even though the chip ships blank set to 8mhz internal RC as most are, the DFU bootloader reprograms the fuses to use an external. We had someone in here the other week tearing their hair out as to why they couldn't program it via SPI until I suggested applying external clock to see if that resurrected it. Then Dean clarified the whole datasheet/bootloader discontinuity
[14:32:17] <N1njaway> about the DFU reprogramming the fuses :)
[14:32:17] <bss36504> Yeah, that was me
[14:32:25] <bss36504> lol
[14:32:27] <N1njaway> Oh okay, couldn't remember :)
[14:32:37] <N1njaway> The names... they all get jumbled in my brain box.
[14:32:56] <bss36504> damn brain boxes...
[14:33:38] <N1njaway> bss: Worst-cast get something like a CSTCE (punch in Digikey) which is an external resonator with the caps internal, so you just connect to XTAL1, XTAL2, GND
[14:33:48] <N1njaway> Oh crap I'm late - bbl!
[14:34:11] <bss36504> Awesome, thanks for the help. Sorry you're late!
[15:33:48] <faf> I am looking for the i2c documentation on
https://sites.google.com/site/qeewiki/books/avr-guide ,is there anyone who involve preparing document on that page?
[15:34:11] <faf> maybe that person can tell me if I can get that document through another link
[15:40:58] <faf> or can anyone suggest a very simple working TWI code?
[15:55:43] <tzanger> megal0maniac_afk: PS/2 is nothing like I2C
[17:02:10] <TechIsCool> so I can't get AtmelStudio to generate a eep file correctly. What am I doing wrong? static uint8_t DEVICE_ADDRESS_ee EEMEM = 25 ; but nothing changes in the eep file
[17:06:47] <RikusW> try adding section attributes
[17:07:02] <RikusW> its somewhere in the avr-libc docs
[17:08:01] <TechIsCool> I was not calling a read on the eeprom and it was automatically removing. oh well found it
[20:21:26] <Felix29> Hi, does anybody know of a V-USB example for a SNES controller?
[20:26:23] <Amadiro> Felix29, do you want to translate the SNES protocol to USB?
[20:26:34] <Felix29> yes
[20:26:51] <Felix29> i know it's been done
[20:27:00] <Felix29> but i can't find that project anymore
[20:27:00] <Amadiro> Ah, cool. I haven't used v-usb myself, since the 32u4 is pretty affordable.
[20:27:12] <Amadiro> (or smaller models like the 8u4 (or 8u2?)
[20:27:33] <bss36504> I'd use an actual USB part with LUFA
[20:27:33] <Felix29> yeah, but I haven't used those
[20:27:44] <Felix29> have you used them at 5V by any chance?
[20:27:46] <bss36504> They're literally the same as any other mega plus USB
[20:28:31] <Amadiro> Felix29, yep
[20:28:40] <bss36504> Check out the datasheet, they can clock up to 16 MHz at 5v
[20:28:52] <bss36504> should be pretty trivial to get something working.
[20:29:00] <Valen> I am having great difficulties getting my 32u4 working :-<
[20:29:02] <Valen> nfi why
[20:29:15] <Valen> all the other boards i have made work fine, this one is refusing to enumerate
[20:29:43] <bss36504> Valen: really. How is it clocked?
[20:29:51] <Valen> 16mhz xtal
[20:30:02] <bss36504> when you say "all the otehr boards, do they use 32u4s as well?
[20:30:05] <Felix29> so which one are you guys using? Is there any projects you put online?
[20:30:09] <Valen> or 16u4
[20:30:40] <Valen> here is the schematic
http://i.imgur.com/UL1bUd6.png http://gerblook.org/pcb/5RwvWmD9AmA5oRYKk3Cb8n is the pcb
http://imgur.com/4K6cRgk is a photo of the pcb
[20:30:49] <Amadiro> Felix29, I'm using the 32u4, but you can probably get away with something smaller like the 8u2 or so
[20:30:56] <bss36504> Felix29: you could use any of the At90USB chips or a U2/U4
[20:31:02] <Valen> any help would be super apreciated, I've been banging my head against the wall for hours now
[20:31:50] <bss36504> Valen: Does it program?
[20:31:58] <Valen> nope
[20:32:08] <Valen> wont even enumerate on the bus in order to program
[20:33:01] <bss36504> Oh wait, do you have an actual programmer? Some of the U2/U4 chips have different bootloaders or no bootloaders, apparently you can tell by the suffix. I dont know which ones are which, but I know they exist
[20:33:20] <Felix29> yeah, I am trying to figure out if I wanna keep going with AVR or switch to PIC since there's DIP ICs that can do USB
[20:33:42] <Valen> I do, but I also used a 16u4 I got from another packet with the same problem
[20:33:45] <Valen> its trying to work
[20:34:08] <bss36504> Felix29: I personally dont like PIC. I think they have a number of drawbacks in architecture and how the IDE works, but it's really personal preference. Thats mine though :)
[20:34:08] <Valen> i get read errors then device failed to accept address errors
[20:34:19] <Valen> like when you cross d+ and d- lines
[20:34:28] <bss36504> Valen: Do you have an actual programmer?
[20:34:48] <Valen> i have a dragon
[20:35:02] <Valen> lol, that is an awesome line
[20:35:03] <bss36504> have you attempted programming with the dragon?
[20:35:06] <Felix29> bss36504: I've heard that before. So far, I am getting along with the IDE though. Having DIP is the only major advantage as far as I can tell
[20:35:06] <bsdfox> Valen, don't you need a pullup on D- or D+ ?
[20:35:08] <Valen> Valen: i have a dragon
[20:35:14] <bsdfox> depending on the usb speed you want to use
[20:35:16] <bss36504> bsdfox: nooooooo!
[20:35:28] <bss36504> 22Ω in series is it
[20:35:28] <Valen> no, that'd kill stuff as far as i know
[20:35:45] <bss36504> it's differential, so no. both lines need full swing
[20:35:59] <Valen> I didn't want to use the programmer, it'll be a pain to get wired up and probably wouldn't solve the problem
[20:36:35] <Valen> I have made 2 PCBs one with a 32u4, one with a 16u4 (the same artwork for the PCB) with the 16u4 out of a packet that should be working
[20:36:49] <Valen> and i can see it wiggling the d+ line at least when i hit reset
[20:37:03] <Valen> current draw goes up to 20ma for a second or two, then drops back to 13ma
[20:37:10] <bss36504> well side note then, I'd suggest getting a JTAGICE3 sometime. $99, which isn't too bad, and it supports every part they make
[20:37:14] <Amadiro> Felix29, bss36504 no need to use the IDE, btw, you can just use your favourite text editor/IDE and compile with gcc
[20:37:26] <bsdfox> Valen,
http://www.beyondlogic.org/usbnutshell/usb2.shtml not sure if the avr usb peripheral might enable internal pullups automatically but one of the lines does need to be pulled high for speed id
[20:37:32] <bss36504> Amadiro: I like IDEs though. I'm lame like that.
[20:38:07] <N1njaway> IDEs make workflow considerably faster for projects of any significant size.
[20:38:11] <Amadiro> bss36504, but you can use one that is better.
[20:38:15] <Valen> well all the other ones i've made work without one ;->
[20:38:24] <Valen> and the atmel datasheet doesn't talk about it
[20:38:25] <Felix29> Amadiro: To me it's most important to have a nice community and exchange of code
[20:38:49] <Amadiro> Felix29, yeah, AVR is pretty good on that, but so is ARM. PIC probably comes in third or so
[20:38:56] <bsdfox> Valen, do you get any activity when you plug it in? (oscope/wireshark)
[20:39:11] <Valen> I haven't wiresharked it thats a good idea
[20:39:23] <Valen> I get a bunch of errors in syslog about it failing to enumerate
[20:39:24] <N1njaway> Valen: Is this a from-scratch board?
[20:39:27] <Valen> yes
[20:39:39] <N1njaway> Valen: Does it have a clock crystal or resonator on the Atmel?
[20:39:48] <bsdfox> Valen, yeah wireshark will help. if you're getting failed to enumerate errors the pullup isn't your problem
[20:40:01] <Valen> 16mhz xtal that is running as close as i can work out right
[20:40:18] <N1njaway> Do you have an 8Mhz around?
[20:40:22] <Valen> IE measuring 11 wave forms on my scope i cant see an error, though I doubt i'd notice it
[20:40:33] <Valen> i dont *think* so, i might be able to get one
[20:40:40] <bsdfox> 11 wave forms? lol
[20:40:44] <Valen> the last boards i did with 16mhz worked (different design)
[20:40:51] <Valen> wave lengths perhaps?
[20:40:56] <N1njaway> The built-in DFU bootloader expects an 8Mhz clock to be present on start. If you use 16Mhz there's a different divider that needs to be set in the USB setup refisters.
[20:41:00] <bss36504> N1njaway: Good call. The default setup is usually for 8Mhz.
[20:41:06] <bsdfox> Valen, doubt that's what you mean either
[20:41:20] <N1njaway> So the chip is probably running twice as fast as it should, which means the UBS PLL is not running at the correct rate.
[20:41:38] <bss36504> 96MHz, oh yeah, that baby is screamin'
[20:41:40] <Valen> well i was measuring the peak to peak times on a sinewave, how should i express that as a period?
[20:41:55] <Valen> I believe that the pll automatically works out what is going on
[20:42:00] <bsdfox> Valen, if you're getting a sine wave out of your usb peripheral something is wrong :)
[20:42:06] <N1njaway> Normally you could just upload a version of the bootloader via SPI that has the code compiled for 16 Mhz, but you need a SPI programmer for that.
[20:42:22] <Valen> I was measuring the *clock* as in the output from the xtal
[20:42:24] <Roklobsta> Valen: or he could have a lo-fi CRO
[20:42:37] <Valen> its a tek700mhz scope
[20:42:52] <bsdfox> Valen, you can't measure the output on a crystal.. it'll fuck up the oscillation. it needs to go through a buffer of some sort first
[20:42:52] <bss36504> Valen: The PLL only multiplies it's input by 6. This is explicitly stated in the datasheet.
[20:43:14] <bss36504> If you can use your programmer to set the CKOUT fuse, you'd be better off.
[20:43:25] <bss36504> or use an 8MHz crystal
[20:43:25] <Valen> bsdfox: in 10x mode it doesn't seem to bother the xtal that much
[20:43:41] <bss36504> *that much*
[20:44:03] <bsdfox> Valen, it's likely to be a source of problems though. don't measure that way
[20:44:04] <Valen> www.atmel.com/Images/doc7618.pdf
[20:44:15] <N1njaway> Valen: The PINDIV bit in PLLCSR needs to be set to 0 for 8 Mhz clock, 1 for 16 Mhz clock
[20:44:16] <Valen> USB DFU Bootloader Datasheet
[20:44:23] <Valen> Autobaud (8/16 MHz crystal)
[20:44:39] <Valen> and the other working boards i have made would tend to agree with it
[20:45:27] <N1njaway> Are you powering from the bus, or externally?
[20:45:32] <Valen> external power
[20:45:42] <Valen> heres a weird thing though
[20:45:50] <N1njaway> 1uf on UCAP?
[20:45:53] <bsdfox> see what wireshark thinks
[20:46:07] <N1njaway> 22 ohm's in series on D+ and D-?
[20:46:09] <Valen> N1njaway: yes, you can see the schematic
[20:46:10] <bsdfox> that should be your first step.. you'll see if data is transmitting at all
[20:46:14] <Valen> and the photos
[20:46:25] <N1njaway> Where's the link? I missed it.
[20:46:36] <Valen> (12:15:22) Valen: here is the schematic
http://i.imgur.com/UL1bUd6.png http://gerblook.org/pcb/5RwvWmD9AmA5oRYKk3Cb8n is the pcb
http://imgur.com/4K6cRgk is a photo of the pcb
[20:48:20] <N1njaway> Try attaching a 10K on VBUS to GND
[20:48:33] <Valen> ok thats a new one
[20:48:42] <Valen> what's that for?
[20:49:47] <bss36504> Valen: I see the datasheet for the DFU says "autobaud". can someone explain how that is even possible?
[20:50:01] <N1njaway> I have done a number of designs for the 32U2 and 32U4, some bus-powered and some self-powered. On one particular one (that was battery-powered when unplugged from USB, powered from USB when plugged in) there was difficulty detecting when the device was plugged in or not. I believe it was the 10K bias on +VBUS that fixed that problem.
[20:50:25] <Valen> you could look at the wdt timer and see how it compares to your internal clock
[20:50:37] <Valen> be close enough to work out if you are at 8 or 16mhz
[20:50:43] <bss36504> How, the watchdog is tied to the same clock, is it not?
[20:50:47] <N1njaway> Looking at that schematic now, it's been about 2-3 years, but I remember having a similar problem to what you descrive.
[20:51:13] <N1njaway> bss: WDT is a seperate internal clock.
[20:51:19] <Valen> wdt uses its own RC osc, so it can work if the main osc dies
[20:51:30] <Valen> ~32khz as i recall
[20:51:34] <bss36504> These must be the "odd issues" the U2/U4 have, N1njaway. and oh, the more you know.
[20:51:53] <bss36504> I hardly ever use the WDT.
[20:51:56] <N1njaway> Valen: The 10K is worth trying. Else I would suggest the change to an 8Mhz to see if it's any better.
[20:52:08] <Valen> (you cant use wdt clock to run the IC, but you get the idea)
[20:52:37] <Valen> I'll grab an 8mhz and give it a try, i was thinking similar things but "it worked last time"
[20:52:46] <bss36504> gremlins...
[20:53:47] <N1njaway> Valen: Were you using the same scheme with VBUS?
[20:54:04] <N1njaway> Also is your HWB switch in the correct position?
[20:54:33] <N1njaway> Everything else looks correct from what I can see.
[20:55:18] <Valen> http://i.imgur.com/wSx65Yq.png is most of the old schematic
[20:55:19] <N1njaway> Unless you somehow ordered one of the U4's without the DFU on it :)
[20:55:37] <Valen> if it didn't have DFU wouldn't the d+- lines just be inputs/
[20:55:39] <Valen> ?
[20:56:08] <N1njaway> Should just be tri-stated, yes.
[20:56:30] <Valen> because scoping d+ i see wobbly lines when i hit reset
[20:56:43] <bss36504> wobbly at what level?
[20:56:49] <Valen> USB levels
[20:57:01] <N1njaway> Wobbly seems to imply potentially tri-stated :)
[20:57:01] <bss36504> I mean, I guess if it was tri-stated, it wouldnt wobble at all...
[20:57:05] <Valen> no clock though like i see on a working one
[20:57:19] <Valen> its digital, looks like its trying to do something
[20:57:26] <Valen> but a scope isn't the right tool really
[20:57:50] <Valen> d- isn't mirroring it, but then it doesn't on a working one either until it looks like its setup and there is a clock
[20:59:16] <N1njaway> I really prefer having a SPI/JTAG programmer on-hand as it makes it waaaay easier to debug this kind of stuff. :)
[20:59:18] <Valen> well i say "clock" it could be anything, but it looks like a clock ;->
[20:59:31] <Valen> I do have a dragon, but I'm not sure how it'd help really
[20:59:38] <bss36504> The more i do with USB, the less I like it.
[20:59:52] <bss36504> It's a bit of a pain
[21:00:03] <Valen> Presuming I can get it flashing a LED, where to from there?
[21:00:20] <N1njaway> bss: USB has worked flawlessly for me here. I think it may just be a bit of cutting the teeth at your end :)
[21:00:32] <bss36504> That is in fact something I need.
[21:00:38] <N1njaway> bss: But get a design or two under the belt and it's old hat, I promise!!
[21:00:55] <Valen> I thaught it was....
[21:01:00] <bss36504> I like my job, but it would be nice to work under someone who actually knows more about the application than I do.
[21:01:00] <N1njaway> The fact that USB on these devices only takes 2 resistors and a cap is pretty cool :)
[21:01:45] <Valen> my first time it worked first go, just had to swap d+ and d-
[21:01:56] <N1njaway> Valen: It would at least give you confidence that the device is booting up, and you can then send out wiggle patterns or bit walks on the IO ports to scope to make sure you are seeing what you expected.
[21:01:56] <Valen> (which btw gives the exact same error)
[21:02:25] <bss36504> Ok, have you tried swapping the D+ and D-? :P
[21:02:35] <Valen> I'm pretty sure its running, its pulling the right current and the right wiggles at least somewhat
[21:02:45] <Valen> i did that, then there was no enumeration at all
[21:02:52] <Valen> no attempt even
[21:03:01] <bss36504> Ah, I figured you would have tried that
[21:03:09] <N1njaway> If you didn't assemble this under a microscope, you may also want to power off the board, grab a set of fine-point probes or needles you can connect a DVM to, and tap critical sets of pins to make sure you have no shorts or solder-bridges between pins that aren't evident.
[21:04:01] <N1njaway> Valen: Also, I would make sure you try a different USB port/controller/hub. I have seen instances where USB ports can sometimes get cranky and simply flat-out refuse to do anything else until completely reset, hubs that need power-cycle and replugging, etc.
[21:04:12] <Valen> tried 2 laptops, all ports
[21:04:30] <Valen> N1njaway: I made 2 boards with the exact same problem
[21:04:37] <Valen> 3 if you count the one i milled first
[21:04:49] <Valen> I just presumed that the fault was with the milled board so i got some made
[21:05:40] <N1njaway> Hmm. Do you have a 10uF on vbus there?
[21:05:47] <Valen> yup
[21:05:57] <Valen> over next to where they come into the board
[21:06:21] <bss36504> I've never personally experienced it, but is it possible the crystal is too far away?
[21:06:50] <N1njaway> Yeah, I see that. If you aren't powering through VBUS, you should be able to eliminate that or try replacing it with a 0.1uf. It may be causing VBUS to come up too slowly or potentially surging the USB port.
[21:07:30] <Valen> that has been mentioned, I spose I could make a blink a LED and count seconds to see if its in spec
[21:07:44] <Valen> the 2nd board had no caps at all on it ;->
[21:08:09] <N1njaway> bss: It's a bit far away but should still be okay. The thing I HAVE seen occasionally is the need to set the CLKOPT fuse in order to bang the clock harder. I have seen variances in silicon between -A and non-A series parts (this was in a ATMEGA128) where you absolutely needed to set CLKOPT to get the correct frequency reliably.
[21:08:35] <Valen> I haven't needed this before, whassit do?
[21:08:37] <bss36504> hmm, interesting.
[21:08:59] <bss36504> As much of a pain as it may be with the dragon, try to see if you can program this thing that way.
[21:09:29] <N1njaway> Had to identical boards, crystals, settings, everything. One I could stick a 1x o-scope probe on the clock crystals on both sides and it would happily chug away no problem. the -A series part, unless CLKOPT was set, would actually cause the crystal to completely stop when the probe was on it.
[21:09:50] <Valen> CLKOPT is not found in the u4 datasheet?
[21:10:25] <N1njaway> i.e. the reaction of the silicon was DIFFERENT between the 128 and 128A and was not called out in the errata or migration notes. That's one I had reported back to Atmel via our FAE. The fix was to simply set CLKOPT on everything.
[21:10:33] <N1njaway> Valen: Let me look. It may not be on there.
[21:11:20] <N1njaway> CLKOPT increased the drive-strength applied to clock crystals and resonators when enabled. Basically you could turn it off in theory to save power consumption, etc.
[21:12:34] <N1njaway> Valen: Okay, the U4 doesn't have CLKOPT so that rules that out. Not to say the clock might not still be the issue, but hopefully it's better.
[21:13:24] <Valen> I will stick the 8mhz one in there and see if it does anything
[21:13:50] <N1njaway> If you hit the clock with a 10x o-scope probe, you should measure a total period of 62.5us from sine-wave crest to crest
[21:14:12] <bss36504> Shoudnt it be more of a sawtooth deal?
[21:14:22] <Valen> I compared it with a working one over 11 wavelengths and it was the same as far as we could tell
[21:15:16] <N1njaway> bss: TTL clocks should be somewhat square-wave'ish, but anything higher-speed goes sine-wave quite quickly. Partially that's by design - slower edge-rates lead to less harmonics which leads to less emissions.
[21:15:16] <Valen> I will give it a go over one, I tell ya what, turning the knob to set measurement bars is so freekin awesome
[21:15:57] <Valen> (and having it read out the measurement to you)
[21:16:06] <bss36504> N1njaway: Yeah I guess I've just only seen this speed grade in a curved-sawtooth type wave.
[21:16:31] <N1njaway> Valen: Also psosibly try removing the 10uf cap from VBUS and/or sticking the 10K to GND on there.
[21:16:41] <Valen> I'll try that
[21:17:57] <Valen> I could perhaps fire up clkout on the working one and feed that into the non working one
[21:18:23] <N1njaway> Valen: On Atmel's datasheet, there is nothing shown on VBUS when doing a self-powered (non-bus powered) device
[21:19:18] <N1njaway> I had added the 0.1uf and 10K on my application since the device needed to detect when USB was attached since it was normally powered via battery and code would already be running.
[21:19:38] <Valen> to be fair they don't have a cap on any of those diagrams
[21:20:00] <N1njaway> Also, have you attached it to the USB port and then pressed RESET or cycled power to the board?
[21:20:21] <N1njaway> My concern, though, is that the 10uf may be surging VBUS or causing it to rise too slowly.
[21:20:35] <N1njaway> I would probably remove it and retry.
[21:20:41] <Valen> oh I'll do that to be sure
[21:21:00] <Valen> but the 2nd board with the 16u4 doesn't have *any* caps on it and has the same behaviour
[21:21:29] <Valen> I'm always wary of powering usb before the board, i haven't seen anything to say that doing that is ok
[21:21:40] <Valen> i have powerd the board, plugged usb and hit reset
[21:21:45] <Valen> also reset + hwb
[21:23:02] <Valen> the datasheet doesn't say not to put the 10uf on for any reason, all it says is "• A 10μF capacitor is highly recommended on VBUS line",
[21:23:07] <Valen> this is so frustrating
[21:23:26] <Valen> I was really hoping somebody would point out what obvious thing i had done wrong ;->
[21:23:50] <N1njaway> Valen: I surmise that it might be suggested to put the cap on VBUS there if you are doing a bus-powered application.
[21:24:12] <Valen> well i'll nerf it and see what happens
[21:24:47] <Valen> also, I had an absence of .1 or .01uf caps for bypassing, I used a mix of 1uf and 450nf caps, think that would cause a problem?
[21:26:07] <N1njaway> Generally the atmel checks the state of VBUS to see if there is device attachment, and if so, then attempts enumeration. My concern is that it could possibly be weird because you are externally powering the device and VBUS is rising slowly or such due to the cap and might not be getting reliable detection. That or the cap is holding a charge when the USB is disconnected (as would be expected) so
[21:26:07] <N1njaway> VBUS never dips down, and thus it doesn't see VBUS come back up for attempting to reinitialize enumeration.
[21:26:36] <N1njaway> I put the 10K on VBUS to pull it down to GND weakly to ensure the device could reliably see VBUS detached when USB was unplugged.
[21:26:58] <Valen> its a fair point, but with it all connected, then just hitting reset would bypass that failure mode wouldn't it?
[21:27:01] <N1njaway> And when it did, it then waited for VBUS to come back up, and then it would reinitilize enumeration.
[21:27:09] <bss36504> N1njaway: Just out of curiosity, in your products, what do you use for a USB software lib? LUFA?
[21:27:20] <N1njaway> Valen: In theory, maybe.
[21:27:36] <Valen> well its not going to pull vbus to gnd during reset ;->
[21:27:40] <Valen> (well i hope not lol)
[21:27:47] <N1njaway> Valen: But this is why it's useful to be able to load your own code on via SPI/JTAG so you can poke at the registers and see what's going on.
[21:28:09] <N1njaway> bss: I've used LUFA as well as just some simply-coded down-and-dirty HID stuff.
[21:28:18] <bss36504> Valen: That's a feature actually. By pulling VBUS to ground, you're guaranteed to reset the host's hub as well ;)
[21:28:18] <Valen> well I'll do that as my next step
[21:28:31] <Valen> and let the smoke out of cheap wall chargers?
[21:28:36] <Valen> PULL IT DOWN HARD!
[21:29:05] <bss36504> The little men inside the chip run around turning valves and dodging steam blowoffs
[21:29:30] <N1njaway> Valen: Yes, but since I don't know the innards of the DFU bootloader and how it is doing presence detection, all I can tell you is how I've made it work for my own applications in the past :)
[21:29:32] <Valen> nah it'd be all star trek with things exploding everywhere, but its ok because it all still works
[21:29:42] <Valen> yup, i'll give it a go for sure
[21:30:09] <N1njaway> You'd just have to rebuild the warp core from time to time, just like in Star Trek
[21:30:20] <Valen> that has always bothered me about trek, their electronics have loads of magic smoke in them, they can keep working even after letting some out.
[21:30:44] <bss36504> Valen: Then they'd send their second in command, a one of a kind android, their chief engineer and the head doctor to the surface.
[21:30:44] <Valen> but they don't know about the concept of a fuse, and run the power for the entire ship through some dudes desktop
[21:30:44] <N1njaway> I like how everything always explodes on the bridge when there are problems in *engineering*
[21:31:18] <Valen> bss36504: to be fair if i was captain of a space ship I'd damn sure be doing the away missions my self
[21:31:19] <N1njaway> Valen: Dunno, maybe WE'RE doing it wrong and that's why we don't have spaceships yet.
[21:31:28] <Valen> how else are you going to get to bang the hot green lady
[21:31:37] <bss36504> "The engines are overloaded! The console on the bridge has to shunt all the excess power!"
[21:32:02] <N1njaway> Maybe I could make better high-tech things if I took the 200A legs of my three-phase box here and routed them through my desktop PC first.
[21:32:05] <Valen> i told you to install the breaking resistor,
[21:32:06] <bss36504> Thats a good point though. We dont have a warp drive
[21:32:16] <Valen> pshaw, red shirts are cheaper than fuses
[21:32:33] <bss36504> N1njaway: Just literally take the wires and insert them into the case.
[21:32:49] <Valen> i think its more like having a 240v mains powered keyboard
[21:33:00] <Valen> but running the 240v as the signaling system
[21:33:01] <N1njaneer> Imagine how bright the CAPS LOCK light could be
[21:33:09] <bss36504> FEEL THE POWER AT YOUR FINGERTIPS
[21:33:22] <Valen> heh get that ungrounded mains buzz w000t
[21:33:42] <Valen> would encourage people to keep their keyboards clean
[21:34:08] <Valen> that was something i liked about enterprise, when stuff broke there would be holes in things, and people would be cutting and welding stuff
[21:34:20] <bss36504> but the acting...
[21:34:26] <bss36504> it was meh
[21:34:27] <Valen> i liked it ;->
[21:34:29] <N1njaneer> I've had the pleasure of grabbing a 1" feeder cable when it has 30kW of power flowing through it. It's crazy that you can absolutely feel the EM field without any difficulty.
[21:34:40] <Valen> it wasnt OMG super awesome but still
[21:34:49] <N1njaneer> I liked Enterprise for the same reason.
[21:34:55] <Valen> I think the "temporal cold war" was what killed it
[21:34:59] <Valen> who likes cold wars?
[21:35:03] <Valen> i mean seriously
[21:35:04] <bss36504> Alright, it was definitely alright. I always had a good chuckle
[21:35:13] <Valen> and time travel is always bad
[21:35:16] <bss36504> More of a Stargate fan myself
[21:35:17] <N1njaneer> Amusingly I'm sitting here watching TNG episodes background while I crimp USB motherboard connectors :)
[21:35:21] <Valen> I loved stargate
[21:35:30] <Valen> i loved their world building
[21:35:38] <N1njaneer> SG1 was awesome, and not just because RDA was my childhood hero!
[21:35:56] <Valen> how this year we found thing X, then next year look we built on X and now we have this new shiny thing
[21:36:13] <Valen> and when all else fails launch a buttload of nukes at the bastard!
[21:36:15] <bss36504> All the Stargates were good, SG1 is probably my favorite, but Universe was cancelled too early
[21:36:24] <Valen> universe could have been good
[21:36:26] <N1njaneer> Valen: Good writers == Good Show, an amazing concept that only now other shows are catching on to
[21:36:38] <Valen> i think they were getting their crap together
[21:36:50] <Valen> got a bit wavy in the middle
[21:36:57] <bss36504> It was supposed to have a 4 season story arc, but people were impatient
[21:37:15] <N1njaneer> I went back and watched the original Stargate movie a while ago, and it's like all the actors are really shitty caricatures of the SG1 characters. Almost Wormhole Extreme'esc, but funnier because the movie was trying to be serious.
[21:37:30] <Valen> the show was better than the movie
[21:37:31] <bss36504> haha omg so true
[21:37:41] <Valen> are there any sci-fi shows being made presently?
[21:37:49] <Valen> i mean sci-fi, not monsters in closets
[21:37:52] <Valen> with magic
[21:37:52] <bss36504> Curt Russel is not really the pinnacle of acting prowess.
[21:38:02] <N1njaneer> Like, James Spader makes the absolute worst Michael Shanks
[21:38:22] <Valen> Oh btw, great hard sci-fi movie is Iron Skies
[21:38:23] <bss36504> Valen: I like Warehouse 13 a lot. Not as sciency, but still pretty fun
[21:38:33] <Valen> yeah warehouse 13 is good
[21:38:36] <Valen> I loved eureka
[21:38:45] <N1njaneer> Valen: I'm pissed they cancelled Terra Nova. That show was well written, amazingly produced for a TV budget, got great ratings, and they just dropped it.
[21:38:47] <bss36504> Sanctuary. Eureka is one of my all time favorites
[21:38:55] <N1njaneer> W13 is great - is that back on-season yet?
[21:39:04] <Valen> i was meh on TN
[21:39:07] <bss36504> I have no idea. I need to catch up a bunch.
[21:39:13] <Valen> sanctuary was good
[21:39:19] <bss36504> Is it still on?
[21:39:30] <Valen> finished
[21:39:37] <bss36504> I dont get Syfy any more, so I need to watch all this online. Thats a bit sad :/
[21:39:47] <N1njaneer> I watched ALL of Breaking Bad here as background in like a 3 week crash as we did a major build with a lot of late nights, now I'm kind of sad it's over :)
[21:39:49] <Valen> I only have FTA tv in australia
[21:40:12] <bss36504> BB is amazing.
[21:40:14] <N1njaneer> Valen: Iron Sky was amazing.
[21:40:32] <Valen> I loved how accurate it all was except when they decided to break things
[21:40:43] <Valen> breaking the rules is ok if you know your doing it
[21:40:48] <N1njaneer> SG1 is to Stargate as AVR is to Arduino, it's that simple :)
[21:40:55] <bss36504> Rotten Tomatoes just loved Iron Sky haha
[21:41:22] <bss36504> N1njaneer: Truer words were never spoken.
[21:41:28] <N1njaneer> lol you can quote me on that.
[21:42:22] <bss36504> I have some classmates (computer engineers, I'm EE) and they think they'll be able to implement usable image processing on an Arduino to guide a quadcopter behind a human leader
[21:42:31] <Valen> lol
[21:42:34] <Valen> ok
[21:42:38] <Valen> let me know how that works
[21:42:40] <bss36504> Basically my thoughts.
[21:42:41] <N1njaneer> bss: You should egg them on!
[21:42:56] <N1njaneer> Because there's trolling, and then there's TROLLING. :)
[21:43:05] <Valen> if they are godlike they might be able to aim for a colour
[21:43:10] <bss36504> I could tell them to use, idk, GPS or something feasible, but I kind of want to see what happens.
[21:44:01] <bss36504> Valen: ikr? As if image processing stills wasn't hard enough on a computer with basically limitless computing power (for all intents and purposes), now they want to put it in a limited hardware setting and then limit it further by the arduino api.
[21:44:28] <bss36504> The camera module they're using doesn't even output bitmaps. JPEG. So theres that too
[21:44:37] <N1njaneer> One of the biggest problems I have with Arduino stuff is that yeah, it's a super way for people to get in to this stuff as hobbiests, but at the cost of an easy start and easy implementations, you will always hit the "glass ceiling" waaaaay faster. And then unless you really know what's going on and you can dig deeper, there's no way to get around the limitation.
[21:45:37] <bss36504> Yeah, I guess if my only task was to take "simple input x" and apply it to "simple output y" i'd use an arduino. But that's about it
[21:46:06] <Valen> rofl
[21:46:18] <Valen> even decoding jpeg in an avr would be exciting
[21:46:31] <N1njaneer> bss: Even figure that if 320 x 240 was read in as monochrome 8bpp, that's 76,800 bytes per frame. At least double or quadruple that in cycles JUST to write to memory.
[21:47:07] <N1njaneer> At 30fps, that's 2.3 million port-reads per second. Good luck having much time to do much else, even at 16Mhz.
[21:47:17] <bss36504> It's a bit ridiculous. maybe if the arduino was full java, you could use some libs to aid on the software part. then you add the 20Mhz clock speed, it's just not gonna happen.
[21:47:46] <N1njaneer> If you were really good, you could possible do in-place blob detection with one AVR and dump the resulting boiled-down data to a second to process it.
[21:47:58] <Valen> the only way i could see them doing it would be to screw with the agc in the camera, have a dark background with a white target and get monochrome
[21:48:05] <Valen> ie 1 bit per pixel
[21:48:22] <bss36504> yeah, but to make that reliable in all light conditions....
[21:48:22] <Valen> then cheat some more and just find the average of each line as it came in
[21:48:34] <Valen> oh it'd suck at pretty much anything ;->
[21:48:41] <N1njaneer> Valen: Yeah, I was going to suggest that as well. Though if you could read 8bpp, a bit of 7400 logic offboard could let you just stick on a magnitude comparator.
[21:48:42] <Valen> but you could make it work well enough for the demo
[21:48:53] <Valen> N1njaneer: true enough
[21:48:58] <Valen> heh
[21:49:16] <N1njaneer> At that point, though, I just stick on an FPGA and do the heavy lifting there in my designs :)
[21:49:18] <Valen> read it in by sampling a comparator input of the luminance channel off an analog signal
[21:49:39] <Valen> I'd just put a mini-itx PC on the thing, farm it to the server farm over wifi
[21:49:49] <N1njaneer> But latency!
[21:50:00] <bss36504> I think they should use a gps module, so outdoors you can localize to the person within +/- 10m, then use some IR sensors to assist moving indoors.
[21:50:31] <bss36504> I forgot to mention that they are tethering this to an android phone.
[21:50:36] <bss36504> so they can track to that.
[21:50:59] <N1njaneer> bss: Ambitious.
[21:51:03] <N1njaneer> All around.
[21:51:08] <N1njaneer> You should let us know how that goes.
[21:51:11] <bss36504> Better than image processing.
[21:51:33] <N1njaneer> Where is this at, if you don't mind me asking? :)
[21:51:56] <bss36504> My group is doing a full-custom multi codec portable music player and a full syncing program. It's myself, another EE and two computer engineers. I go to Vermont Technical College.
[21:52:19] <N1njaneer> Ahh cool, not toooooo far away. I'm in Cleveland.
[21:52:48] <bss36504> Oh neat. I've never been that far west. Kinda sad. Someday /me looks to the future with longing eyes
[21:53:03] <bss36504> wait, /me doesnt work in the middle of a line?
[21:53:08] <bss36504> damn IRC crap.
[21:58:04] <Valen> nope
[22:12:30] <N1njaneer> Crimp crimp crimp crimp cripm
