Back
[00:33:33] <langoliers> Bing Rewards: You’ve earned a free entry to win an Xbox 360 prize pack. < do you think i will register for this? :)
[00:52:22] <langoliers> want to program your own clock frequency on-the-fly? :)
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si514.pdf
[03:17:12] <OndraSter> langoliers, no thanks, I have got a PLL :P
[04:07:30] <kdehl> Um. I have a 3.3 V ENC28J60 network module, but I run my controller at 5 V. Can I just use a MAX756 in between those two to make them work together?
[04:08:16] <kdehl> It said its maximum frequency is 500 kHz. Which I'd guess is sufficient for low-speed networking, which is all I need.
[04:08:19] <twnqx> that's a voltage rgulator...
[04:08:23] <kdehl> So, no?
[04:08:28] <kdehl> I'm clueless here.
[04:08:42] <twnqx> what you want is called a level shifter
[04:08:45] <kdehl> Ah.
[04:09:12] <kdehl> Okay.
[04:15:59] <jacekowski> kdehl: that ENC is 5V tolerant iirc
[04:16:17] <jacekowski> kdehl: so you don't need anything in between
[04:16:35] <jacekowski> kdehl:
http://ww1.microchip.com/downloads/en/devicedoc/39662c.pdf
[04:17:15] <jacekowski> kdehl: so what you want is bunch of resistors inline and you're done
[04:17:42] <jacekowski> kdehl: but you still need 3.3V for supply to that chip
[04:18:35] <kdehl> Interesting! But mine is on a breakout board with Ethernet connectors and stuff already mounted.
[04:18:50] <twnqx> i'd drop in a txb0106 for good measures :P
[04:19:13] <jacekowski> kdehl: well, that's fine
[04:19:26] <kdehl> You sure?
[04:19:32] <jacekowski> kdehl: yes
[04:19:33] <kdehl> I'm a little scared. :)
[04:19:38] <kdehl> Okay, awesome!
[04:19:39] <jacekowski> what board is it exactly?
[04:19:44] <twnqx> it will likely work, yes
[04:20:01] <jacekowski> kdehl: you need 3.3V for the supply, but i/o pins will take 5V
[04:20:06] <kdehl> jacekowski:
https://www.olimex.com/Products/Modules/Ethernet/ENC28J60-H/
[04:20:08] <twnqx> slightly out of spec, so don't do it commercially :P
[04:20:20] <jacekowski> twnqx: not out of the spec
[04:20:23] <kdehl> That's the one I have, iirc. I'm at work now, so I don't have it in front of me.
[04:20:25] <jacekowski> twnqx: spec says that 5V is ok
[04:20:30] <twnqx> jacekowski: in that direction yes
[04:20:41] <twnqx> the 3.3V out are out of spec for 5V AVR inputs, though
[04:20:59] <kdehl> Okay, so supply the board with 3.3 v, but I/O pins at 5 V is fine.
[04:21:41] <twnqx> also use a 3.3V power supply that can handle the 4.3v on its lines
[04:21:50] <twnqx> which the clamp diodes will produce
[04:22:01] <twnqx> and try some resistors on the outputs
[04:23:04] <kdehl> I was thinking of either using two 1.5 volt batteries (if that's enough voltage) or an old computer PSU to power it.
[04:23:12] <jacekowski> twnqx: not exactly
[04:23:22] <jacekowski> twnqx: on AVR Vih is 0.6*Vcc
[04:23:25] <jacekowski> twnqx: so 3V
[04:23:43] <kdehl> If two batteries are sufficient, I'd prefer it that way for now. I haven't slaughter the PSU yet.
[04:23:46] <jacekowski> so it's in the spec that way
[04:24:04] <twnqx> and the ENC guarantess Voh of vcc-0.7V :)
[04:24:06] <twnqx> so 2.6
[04:24:22] <jacekowski> i thought it's cmos
[04:24:39] <twnqx> page 80 of the data sheet you linked :)
[04:24:57] <jacekowski> yeah
[04:25:13] <kdehl> That TXB0106 looks good though. I mean, I'll probably run into this problem again sooner or later.
[04:25:26] <twnqx> it's small :)
[04:25:40] <jacekowski> kdehl: well, everyone runs 5V tolerant devices like that with no problems
[04:25:47] <twnqx> yeah
[04:25:57] <twnqx> it normally works
[04:26:03] <kdehl> Okay.
[04:26:05] <kdehl> Hm.
[04:26:22] <jacekowski> even on bigger runs it's cheaper to reject every 1000th device than add extra level converter
[04:26:39] <kdehl> Heh.
[04:26:44] <kdehl> Yeah, I can imagine.
[04:27:06] <twnqx> 180mA... drop in a small LDO from 5V to 3.3V for the power supply
[04:27:20] <twnqx> sot23 + 2 capacitors, done
[04:27:55] <kdehl> Do I really need that?
[04:28:07] <jacekowski> you need some way to create your 3.3
[04:28:13] <kdehl> I thought the voltage from a PSU was close to perfect already.
[04:28:19] <twnqx> http://www.ti.com/product/tlv70033
[04:28:22] <twnqx> simple enough
[04:28:26] <jacekowski> kdehl: so you have 2 PSUs?
[04:28:32] <jacekowski> kdehl: one for 3.3 one for 5?
[04:28:40] <twnqx> well, every modern PC psu has 5V and 3.3V :P
[04:28:54] <jacekowski> on load
[04:29:02] <twnqx> kdehl: you might run into problems using a PC power supply with this low output current
[04:29:02] <jacekowski> off load you don't know what you're getting
[04:29:09] <kdehl> Aha.
[04:29:15] <kdehl> Right.
[04:29:18] <kdehl> Good point.
[04:29:39] <jacekowski> some psu's will refuse to work off load
[04:29:45] <kdehl> But anyway, what about to 1.5 volt batteries for now, shouldn't that work, just to get it started?
[04:29:54] <kdehl> Yeah, I do remember that now when you mention it.
[04:29:56] <twnqx> brand new should deliver 3.2V
[04:30:08] <twnqx> so... i wouldn't
[04:30:13] <kdehl> Ah.
[04:30:14] <twnqx> just drop in one of those
[04:30:14] <kdehl> Hm.
[04:30:21] <twnqx> order them as samples from TI :P
[04:30:42] <kdehl> Done!
[04:31:03] <kdehl> Which one should I pick?
[04:31:34] <kdehl> No, wait. I'm stupid.
[04:32:36] <twnqx> that's bad if you want to design electronics :P
[04:33:14] <kdehl> Indeed. But that's why I have you guys!
[04:35:03] <kdehl> So, if I understand it correctly, this tlv70033 takes 2-5.5 volt input and always outputs 3.3 volts?
[04:35:09] <twnqx> nah
[04:35:33] <twnqx> it will output MIN(input - 0.2,3.3)V
[04:35:39] <twnqx> no upward conversion
[04:35:47] <twnqx> those are more complex
[04:36:11] <kdehl> Ah. But if I input 5 volts or so I'm guaranteed to get 3.3 volts output?
[04:36:22] <twnqx> yeah, from ~3.5-5.5V
[04:36:24] <kdehl> Ah yes, that's what you wrote.
[04:37:47] <kdehl> So I use this to power the ENC28J60, but I run the I/O pins straight to the AVR running at 5 V and I shouldn't have a fire.
[04:38:00] <twnqx> no fire for sure :)
[04:38:46] <twnqx> if i would be designing this, i'd add resistors to limit the output current from the AVR io pins
[04:39:33] <twnqx> 5V/1mA => 5kOhm, so probably around 4.7kOhm
[04:40:13] <twnqx> but only on the outputs of the AVR to the inputs of the ENC, not for the other direction
[04:41:22] <kdehl> Okay. Maybe when I finish it up (if I ever will). It's not necessary for testing, is it?
[04:42:43] <kdehl> How would you connect them, in series with the data lines?
[04:42:56] <kdehl> That would drop the voltage level, wouldn't it?
[04:44:36] <kdehl> Shit, I'm so bad at analogue electronics.
[05:04:42] <kdehl> How about I use a LM3940IT?
[05:05:12] <kdehl> "Low Dropout Regulator for 5V to 3.3V Conversion"
[05:08:08] <kdehl> Seems to be the same.
[05:08:08] * kdehl orders
[05:23:10] <twnqx> it's bigger and has more power
[05:24:12] <twnqx> you shouldn't end up with a relevant voltage drop because of the resistors - there's no real divider anywhere, only the clamp diodes inside the chip
[05:28:12] <twnqx> beware of the capacitor sizes for your chip. the output one is likely an electrolytic
[05:34:04] <kdehl> Hm koay.
[05:34:06] <kdehl> Okay.
[05:41:09] <RikusW> kdehl: how about GTL2002 or GTL2003 ?
[05:41:54] <kdehl> RikusW: Seems good!
[05:44:05] <kdehl> I bought this one:
[05:44:05] <kdehl> http://www.ebay.com/itm/121032259497?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649
[05:50:38] <Horologium> kdehl, what enc28j60 module do you have?
[05:51:31] <kdehl> Horologium:
https://www.olimex.com/Products/Modules/Ethernet/ENC28J60-H/
[05:51:56] <kdehl> I think it's that one. I ordered it elsewhere. I'm at work, so I don't have it here right now.
[05:52:22] <kdehl> I'm thinking about ordering this one though:
[05:52:25] <kdehl> http://www.ebay.com/itm/ENC28J60-Ethernet-Controller-Board-LAN-Network-3-3-5V-for-AVR-Arduino-Compatible-/181118336226?pt=LH_DefaultDomain_0&hash=item2a2b7e7ce2
[05:52:44] <kdehl> It explicitly says 5 V, even for power supply. It'd make things so much easier.
[05:56:31] <Horologium> that one has a 3.3V regulator onboard.
[05:57:33] <Horologium> I like the one from futurlec.com
[05:59:38] <Horologium> http://futurlec.com/Mini_Ethernet.shtml not as compact but it works well for me.
[06:00:01] <kdehl> Nice.
[06:00:16] <kdehl> But it ought to be the same though?
[06:00:28] <kdehl> They're all based on the same chip.
[06:00:55] <kdehl> MAybe the SPI is implemented differently.
[06:01:09] <kdehl> Or is the SPI support in the DNC28J60 itself?
[06:04:42] <Horologium> spi is on the chip itself.
[06:05:13] <kdehl> Ah, cool.
[06:06:01] <kdehl> So in other words, all the modules should be totally compatible.
[06:06:08] <Horologium> that module from futurlec has an onboard 5V/3.3V buffer along with regulator.
[06:06:23] <Horologium> as far as programming side, yes, they are all the same.
[06:06:45] <Horologium> heck, I usually just use a bare chip and some external components.
[06:07:09] <Horologium> ripped apart a couple of dead routers for the magjacks to use with them.
[06:07:34] <kdehl> Heh.
[06:07:34] <kdehl> Nice.
[06:08:35] <kdehl> How's the programming, though? Is there an internal TCP/IP stack or do I have to make one myself?
[06:08:43] <kdehl> (Or steal someone else's online.)
[06:08:52] <Horologium> make or steal one.
[06:08:57] <Horologium> there are several out there.
[06:09:13] <kdehl> Yeah.
[06:09:30] <Horologium> one right on the olimex page there for an atmega32
[06:09:34] <kdehl> I think I'll start looking into making one. If I get stuck I'll screw it.
[06:09:37] <kdehl> Oh.
[06:10:10] <Horologium> http://shop.tuxgraphics.org/electronic/index-eth.html
[06:10:17] <Horologium> I like the one these guys use.
[06:10:45] <kdehl> Ah, nice.
[06:10:47] <Horologium> there are both client and server on there.
[06:11:30] <kdehl> I don't need the web server stuff, only TCP level.
[06:14:07] <Horologium> how do you plan on connecting to it?
[06:14:20] <Horologium> using it to send data directly or poll and request?
[06:15:44] <Horologium> http://tuxgraphics.org/electronics/200901/avr-ethernet-realtime.shtml
[06:15:47] <kdehl> I don't know, I still don't understand at what level I need to program stuff.
[06:16:35] <Horologium> every level.
[06:16:38] <Horologium> unless you get a stack.
[06:16:53] <Horologium> but you still need to know how you are talking to it...or how it is talking to other devices.
[06:20:37] <kdehl> Hehe. Well... Okay, the thing is that I've made a paint program with networking support. There's a standalone server that keeps a central canvas, and a bunch of clients programmed in different languages that can connect to it.
[06:21:37] <kdehl> I now want to make a hardware version of this program. I have already (kinda) created PS/2 mouse support, I (again, kinda) have support for diplays that works, and now I want the networking support.
[06:22:47] <kdehl> That's the idea, I haven't really planned anything else for it yet.
[06:24:47] <kdehl> And the protocol is implemented on top of TCP/IPv4.
[06:37:53] <twnqx> err
[06:37:58] <twnqx> tcp... on an avr?
[06:38:07] <twnqx> did you really think that through?
[06:38:23] * twnqx drops a legit 64kB packet on the avr
[06:40:22] <kdehl> Hm.
[06:40:42] <kdehl> Can't I limit the length of the packets that the host is able to revceive?
[06:40:49] <twnqx> how large can your canvas be, 2kB? :P
[06:40:52] <kdehl> I thought that was built in to TCP.
[06:41:28] <twnqx> no, there's ony a maximum segment size
[06:41:32] <kdehl> Hehe, yeah, it's small. Actually you don't have to have the whole canvas available on the client at once. You can tell the server to only send part of it.
[06:41:36] <kdehl> Oh.
[06:41:39] <twnqx> which is the size of the transmission unit
[06:42:02] <kdehl> Which means part of a TCP packet?
[06:42:08] <twnqx> yes
[06:42:09] <kdehl> Ah.
[06:42:10] <kdehl> Oops.
[06:42:30] <kdehl> So, I need to be able to handle a full 64 kb packet, huh.
[06:42:35] <kdehl> Damn.
[06:42:37] <twnqx> anyway, the memory sounds awfully low for what avr can handle
[06:42:45] <kdehl> External RAM then I guess...
[06:43:07] <twnqx> for a total of max 64k - IO range
[06:43:08] <twnqx> \o/
[06:43:15] <twnqx> unless you manually bank switch :P
[06:43:23] <kdehl> Hm.
[06:43:47] <kdehl> But how do all those tiny web servers handle it? They have TCP implemented, don't they?
[06:47:12] <Roklobsta_> yes
[06:48:10] <kdehl> So how do they solve it? If they suddenly get a 64 kbyte package?
[06:48:30] <Roklobsta_> have a look at the source. ignore it probably
[06:48:38] <kdehl> Ah.
[06:48:57] <kdehl> Yeah, I will.
[06:50:14] <tzanger> ou don't have to solve problems like that
[06:50:26] <tzanger> you can simply not accept the packet, it'll be retried a few times then dropped by the other side
[06:50:35] <tzanger> yes it is bending the rules but it happens
[06:52:38] <kdehl> Heh. But that would let the client believe it couldn't connect to the server, and report a timeout, wouldn't it?
[06:53:30] <kdehl> So there's no way of telling the client to re-send packages in smaller sizes?
[06:54:02] <kdehl> Unless you twist the application-specific protocol itself, I guess.
[06:58:40] <twnqx> you could also use a cpu with more ram
[06:58:58] <twnqx> also, a web server is unlikely to be hit with large data blocks
[06:59:13] <twnqx> it's just the GET request, maybe a POST would be huge enough
[06:59:22] <twnqx> or could at least be crafted
[07:00:39] <jacekowski> kdehl: there is, you set window to small value
[07:00:44] <jacekowski> kdehl: very small
[07:02:02] <kdehl> jacekowski: Ah. So, there is a solution!
[07:05:20] <twnqx> ugh, must have misunderstood windows size then
[07:05:33] <twnqx> i thought that was the number of packets in flight before requiring an ack
[07:06:13] <kdehl> Heh. We both leared something today.
[07:11:32] <tzanger> kdehl: yes, there is, but if you're trying to get a single large packet you might have to rethink how much data you're sending to a machine with 64kB total memory
[07:14:37] <kdehl> tzanger: Yes, good point.
[07:14:51] <kdehl> Let's just say that this protocol wasn't designed for microcontrollers in mind.
[07:15:56] <tzanger> jacekowski: how does windowing affect packet size? are you thinking about MTU/PMTU?
[07:16:18] <tzanger> kdehl: is using a gateway PC to "translate" the protocol to something smaller/simpler for micros a possibility?
[07:18:50] <tzanger> kdehl: EVEN IF you can get the individual fragments down to small enough chunks for the micro, you are not guaranteed to get them in order and the TCP/IP stack would have to reassemble before it can do something useful with them
[07:18:57] <tzanger> whcih means having enough memory to reassemble
[07:19:50] <jacekowski> tzanger: if your window is set at 100 bytes, then the other side will send at most 100 bytes at a time
[07:20:02] <jacekowski> tzanger: 100 unACKed bytes
[07:20:29] <jacekowski> so if your window is set to 100bytes you only need 100bytes of memory
[07:20:45] <jacekowski> for reassembly and stufff
[07:24:12] <kdehl> Just a sec, work just came in... trying to push it away.
[07:27:09] <kdehl> Succeded.
[07:27:36] <tzanger> jacekowski: that's not true
[07:27:44] <tzanger> if your window is set to 100 bytes there will be no more than 100 bytes in transit
[07:27:48] <kdehl> Packets don't have to arrive in the right order, I can't update the canvas (or screen) until I have all the packages anyway.
[07:28:05] <tzanger> but if they send you a 1kB packet, it'll be fragmented to hell and you have to get ALL the fragments and reassemble them before you can verify the 1kB packet was received correctly
[07:28:16] <kdehl> But I do need enough RAM for the part of the canvas that I requested from the server.
[07:28:28] <kdehl> Which I believe I have. With some margins.
[07:29:35] <kdehl> So I think I'm fine, as long as I don't have to buffer huge packages of TCP data.
[07:30:08] <tzanger> what you could do is have a fixed size reassembly buffer (the canvas size + TCP/IP overhead) and reassemble directly into that canvas
[07:30:53] <kdehl> Yes, that could work.
[07:31:22] <kdehl> Or actually, I could even have the packages coming in compressed, and decompress them directly into canvas. That way I wouldn't have to have space for two uncompressed canvases.
[07:31:32] <jacekowski> tzanger: no, if your window is set to 100 bytes then there will be no more than 100 bytes "on the wire"
[07:31:45] <jacekowski> tzanger: send buffer has NOTHING to do with window size
[07:31:46] <kdehl> Or maybe compression is too slow to handle.
[07:32:32] <kdehl> jacekowski: Do the 100 bytes include TCP/IP overhead, or only payload?
[07:32:36] <jacekowski> payload
[07:32:50] <kdehl> Ah, okay.
[07:32:53] <jacekowski> but window can be set as small as 1 byte
[07:32:57] <kdehl> Heh.
[07:33:01] <kdehl> That's a lot of overhead.
[07:33:33] <jacekowski> yes
[07:33:42] <jacekowski> but on micro it may be the way to go
[07:33:51] <kdehl> Indeed.
[07:34:11] <kdehl> Well, screw compression. I'll do it uncompressed.
[07:34:30] <kdehl> Perhaps with some external SRAM.
[07:34:38] <cluelessperson> Hi guys, I'm working on the WS2811 ELD
[07:34:39] <cluelessperson> LED
[07:34:47] <cluelessperson> I'm using assembly to achieve the timing restraints
[07:35:09] <cluelessperson> On page four of this link
http://www.espruino.com/datasheets/WS2811.pdf
[07:35:27] <jacekowski> but well, in some cases reducing window may not work
[07:35:35] <cluelessperson> my understanding is on high speed 800khz each bit will be 20 cycles at 16mhz
[07:35:52] <jacekowski> yes
[07:35:58] <cluelessperson> that "RET code" there, listed. Is that referring to the time between each bit?
[07:39:50] <tzanger> jacekowski: it's not the data on the wire that is the issue
[07:39:53] <tzanger> it's the packet size
[07:40:03] <tzanger> window does nothing to affect packet size
[07:40:05] <jacekowski> and window size will limit packet size
[07:40:24] <tzanger> no, it'll limit the size of the fragment being sent, not the size of the packet
[07:40:30] <jacekowski> if window is set to 100 bytes, the host will not be allowed to send more than 100 bytes
[07:40:44] <tzanger> if you want to send a 100kB packet 1 byte at a time, set your window to 1 byte and enjoy your throughput
[07:40:46] <jacekowski> therefore packet size will be limited to 100bytes + tcp/ip headers
[07:41:16] <jacekowski> read up on definition of a packet
[07:41:25] <jacekowski> http://en.wikipedia.org/wiki/Network_packet
[07:42:22] <jacekowski> you have 100kB BUFFER
[07:48:23] <tzanger> ok, sure, but window just controls how much payload can be sent before an ACK is required
[07:48:38] <tzanger> window does not control the size of an individual packet
[07:48:47] <tzanger> MTU controls the size of an individual packet
[07:49:47] <tzanger> window stipulates the maximum amount of payload that can be sent (in any size packet up to MTU which is bounded by window) without the far end ACKing
[07:53:01] <tzanger> I guess by setting window you also set MTU
[07:54:12] <kdehl> The largest SRAM in a DIP that I can find is 128kbyte, is that really it?
[07:54:20] <tzanger> sounds about right
[07:55:56] <tzanger> you can get up to 2Mbit FRAM in i2c/spi
[07:55:59] <tzanger> that might be an option for you
[07:56:22] <tzanger> $21 for 2Mbit
[07:59:32] <kdehl> True that. Maybe it's easier to go serial for such a large memory space. I don't really need huge throughput either.
[07:59:41] <kdehl> tzanger: Where did you find that?
[07:59:58] <tzanger> digikey, plug in "fram" for the search term, specified I2C/SPI interface
[08:00:20] <tzanger> SRAM is still limited to 1Mbit there no matter what size, but it's cheaper and you can just stack them
[08:01:41] <kdehl> They're limited to a certain size? How come?
[08:02:14] <tzanger> it's a business decision, no physical/technical reason. nobody buys big sram memories, they're too expensive
[08:02:49] <tzanger> wow, $3 for SPI, $13 for I2C
[08:03:06] <kdehl> Heh.
[08:03:09] <tzanger> get four 128kB memories tied to 4 chip selects and there's 1MByte of SRAM
[08:03:19] <tzanger> er sorry 512MByte
[08:03:28] <kdehl> Where did you find those?
[08:03:34] <kdehl> http://www.ebay.com/itm/MT-XRAM-1M-1MB-8Mbit-low-power-SRAM-module-/130799519377?pt=LH_DefaultDomain_0&hash=item1e74424691
[08:03:37] <tzanger> 4x the memory for the same price as one 128kB I2C memory
[08:03:41] <tzanger> kdehl: digikey again
[08:03:43] <kdehl> Man, that'd be lazy.
[08:03:44] <kdehl> Ah.
[08:03:49] <kdehl> Sorry, missed that.
[08:04:38] <tzanger> I think you need to think about your problem space and get some more solid requirements.
[08:06:08] <kdehl> Yeah. I need to think this through.
[08:06:29] * RikusW wonders which is worse pic or arduino...
[08:06:44] <OndraSter> http://clip2net.com/s/4YpjMv
[08:06:44] <OndraSter> yay
[08:06:59] <OndraSter> finally fixed the farnell/mouser source
[08:07:37] <RikusW> nice
[08:09:00] <OndraSter> it is made even for a quick adding -- if you are in the part select field, you enter a part's name and then -- Shift + Enter -- quick add @ 1 pcs, enter -- jumps to the amount field. Another enter in the amount field -- adds X amount of the item. :)
[08:09:06] * OndraSter loves C#
[08:09:09] <OndraSter> fast to develop in.
[11:05:20] <vec_> Tom_itx: your webby is down?
[11:15:29] <Tom_itx> is it?
[11:16:04] * OndraSter thinks that Tom_itx secretly powered it up again
[11:16:14] <OndraSter> :P
[12:08:07] <DrLuke> is there any nice site where I can conveniently search for avrs?
[12:08:23] <DrLuke> as in, specify the features and it spits me out a list of avrs that fulfil my wishes
[12:09:48] <specing> DrLuke: atmel.com ?
[12:13:48] <OndraSter> :)
[12:14:40] <DrLuke> specing: Actually their list is pretty sucky
[12:17:10] <specing> DrLuke: forward your complaints to abcminiuser
[12:17:37] <abcminiuser> DrLuke, there's a mark one-thousand device selector on the site now
[12:17:41] <DrLuke> for starters it doesn't have a search analogous to digikey, farnell etc
[12:17:46] <DrLuke> oh?
[12:17:49] <abcminiuser> They make a new one every few months when they realise the old one sucks
[12:19:17] <abcminiuser> Damnit, 6.1 release still isn't up
[12:19:20] <abcminiuser> Darn US
[12:19:29] <DrLuke> ah I found it, it was pretty hidden
[12:19:34] <DrLuke> should have a big red flashy button
[12:21:31] <specing> < abcminiuser> They make a new one every few months when they realise the old one sucks
[12:21:34] <specing> silly ATMEL
[12:21:42] <abcminiuser> Indeed
[12:21:51] <abcminiuser> We do chips, not web
[12:22:52] <Tom_itx> they should have it on the front page with a big 'EASY' button
[12:23:03] <Tom_itx> (tm)
[12:23:39] <twnqx> abcminiuser: i managed to revive one of the stk600s with avr studio 4
[12:23:56] <twnqx> as soon as i do the mandatory as5.1/as6 update it's bricked again :(
[12:23:59] <abcminiuser> Awesome!
[12:24:02] <abcminiuser> Less so
[12:24:04] <abcminiuser> Hrm
[12:24:37] <twnqx> i guess the fact that i run windows inside a VM might contribute
[12:24:48] <abcminiuser> Oh, yes, probably
[12:24:50] <twnqx> because the board seems to disconnect in the middle of the upgrade
[12:25:04] <twnqx> and i have to manually add it to the VM
[12:25:13] <abcminiuser> If they changed the protocol to the new DATA/DATA/EVENT system it will break under VirtualBox
[12:25:15] <twnqx> it's ike xilinx' jtag programmer... have to add it three times
[12:25:27] <abcminiuser> Since VirtualBox only emulates two endpoints per USB device, for some crazy reason
[12:25:36] <twnqx> :o
[12:25:46] <twnqx> meh i don't want a physical crapos box :(
[12:27:01] <twnqx> i also see the other bricked stk600 disconnect with AS4
[12:27:09] <twnqx> so it might be related
[12:27:29] <twnqx> hm, might borrow a pc from my parents for testing
[12:28:06] <OndraSter> :)
[12:28:06] <OndraSter> with a special "ARDUINO ATMEGA" button
[12:28:06] <OndraSter> which takes them to mega328
[12:28:17] <twnqx> would AS run on win98?
[12:28:26] <twnqx> i should have some laptop with that somewhere :P
[12:30:02] <OndraSter> doubt it :P
[12:30:38] <OndraSter> everything requires NT kernel
[13:53:37] <TechIsCool> alright dumb question anyone know where the spec sheet for what I need on my adc power input? I have never needed analog before
[13:56:08] <twnqx> ...
[13:56:09] <tzanger> what do you mean?
[13:56:15] <RikusW> AVcc ?
[13:56:22] <TechIsCool> yah
[13:56:24] <RikusW> 100nF cap + 10uH coil
[13:56:29] <twnqx> avcc would be documented right in the adc section of your chip
[13:56:30] <RikusW> I used 39uH
[13:56:38] <tzanger> AVCC should just be a quiet verson of VCC (if you don't know what to do, put a 100 ohm resistor from VCC to AVCC)
[13:56:42] <TechIsCool> also aref?
[13:56:59] <RikusW> there is an internal reference
[13:57:04] <twnqx> whatever you want, including nothing bu t a cap
[13:57:10] <tzanger> aref is the "100%" value for the ADC. you typically connect it to avcc or some convenient reference LESS THAN AVCC (2.048V, 1.024V, etc.)
[14:00:12] <TechIsCool> I would assume I would be fine with normal internal voltage reference or is there a reason to do external.
[14:05:59] <RikusW> internal is fine
[14:09:18] <TechIsCool> RikusW: Thanks
[14:34:34] <RikusW> TechIsCool: a cap on Aref will stabilize the reference
[14:35:12] <RikusW> TechIsCool: just have a look at the datasheet ADC blockdiagram
[14:35:42] <TechIsCool> I have I gave it read through and I think the only thing I was missing was the inductor and cap combo for the avcc
[14:36:25] <RikusW> cap on Aref wouldn't hurt either 100nF
[14:36:41] <TechIsCool> on both a and b?
[14:36:45] <TechIsCool> xmega no mega
[14:37:24] <RikusW> Internal reference voltages of nominally 2.56V or AVCC are provided On-chip. The voltage refer-ence may be externally decoupled at the AREF pin by a capacitor for better noise performance.
[14:37:39] <TechIsCool> alright
[14:37:41] <RikusW> which AVR are you using ?
[14:37:51] <TechIsCool> 32u4a
[14:37:52] <RikusW> (above was from m32u4 ds)
[14:37:59] <RikusW> xmega ?
[14:38:08] <TechIsCool> yes
[14:39:00] <TechIsCool> I can't find the word decouple in the datasheet
[14:39:06] <RikusW> 32a4u ?
[14:39:15] <RikusW> I used mega32u4..
[14:39:19] <TechIsCool> yup sorry said it backwards
[14:39:29] <TechIsCool> its the Xmega 32a4u
[14:40:32] <RikusW> seems xm is wired differently to m32u4
[14:40:52] <TechIsCool> I guess it has it built in then most likely
[14:40:55] <RikusW> on mega mux output goes to the Aref pin
[14:41:20] <RikusW> on xm Aref goes to mux input
[14:48:23] <OndraSter_> TechIsCool, ey
[14:48:26] <OndraSter_> what's the Q?
[14:48:49] <TechIsCool> OndraSter_: if you need to decouple the aref in the xmega
[14:49:10] <OndraSter_> well
[14:49:14] <OndraSter_> unless you are using it with external reference
[14:49:23] <OndraSter_> if you are using internal reference then it does not matter if it is or not
[14:49:28] <OndraSter_> (actually it does, because you might use it as a digital IO)
[14:49:50] <TechIsCool> hmm what about digital
[14:50:22] <OndraSter_> what is your Aref source?
[14:50:22] <OndraSter_> internal?
[14:50:22] <OndraSter_> external?
[14:50:49] <TechIsCool> I was going to use internal I guess. Al I am reading is a light sensor but don't need major accuracy
[14:50:54] <OndraSter_> there is no Aref then
[14:51:04] <OndraSter_> there is internal reference
[14:51:10] <OndraSter_> which is decoupled internally
[14:51:15] <TechIsCool> That's what I thought
[14:51:36] <TechIsCool> RikusW: Had metioned that on the mega you should decouple the aref even with internal
[14:52:11] <OndraSter_> well
[14:52:21] <OndraSter_> since here Aref is muxed with a digital IO
[14:52:23] <OndraSter_> then you do not
[14:52:27] <OndraSter_> there is no separate reference
[14:52:42] <TechIsCool> alright
[14:54:05] <OndraSter_> check the ADC AppNote
[14:54:07] <OndraSter_> there is one
[14:54:10] <OndraSter_> or maybe more
[14:54:13] <OndraSter_> ADC or Analog or somethign
[14:54:35] <TechIsCool> will do
[14:54:49] <OndraSter_> or was I just imagining it..
[14:55:00] <OndraSter_> there is one for recommended board layout or decoupling for sure
[14:55:17] <OndraSter_> I just use whatever uH inductor for AVCC input
[14:55:27] <OndraSter_> the rest is regular only cap filtered
[14:56:02] <TechIsCool> What uH should I use 10,39 something else
[14:56:06] <OndraSter_> well
[14:56:17] <OndraSter_> I remember using something like 47 - 100uH
[14:56:21] <OndraSter_> check the appnotes
[14:56:24] <OndraSter_> it is all there
[14:56:30] <TechIsCool> will do
[16:23:48] <xelion> tzanger: you there?
[16:48:14] <tzanger> xelion: yes
[17:40:55] <langoliers> h
[17:41:17] <Dan39> i
[21:26:18] <Lt_Lemming> does anyone know of a Quad N MOSFET array with decent power handling? 15w per channel +
[21:29:58] <langoliers> its alive !
[21:29:59] <langoliers> :)
[21:30:24] <langoliers> RGB led falshing^^
[21:40:08] <theBear> i never even heard of one
[21:41:08] <theBear> but i do know that these days if i want high voltage switching fets i go to my pile of 'dead' downlight/general purpose 'electronic transformers' and steal a nice big to3p or to220 maybe, and if i want high power low voltage fets, i look for a dead mobo to salvage from
[21:46:52] <Lt_Lemming> theBear, this is for the TUCLAD
[21:47:14] <langoliers> Lt_Lemming<= N-mosfet for what?
[21:47:33] <theBear> the whatson ?
[21:47:36] <langoliers> 15 sounds like a TO-220 to me, grab an irfz2x ?
[21:47:49] <Lt_Lemming> switching LED arrays at 30KHz
[21:47:58] <langoliers> volts?
[21:48:08] <langoliers> current?
[21:48:13] <Lt_Lemming> 24V plus
[21:48:23] <langoliers> the fet will not dissipate 15W i think
[21:48:24] <theBear> hmm, that's fast
[21:48:25] <Lt_Lemming> .5A
[21:48:50] <langoliers> Lt_Lemming<= irf7455 can do 30V and 12A peak
[21:48:55] <theBear> you'd hope not, you picked poorly if you spending any % of time in linear mode at that kinda speed/use
[21:49:17] <Lt_Lemming> langoliers, in a multiple pack though?
[21:49:23] <langoliers> there are dual ch ones too, no quads
[21:49:30] <Lt_Lemming> yeah
[21:49:39] <langoliers> irf.com has some so-8 with double N in it
[21:49:43] <Lt_Lemming> it's just a wish basically
[21:50:00] <langoliers> irf7313 maybe, search for it
[21:50:05] <theBear> i heard diving into shallow water can turn a regular into a quad <badjoke><grin>
[21:50:44] <langoliers> hm, this RGB led does not mix colors well
[21:50:54] <Lt_Lemming> langoliers, just concerned with those about the power handling
[21:51:16] <langoliers> Lt_Lemming<= no idea what you are doing :)
[21:51:18] <theBear> which reminds me, anyone got access to a q35/bearlake based board, pref. intel board/bios/dmi, ideally dq35jo
[21:51:58] <langoliers> Lt_Lemming<= mosfet has i^R losses, with 8 milliohms, and proper drive they do not dissipate much
[21:53:20] <langoliers> so the cheap RGB led is not for color mixing ;<
[21:56:00] <theBear> even the expensive one isn't... back when i did 'prof. lighting' for a job, you'd find that things with either rgb or rgbw or discrete combinations of various colour leds would be either end-user or tech/calibration pre-adjusted for 'full white' and this was usually maybe 5-15% down on 2 or 3 channels
[21:56:19] <Lt_Lemming> yeah langoliers, but the current and voltage on these, at high freq means they will spend a fair bit of time in transition
[21:57:07] <theBear> 30k isn't that fast for a modern switching fet, they really shouldn't spend any appreciable % of their on time in linear mode
[21:58:26] <theBear> also it'd screw with brightnesses and avg vs peak bright etc, especially if you consider that to make something switch that slowly, whatever you are doing wrong is likely not reliable in a critical timing situation
[21:58:30] <langoliers> Lt_Lemming<= by proper drive i mean use proper drive. gate source acts like a 1nf capacitor.
[21:58:43] <theBear> often smaller, and 1nf aint that big
[21:58:46] <langoliers> 50ns rise/fall time or less
[21:59:04] <theBear> grr, we got a mathbot here ?
[21:59:56] <theBear> ns = 1,000,000/th of a second ? cos at 50ns it would take you 1.5 seconds just to switch them on that many times, letalone light an led and turn off again
[22:00:17] <langoliers> 1ns = 1e-9 s
[22:00:42] <theBear> oh, so err, surely you can get faster than that
[22:01:06] <theBear> modern ram with billions of little junctions can do 3 full cycles in that time
[22:01:34] <langoliers> period of 30kHz squarewave is 33.333us
[22:01:42] <langoliers> compare this to the switching times
[22:02:09] <theBear> yeah, that's what i did, just starting the maths at the other end... i don't like it
[22:02:19] <theBear> then again, the %'s work out ok
[22:02:25] <langoliers> we take 100ns switch time, and get 0.3% in the linear region
[22:02:33] <theBear> and way better than yer average matrix'd display
[22:03:30] <langoliers> the least you should use is transistor driving the gate to get 100-200mA peak current
[22:04:03] <Lt_Lemming> langoliers, actually using an LED driver chip to switch them
[22:04:36] <langoliers> and the led driver chip drivers the mosfets ?
[22:04:53] <Lt_Lemming> yes
[22:05:45] <Lt_Lemming> it's a low side driver, so will be driving the gates to Vled through a pullup, then grounding that using the chip.
[22:06:16] <langoliers> then i believe you will consult the manufacturer datasheet
[22:08:29] <Lt_Lemming> the driver can only handle 30mA
[22:09:11] <langoliers> bad driver then
[22:09:31] <langoliers> is it microchip or maxim ?
[22:09:35] <Lt_Lemming> TI
[22:09:45] <langoliers> ;/
[22:09:51] <Lt_Lemming> it's a 24 channel PWM driver
[22:09:55] <Lt_Lemming> 12 bits per channel
[22:10:22] <langoliers> then maybe they meant it to be used with bs170
[22:10:31] <langoliers> that has maximum 500mA current.
[22:10:33] <Lt_Lemming> bs170?
[22:11:00] <langoliers> it is asmall, fast mosfet, switches on off 10/10ns
[22:11:11] <Lt_Lemming> yeah
[22:11:22] <Lt_Lemming> I'm already using a SOT23 FET
[22:11:26] <Lt_Lemming> trying to cut down part count
[22:39:19] <langoliers> Lt_Lemming<= use less leds ;)
[22:39:27] <Lt_Lemming> NEIN!
[22:39:43] <langoliers> or don't use that ugly ic
[22:40:22] <Lt_Lemming> if you can suggest a better one with that many or more channels, I am all ears
[22:40:28] <langoliers> the atmega can drive 20-40mA peak too for small die mosfet drive
[22:41:00] <langoliers> though more than 200mA on the input line is not advised
[22:41:45] <langoliers> this equals to 5-20 channels depending on your taste
[22:42:25] <Lt_Lemming> langoliers, sure, but that doesn't give me 24 PWM channels
[22:42:32] <Lt_Lemming> and I need 72 of them total
[22:42:49] <Lt_Lemming> http://www.youtube.com/watch?v=JUOOCtB2OEw
[22:44:53] <langoliers> hah, then fet drivers are needed
[22:45:06] <Lt_Lemming> sigh
[22:45:10] <Lt_Lemming> trying to avoid that
[22:45:14] <Lt_Lemming> if at all possible
[22:45:52] <langoliers> no
[22:46:02] <langoliers> part count will be high.
[22:46:11] <langoliers> you will not get less parts
[22:46:26] <Tom_itx> there are led array drivers
[22:46:36] <langoliers> Tom_itx<= yeah he is using one.
[22:46:38] <langoliers> ;>
[22:46:52] <Tom_itx> k, i didn't read all the scrollback
[22:56:24] <langoliers> 62 led color changes per minute with 1000ms delay is fine for internal 8MHz calibrated RC oscillator precision?
[22:56:40] <langoliers> 3.33%
[22:58:15] <bsdfox\> langoliers, yeah internal RC oscillator sucks on most of the chips
[22:58:34] <langoliers> for led flashing it will do
[22:58:43] <langoliers> and many other things
[23:00:47] <bsdfox\> yeah but it's not suitable for time keeping or precision timing purposes
[23:03:04] <langoliers> hm, definitely, 62 ticks per minute :)
[23:03:20] <langoliers> i need an xtal for a simple timer
[23:04:00] <langoliers> i have read that some ics have 32768Hz quartz osc integrated
[23:04:23] <langoliers> for this purpose
[23:30:03] * MrTrick_ glares at MHVavrtools
[23:31:09] <MrTrick> Is anyone here using them? I run the ./build.sh script, and it hangs on compiling gmp
[23:36:07] <langoliers> never heard of it MrTrick
[23:36:17] <MrTrick> hmm, okay.
[23:36:27] <langoliers> avr-gcc for me
[23:36:41] <langoliers> make all
[23:37:15] * MrTrick has been using atmelstudio on windows
[23:38:11] <langoliers> .sh runs on win ?
[23:41:21] <theBear> probly in cygwin or similar
[23:41:40] <theBear> ie. a real shell built/implemented for windows
[23:41:48] <langoliers> ok, use linux then
[23:42:37] <langoliers> i have it working at the moment too.
[23:44:09] <theBear> huh ? what build.sh script ?
[23:44:22] <theBear> oh, mhvavrtools eh ? what's that do
[23:44:47] <langoliers> no, linux, avr-gcc and linker and objcopy, just make and make burn and code is compiled, burned
[23:45:19] <langoliers> make && make burn
[23:45:21] <MrTrick> yeah, a few have recommended I try mhvlib (a C/C++ avr standard library)
[23:45:23] <langoliers> simple enough ?
[23:45:53] <MrTrick> mhvlib recommend you use the mhvavrtools package, which is not building for me.
[23:46:34] <langoliers> who does c++ on microcontrollers?
[23:50:05] <langoliers> OndraSter_<= electron mobility is faster than holes
[23:50:17] <langoliers> also N-fets have lower RDS_on
[23:51:02] <langoliers> reason why (ordinary) NPN transistors are fasterthan PNP
[23:51:20] <langoliers> ofc there are gigahertz and faster bw PNP devices now
[23:54:16] <theBear> these days everyone and their mums ! arduino and by roll on effect every new stupid redundant lib out there is c++ it seems :)
[23:54:35] <langoliers> oh okey
[23:54:59] <langoliers> will be nice to run a js on a micro
[23:55:35] <langoliers> or some vb thing that requires a 3MB dll
[23:56:30] <langoliers> i know numberless useful ways to use that much space
[23:56:57] <theBear> heh
[23:57:35] <langoliers> xmegas started the flash storage boost already
[23:57:54] <langoliers> 16-32k is small to them
[23:58:05] * Casper wants a new sd card
[23:58:39] <Casper> if I had money, it would be like a 32G 600x :D
[23:58:46] <Casper> or faster
[23:58:51] <theBear> ooooh don't talk to me about flash ! you have no idea the insane amount of time i spent messing around with that mobo recently trying to identify/confirm/iron out its various bios/boot quirks
[23:59:41] <theBear> for the moment i've conceded... gotta hit enter a few times to get from post -> boot start, various things don't work, slightly scrambled dmi/oem strings somehow/somewhere, but at least it's fast and rock solid
[23:59:44] <Casper> theBear: oh you'Re alive! hi!
[23:59:56] <theBear> don't say flash tho, already i'm thinking thru it all again