#avr | Logs for 2012-02-09

Back
[00:18:46] <Landon> if I have the following, the microcontroller is as good as unwakeable, right? cli followed by sleep
[00:23:09] <Kevin`> I think so, for normal situations
[00:23:12] <Kevin`> why would you do that though?
[00:24:08] <Landon> well I have a timer counting down and when it's done, I want to switch states to display a failure on the LCD
[00:24:21] <Landon> but I don't need anything after that, so I just cli and it'll return to the main loop which has sleep
[00:24:29] <Landon> ... except it keeps executing the last state
[00:27:48] <Landon> I guess putting it into an idle state wouldn't be so bad, since the only possible interrupts after I disable the timer are from the keypad
[00:30:28] <Kevin`> Landon: the default sleep mode keeps timers running. although the interrupt shouldn't trigger
[00:30:38] <Kevin`> (because you disabled interrupts, otherwise it would)
[00:31:09] <Landon> yeah, I also disabled the timer after it counts down
[00:32:40] <Landon> not a huge deal, just that it seemed more humane to put it into a coma than doing an idle loop forevermore :P
[00:37:30] <Kevin`> coma should work
[00:37:54] <Kevin`> pick a nice sleep mode where all the oscillators and blocks are off
[00:41:29] <ziph> Stick a latch on the board that keeps it in reset. ;)
[00:46:31] <Landon> ziph: now that's just cruel
[00:46:52] <Landon> do IO pins have a defined state when reset is being held?
[00:47:13] <ziph> Yes, weak pulled high I think.
[00:47:28] <ziph> Check the datasheet though if it matters.
[00:47:45] <Landon> heh no
[00:47:51] <Landon> personal project, an idle loop hardly matters
[00:50:22] <Landon> I do think I've reached the limit for feasibility of using purely assembly though, heh
[00:50:33] <Landon> too bad there's not an HLA compiler for avr or something :P
[00:52:28] <Kevin`> there's this 'c' thing, that makes your programs sane
[00:52:51] <Landon> ;)
[00:52:56] <Landon> yeah
[00:53:23] <Landon> I was trying to get a decent size project through in assembly and see how it translates into C
[00:54:02] <Landon> I tried starting off with C initially, but I didn't have much idea of how it translated to what I knew
[00:59:15] <ziph> You can have it annotate the assembler with the source lines.
[00:59:51] <Landon> really? I was wondering if it could do something like that
[01:00:13] <ziph> It's an option to objdump.
[01:00:57] <Kevin`> make sure to use the optimization option you want when having it do that
[01:01:45] <ziph> To make it harder to understand?
[01:03:08] <CapnKernel> !seen edboogie2011
[01:03:09] <tobbor> edboogie2011 was last seen in #avr on Dec 22 09:58 2011
[01:19:32] <Kevin`> ziph: I personally think the optimized code is easier to understand, actually. but I did say DESIRED level ;p
[01:20:51] <ziph> When you're just starting the reordering and hoisting will confuse you though.
[03:39:49] <_abc_> Does anyone know of a general purpose communications library whch bridges mcu(s) and hosts (pc), especially serial oriented?
[03:44:19] <dekroning_> good morning guys
[04:09:51] <ziph> _abc_: LUFA? :)
[04:10:53] <_abc_> no, linbus, modbus and their ilk
[04:55:19] <_abc_> http://code.google.com/p/bamo128/ anyone here using this? Is it nice?
[04:57:07] <OndraSter> looks hawt
[05:07:00] <Sgt_Lemming> home now, </flop>
[05:10:49] <Steffann> Welcome home
[05:24:54] <RikusW> rue_shop: are you around ?
[05:27:08] <OndraSter> wh00p wh00p
[05:27:09] <OndraSter> The comments for your order are: This is the shipment notification of your order. We have shipped your order via Hong Kong DHL.We'll inform you the tracking number as soon as we get it.
[05:27:09] <OndraSter> Regards
[05:27:09] <OndraSter> ITead Studio
[05:27:29] <Steffann> :)
[05:29:20] * RikusW did a dW dump now to have a closer look at flow control
[05:29:41] <RikusW> its amazingly simple to do the dump :)
[05:31:00] * amee2k . o O ( open toilet, pull down pants, sit down, .... )
[05:31:33] <RikusW> a data dump =-O
[05:31:40] <amee2k> >_>
[05:31:59] <amee2k> what kind of emoticon is =-O anyway
[05:32:09] <RikusW> surprise ?
[05:32:14] <amee2k> oh
[05:32:38] <RikusW> and >_> ?
[05:32:46] <RikusW> eyes popping out ?
[05:32:54] <RikusW> or looking to the right ?
[05:33:02] <amee2k> lol
[05:33:05] <amee2k> -_-
[05:33:08] <RikusW> err left...
[05:33:27] <RikusW> -_- == see nothing say nothing ?
[05:34:24] <amee2k> ^_^
[05:35:25] <RikusW> lifted eyebrows ?
[05:35:35] <amee2k> 0.0
[05:41:45] <OndraSter> I can do
[05:41:50] <OndraSter> -_^
[05:42:06] <RikusW> how about <_> or >_< ?
[05:43:03] <RikusW> or try being a flipflop ? ;)
[05:43:10] <OndraSter> >_< is retarded
[05:43:11] <amee2k> :\
[05:43:12] <amee2k> :|
[05:43:14] <amee2k> :/
[05:43:16] <amee2k> :-
[05:43:17] <amee2k> :\
[05:43:18] <OndraSter> <3
[05:43:24] <amee2k> \o/
[05:43:48] <RikusW> -_^ ^_- -_^ ^_- -_^ ^_- -_^ ^_-
[05:43:50] <amee2k> i usually use >_< as the last step before performing facepalm
[06:12:03] <ElMonkey> does anyone happen to have a makefile rigged to produce human readable assembly as one target?
[06:17:31] <amee2k> avr-objdump --disassemble doesn't cut it?
[06:18:04] <Bushman> ave
[06:18:50] <ElMonkey> amee2k, thanks, i didnt know about that
[06:19:13] <amee2k> its the most readable i've seen in one line anyway
[06:32:27] <_abc_> does anyone know why avg-gcc error output is not parsed right by typing :make in vi(m)? I get an empty screen after that instead of the error list and/or success. It's something about the error dump format.
[06:32:35] <_abc_> RikusW: hehe
[06:40:25] <ElMonkey> something weird is happening again
[06:41:24] <ElMonkey> my ISR only has about 60 instructions, according to the disassembly
[06:41:30] <ElMonkey> yet it seems to take a lot more time
[06:41:44] <RikusW> loops ?
[06:44:34] <ElMonkey> http://pastebin.com/zWPk51ky
[06:44:38] <ElMonkey> no loops that i can see
[06:46:01] <ElMonkey> admittedly I dont get the call instruction at CE
[06:50:10] <RikusW> push / pop lds / sts take more than 1 clock
[06:50:15] <RikusW> check the datasheet
[06:50:30] <RikusW> branches too
[06:50:32] <OndraSter> dealing with RAM takes more than 1 cycle
[06:50:49] <RikusW> 2 afaik
[06:51:06] <ElMonkey> well i can't run the code at 25kHz on an avr running at 16MHz
[06:51:13] <ElMonkey> which seems a little excessive
[06:51:21] <ElMonkey> as there should be 640 clock cycles for that to execute
[06:51:42] * RikusW want to do a 156kbps soft uart....
[06:51:45] <ElMonkey> which i just cant match to the 60 or so instructions
[06:51:47] <RikusW> at 16MHz...
[06:52:16] <RikusW> the interrupt itself take 10 clocks or so overhead
[06:52:40] <ElMonkey> that i understand
[06:52:57] <ElMonkey> but i'm looking at 10 clocks per instruction in that code
[06:53:09] <ElMonkey> if something isnt messed up again
[06:54:18] <ElMonkey> the fuses look alright
[06:54:29] <ElMonkey> eg, noo CLKDIV8 happening
[06:54:48] <ElMonkey> and the timer fires at the right times for being setup at 16MHz, too
[06:56:17] <ElMonkey> this is especially weird because same code can run on an 8MHz AVR no problem at 16kHz
[06:56:27] <ElMonkey> so it should be able to do 32k on this thing
[06:56:55] <RikusW> whats the call 0 doing ?!
[06:57:04] <RikusW> that seems WRONG
[06:57:05] <ElMonkey> nfi
[06:59:01] <ElMonkey> oh weird
[06:59:16] <ElMonkey> its gone in the .elf
[06:59:22] <ElMonkey> its a proper call there
[06:59:52] <ElMonkey> i guess it was a stub in the .o
[07:00:34] <ElMonkey> hmm, but that thing has a loop
[07:00:40] <ElMonkey> i wonder where that comes from...
[07:01:39] <ElMonkey> could it be that an "x % 625" is taking ages on a 16bit int?
[07:05:45] <RikusW> yes
[07:09:34] <dekroning> anyone know a cheap AVR chip that can handle simple 10mbit ethernet connectivity? Microchip has these cheap MCu's for doing this, however mplabx and their documentation sucks so much
[07:13:31] <OndraSter> integrated ethernet?
[07:13:39] <OndraSter> or ethernet via SPI and external chip
[07:13:49] <OndraSter> like ENC28J60 :)
[07:13:52] <GeorgeJ> dekroning: I believe some XMega's have MMI's but not PHY interfaces. You'd probably be better off using an enc28j60.
[07:15:09] <Tom_itx> icky but true
[07:16:23] <dekroning> OndraSter: yeah for example I currently have the PIC18F67J60
[07:16:58] <cyanide> CapnKernel, you there?
[07:17:46] <OndraSter> Tom_itx, since you are selling those programmers, I presume you had to do some talk with govt to get license or w/e to call it, right?
[07:18:05] <ziph> A licence to call it?
[07:18:17] <OndraSter> to license to sell it
[07:18:21] <OndraSter> you know
[07:18:25] <OndraSter> paying taxes
[07:18:30] <ziph> What country are you in?
[07:19:04] <OndraSter> CZE
[07:19:18] <OndraSter> the only country where they are saving money on police and army :P
[07:19:25] <OndraSter> and giving more and more taxes for small businessmen
[07:19:43] <OndraSter> it is cheaper to run your business in, let's say, france
[07:19:48] <OndraSter> to register it there
[07:19:49] <OndraSter> the company
[07:19:52] <OndraSter> and pay taxes there
[07:20:04] <ziph> Yeah, Tom is in the US and the laws are going to be very different.
[07:20:17] <ziph> But there are usually small business development places that will help you.
[07:21:41] <ziph> With electronics there's laws related to ROHS, EMC and various EC directives.
[07:21:57] <OndraSter> well yes
[07:22:06] <OndraSter> that's about the manufacturing process
[07:22:12] <OndraSter> I am more interested in knowing the taxes and such
[07:22:16] <OndraSter> how it works in USA
[07:22:18] <OndraSter> compared to here
[07:23:27] <ziph> Tax in the US is terrible.
[07:23:45] <ziph> You have sales tax in most states that must be charged if the sale is to someone within your state.
[07:24:19] <ziph> You have to file a tax return in every state you do work in or hold investments in; buy a municipal bond in some state and you now have to file a return for that state too.
[07:24:41] <ziph> And you also have to do federal tax returns.
[07:25:22] <ziph> There's loads of business related taxes in each state, too.
[07:25:39] <Jagged> and local taxes and licenses, too
[07:25:40] <OndraSter> uh
[07:25:49] <Jagged> it's pretty silly
[07:25:51] <ziph> And real gems like an "Unincorporated Tax" which is specifically levied against small business in some states.
[07:25:55] <OndraSter> I think we should start a new country
[07:25:57] <OndraSter> "Logicistan"
[07:26:03] <OndraSter> based on logic, rather laws
[07:26:15] <ziph> Australia is good that way.
[07:26:26] <ziph> No requirement to register a business unless you're operating under a trading name.
[07:26:31] <OndraSter> hmm
[07:26:33] <OndraSter> sounds good
[07:26:36] <ziph> A single federal return even for small business owners.
[07:26:54] <ziph> No payroll or any other kind of business related tax until you have a payroll in excees of $1,000,000.
[07:27:14] <ziph> You can fail to do tax returns for 10 years and the tax department won't bother you.
[07:27:38] <ziph> Fines and interest payments are incredibly rare and are often reimbursed anyhow.
[07:27:58] <OndraSter> o_O
[07:27:59] <OndraSter> O_o
[07:28:13] <OndraSter> I think I have uncrossed australia from "move to" list :)
[07:28:59] <ziph> And as far as selling electronics goes you just self certify which at most is a cheap test (with no sign off) from a lab.
[07:29:16] <ziph> For unintentional radiators that is; selling a radio would require more paperwork.
[07:30:49] <ziph> If your sales don't exceed $75,000 a year you don't even have to charge the nation wide flat 10% goods and services tax.
[07:31:52] <ziph> They're looking at changing it so that a large proportion of people don't even have to file tax returns.
[07:32:01] <OndraSter> you are from AUS?
[07:32:05] <ziph> Yeah.
[07:32:11] <OndraSter> yay
[07:32:17] <OndraSter> I think I know where to go now
[07:32:18] <OndraSter> lol
[07:32:23] <ziph> :)
[07:33:08] <ziph> Canada is probably another sane place for business, with the advantage of an FTA with the nice big fat US market.
[07:36:56] <ziph> FTA's tend to simplify electronics sales because they often include provisions to allow any electronics meeting the legal requirements of one country to be sold and used in the other with zero paperwork.
[07:55:05] <_abc_> ziph: A lot of Japanese electronics get validated to CSA instead of FCC and UL for that reason
[07:56:05] <ziph> CSA?
[07:56:56] <_abc_> Canadian FCC equivalent
[07:57:41] <_abc_> http://en.wikipedia.org/wiki/CSA_International
[07:57:46] <_abc_> aka UL/CSA
[07:58:06] <_abc_> http://www.nbsc.com/certifications_UL_CSA.aspx
[07:58:45] <_abc_> I know FAR more devices certified to CSA than to UL, when sold primarily outside USA
[07:59:59] <_abc_> In general, I find CSA standards to be higher than UL for what I need to deal with (not much)
[08:00:10] <_abc_> Higher as in higher quality/better defined imho
[08:01:09] <ziph> Yeah, I've only had to worry about EMC.
[08:01:33] <_abc_> EMC is a separate can of worms
[08:01:38] <ziph> Yeap.
[08:01:48] <ziph> CSA doesn't include it at all?
[08:01:49] <_abc_> You need to claim CE mark or FCC part 15 class A or B compliance
[08:02:22] <ziph> Is there a scheme for Canada?
[08:11:47] <OndraSter> hmm I just found out
[08:11:50] <OndraSter> Uzebox is overclocked
[08:11:54] <OndraSter> 28.6MHz :)
[08:11:58] <OndraSter> works appearantly fine
[08:12:02] <OndraSter> for 20MHz specced atmega
[08:22:49] <SianaGearz> depends on voltage.
[08:23:03] <SianaGearz> 40MHz is just about barely possible at 5V as far as i remember.
[08:27:09] <SianaGearz> if they're running 5V and 28Mhz, it's easily OK.
[08:28:13] <OndraSter> wow
[08:28:15] <OndraSter> 40MHz
[08:28:19] <OndraSter> on regular 20MHz mega?
[08:33:38] <SianaGearz> OndraSter: just about barely, not really recommended :P
[08:33:47] <OndraSter> :D
[08:34:38] <amee2k> thats a stiff bit of overclocking
[08:55:37] <_abc_> from the nomenclature p.o.v. atmega8 323 161 etc are avr8s and atmega16 164 328 etc are avr4s ?
[08:57:05] <rue_mohr> SianaGearz, do they get hot?
[09:02:39] <SianaGearz> rue_mohr: no, shouldn't happen, the clock limits aren't thermal in nature.
[09:16:08] <rue_mohr> iirc I had to downclock a m32 cause it was drawing too much power at 16Mhz for my small battery robot
[09:17:03] <OndraSter> hehe
[09:17:20] <OndraSter> I want to make small remote wireless temperature measuring stations
[09:17:29] <ElMonkey> man i hadnt realized how difficult motion control is
[09:17:32] <OndraSter> thinking whether to use one 3.7V 18650 battery or simply small coin cell
[09:17:36] <OndraSter> the longer it runs on the battery, the better
[09:17:47] <OndraSter> the CPU will be in idle state and measure like once a 10 seconds or so
[09:17:49] <nevdull> rue_mohr: i can believe it. the AVR datasheets usually have an active supply current vs frequency graph near the back
[09:17:50] <rue_mohr> ElMonkey, what you making?
[09:17:53] <ElMonkey> only having 40kHz granularity for pulsing sucks
[09:17:54] <OndraSter> and send it through NRF24L01 to the main station
[09:18:08] <ElMonkey> rue_mohr, attempting to put CNC control on a mill
[09:18:11] <OndraSter> using internal 125kHz RC (attiny13a)
[09:18:32] <rue_mohr> stepper or dc?
[09:18:43] <ElMonkey> steppers
[09:18:57] <rue_mohr> interested in a linear interpolation library?
[09:19:01] <ElMonkey> sure
[09:19:09] <rue_mohr> can I find it now :)
[09:19:12] <rue_mohr> !assist code
[09:19:15] <ElMonkey> hehe
[09:19:16] <rue_mohr> awe
[09:19:21] <rue_mohr> thought I fixed that
[09:19:22] <rue_mohr> !time
[09:19:24] <rue_mohr> !time
[09:19:25] <rue_mohr> damn
[09:19:33] <CapnKernel> !seen toboor
[09:19:38] <CapnKernel> !seen tobbor
[09:19:57] <rue_mohr> apparently restarting every 24 hours dons't work
[09:20:05] <rue_mohr> !time
[09:20:06] <tobbor> My watch says its 07:16 Thu Feb 09 2012
[09:20:10] <rue_mohr> !assist code
[09:20:11] <tobbor> Possibly http://eds.dyndns.org/~ircjunk/code
[09:20:24] <OndraSter> 4o4
[09:20:57] <rue_mohr> void SimotaniouslyLinearlyInterpolateMultiAxis(axies_t * this) {
[09:20:59] <rue_mohr> found it
[09:21:06] <rue_mohr> http://eds.dyndns.org/~ircjunk/programming/c/stepmotion/
[09:21:19] <ElMonkey> does it do speed ramps?
[09:21:43] <rue_mohr> no, it calls on your code to do the step and the delay
[09:21:57] <rue_mohr> it just organizes who steps
[09:22:28] <rue_mohr> it sets up all the steps, then calls a 'go' their all callbacks so you can use them however you want
[09:22:58] <ElMonkey> i think i know what you mean :)
[09:23:01] <rue_mohr> I think I used the step to build the step info, and applied it and did the delay on 'go'
[09:23:13] <rue_mohr> it looks like everything is there
[09:23:34] <rue_mohr> test~ programs have main()
[09:23:49] <ElMonkey> the steps are equally spaced as per your output, though?
[09:23:51] <ElMonkey> eg, no ramp?
[09:24:04] <rue_mohr> look at test3.c
[09:24:16] <rue_mohr> your delay would have to go in motSync()
[09:24:29] <rue_mohr> you have to organize your own delay
[09:24:53] <rue_mohr> I dont think I have a library for acceleration profiles
[09:25:44] <ElMonkey> hmm
[09:25:59] <ElMonkey> well, thanks for the pointer, i'll look through what you done :)
[09:26:41] <rue_mohr> http://eds.dyndns.org/~ircjunk/robots/arm4/p1010986.jpg
[09:26:48] <rue_mohr> it was used to control that robot
[09:26:56] <ElMonkey> it seems doubtful that there is enough CPU time to do speed ramping at 10s of kHz
[09:27:32] <rue_mohr> oh, its written as pc code tho, I'd not suggest it for avr without mods
[09:27:57] <rue_mohr> its heavy on memory and pointers
[09:28:20] <ElMonkey> ah yea
[09:28:35] <charolastra> hi, what could be the reason why a fresh batch of atmega32s won't answer to the programmer? i have simple circuit which works fine with chips i already programmed but when switching the chip to another from the same patch (but it sat on the shelf for some months) and the chip doesn't get recognized by the programmer (even tried another programmer)
[09:28:35] <ElMonkey> i could do it easily if i had floating point and more everything :)
[09:34:33] <ElMonkey> speaking of which, anyone know of cheap avr32 boards?
[09:35:10] <ElMonkey> just need enough i/o pins, doesnt have to be much else on th eboard
[09:51:23] <OndraSter> ElMonkey, is AVR32 worth starting with?
[09:51:46] <OndraSter> .. asking just from curiosity, I am heading towards ARM for higher speeds and higher IO etc requests myself
[09:56:02] <ElMonkey> OndraSter, i am not sure
[09:56:24] <ElMonkey> ARM tends to have a lot of crap on chip and needs tons more initialization etc
[09:56:38] <ElMonkey> also, more picky about supply voltage and such
[09:57:10] <ElMonkey> plus, i dont have a programmer for ARM
[09:57:16] <OndraSter> wiggler :)
[09:57:23] <OndraSter> I am not sure about prices of the AVR32 family
[09:57:28] <ElMonkey> but i have the dragon, which should work just fine for AVR32
[09:58:20] <OndraSter> Dragon is good, except it is slooooooooow
[09:59:44] <ElMonkey> only arm7 stuff i ever done was 5 years ago for uni
[09:59:53] <ElMonkey> and that was just a simple project
[10:00:10] <ElMonkey> just a few lines of code plus an open source RTOS
[10:15:15] <inflex> how slow is slow with the dragon?
[10:15:40] <inflex> seriously, I hear about it all the time - but I wonder if a lot of it is just people repeating what other people have said... ? Takes me about 2 seconds per K to programme my stuff
[10:15:57] <inflex> so, I suppose if you have 32K, yeah, it's a slow flashing
[10:18:00] <asteve> hmm, is a minute that slow?
[10:18:28] <asteve> you've really loaded the uC if you're using all 32k :)
[10:25:26] <OndraSter> half kilo program took like 3 seconds to upload to mega32
[10:25:38] <OndraSter> for me
[10:25:59] <OndraSter> maybe one could rise the JTAG speed
[10:35:38] <amee2k> hmm... if it isn't a thermal limitation, what is the limiting factor behind the clock speed on 8 bit avrs?
[10:36:23] <asteve> definitely thermal
[10:36:35] <amee2k> someone earlier said it wasn't thermal
[10:36:58] <amee2k> and my m88 at 20MHz isn't even getting warm from what i can tell
[10:37:28] <asteve> let me rephrase that, there is definitely a thermal limitation; it may not be reached at the current speed
[10:37:53] <asteve> you're writing memory, the slower you go the less likelihood of errors?
[10:38:12] <amee2k> well, yeah. but what is the limitation behind that?
[10:45:24] <ElMonkey> more heat, more leakage current
[10:45:27] <ElMonkey> less reliable switching
[10:45:51] <ElMonkey> dunno what the intrinsic gate delays of these things are
[10:55:26] <OndraSter> they should ask Intel how to do 3D transistors lol
[10:55:34] <OndraSter> AVR on 100MHz.... *fap*
[10:58:28] <amee2k> that would be quite hot
[10:58:55] <amee2k> sometimes things aren't complicated but they need to happen fast
[10:59:19] <amee2k> having to use an overkill MCU or FPGA just for the clock speed is, well, overkill :P
[10:59:34] <OndraSter> even FPGA with AVR "emulator" can be faster
[10:59:36] <OndraSter> than real AVR :(
[11:00:10] <amee2k> FPGA MCUs are kinda neat because you get to pick what peripherals you want
[11:00:44] <ElMonkey> they could probably get into the GHz range just by a process shrink :)
[11:00:59] <OndraSter> do you know what process are they using?
[11:01:01] <ElMonkey> though then it'd be useless to just attach loose wires to the chips as we do :=
[11:01:03] <OndraSter> like 130nm would be my guess
[11:01:09] <OndraSter> haha
[11:01:13] <OndraSter> they could add features
[11:01:14] <OndraSter> ethernets
[11:01:19] <OndraSter> everything!
[11:01:30] <ElMonkey> i just want faster bit banging :)
[11:01:34] <OndraSter> hehe
[11:01:39] <amee2k> i've only seen very few MCU + PLC/FPGA combos, i.e. MCU with no peripherals, but you get an on-die fpga to pick whatever peripherals you want for your design
[11:01:53] <OndraSter> some ARMs have that
[11:02:02] <amee2k> yeah
[11:02:16] <amee2k> i strongly wonder why it isn't more common though
[11:02:28] <ElMonkey> because vhdl is a right pain in the ass
[11:03:08] <amee2k> the chip designers would need to come up with peripheral designs anyway, so they might just ship the peripherals as a VHDL library
[11:03:29] <ElMonkey> as bitstreams more likely
[11:03:36] <ElMonkey> dunno
[11:03:44] <ElMonkey> its probably not very cost effective for them
[11:03:49] <amee2k> so you have like a script where you can select what peripherals you want and how many of them and it'll just link the right stuff together and compile it
[11:04:59] <amee2k> i'd argue quite the contrary. they could use like 2-3 different designs that cover the same application range as say the entire mega does now with a few dozen devices
[11:05:29] <amee2k> only difference besides flash and ram sizes would be the number of uncommitted gates to implement peripherals
[11:06:07] <amee2k> no more "aww this one would just fit if only i had a third uart :/"
[11:06:50] <OndraSter> haha
[11:06:51] <OndraSter> they have now USI
[11:06:56] <OndraSter> or UARTs that can work as SPI
[11:07:02] <OndraSter> and supply 1 SPI + 3 UARTs
[11:07:05] <OndraSter> on higher atmegas
[11:07:09] <OndraSter> (1280 and 2560 I think)
[11:07:40] <amee2k> and if you need a minor variation on some existing peripheral block you can just modify it, like single timer with 8 OCRx registers and assorted waveform generators for massive pwming
[11:08:37] <amee2k> or i could simply put a quadrature decoder in fpga on mine and lower CPU load by like 150% >_<
[11:08:52] <nevdull> and in some avrs you can run the USART in SPI mode (master only tho)
[11:09:19] <amee2k> ...
[11:09:25] <amee2k> it was an example, dude
[11:10:00] <amee2k> also, the USI on attinys is a wet fart imo
[11:10:11] <OndraSter> haha wet fart
[11:10:40] <amee2k> what.
[11:23:53] <amee2k> "i'm looking for a really good detective story to read over the holidays" asks the customer in the book store. "then i'd recommend this one" says the shop assistant, "you'll have to read all the way to the last page to find out that it was the buttler who killed them all"
[11:23:57] <amee2k> >_<
[11:24:19] <OndraSter> lol
[11:57:48] <OndraSter> so, I am learning to be aussie
[11:57:52] <OndraSter> playing as Sniper in TF2 lol
[11:58:01] <OndraSter> he's aussie
[11:58:17] <Jan-> hidelly ho
[11:58:28] <OndraSter> hey
[11:59:57] * Jan- offers OndraSter a little cake
[12:00:03] <Jan-> have a cake, OndraSter
[12:00:52] <OndraSter> yeeee
[12:00:53] <OndraSter> thanks
[12:01:03] <Jan-> you sound like Gir from Invader Zim
[12:01:10] <OndraSter> haha
[12:03:58] <Jan-> YEEEEEE!
[12:04:03] <Jan-> I'm running!
[12:04:09] <Jan-> I'M RUNNING!
[12:04:17] <OndraSter> :)
[12:04:24] <OndraSter> what is the progress, do you have blinkie
[12:04:25] <OndraSter> ?
[12:04:34] <Jan-> ya ya :)
[12:04:40] <OndraSter> cool
[12:04:45] <OndraSter> I will have hopefuly blinkie soon too
[12:04:52] <OndraSter> except... 32x96 blinkies :D
[12:06:03] <OndraSter> *SNEEZE*
[12:06:13] <Jan-> cripes.
[12:06:19] <Jan-> well I have 192 blinkines I want to drive all at once
[12:06:21] <Jan-> in a big array
[12:06:23] <OndraSter> :)
[12:06:25] <Jan-> but I think we need a big FET for that
[12:06:37] <OndraSter> 16x12?
[12:07:07] <OndraSter> my setup is quite simple, let me draw it
[12:07:52] <Jan-> It's a strobe light
[12:07:55] <Jan-> made out of LEDs
[12:08:03] <OndraSter> oh
[12:08:07] <OndraSter> PWM to drive them?
[12:08:11] <Jan-> the final thing will be rgb, but we have a big led array that's OK for proof of concept
[12:08:15] <OndraSter> and all light/shut at once?
[12:08:16] <OndraSter> or separate
[12:08:25] <Jan-> actually no, it's for use on video cameras so we don't want to use any strobing
[12:09:32] <Jan-> it would eventually be nice to control the brightness
[12:09:35] <Jan-> but I'm not sure how best to do that
[12:09:41] <OndraSter> PWM
[12:09:52] <OndraSter> with opamp and capacitor
[12:09:54] <Jan-> sure, but as I say, we don't want to use any sort of strobing or pulse modulation
[12:09:56] <OndraSter> to make it analog value probably
[12:10:04] <OndraSter> well that opamp + PWM will (should) fix that
[12:10:37] <Jan-> the idea is to control exactly which video frames get illuminated
[12:10:45] <Jan-> I'm not sure if I have any D to A available
[12:11:04] <OndraSter> DACs are not available on megas
[12:11:20] <OndraSter> that's why I suggested PWM with some output electronics
[12:11:25] <OndraSter> to drive the FET(s)
[12:11:45] <Jan-> hrms
[12:11:52] <Jan-> what a PITA
[12:12:42] <OndraSter> our school papers have DAC with PWM
[12:12:45] <OndraSter> let me draw it
[12:13:08] <Jan-> it's OK, I can't see pics anyway
[12:13:11] <OndraSter> oh
[12:13:13] <OndraSter> how come?
[12:13:14] <Jan-> My bigger concern is how we drive this big LED array
[12:13:17] <Jan-> it's only 6 watts worth
[12:13:20] <OndraSter> FETs <3
[12:13:28] <Jan-> sure, but aren't they weird when analog driven
[12:13:53] <OndraSter> analog driven = get to stage where the FET isn't fully conductive
[12:13:58] <OndraSter> so it limits current
[12:14:12] <Jan-> It may be that I have to use a proper D to A chip then
[12:14:19] <OndraSter> that is possibility too
[12:14:21] <Jan-> as we need to be able to control the output very quickly, over one video frame
[12:14:23] <OndraSter> serial DACs are cheap
[12:15:33] <Jan-> the idea is that we can then do things like flickering fluorescent tubes
[12:15:37] <Jan-> when some pulses are brighter
[12:16:16] <Steffann> Anyone here knows if USB allows it to open a device twice.. by using different endpoints?
[12:22:58] <ElMonkey> Jan-, due to the nonlinearity of LEDs high frequency PWM is the only way
[12:50:28] <Tom_itx> xmega have dac
[12:52:29] <OndraSter> yeah
[12:52:35] <OndraSter> but she has mega168 I think :)
[12:56:31] <OndraSter> hmm
[13:00:16] <Tom_itx> is true
[13:04:34] <Jan-> seems like an odd choice
[13:04:44] <Jan-> adc but no dac
[13:04:45] <OndraSter> Jan-, you have 168 right?
[13:04:56] <Jan-> I think so
[13:06:56] <OndraSter> there was some dude from STM like three months ago at our school one day, brought some STM32 development boards... but I was in different class :(
[13:09:26] <Jan-> Perhaps we can't have dimmable lights then
[13:09:32] <Jan-> which is kind of a shame
[13:09:59] <Jan-> maybe we can have some sort of primitive arrangement where you'd get 0, 25, 50 or 100%
[13:10:40] <Jan-> presumably a parallel DAC has very short setup time, anyway
[13:10:42] <Tom_itx> x10
[13:10:51] <Jan-> 10 what?
[13:11:11] <Tom_itx> x-10
[13:11:27] <ElMonkey> Jan, what is the problem with PWM?
[13:12:10] <Jan-> it's for use with video cameras
[13:12:16] <Jan-> so you get odd artifacts with any sort of strobing
[13:12:39] <ElMonkey> not when its at high enough frequency :)
[13:12:47] <Jan-> It'd have to be pretty high.
[13:13:12] <Jan-> Worst case scenario is a 4000 by 3000 pixel frame at 120 frames per second
[13:13:13] <ElMonkey> unless you do very fast pans with very small highlights
[13:13:30] <ElMonkey> should be no problem
[13:13:37] <Jan-> It's a problem, believe me
[13:13:38] <ElMonkey> depending on what your output stage should handle
[13:13:56] <ElMonkey> LED dimming is a pain either way
[13:13:56] <Jan-> Many cameras have rolling shutters, and read the lines of pixels out sequentially
[13:14:02] <ElMonkey> color temperature changes
[13:14:08] <Jan-> if you strobe it, you end up with a venetian blind effect
[13:14:09] <ElMonkey> if you dont PWM it
[13:14:40] <ElMonkey> 3000*120 lines is just 360k :)
[13:14:50] <Jan-> well we're thinking of probably a white emitting version, and possibly also an RGB version
[13:14:56] <ElMonkey> so if you run a 100k PWM, i doubt you can see anything
[13:15:04] <Jan-> 100KHz?
[13:15:06] <ElMonkey> yea
[13:15:33] <Jan-> that's just over one cycle per line
[13:15:54] <Jan-> believe me, I have done the math on this
[13:15:56] <Jan-> we need DC light
[13:16:08] <ElMonkey> then dont do it with LEDs :)
[13:16:30] <Jan-> Nothing else switches fast enough, with the possible exception of xenon strobes but then they're very brief.
[13:17:57] <ElMonkey> so whats keeping you from switching the LEDs at 200 or 300 kHz?
[13:18:32] <Jan-> http://en.wikipedia.org/wiki/Rolling_shutter
[13:18:36] <Jan-> read that and get back to me
[13:19:04] <ElMonkey> i know what rolling shutter is
[13:19:44] <Jan-> almost no matter how fast you go, you end up having individual lines, or even groups of pixels, more illuminated than others.
[13:20:11] <ElMonkey> unless your exposure time is really really short, it'll be fine
[13:20:24] <ElMonkey> and if you're looking to simulate flickering, well, bugger, thats strobing
[13:20:32] <Jan-> no, it won't, this problem is actually observed in existing lighting units when they're used with certain cameras.
[13:20:46] <Jan-> It is not OK. I have done the math. I have planned this. This does actually respond to a real world situation. OK?
[13:20:52] <ElMonkey> how fast do they PWM the LEDs?
[13:21:14] <Jan-> The real problem is not so much LEDs but xenon flash tubes, which are much, much faster than LEDs.
[13:21:19] <ElMonkey> relax, man, i'm just trying to learn about your situation
[13:21:58] <Jan-> We have had reports that you can actually see the xenon tube trigger pulse as a little blue blip at the start of the line where the light comes on, then you can see the light build up in a fraction of a fraction of a second.
[13:22:11] <Jan-> Then it's constant brightness for a while, many dozens of lines
[13:22:19] <Jan-> then you see the capacitor that's feeding the tube start to fail empty
[13:22:25] <Jan-> and it fades out more gradually.
[13:22:53] <Jan-> We're talking about camera systems that can actually map the output curve of a xenon flash lamp, even at normal frame rates. We really, really dare not PWM it.
[13:23:32] <Jan-> Even a 1920x1080 HD picture at 24fps is about fifty megapixels per second.
[13:23:43] <Jan-> Although the effective rate is always at least twice that.
[13:23:45] <ElMonkey> only solution i can see is to have the pwm drive a shift register so that not all LEDs strobe at the same time
[13:23:58] <Jan-> Or use a DAC and a big pass transistor and have actual DC light.
[13:24:47] <ElMonkey> all i know is that driving the LEDs at DC means you get color shift as you dim, as well as a fraction of light output compared to PWM at max current
[13:24:55] <Jan-> I guess really you could PWM it, but to really put yourself out of the trouble zone, you'd need to plan on a 4K frame at 120fps
[13:25:21] <Jan-> so if you can PWM the LEDs at about, er, 550MHz you might be OK
[13:25:27] <ElMonkey> Jan, as said, i guess you'd have to jerry-rig the array to create a phase delay
[13:25:38] <Jan-> Well, the RGB ones don't color shift much
[13:25:41] <Jan-> they color shift a bit with heat
[13:25:48] <Jan-> the white ones do shift.
[13:25:52] <ElMonkey> yea, RGB isn't that bad
[13:26:16] <ElMonkey> can you line scan the RGB matrix?
[13:26:29] <ElMonkey> er, the LED matrix
[13:27:07] <ElMonkey> then if you have 20 lines of LEDs, you can delay each by 1/20th of an effective PWM cycle
[13:27:36] <ElMonkey> which means you can probably go a lot slower effectively
[13:27:56] <ElMonkey> but thats not easy :/
[13:28:22] <ElMonkey> yet the only effective solition i can think of, if you're worried about blips in the image
[13:29:43] <ElMonkey> at high power, LED's don't switch on instantly either, i imagine its the same ballpark as gas discharge lamps
[13:29:45] <amee2k> mmh, pwm on topic again?
[13:29:57] <amee2k> ElMonkey: who says they don't?
[13:30:10] <Jan-> leds switch very fast
[13:30:16] <Jan-> possibly as fast as xenon to be honest, they are super quick
[13:30:22] <ElMonkey> amee2k, just because you're driving the same kind of current
[13:30:28] <Jan-> you can get data down an led at megabits per second
[13:30:29] <amee2k> LEDs go up well into the MHz region
[13:30:31] <ElMonkey> i mean, the LED is fast, but your power transistor wont be :)
[13:30:43] <Jan-> The idea is that if we drive it DC, we don't need to switch fast
[13:30:44] <amee2k> depends on the transistors ;)
[13:30:48] <amee2k> and the transistor driver
[13:30:55] <Jan-> so long as we switch during the shutter period it doesn't matter
[13:31:00] <Jan-> we just need to switch variably.
[13:31:03] <amee2k> Jan-: i just jumped into the conversation, what are you making if i may ask?
[13:31:30] <amee2k> the camera-friendly LED lamp?
[13:31:30] <ElMonkey> i guess you just need a huge heatsink on the driving transistor, then
[13:31:31] <Jan-> A light for doing strobes, photo flashes, gunfire and other brief-period effects on rolling shutter cameras.
[13:31:43] <amee2k> ah, ok
[13:31:46] <Jan-> it's basically just a flashing light
[13:31:53] <Jan-> but it needs adjustable phase and timing
[13:31:54] <amee2k> now i remember
[13:32:01] <Jan-> so you can slide it into sync with the camera.
[13:32:59] <Jan-> the issue is that it'd be nice to have variable brightness
[13:33:00] <amee2k> how is DC driving going to help? with DC i take it you don't need any sync at all, no?
[13:33:02] <ElMonkey> i guess you only need to largely figure out the nonlinearities
[13:33:15] <Jan-> well, DC inasmuch as it's DC during the one frame period when it's on.
[13:33:19] <ElMonkey> or you can just stick a large-ish RC filter onto the PWM output :)
[13:33:29] <ElMonkey> that goes into the driver
[13:33:49] <Jan-> If you put a PWM into it, it'll happily paint stripes onto the frame as the camera scans out the image.
[13:33:50] <ElMonkey> then again it becomes hard to sync
[13:34:03] <amee2k> ElMonkey: any half decent FET will go into the milliohm range. i've switched 5A LED arrays for a LED strobe and had no heating whatsoever on a shitty IRF520
[13:34:04] <ElMonkey> so i guess if you do it with a low and high side driver, you can do it
[13:34:08] <Jan-> I thought an RC filter might work, depending how much delay it would have in it
[13:34:22] <ElMonkey> amee2k, yea, but you were switching
[13:34:26] <ElMonkey> not dimming without pwm
[13:34:35] <amee2k> yes, switching
[13:34:58] <amee2k> duty cycle was only ~2% so i could hugely exceed any current ratings without blowing out the leds
[13:35:14] <ElMonkey> Jan-, RC on low side for dimming, now filter on high side for rapid switching on genlock
[13:35:33] <ElMonkey> er, no filter on high side, of course
[13:35:52] <Jan-> Yeah, but if you have three flashes separated by one frame and you want bright-dim-bright...
[13:35:56] <amee2k> Jan-: hmm i could make a drawing of the LED strobe circuit i used. do you have someone to describe it to you?
[13:36:05] <Jan-> I want to be able to individually address any frame with any amount of light
[13:36:10] <amee2k> i'm not sure if i can adequately put it into words so it is descriptive :(
[13:36:12] <ElMonkey> you can still do that
[13:36:17] <Jan-> it's just that the amount of light isn't allowed to change during the exposure.
[13:36:25] <ElMonkey> your PWM at 10kHz or so should be fine
[13:36:37] <Jan-> Sure then you nee donly a very small C in the RC
[13:36:49] <ElMonkey> actually, i'm stupid
[13:36:55] <ElMonkey> you just need one transistor
[13:37:20] <ElMonkey> you can run the PWM at "normal" speeds, you just need to make sure to change duty cycle only on genlock
[13:37:53] <Jan-> sure
[13:38:03] <ElMonkey> well, that's it then
[13:38:10] <Jan-> so PWM output pin
[13:38:11] <Jan-> RC filter
[13:38:14] <Jan-> bigass transistor
[13:38:32] <Jan-> I'm always confused by transistors. They're all current based.
[13:38:39] <ElMonkey> FETs arent
[13:38:43] <Jan-> How do I turn a transistor half on? aaargh.
[13:38:59] <ElMonkey> Jan, thats why people switch them :)
[13:39:00] <OndraSter> check the datasheet for the Vgs voltage
[13:39:05] <OndraSter> but
[13:39:10] <OndraSter> you have to use DAC then :P
[13:39:12] <ElMonkey> much easier than dealing with the exponential curve in the transition region
[13:39:32] <Jan-> I think we have some IRFIZ24N fets
[13:39:38] <ElMonkey> OndraSter, PWM + RC is just a one-bit DAC :)
[13:39:44] <ElMonkey> more or less
[13:39:47] <Jan-> Vgs is +/- 20v
[13:40:17] <Jan-> that sounds like a pain too
[13:41:17] <Jan-> could someone here help me calculate the RC filter for that if we decided to do it?
[13:42:35] <amee2k> http://ompldr.org/vY3EzOA/led-strobe.png << i had very good results with that one. with the LED power rail ~10-15V higher than the forward voltage, the rise time was well under 1us
[13:42:51] <Jan-> amee2k: okies, I'll get Phil to have a look at it
[13:42:54] <ElMonkey> Jan-, i guess you want one with a time period as large as possible
[13:43:28] <ElMonkey> for 120 frames, about half or quarter of frame time
[13:43:41] <ElMonkey> and PWM as fast as possible to get little ripple only
[13:43:42] <Jan-> bit less maybe
[13:43:44] <amee2k> Jan-: what i used it for was a LED strobe that i synced to the tacho output of a computer fan, so when seen in the dark the fan wheel would appear to be standing still
[13:43:45] <Jan-> sure
[13:43:55] <Jan-> amee2k: I get the idea
[13:44:19] <Jan-> how many PWM outs does this chip have?
[13:44:21] * Jan- googles
[13:44:23] <ElMonkey> amee2k, though now the goal is to not have a fast rise time :)
[13:44:47] <ElMonkey> probably one or two timers at least
[13:44:54] <amee2k> ElMonkey: put a cap on the gate then and your switching time will go down the drain :P
[13:45:04] <Jan-> possibly need the timers for actually timing the on-period
[13:45:05] <ElMonkey> amee2k, hence the RC filter :)
[13:45:28] <ElMonkey> Jan-, i think most avr's have one RTC, and two more timers at least
[13:45:31] <ElMonkey> unless its a tiny
[13:45:32] <amee2k> also, from what i understand is if the pulses are synced to the shutter, the pulse width and rise time doesn't matter
[13:45:46] <ElMonkey> amee2k, still does due to line-scan effects
[13:45:51] <Jan-> as long as it rises and falls adequately fast that it can be switched in the off period.
[13:45:58] <Jan-> between that time it needs to be DC
[13:46:02] <amee2k> the CCD sensor or film will be a very good integrator
[13:46:10] <Jan-> no, it isn't.
[13:46:15] <Jan-> otherwise we'd just PWM it.
[13:46:29] <ElMonkey> Jan-, mind me asking who you're doing this for?
[13:46:31] <Jan-> many modern cameras use a rolling shutter.
[13:46:58] <Jan-> ElMonkey: My carnal-sin, live-in unmarried lover type person is in the film industry
[13:47:01] <Jan-> it's his project
[13:47:09] <amee2k> Jan-: well, yes. but as long as your pulse doesn't run into the shutter time it shouldn't matter, no?
[13:47:19] <Jan-> amee2k: I want variable brightness inside that time
[13:47:24] <Jan-> so I need a fast switching DAC
[13:47:29] <ElMonkey> i see :)
[13:47:30] <amee2k> then vary pulse length as well
[13:47:44] <Jan-> it may be easiest just to get a DAC of some kind
[13:47:52] <ElMonkey> Jan-, no it wont
[13:48:00] <amee2k> in theory, you can do it all with the strobe and one pulse per frame
[13:48:03] <ElMonkey> you still have the same problem of nonlinearity in the driver
[13:48:13] <amee2k> you need three controls for it, frequency, phase, and pulse length
[13:48:22] <Jan-> there's not much we can do about that ElMonkey
[13:48:31] <Jan-> other than maybe use a high bit depth and fix it in math
[13:48:45] <Jan-> amee2k: rather frequency, phase, and brightness.
[13:48:48] <ElMonkey> well you can measure it
[13:48:57] <ElMonkey> and just add a lookup table to your micro
[13:49:12] <Jan-> sure
[13:49:15] <amee2k> the driver i used has a constant current output. as long as the supply rails are high enough it'll deliver very square pulses down to the low microsecond region
[13:49:20] <Jan-> it's just that if we do that in 8 bit it may end up pretty clunky
[13:49:28] <amee2k> Jan-: pulse width would accomodate the brightness adjustments
[13:49:34] <ElMonkey> nah, 8 bit is fine
[13:49:38] <ElMonkey> since its exponential
[13:49:48] <Jan-> amee2k, it's (possibly) a rolling shutter camera, we need actual variable brightness DC light.
[13:49:48] <ElMonkey> matches the gamma nicely
[13:50:08] <Jan-> I have found 8 bit parallel DACs.
[13:50:13] <Jan-> Guess they could be programmed via a shift register
[13:50:22] <Jan-> maybe there are SPI ones
[13:50:26] <amee2k> i think my understanding of how the shutter works is reaching its limits now
[13:50:35] <ElMonkey> how many outputs do you need?
[13:50:49] <amee2k> 75HC595 comes to mind
[13:50:54] <amee2k> err 74HC
[13:51:02] <ElMonkey> i thought this was just for one strobe-ish light at a time
[13:51:43] <amee2k> or use a micro large enough so you can just output the 8 bits in parallel directly from the MCU
[13:51:44] <ElMonkey> either way, if you need more, you can just bit-bang a port from a timer interrupt
[13:51:51] <ElMonkey> yea, or that
[13:52:34] <amee2k> iirc mega16/32 have nicely arranged 8 bit ports that are convenient for parallel output
[13:53:30] <Jan-> Well it is one at a time
[13:53:43] <Jan-> but much as it's nice to go bright-dim-dim, it's also nice to go red-blue-blue :)
[13:53:43] <ElMonkey> for 120Hz, if you want 8 bit output resolution, which is fine IMO, you just need a 30kHz bit-banging interrupt for as many parallel outputs as you want
[13:54:07] <Jan-> I wonder if those parallel dacs have a chip select line
[13:54:13] <Jan-> then you could put them all on one "bus"
[13:54:18] <Jan-> (is that what a bus is?)
[13:54:21] <ElMonkey> really, i wouldnt bother with the DACs
[13:54:35] <amee2k> i'm with ElMonkey on this one
[13:54:35] <ElMonkey> they do the same thing internally anyway :)
[13:54:37] <Jan-> just PWM and RC it?
[13:54:41] <ElMonkey> yea
[13:54:44] <Jan-> okies
[13:54:52] <Jan-> let's make a single white one first though
[13:54:54] <amee2k> i'd /only/ PWM it
[13:54:55] <Jan-> with no variable brightness
[13:55:09] <Jan-> amee2k: that wouldn't work unless you can PWM at hundreds of megahertz.
[13:55:09] <Kevin`> Jan-: a dac may not be very appropriate for power control. it's probably more appropriate to use a buck style smps configuration to control current
[13:55:28] <Jan-> Kevin`: sure, but SMPS design is spawn of the devil.
[13:55:35] <Kevin`> lol
[13:55:36] <Jan-> I have no interest in making this even harder.
[13:55:43] <amee2k> maybe i'm getting wrong how this shutter thing works, but i think it will work
[13:55:45] <ElMonkey> Jan-, you worry to much, they can fix it in post :P
[13:56:00] <Jan-> amee2k: the way it works is that at some point toward the end of the exposure period, it reads all the pixels out sequentially.
[13:56:18] <Jan-> ElMonkey, the point of this is that strobe lights are something that are quite hard to fix in post.
[13:56:28] <Jan-> If you have a partially illuminated frame, you really can't fix that.
[13:56:35] <amee2k> but you have a period where the entire active area of the sensor is exposed at once, right?
[13:56:46] <Jan-> Depends on the timing amee2k - which is the exact problem.
[13:56:58] <Kevin`> Jan-: something really simple like pwm with an inductor+diode to maintain constant current would probably work quite nicely
[13:57:05] <amee2k> hmm i think i see the problem then
[13:57:07] <Jan-> if you PWM it you can potentially get "venetian blinds" in stripey lines of bright and dim
[13:57:17] <amee2k> because i made the implicit assumption that this would be the case :/
[13:57:33] <ElMonkey> Jan-, i know, i happen to have a friend working in fx/post, and bitches about this kind of thing all the time :)
[13:57:53] <Jan-> ElMonkey: your friend probably finds himself inching through video clips, flashing frames red/blue/blue or whatever to simulate police lights.
[13:58:02] <Jan-> And that's pretty unsatisfactory as you don't get proper lightsourcing.
[13:58:13] <amee2k> how about a hybrid approach... the current sink to drive the LEDs has separate inputs for brightness and an "enable" input for PWM?
[13:58:30] <amee2k> this way you could use a slow DAC that you set up once and then leave it alone
[13:58:35] <Jan-> amee2k we discussed that but it doesn't really help if you want the ability to address any frame you want at any brightness, which you really do.
[13:58:58] <amee2k> you need to change the brightness on a per-frame basis??
[13:59:02] * amee2k glares
[13:59:06] <Jan-> possibly
[13:59:24] <Jan-> the scenario I've been given is that some emergency vehicles have strobes on them that go red-blue-blue very fast
[13:59:35] <amee2k> well, it would still give you more time to change the brightness setting between pulses
[13:59:36] <ElMonkey> i wonder what the actual shutter angle is if rolling shutter is considered
[13:59:43] <ElMonkey> i know the RED is pretty bad
[13:59:51] <ElMonkey> but the alexa i never seen trouble with
[13:59:55] <amee2k> and since the DAC doesn't need to provide the sharp edges, you can use one that has like 1/10th the bandwidth or less
[13:59:59] <Jan-> plus we want to be able to do things like flickering fluorescent tubes
[14:00:08] <Jan-> so you need per frame brightness control
[14:00:26] <Jan-> ElMonkey: both red and alexa are rolling shutter and applicable to this
[14:00:26] <Kevin`> fortunately frames are pretty long
[14:00:38] <Jan-> alexa reads out very VERY fast and barely has a problem
[14:00:44] <Jan-> red is really quite slow
[14:00:59] <Jan-> but red is a pile of crap
[14:01:33] <_abc_> Jan-: I thought you hate microcontrollers. What are you doing on #avr ? :)
[14:01:36] <Jan-> OK so I guess the first thing to do is make the basic white, non variable one.
[14:01:50] <Jan-> To do this I need phase and frequency buttons
[14:01:53] <amee2k> once the PWM channel has turned off the DAC has half a frame time to slew to the new value
[14:01:54] <Kevin`> Jan-: feed the dac output into the feedback of a linear op-amp controlled current source and you'll get nice response for this
[14:01:54] <Jan-> so that's four buttons and the LED array to interface
[14:02:08] <Jan-> amee2k: sure
[14:02:15] <Kevin`> Jan-: that's simpler than it sounds, btw ;p
[14:02:18] <Jan-> that's one way the PWM + RC approach would work. you can have a very slow RC delay.
[14:02:39] <Jan-> (comparatively)
[14:02:41] <amee2k> no, i meant separate PWM and DAC channels
[14:02:48] <Jan-> it doesn't really help
[14:02:57] <Jan-> but it's something we'd considered
[14:03:29] <Jan-> one of the potential problems with this approach is that you are illuminating the scene with a longer burst of light than you'd get from a xenon flash tube, so the motion blur is longer than it should be.
[14:03:30] <amee2k> no need for filtering, and you'd get potentially nice sharp pulses at the desired current levels
[14:03:59] <Jan-> it's possible that we could actually have very short pulses, so long as they were at the part of the frame when it isn't being read off the sensor.
[14:04:06] <Jan-> So we might want extra high speed gating for that.
[14:04:22] <Kevin`> 30hz isn't exactly high speed
[14:04:30] <Jan-> I'm designing for up to 120
[14:04:35] <Kevin`> 120hz isn't exactly high speed
[14:04:53] <Jan-> Well considering this device is clocked at 20MHz
[14:05:32] <Kevin`> you have enough time to do things at a few thousand kiloherz pretty easily, from my experience
[14:05:34] <Jan-> so I guess you could have 80khz ish PWM with 8 bit resolution :)
[14:05:52] <Jan-> well
[14:06:00] <Jan-> 20000000/256 = 78215
[14:06:02] <Kevin`> erm, off by a bit there
[14:06:17] <Kevin`> but I wasn't talking about pwm, more along the lines of what amee2k suggested
[14:06:39] <Jan-> it might be nice to have sharp switching without worrying what the DAC was doing
[14:06:44] <Jan-> but only in specific situations
[14:08:13] <Kevin`> btw, this is for led lighting, right? otherwise the lag from the light itself is going to overshadow everything
[14:08:21] <Jan-> certainly
[14:08:32] <Jan-> although white LEDs do have some yellow light lag.
[14:08:54] <ElMonkey> phosphorous
[14:08:58] <ElMonkey> damn it
[14:09:13] <Jan-> when you turn a white LED on you get a burst of blue light, then the yellow component fades in
[14:09:17] <Jan-> then you get the reverse on shutdown
[14:09:39] <Jan-> this is one reason why RGB is interesting
[14:09:51] <Kevin`> Jan-: if you don't want that, get an led that uses seperate emitters for each frequency instead of phosphorous
[14:09:53] <Jan-> color leds switch really fast
[14:10:02] <ElMonkey> well if you do the thing as i suggested, all that should happen in the shutter-off period
[14:10:06] <Jan-> Well we want to offer both in the end
[14:10:27] <Jan-> no led has a very good white performance in terms of cinematography, but white LEDs are better than RGB clusters.
[14:10:44] <Jan-> but the clusters will switch faster, so it's a choice.
[14:11:05] <ElMonkey> huh, i thought the color index of RGB LEDs was much better
[14:11:29] <ElMonkey> certainly RGBA(amber) light sources have a pretty good CRI
[14:11:35] <Kevin`> you'd think someone would make leds that were tuned to the same frequencies your cameras are built to be sensitive too. it's not like they are even recording the entire spectrum to start with ;p
[14:11:36] <ElMonkey> better than xenon, iirc
[14:13:26] <Jan-> not a chance
[14:13:39] <Jan-> it's a big deal in the industry right now
[14:13:57] <Jan-> basically all LEDs are shit
[14:14:20] <Jan-> Arri made some which have three different types of white in them with active sensing and calibration, and they're sort of barely OK.
[14:14:39] <Jan-> the multi color clusters are just hopeless.
[14:15:11] <Jan-> http://www.screenlightandgrip.com/images/generators/LED_Comp_Sprectrum.jpg
[14:21:35] <Jan-> anyway we have a white LED array for tests.
[14:22:52] <Jan-> (and I don't even know how to drive that)
[14:31:37] <Steffanx> Stop saying "I don't know how…" or "I cant do…" Jan-
[14:32:01] <Jan-> well the simplest approach is one of thos "digital fet" things with the 5v logic level driver built in
[14:32:10] <Jan-> but that won't let me expand to variable brightness later on
[14:33:08] <mog> Steffanx, extra points for using ellipsis rather than . . .
[14:33:50] <Jan-> is that what he means by …
[14:34:04] <Steffanx> Get a proper client mog ?
[14:34:45] <mog> Steffanx, id rather my client not muck with what i type
[14:35:00] <Steffanx> I cant care less
[14:35:11] <mog> clearly
[14:35:52] <Steffanx> There are more important things on the world
[14:36:00] <Jan-> Cakes, for instance.
[14:36:03] <Jan-> They're critically important.
[14:36:06] <Steffanx> Exactly
[14:36:08] <mog> mmm cake
[14:36:14] * Jan- decides to go and make cake
[14:37:48] <amee2k> Jan-: why exactly is it important that the LEDs are actually off during the off-time?
[14:38:49] <amee2k> i mean
[14:39:19] <amee2k> in order not to flicker, it is only important that every part of the frame receives an even amount of light
[14:39:45] <amee2k> if you just ran the LEDs with DC without any PWM, that would accomplish the feat of having a flicker-free light source, no?
[14:45:30] <Jan-> Sure, but we want to be able to simulate photo flashes and gunfire and stuff
[14:45:37] <Jan-> that's the entire point
[14:47:44] <SianaGearz> that is a long conversation. wonder what's the topic... but can't find the beginning :P
[14:47:52] <Kevin`> Jan-: how do you plan to synchronize it with the camera shutter?
[14:48:17] <Jan-> It'll have buttons to trim the phase and frequency into sync
[14:48:27] <Jan-> some cameras do have sync outputs, so we might support that too
[14:48:32] <Jan-> but really this is addressed at the ones that don't
[14:49:28] <SianaGearz> oh a computer controlled light to make distant light effects on video shot?
[14:49:58] <SianaGearz> why is everyone suggesting PWM, make an R/2R DAC ;)
[14:52:58] <SianaGearz> just use a digital output port, wire it up with resistors halving voltage next each, and use that signal through a power amplifier.
[14:53:39] <amee2k> SianaGearz: the cameras this is targeting apparently have some type of shutter that produces distortion on sharp temporal contrast boundaries
[14:54:25] <amee2k> you get half-illuminated frames if you have a lighting transient in the middle of the shutter action
[14:54:27] <SianaGearz> that kind of asks for a lowpass after a DAC.
[14:54:46] <Jan-> sigh
[14:54:54] <Jan-> this is why I tire of explaining it :/
[14:55:09] <amee2k> SianaGearz: apparently the objective is to do fast lighting effects but synchronized to the camera action to avoid the shutter artifacts
[14:55:20] <SianaGearz> mhmm.
[14:55:25] <SianaGearz> i see.
[14:55:25] <amee2k> sort of a vertical sync for the scene to be filmed
[14:55:50] <SianaGearz> no lowpass. wait for the shutter to fully close, change brightness as rapidly as possible, and then wait.
[14:56:11] <Jan-> precisely
[14:56:26] * amee2k idly points out that he only summarized the previous conversation and has no actual part in the project
[14:56:59] <SianaGearz> still sounds like you want an R/2R DAC. maybe somewhat higher quality ones, i.e. ones used on GPU VGA ports.
[14:58:09] <amee2k> well, one thing i proposed earlier (but that was apparently rejected) was using a slower DAC for the brightness setting, and a fast enable input on the LED driver to sync the LEDs to the shutter action
[14:58:33] <Jan-> we need to be able to change brightness in the shutter closed period
[14:58:40] <Jan-> so it doesn't necessarily gain us much
[14:58:48] <Jan-> (though it might in some limited circumstances)
[14:58:50] <amee2k> this way the DAC would only need a bandwidth of a few hundred Hz up to the low kHz range, and you'd still get the sharp switching edges needed for proper sync
[14:59:25] <amee2k> because DAC slew rate basically doesn't matter as long as it is fast enough to reach the whole range in the shortest reasonable off-time
[14:59:33] <Jan-> yers
[14:59:42] <Jan-> but if it's capable of doing that we don't need to switch any faster
[15:00:05] <Jan-> although, as I say, if you wanted sub-frame-time illumunation that just didn't happen in the readout period, you might need even faster switching then.
[15:00:41] <amee2k> yes you do. if you use the DAC for everything, then the switching time will also depend on the slew rate
[15:00:56] <SianaGearz> it's funny that you're trying to make light effects work which you can't film on natural sources :P because rolling shutter would make a line out of them :P
[15:01:02] <Jan-> as long as it can go on to off in the dead time who cares
[15:01:04] <amee2k> and you'll need a massively oversized DAC to meet the bandwidth requirements this imposes
[15:01:34] <amee2k> see, i'll make an example with figures i pulled out of my afterburner just to illustrate the point, okay?
[15:02:29] <Jan-> mmhmm
[15:02:36] <amee2k> say, you have 100us on-time and 100us off-time. thats 5kHz which any PWM output will do happily with rise and fall times of <<1us
[15:03:02] <Jan-> mmhmm
[15:03:29] <amee2k> the DAC needs to be able to slew all the way in 100us now. that would ideally translate to 10kHz but you'll probably want slightly better to have headroom. i'd primarily select the DAC for the required slew rate
[15:04:22] <amee2k> if your DAC goes 0-5V then you'd have a slew rate of 50mV per microsecond, which is fairly slow from what i've seen, but i'm not an expert on DACs either
[15:05:09] <amee2k> now consider you're ONLY using the DAC to do the pulsing action. you want a rise and fall time of down to 1us and less
[15:05:42] <ElMonkey> amee2k, the goal is not to have the LEDs change state during a frame, because of rolling shutter
[15:06:06] <amee2k> so say 1us is sufficient, so the DAC needs to be able to slew all the way in 1us. your frequency requirement just jumped up to 1MHz
[15:07:23] <ElMonkey> my idea was to do this: http://en.wikipedia.org/wiki/1-bit_DAC
[15:07:30] <ElMonkey> with fast pwm
[15:07:47] <ElMonkey> but only change the output value during the blanking time of the shutter
[15:08:12] <amee2k> the slew rate now is 5V/us too which is quite a bit faster, you'd want to select a DAC that does at least 8-10V/us for this one
[15:09:12] <amee2k> ElMonkey: that would work, but only with the hybrid approach with the extra "enable" signal
[15:09:25] <ElMonkey> amee2k, why extra enable?
[15:09:40] <amee2k> otherwise you'd need too high of a frequency because the time constant of the low pass filter needs to be very short
[15:09:41] <ElMonkey> you just set a 0 duty cycle when you want it off
[15:09:53] <Jan-> it still needs to change inside one frame
[15:09:57] <Jan-> I don't see the difference
[15:10:08] <amee2k> 1MHz analog bandwidth will need something like 20+Mbps
[15:10:10] <ElMonkey> the LP filter needs just to be fast enough to respond during the blanking time
[15:10:16] <ElMonkey> which is a few ms at worst
[15:10:38] <amee2k> ElMonkey: only if you can disable the LED driver during the blanking time
[15:10:46] <amee2k> and not do the blanking with the DAC itself
[15:10:58] <ElMonkey> amee2k, well the PWM+RC = DAC
[15:11:12] <amee2k> square waves have infinite harmonics and infinite bandwidth
[15:11:13] <Jan-> as long as it can change state inside a frame it's fast enough
[15:11:25] <ElMonkey> if i oversample the PWM at say 100kHz, that gives plenty resolution to switch output during blanking time
[15:11:27] <Jan-> Personally I'd rather use a real DAC
[15:11:49] <amee2k> ElMonkey: but then your DAC won't be able to slew in 1us all the way anymore
[15:11:59] <ElMonkey> sure it will
[15:12:08] <amee2k> no it won't
[15:12:10] <Jan-> anyway there are six PWMs!
[15:12:12] <Jan-> that's a lot
[15:12:15] <Jan-> I didn't know
[15:12:18] <asteve> six pwm's!
[15:12:24] <asteve> pwms*
[15:12:40] <ElMonkey> if the RC has a time constant of say 1ms, it'll do pretty much full swing in 3ms
[15:12:41] <amee2k> your switching interval is 10us already. your low pass filter would need a time constant into the several 100 us to be effective
[15:12:59] <ElMonkey> yes, which is fine
[15:13:05] <amee2k> ElMonkey: for your DAC to generate a square wave you need a full swing in 1us
[15:13:18] <ElMonkey> eh?
[15:13:22] <Jan-> it doesn't need to generate a square wave
[15:13:29] <ElMonkey> the output of the DAC only changes once a frame
[15:13:30] <Jan-> it just needs to be able to go from 0 to 100% in say 1/120 of a second
[15:13:43] <amee2k> not if you have a separate enable pin on the driver to do the blanking action
[15:13:55] <amee2k> thats what i've been talking about for 20 minutes now
[15:14:04] <amee2k> and what i think you're assuming to be the case implicitly
[15:14:10] <ElMonkey> i think you're still talking about a switching driver
[15:14:13] <amee2k> which is why you don't get what i mean
[15:14:15] <Jan-> how fast can the pwm go?
[15:14:27] <ElMonkey> MHz range
[15:14:59] <amee2k> as fast as you can find a suitable transistor for
[15:15:05] <ElMonkey> you can toggle the output every clock cycle, essentially
[15:15:13] <Jan-> then I guess it's possible to filter it down to DC with reasonable minimum switching time
[15:15:35] <Kevin`> Jan-: you don't need to filter it.
[15:15:41] <Kevin`> pay attention to what he's saying :/
[15:15:48] <Jan-> We can't PWM the LEDs.
[15:16:12] <Kevin`> Jan-: use a linear regulator to control the power of the leds, and use pwm to turn the whole thing sharply on and off
[15:16:13] <Jan-> If you PWM the LEDs, you paint a nice little venetian blind onto the image.
[15:16:19] <Jan-> ....oh
[15:16:28] <Jan-> do I get enough fine control over the PWM to sync it up?
[15:16:59] <Kevin`> yes. you'll probably be fine doing it in software if you need to, even
[15:17:08] <Jan-> that was my intention
[15:17:17] <ElMonkey> you can pretty much set phase and freq arbitralily
[15:17:45] <Jan-> I basically need to set things up so that you can hold down a button and slide the frequency or phase around
[15:17:53] <amee2k> i shall now venture to switch my dinner over into my stomach \o/
[15:17:53] <Jan-> four buttons
[15:17:58] <Jan-> phase and frequency up and down
[15:30:52] <OndraSter> so, if I were to build something like this
[15:30:53] <OndraSter> http://midnightdesignsolutions.com/dds60/index.html
[15:31:00] <OndraSter> but wanted to digitally control output voltage
[15:31:13] <OndraSter> could I use some digital pot?
[15:31:21] <OndraSter> not sure how would it feel for 60MHz noise
[15:33:24] <_abc_> What is the fastest toggle speed on an output pin of an atmega8 etc?
[15:33:37] <OndraSter> clock/2
[15:33:45] <OndraSter> not sure about output waveform
[15:33:46] <Tom_itx> re abcminiuser
[15:33:54] <Kevin`> _abc_: ignoring the clock output, right?
[15:33:57] <_abc_> At 20Mhz xtal I assume the shortest sequence is someting like PORTx=value PORTx=~value etc
[15:34:06] <_abc_> Kevin`: yes, programmed bit banging speed
[15:34:11] <_abc_> I am not abcminiuser
[15:34:14] <_abc_> I am _abc_
[15:34:19] <_abc_> Very different :)
[15:34:20] <Jan-> same thing
[15:34:32] <Tom_itx> good i wasn't talking to you then huh?
[15:34:35] <_abc_> Jan-: abcminiuser is a genius who now works for Atmel I think
[15:34:43] <_abc_> I'm just the janitor here...
[15:35:01] <Kevin`> _abc_: for toggle, PINX=1 is probably faster in code
[15:35:06] <_abc_> Kevin`: so back to back in a flattened loop
[15:35:13] <_abc_> yes that's what I said?
[15:35:30] <Kevin`> you had two seperate instructions for set and clear
[15:35:32] <_abc_> You mean PORTx not PINx (inputs?)
[15:35:58] <Kevin`> I mean pinx. writing to pinx toggles each pin that has a bit set to one
[15:36:06] <_abc_> Hmm
[15:36:07] <Kevin`> at least on any semi-newish chip
[15:36:24] <_abc_> Not on what I asked (atmega8, 88, 168 etc)
[15:36:52] <_abc_> So anyway I can expect output change to be possible by toggling at 1/2 Fclk at the fastest
[15:37:06] <_abc_> So 5MHz out max I think
[15:37:15] <_abc_> Which is fast enough for what I need, I think
[15:37:34] <Kevin`> _abc_: a timer can run that fast too, and not use cpu time, of course
[15:37:46] <_abc_> I need it really from the cpu :)
[15:37:49] <amee2k> i've got way too many mushrooms :(
[15:37:55] <Kevin`> eat some
[15:38:00] <_abc_> Another option would be to program the SPI to output stuff very fast
[15:38:24] <_abc_> But I need more than one channel...
[15:38:25] <amee2k> Kevin`: well, thats the point. i already made enough to eat for two days and still have some left
[15:38:27] <OndraSter> SPI is 1/2 tops
[15:38:32] <OndraSter> 1/2Fclk
[15:38:47] <_abc_> Yes but that's twice as fast as the other one...
[15:38:49] <_abc_> *option
[15:39:13] <OndraSter> wait, why would dumping all 0s and 1s to PINx would make less than 1/2Fclk?
[15:39:16] * _abc_ notices there are very few 10MHz capable SPI parts, but it is easy to find 80MHz ones :/
[15:39:37] <_abc_> OndraSter: I think it's as fast
[15:39:50] <OndraSter> OUT takes 1 instruction cycle
[15:39:59] <OndraSter> that's 10MHz for 20MHz atmega
[15:40:12] <_abc_> Hmm
[15:40:24] <Kevin`> _abc_: you can run spi perhipherals at slower than their rated speed
[15:40:29] <Kevin`> it's a maximum
[15:40:36] <_abc_> yes but I want *fast* :)
[15:41:00] <OndraSter> LDI R16, 0xFF; LDI R17, 0; OUT PINA, R16; OUT PINA, R17; OUT PINA, R16;
[15:41:01] <OndraSter> etc
[15:41:16] <OndraSter> but
[15:41:20] <OndraSter> if you'd run to the end of the code
[15:41:26] <OndraSter> there would be few cycles delay
[15:41:39] <OndraSter> you could get away with 2 cycles
[15:41:50] <OndraSter> per 16382 :)
[15:42:18] <OndraSter> let it just overflow to 0000 address once it reaches the end of the flash
[15:42:25] <OndraSter> (16382 for 32kB device)
[15:43:39] <_abc_> Heh I only need a short stretch of tightly contolled bursting
[15:43:39] <theBear> that's a OLD SCHOO' trick
[15:43:51] <theBear> from the times of code being on some kind of rotating cylinder
[15:44:11] <_abc_> haha theBear drum memory ftw
[15:44:23] <OndraSter> haha drum memory
[15:44:46] <theBear> the 'trick' kinda seems a lot more intuitive in that kinda situation, but still a 'cool' trick in my eyes
[15:45:06] <OndraSter> oh
[15:45:09] <OndraSter> if you want to control the length
[15:45:51] <OndraSter> you might want to put only like to the last half of the flash this part, to the beginning some setup of timer interrupt... and when this timer interrupts, it would change the address where it would return after RETI :)
[15:46:11] <OndraSter> and wait for the start again
[15:57:53] <_abc_> theBear: I'll raise you some Mercury delay lines ...
[15:58:14] <theBear> oooh
[15:58:17] <theBear> err
[16:33:06] * Jan- rolls the chair over her foot
[16:33:09] <Jan-> *hop*
[16:33:11] <Jan-> *clutch(
[16:33:14] <Jan-> *wail*
[16:34:55] <OndraSter> cluch
[16:34:57] <OndraSter> clutch
[16:35:01] <OndraSter> driving car, Jan- ? :D
[16:35:19] <Jan-> no I was clutching my foot
[16:35:22] <OndraSter> ah
[16:35:22] <Jan-> which throbs :(
[16:37:49] <Jan-> what's an "odt" file
[16:38:34] <bram1> jan: open document text or something, you can view it with openoffice or libreoffice
[16:38:51] <Jan-> feh freetards
[16:40:46] * specing_ smacks Jan- for not being a "freetard"
[16:41:06] * Jan- pushes specing_ into the scorpion pit
[16:42:56] <amee2k> i think the other office software package from redmond has a patch for importing opendocument too
[16:43:22] <amee2k> at least they made a not very big deal out of it a few years ago
[16:44:12] <OndraSter> you can open and save and use odt
[16:44:16] <OndraSter> in office 2010 at least
[16:44:19] <OndraSter> 2007 probably too
[16:44:29] <OndraSter> because european union forced them (or whoever)
[16:44:37] <OndraSter> because DOCX was appearantly not opensource enough!
[16:45:21] <amee2k> in my experience, people who have a strong preference for either MS office or openoffice also tend to prefer its primary file format
[16:46:04] <amee2k> and only import and export to other formats if required
[16:46:07] <OndraSter> (I am huge MS fan :D)
[16:48:05] <ElMonkey> then there's the sane people, like me, who prefer to write in TeX
[16:49:07] <Jan-> I don't care as long as it can create a PDF file
[16:49:15] <amee2k> tex is pretty cool and i want to make a point of doing more with it
[16:49:31] <amee2k> but i still prever OOo for its WYSIWYG-ishness
[16:49:49] <Jan-> No piece of software can legitimately be called "ooh!"
[16:50:07] <amee2k> yes it can :P
[16:50:07] <OndraSter> yes
[16:50:12] <OndraSter> because it is already programming language!
[16:50:14] <OndraSter> well
[16:50:15] <amee2k> three Os are short for open office org
[16:50:16] <OndraSter> "programming"
[16:50:21] <Jan-> ffs
[16:50:28] <Jan-> at least "word" is descriptive
[16:50:38] <OndraSter> who is gonna port interpreter ooh or brainf*ck onto AVR? :)
[16:50:43] <amee2k> word is just a word
[16:50:48] <amee2k> and OOo is just an acronym :P
[16:51:27] <Jan-> and amee2k is a girls name :)
[16:51:27] <dirty_d> any of you familiar with twi on xmega?
[16:51:36] <dirty_d> having a strange problem
[16:51:43] <amee2k> and jan is still a dude's name :P
[16:51:47] <Jan-> quiet you
[16:52:03] <amee2k> also, i don't think "Writer" or "Draw" is any less descriptive than Word
[16:52:25] <Jan-> amee2k: For longer than I can remember....
[16:52:30] <Jan-> I've been looking for someone like you...
[16:52:33] <amee2k> with the considerable routine i have with Draw it is pretty much unbeatable for quick semi-graphical drafting for me
[16:52:34] <Jan-> ...with a head like yours...
[16:52:38] <Jan-> ...and a torso too...
[16:52:45] <OndraSter> I like my OneNote
[16:52:47] <OndraSter> for drawing
[16:52:48] <amee2k> o.O
[16:52:49] <Jan-> Birds sing, and YOU'RE GONNA PAY!
[16:52:51] <OndraSter> just pick the pen...
[16:52:54] * Jan- shoves amee2k into the scorpion pit
[16:52:56] <OndraSter> and DRAW DRAW DRAW
[16:53:05] * amee2k turns orange
[16:53:17] <Jan-> amee2k: you aren't an Invader Zim fan then
[16:53:26] <amee2k> is that edible?
[16:53:32] <Jan-> http://www.youtube.com/watch?v=T9t8ybxBB_0
[16:53:36] <amee2k> (by that, i usually mean No)
[16:54:05] <amee2k> never heard of that before
[16:54:52] <Jan-> it's awsum :)
[16:54:58] <Jan-> look for "the nightmare begins"
[16:55:01] <Jan-> it's the first episode
[16:55:29] <OndraSter> duh
[16:55:32] <OndraSter> wth is that :D
[16:55:42] <Jan-> http://www.youtube.com/watch?v=-S28LQYiJq0
[16:55:43] <OndraSter> let me tune Opera into tvtorrents
[16:55:45] <amee2k> OndraSter: well, for free-hand OOo it probably is not so hot but i usually use it for technical drawing / mixed text where it is a pretty good fit for me
[16:56:46] <amee2k> http://ompldr.org/vY21vNw/backplane2.png << stuff like that, for example
[16:57:21] <amee2k> http://ompldr.org/vY21vNg/backplane1.png
[16:58:17] <OndraSter> yay
[16:58:19] <OndraSter> what is it gonna be?
[16:58:49] <amee2k> part of some conceptual work for a dev board project of a friend of mine
[16:58:57] <OndraSter> ah
[16:59:03] <OndraSter> I thoguht about "SLOT" for AVR
[16:59:23] <dirty_d> how the hell do i lose arbitration when theyre only one master?
[16:59:47] <amee2k> dirty_d: you're transmitting while the addressed slave is trying to respond?
[17:00:17] <amee2k> think about an arduino, but with an ARM MCU, and with a backplane like a PC mainboard instead of the header rows on each side
[17:00:49] <OndraSter> hmm
[17:00:52] <OndraSter> and duplexing their IOs?
[17:01:01] <OndraSter> or like control command
[17:01:04] <OndraSter> selector of the slot
[17:01:10] <OndraSter> and the other devices would go into HiZ?
[17:01:37] <amee2k> the exact backplane design is still very conceptual right now, but the idea was to just break all MCU lines out on a parallel bus
[17:02:24] <Jan-> back...plane...
[17:02:25] <amee2k> so extension cards could pick out what they need. optionally with jumper configuration for e.g. which lines to use for interrupts and which to use for chip select with SPI cards
[17:02:45] <OndraSter> PnP? :D
[17:02:59] <OndraSter> I wanted to do arduino library for OneWire with PnP
[17:03:11] <amee2k> there is also an idea to have a "management card" in a special slot that has point-to-point connections to each card to allow for presence detect and dynamic configuration
[17:03:51] <amee2k> it probably won't be 100% PnP. at least not with the current MCU
[17:04:07] <amee2k> would take too many resources for very little gain
[17:05:03] <amee2k> but if we go with the "management card" infrastructure, the facilities for full PnP and automatic resource allocation would be there given appropriate extension card design to make use of it
[17:05:34] <Jan-> what are you building, amee2k/
[17:06:12] <amee2k> Jan-: its a microcontroller dev board
[17:06:17] <OndraSter> the thing is, if AVR was not harvard but JvN, you could simply provide small flash with the code to drive the thing on each board
[17:06:18] <amee2k> its not my project, really. i was just helping a friend out with some conceptual work
[17:07:03] <Jan-> I see
[17:07:05] <amee2k> i don't think that'll scale well considering the level of processing power
[17:07:06] <Jan-> anyway I have to go sleep
[17:07:11] <Jan-> I'm determined to get more sleep
[17:07:15] <Jan-> being tired at work is ass
[17:07:22] <dirty_d> ameek2 i dont think so
[17:07:23] <amee2k> the required software framework wouldn't make anywhere near effective use of the hardware
[17:07:36] <OndraSter> gn Jan-
[17:07:41] <Jan-> \nini all
[17:07:42] <amee2k> nighty :)
[17:08:22] <amee2k> also, common hardware in the MCU world is usually documented well enough so writing drivers shouldn't be much of an issue
[17:09:03] <amee2k> also, the only advantage that including drivers on the card would have is independence of the exact hardware type
[17:09:37] <amee2k> from my exp however, embedded hardware is usually chosen for specifc traits that make it lend itself to the application at hand
[17:10:09] <amee2k> so chances are a significant number of projects would not make use of the included driver anyway
[17:11:00] <amee2k> even provided a useful variety of sufficiently compatible hardware actually materializes
[17:14:17] <amee2k> the current hardware line-up is only marginally powerful than top- to mid-range atmegas. any features like that most certainly won't get included until we have higher end MCUs in the selection
[17:14:37] <amee2k> likely not before any usefully RTOS or uclinux capable hardware comes up
[17:14:52] <OndraSter> why we don't have x86 dev boards?
[17:14:56] <OndraSter> just grab 486 CPU
[17:15:02] <OndraSter> put there some external RAM
[17:15:09] <OndraSter> and add your own ICs :)
[17:15:14] <amee2k> because ARM sucks half the balls at half the price :P
[17:15:18] <OndraSter> :D
[17:16:02] <amee2k> i suppose an atom or comparable based MCU module board would be possible
[17:16:08] <OndraSter> yeah
[17:16:09] <amee2k> but i don't see it happening
[17:16:16] <OndraSter> now with raspberry pi...
[17:16:27] <OndraSter> hell, 486 CPU would be enough LOL
[17:16:40] <dirty_d> amee2k, see anything wrong? http://pastebin.com/duNcnKMn
[17:16:42] <OndraSter> 486 DX4 from AMD
[17:16:45] <OndraSter> 100MHz clock...
[17:17:12] <amee2k> at that point switching to an industry standard backplane bus like PCI/PCI-E would be more useful than a pile of broken out GPIOs imo
[17:17:37] <amee2k> especially since desktop class CPUs don't have any GPIOs to break out
[17:18:04] <OndraSter> yeah
[17:18:55] <amee2k> dirty_d: not off hand. but i2c doesn't specify any protocol details beyond framing and slave addressing so if you have a sequence error it is most likely in the main program
[17:19:25] <Tom_itx> can i install avrgcc from the ubuntu package manager?
[17:19:49] <amee2k> i used to use avrgcc from the repo on ubuntu when i was using ubuntu
[17:19:50] <OndraSter> btw, I can connect originally SMBus device to I2C bus on ATmega, if I downclock it to 100kHz, right?
[17:20:01] <dirty_d> amee2k, im using the same order of everything as a program i just wrote for a mega
[17:20:04] <dirty_d> and it worked perfectly
[17:20:07] <Valen> Tom_itx: i think the latest one has ll the bits in it you need
[17:20:31] <Tom_itx> all i really need is avrdude to test something
[17:20:36] <Tom_itx> but i may as well install it all
[17:20:38] <Tom_itx> libc etc
[17:20:46] <amee2k> avrdude is a separate package iirc
[17:20:47] <dirty_d> Tom_itx, it probably has it yea
[17:20:53] <amee2k> apt-cache search avrdude
[17:20:56] <Tom_itx> amee2k, yeah it is
[17:20:59] <Tom_itx> it's in the list
[17:21:09] <Tom_itx> what's avrprog?
[17:21:21] <amee2k> no idea
[17:21:24] <amee2k> never heard of it
[17:21:49] <Tom_itx> some little programmer
[17:21:53] <Tom_itx> parport it appears
[17:22:24] <Tom_itx> i need avr-libc right?
[17:22:35] <Tom_itx> probably not gdb
[17:23:16] <amee2k> the package should list all the dependencies it needs for basic operation
[17:23:33] <grummund> avrprog is also Atmel's attempt at a bootloader utility
[17:23:33] <Tom_itx> this is gcc-avr 1:4.3.4-1
[17:23:35] <amee2k> if it doesn't list avrlibc as "recommended" either, it won't touch it either way
[17:23:36] <Tom_itx> is that current?
[17:23:56] <amee2k> 4.3.5 on my mint box
[17:23:59] <Tom_itx> not much came up as 'recommended'
[17:24:07] <amee2k> seems current enough imo
[17:24:09] <Tom_itx> so i may not need that
[17:24:34] <amee2k> whats wrong with installing it anyway just to be sure?
[17:25:26] <Tom_itx> ok, we'll see what happens
[17:27:08] <Tom_itx> ok, do i need to do anything special with avrdude and USB?
[17:27:19] <Tom_itx> -p usb?
[17:27:29] <Tom_itx> err whatever switch it is...
[17:27:31] <amee2k> lemme check my makefile
[17:28:13] <amee2k> -p atmega88 -P usb -c avrispmkII -B 5
[17:28:33] <atom1> ok
[17:28:40] <amee2k> thats what i'm using. substitute your mcu type as appropriate. iirc there is a list of mcu type names on the man page
[17:28:43] <atom1> except avrispmkii may need to be different
[17:28:48] <atom1> it may need to be avrisp2
[17:29:03] <atom1> for PDI and TPI
[17:29:07] <amee2k> what programmer are you using? your own design?
[17:29:11] <atom1> mine
[17:29:20] <atom1> i just need to test the new firmware
[17:29:27] <amee2k> ah, okay
[17:29:39] <atom1> do you have one?
[17:30:11] <amee2k> i've only ever used it with my real avrisp2, and some noname usb isp board that quit working after a few months
[17:30:53] <atom1> i can't keep track who has em and who doesn't here
[17:31:19] <amee2k> i don't, i only got the avrisp one
[17:31:36] <amee2k> considering a dragon for its HVPP and dW support though
[17:32:05] <atom1> i tried hvpp once with it
[17:32:12] <atom1> i think the chip was bad
[17:32:40] <amee2k> just so i don't have to fiddle if i screw up the fuses again :P
[17:33:04] <atom1> that's what the clock out is for on mine
[17:33:19] <amee2k> what if the reset pin got disabled?
[17:33:29] <atom1> well then you got a problem
[17:33:44] <atom1> i have one for the attiny10 for that but not isp
[17:33:44] <amee2k> i've gota tiny45 without reset pin because i put the i2ctinyusb firmware on it
[17:34:14] <amee2k> gonna make a twi usb adapter board for it sometime
[17:34:22] <atom1> the hv code is slightly different than regular isp
[17:34:33] <atom1> i tried it once with my adapter
[17:40:58] <atom1> amee2k, what programmer are you using with that line?
[17:41:08] <atom1> you need the -B 5 delay?
[17:42:21] <amee2k> avrisp mk2 (date stamp 2009-04)
[17:42:47] <amee2k> i had some mildly inconclusive results where it would sporadically refuse to program
[17:42:59] <amee2k> the -B 5 fixed it. so far, reliably so.
[17:43:11] <atom1> ok
[17:44:17] <amee2k> since that has helped, i never bothered tracing the cause of the issue
[17:46:32] <atom1> ok it apears to work ok
[17:48:43] <atom1> read the signature on a m128 and t10 anyway
[17:49:33] <amee2k> -U "flash:w:$(FLASH_TARGET)" # to upload HEX files
[17:49:44] <atom1> i know
[17:49:48] <amee2k> >_>
[17:49:52] <atom1> i gotta get some files over there first
[17:54:17] <atom1> amee2k, you don't use -e as well
[17:54:19] <atom1> erase first
[17:54:31] <atom1> i think)
[17:54:44] <amee2k> nope
[17:54:59] <atom1> does it automatically erase before write?
[17:55:03] <amee2k> iirc it does an erease cycle on its own when you specify something to write to flash
[17:55:32] <amee2k> (if you have to erase first to reliably program flash, it probably does because i never had issues)
[17:56:48] <atom1> woops
[17:56:55] <atom1> wrong device :/
[17:58:09] <atom1> do i need a path if terminal is in the .hex file directory?
[17:58:16] <atom1> it failed to find the file
[17:58:27] <amee2k> i don't think so
[17:58:51] <amee2k> sudo avrdude -p atmega88 -P usb -c avrispmkII -B 5 -U "flash:w:coil.hex"
[17:59:02] <amee2k> ^^ example command line as generated from my make file
[17:59:10] <amee2k> has worked hundreds of times over like that
[17:59:16] <atom1> avrdude -p atmega128 -P usb -c avrisp2 -B 5 -U "flash:w:$blink_led.hex"
[17:59:37] <amee2k> um..
[17:59:40] <amee2k> lose the $?
[17:59:41] <atom1> without the file write, it listed the signature
[17:59:47] <atom1> oh
[17:59:50] <amee2k> :P
[18:00:08] <atom1> much better
[18:00:15] <atom1> what's the erase command now?
[18:00:37] <atom1> -e
[18:00:58] <amee2k> i don't use any specific erase
[18:01:06] <atom1> i'm just testing it
[18:01:38] <amee2k> yeah, -e should do it
[18:01:44] <amee2k> but i've never used that before
[18:01:55] <atom1> it did
[18:02:52] <atom1> ok isp and tpi work
[18:03:00] <atom1> what's the verify command?
[18:03:58] <amee2k> that would be something like -U "flash:v:reference_file.hex"
[18:04:00] <amee2k> i think
[18:04:09] <atom1> yeah
[18:04:37] <amee2k> it does an automatic verification cycle after a write though
[18:04:44] <amee2k> unless you specify -V to suppress it
[18:04:55] <atom1> i know i just wanted to do a verify but not write
[18:05:15] <amee2k> then use the -U line with ":v" instead of ":w"
[18:05:24] <atom1> yep
[18:06:16] <atom1> what's -D do?
[18:06:39] <amee2k> suppress automatic erase cycle before a flash write
[18:06:49] <atom1> heh
[18:06:57] <atom1> so -D -e is kinda redundant
[18:07:13] <amee2k> kind of, yes :P
[18:07:28] <amee2k> well, -D -e -U "..." is
[18:07:54] <amee2k> from the way i usderstand the documentation, -D is only a modifier to -U
[18:08:01] <atom1> oh
[18:08:09] <amee2k> it won't suppress any explicitly commanded erase cycles
[18:08:55] <atom1> well i figured out what i need
[18:08:57] <amee2k> "When the -U option with flash memory is specified, avrdude will perform a chip erase before starting any of the programming operations, [...]. This option disables that."
[18:09:00] <atom1> it seems to be working fine
[18:09:51] <amee2k> :)
[18:10:18] <atom1> there's a firmware update up now so it works with studio 5.1 now
[18:10:43] <amee2k> o.O
[18:10:52] <amee2k> does it actually fix anything besides egos?
[18:10:53] <atom1> just wanted to be sure it didn't break something else
[18:10:56] <atom1> yes
[18:11:07] <atom1> 5.1 tests for more stuff
[18:11:22] <amee2k> no, i mean the firmware update
[18:11:45] <atom1> it lets the programmer work under 5.1
[18:12:03] <amee2k> i heard horror stories about the dragon stopping to work with anything that came before avr studio 5 if you install the version 5 capable firmware
[18:12:18] <atom1> very possibly. i heard the same thing
[18:12:31] <atom1> i haven't updated mine and see no need to
[18:13:17] <dirty_d> amee2k, it started working all of a sudden
[18:13:21] <dirty_d> i didnt do a damn thing
[18:13:23] <amee2k> imo the whole firmware breaking compatibilit thing is at best grossly negligent
[18:13:27] <dirty_d> maybe a bad connection on the breadboard
[18:13:33] <Tom_itx> very likely
[18:13:53] <amee2k> and thats only the naive interpretation
[18:15:32] <dirty_d> man thats annoying
[18:15:42] <dirty_d> all that time for nothing
[18:16:08] <OndraSter> I was using Dragon in both
[18:16:12] <OndraSter> always had to flash older/newer firmware
[18:16:34] <Tom_itx> what a pain
[18:16:44] <OndraSter> well it worked
[18:16:46] <OndraSter> that's my point :P
[18:16:51] <dirty_d> who wait
[18:16:54] <dirty_d> whoa*
[18:17:08] <dirty_d> i accidentally changed some code to something thats not right
[18:17:10] <dirty_d> and that made it work
[18:17:16] <amee2k> lol
[18:17:27] <Tom_itx> what a trick
[18:17:30] <OndraSter> lol
[18:17:39] <OndraSter> I had rather not that cool bug
[18:17:47] <OndraSter> if you have NO code at address 0
[18:17:53] <OndraSter> it will say something like "connect AVR device"
[18:17:59] <OndraSter> or some kind of simila rerror
[18:18:03] <OndraSter> similar error*
[18:18:15] <OndraSter> like... if you are doing bootloader
[18:18:22] <OndraSter> and it all starts at lets say 3800h
[18:18:32] <OndraSter> and there is zero code at address 0
[18:18:34] <OndraSter> it won't connect
[18:18:37] <OndraSter> (JTAG that is)
[18:18:41] <dirty_d> maybe a mistake in the documentation?
[18:18:53] <dirty_d> my WIF flag never gets set in master read mode after i send the addr
[18:19:04] <dirty_d> but RIF does get set when i actually do get the data
[18:20:10] <OndraSter> what is AVR Studio 5.1 btw?
[18:20:50] <OndraSter> beta
[18:20:51] <OndraSter> oic
[18:21:03] <Tom_itx> the latest mistake
[18:24:37] <OndraSter> :D
[18:24:43] <OndraSter> you don't like Visual Studio?
[18:24:46] <Roamin> quick nub question, do i write : ( 1 << ( x > 8 ? (x - 8) : x) ) or ( 1 << x > 8 ? ( x - 8 ) : x)
[18:25:00] <dirty_d> holy moses
[18:25:52] <Roamin> what im asking is , do i use ? : or (? :)
[18:26:42] <OndraSter> () are never bad thing
[18:26:51] <OndraSter> better to have () and have it working than not have them and not be sure
[18:27:20] <OndraSter> hmm why is there at atmega8 in the avr studio 5.1 release notes that it does not support AVR Dragon?
[18:27:23] <OndraSter> is that just for debug?
[18:27:28] <OndraSter> because there is no reason for ISP not to work
[18:27:37] <Tom_itx> odd
[18:27:46] <OndraSter> same for attiny20
[18:27:53] <OndraSter> attiny4 and 40 too
[18:28:03] <Tom_itx> attiny 4 is TPI
[18:28:04] <OndraSter> only avrisp mkII is said to support them
[18:28:06] <Tom_itx> i can see that
[18:28:08] <OndraSter> oh
[18:28:12] <OndraSter> Dragon doesn't like TPI?
[18:28:17] <Tom_itx> 4 5 9 and 10
[18:28:22] <Tom_itx> i don't think so
[18:28:24] <Tom_itx> it may now
[18:28:25] <OndraSter> oh hmm
[18:28:31] <Tom_itx> i dunno if they updated it for that or not yet
[18:28:40] <OndraSter> not according to the release notes
[18:28:53] <Tom_itx> they opened up the 32k limit and added PDI recently
[18:29:00] <OndraSter> yeah
[18:29:05] <OndraSter> all Xmega and UC3 are supported as well
[18:29:10] <OndraSter> (not sure what UC3 uses)
[18:29:28] <OndraSter> but damn, we want TPI!
[18:29:28] <Tom_itx> maybe Jtag only
[18:29:33] <Tom_itx> i have TPI
[18:29:41] <OndraSter> neither JTAGICE mkII, nor JTAGICE3
[18:29:46] <OndraSter> neither of them know TPI :D
[18:29:55] <OndraSter> only AVRISP mkII
[18:29:58] <OndraSter> on the other hand
[18:30:03] <Tom_itx> and it didn't used to
[18:30:05] <OndraSter> ATtiny28 is supported ONLY in Dragon
[18:30:10] <Tom_itx> the old ones won't i think
[18:30:22] <OndraSter> JTAGICE3 is not old
[18:30:37] <Tom_itx> no, the older avrispmkii
[18:30:39] <OndraSter> ah
[18:31:06] <OndraSter> http://clip2net.com/s/1zNvo
[18:31:13] <OndraSter> that tiny28 is just weird... only Dragon ?!
[18:31:22] <OndraSter> let's see datasheet
[18:31:23] <Tom_itx> i dunno what it is
[18:32:22] <OndraSter> "high current LED driver"
[18:32:23] <OndraSter> builtin
[18:32:24] <OndraSter> o_O
[18:32:32] <OndraSter> only on one port though
[18:32:49] <OndraSter> uhm
[18:33:14] <OndraSter> everyone is better off with external LED driver (that can sink more than 25mA) with serial interface and bigger (or different at least) mega
[18:33:17] <OndraSter> or tiny
[18:34:10] <OndraSter> if I were to drive my LED matrix project with bunch of tiny28s...
[18:34:12] <OndraSter> haha
[19:22:44] <OndraSter> guys, has anyone here been ordering from iteadstudio?
[19:22:53] <OndraSter> I want to know what they write on the package as a price
[19:22:58] <OndraSter> I don't want to pay import tax :P
[19:23:50] <LoRez> you in the US?
[19:24:46] <CapnKernel> OndraSter: You're in CZ, right?
[19:25:12] <CapnKernel> But he wishes he was an Australian like me :-)
[19:25:34] <LoRez> I don't have problems buying stuff from seeedstudio, I'd imagine itead does the same
[19:27:25] <Tom_itx> OndraSter, i just got an order from them
[19:27:56] <LoRez> what'd you get?
[19:28:05] <Tom_itx> a box of boards
[19:28:33] <LoRez> you like the quality?
[19:29:09] <Tom_itx> this time i'm pleased with them so far
[19:29:43] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/boards/USBTiny_Mkii/USBTinyMkII_1-1c_top.jpg
[19:29:46] <Tom_itx> that's one of em
[19:30:00] <Tom_itx> not perfect but for china...
[19:34:54] <OndraSter> ye, CZ
[19:35:41] <Tom_itx> OndraSter, it is marked as 'gift' and the value is
[19:35:42] <Tom_itx> USD $20.00
[19:35:49] <OndraSter> anything above 22 EUR is supposed to be taxed
[19:35:51] <OndraSter> oh cool
[19:35:52] <OndraSter> great
[19:35:53] <OndraSter> thansl
[19:35:55] <OndraSter> thanks
[19:36:31] <Tom_itx> that was for 100 boards
[19:36:55] <OndraSter> wow
[19:36:57] <OndraSter> I have only 50 :D
[19:37:19] <OndraSter> I have got package from USA waiting on customs for me to come and give some price info
[19:37:25] <Tom_itx> i think they know the game
[19:37:25] <OndraSter> there is "electronics" written on it and $15
[19:37:29] <OndraSter> surprisingly they didn't open it
[19:37:43] <OndraSter> there is actually phone and Riff Box (ARM phone JTAG) inside :D
[19:37:48] <OndraSter> worth like $200
[19:37:51] <OndraSter> both together
[19:37:55] <Tom_itx> hang on, i'll take a pic of it
[19:38:04] <OndraSter> I paid $50 in total for it, friend
[19:38:08] <OndraSter> I paid it on two parts
[19:38:15] <OndraSter> so I think I will show them only $25 one
[19:38:35] <OndraSter> and say "no idea, he said he has some old pieces of junk... and me being HW guy, I couldn't let him throw it away"
[19:38:46] <OndraSter> or something lol
[19:38:59] <OndraSter> now I hope nobody is here from czech customs LOL
[19:45:03] <OndraSter> Tom_itx, and did you use regular post or DHL?
[19:46:09] <Tom_itx> regular
[19:46:22] <OndraSter> oh
[19:46:23] <OndraSter> hmm
[19:46:27] <OndraSter> we'll see
[19:46:36] <OndraSter> 50 boards + 3 rotary encoders in the box
[19:47:43] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/boards/USBTiny_Mkii/itead_box.jpg
[19:48:40] <OndraSter> looks like regular ebay package xD
[19:48:41] <OndraSter> thanks
[19:57:53] <LoRez> Tom_itx: you still milling cases for your programmers?
[19:58:02] <Tom_itx> yeah
[20:02:53] <Tom_itx> OndraSter, they were cheaper than GP but took longer to get here
[20:06:01] <OndraSter> GP?
[20:07:39] <Tom_itx> Gold Phoenix
[20:08:10] <Tom_itx> they ship FedEx to me
[20:08:37] <Tom_itx> itead used a sail boat with a torn sail
[20:09:30] <LoRez> yeah, regular shipping from china is shit slow. take the DHL upgrade.
[20:09:50] <Tom_itx> i didn't mind. i knew it would be 4 weeks
[20:10:02] <Tom_itx> they were here when i got back from vacation
[20:10:49] <OndraSter> oh
[20:11:28] <Tom_itx> i just plan on a 4 week wait when i order from HK
[20:14:08] <OndraSter> so, here is a lot of aussies, CapnKernel
[20:14:16] <OndraSter> I want to join you :D
[20:14:42] <CapnKernel> Indeed :-)
[20:17:19] <OndraSter> why are non-green silk screen more expensive? :(
[20:17:22] <OndraSter> just because they look cooler?
[20:18:50] <Tom_itx> green is standard
[20:18:59] <Tom_itx> some are alot harder to do
[20:19:01] <Tom_itx> like black
[20:19:26] <OndraSter> can't they just use regular paint... like for wood? :D
[20:19:38] <OndraSter> then some old school plotter
[20:19:42] <OndraSter> give it white marker...
[20:56:37] <OndraSter> duh it is superlate
[20:56:37] <OndraSter> gn
[20:57:47] <Valen> see how your regular paint likes solder
[23:08:52] <skorket> I can't remember who it was, but a while back I was having some trouble with reading an input line into an ATTiny13 that was noisy due to the power draw from my 4 servos connected. They suggested that I use a LiPo battery with a better regulator and it worked. Whoever that was, thank you
[23:09:22] <ziph> It might've been infle*x.
[23:10:37] <skorket> I remember them saying they had a lot of RC experience
[23:10:48] <ziph> He runs an RC store.
[23:12:22] <skorket> inflex, do you remember giving me advice way back when?
[23:13:08] <skorket> aren't IRC conversations logged?
[23:16:07] <skorket> well, anyway, inflex, if it was you, thank you very much. My project works very nicely because of the advice you gave
[23:22:03] <inflex> Hrmm... the T13 is still noisy (jitter) even on battery supply, just slightly less so
[23:22:22] <inflex> depends on what you're doing with the servos of course, and sometimes you just luck out and get a 'quiet' T13
[23:22:56] <Kevin`> low esr capacitors make things nice
[23:24:07] * inflex needs to make a switch that'll switch everything non-critical off in his office when he walks out of the room
[23:24:21] <inflex> like LCD panels, aircon, lights, phone, hubs etc
[23:24:32] <inflex> printer
[23:52:48] <CapnKernel> Anyone know anything about driving laptop CCFLs?
[23:53:01] <CapnKernel> What kind of voltage and current the inverter boards need?
[23:53:30] <CapnKernel> Whether one needs to do i2c or something to get them to go?