#avr | Logs for 2012-01-16

Back
[00:04:29] <pingec> Can someone explain me what is a boot loader and how it works on an avr?
[00:05:13] <ziph> In that context it is usually a program that runs before your program and lets you download a replacement for your program over RS232 or USB.
[00:05:50] <ziph> It'll either go into download mode or jump straight into your program depending on some external stimulus (often a hardware switch or button)
[00:10:49] <pingec> Is that so I don't need a programator?
[00:29:24] <rue_house> correct
[00:29:31] <rue_house> you just need to talk to it via usb or serial
[00:29:44] <rue_house> and a way to get it to choose to runt eh bootloader instead of your program
[00:30:50] <pingec> I see, thanks
[00:47:06] <Kevin`> who was it that was working on the clock again?
[00:56:36] <rue_house> !thislog
[00:56:37] <tobbor> This one: http://rueshouse.dyndns.org:82/~ircjunk/irclogs/html/%23avr-2012-01-16.html
[00:59:20] <ziph> pingec: Only if you get an AVR with a bootloader on it already (either a USB AVR for USB or for example an Arduino for RS232).
[02:04:13] <lovre> hi all
[02:05:02] <lovre> simple question, when using float type on 8bit AVR, is it really 32bits (with codevision compiler, according to the manual)? Does codevision compiler sort this out internally to handle 4 registers as one 32bit value, or what?
[02:05:57] <inflex> ja, the compilers handle it
[02:06:35] <Casper> and use TONS of ressources while dealing with it
[02:06:40] <Casper> specially divisions
[02:07:15] <ziph> But depending on your specific AVR and application you may not care.
[02:11:09] <lovre> Casper, ziph: ok, but another question, how do i split a float into 4 chars to send it over uart, since i cant do >> with float? I thought about: (char)(myVar>>8) etc, but i cant shift a float
[02:11:43] <inflex> sprintf(buf,"%f", your_float);
[02:11:43] <Casper> you can, if you cast it as long int I guess?
[02:14:00] <ziph> Cast it to a string if you don't want to break strict aliasing rules.
[02:14:02] <inflex> hrmm... strange problem with my wife's 24" Dell LCD... on black zones it frequently gets a dusting of red-dots
[02:14:55] * inflex ponders cracking the whole thing open and checking for dry joins on the DVI connection or the various interface chips
[02:15:07] <ziph> e.g. unsigned char *bytes = (unsigned char *)my_float
[02:15:16] <Kevin`> lovre: um, there's no reason you can't do >> with float
[02:15:23] <ziph> send_some_crap(bytes, sizeof(float))
[02:15:39] <Kevin`> lovre: it should just corrupt the data as far as float-ness is concerned
[02:15:50] <lovre> Kevin`: the whole point of float is that its value depends on the actual position of bits, so you cant really, the codevision prohibits it
[02:16:05] <lovre> Kevin`: yes, it should, but codevision compiler wont allow it
[02:16:15] <lovre> Kevin`: to "protect" the user from himself, or whatever
[02:16:26] <lovre> ziph: the send function accepts only char. dont ask :)
[02:16:43] <Kevin`> lovre: well that's not very nice. you could do this I suppose: char[]=&float
[02:16:57] <lovre> Kevin`: hmm, nice tought of
[02:17:02] <ziph> lovre: Then write a wrapper that accepts a byte buffer and loops over it to call your single character routine.
[02:17:06] <lovre> Kevin`: should it pass the compiler :)
[02:17:32] <lovre> ziph: yes, sounds good
[02:17:49] <Kevin`> lovre: alternatly, you could likely just do ((uint32_t)float)>>, but copying from the memory locations is probably faster
[02:17:53] <ziph> And << and >> aren't defined on floats.
[02:18:13] <lovre> ziph: yes, thats what compiler is crying about
[02:18:20] <ziph> Don't get in to the habit of casting floats to integers, aliasing rules will bite you in the arse one day.
[02:18:42] <lovre> Kevin`: wont it get rounded, so i lose decimal bits?
[02:19:28] <Kevin`> I suppose it's possible. it's a valid conversion isn't it
[02:20:06] <ziph> Sorry, casting pointers to floats to pointers of integers.
[02:20:20] <ziph> Casing a float to an integer just truncates it to an integer.
[02:21:06] <Kevin`> aliasing rules?
[02:21:52] <ziph> If you create an int * from a float * the compiler will assume they don't point to the same data and do optimisation that may make the program behave unpredictably.
[02:23:04] <lovre> ziph: the char[]=&float solution seems a good option to try. Ill try it and get back to you
[02:23:12] <lovre> Kevin`, ziph: thank you :)
[02:23:19] <Kevin`> it's endianness-dependent though
[02:24:10] <ziph> As a special case C assumes that char * can alias anything.
[02:24:13] * inflex thinks it'll just be easier to convert it to a string
[02:24:18] <ziph> Which is why that is legal.
[02:24:41] <ziph> lovre: And you have to worry about endianness usually.
[02:25:24] <Kevin`> printf+float won't take ANY program space or processing time, no
[02:25:24] <ziph> lovre: Although both the AVR compiler and the x86/Intel CPU you're probably using are both little endian, so if it is for PC<->AVR communication only then you'll be fine without endian conversion.
[02:25:30] <Kevin`> it does make stuff easy though
[02:25:38] <lovre> ziph: is it depended on avr version, or all avr have the same endianess?
[02:26:17] <ziph> lovre: It's a bit weird talking about endianness on an AVR, because most of the time it deals in 8 bit data. :)
[02:26:19] <lovre> ziph: its avr <-> avr communication. Suppose thats ok since they both use the same
[02:26:27] <lovre> ziph: lol, yes
[02:26:32] <ziph> lovre: AVRGCC however is little endian when it synthesis large integers though.
[02:27:01] <ziph> (And I presume floats)
[02:27:03] <lovre> ziph: im not using avrgcc, i use codevision instead. but since i use it on both ends i should probably not worry about this
[02:27:17] <ziph> Ah, right.
[02:27:20] <Kevin`> lovre: the 16bit registers on avr are most significant byte first. I think the compiler follows that for big data types
[02:27:28] <Kevin`> erm
[02:27:34] <Kevin`> other way around
[02:27:38] <ziph> Well, codevision for a 68000 would most likely use big endian.
[02:27:49] <lovre> ziph: 68000?
[02:27:57] <ziph> It is usually a property of the CPU/MCU, not the compiler.
[02:28:19] <lovre> ziph: as you said, how is it a property of a MCU since its 8bit based?
[02:28:31] <ziph> It's an old Motorola chip, used to be used in Mac's. :)
[02:28:33] <lovre> ziph: 32 bits are not real, its just 'emulated' via compiler
[02:28:39] <lovre> ziph: i see
[02:28:41] <ziph> lovre: I said it _usually_ is. :)
[02:28:45] <lovre> ziph: :D
[02:28:57] <ziph> lovre: Your compiler may let you switch it, too.
[02:29:06] <ziph> And even more confusingly ARM's can use both.
[02:29:20] <ziph> Sometimes at runtime, sometimes with a firmware switch, sometimes hardcoded in silicon. :)
[02:41:26] <lovre> ziph: *char=(char*)&float -> this seems to work ok
[02:41:32] <lovre> i mean
[02:41:50] <lovre> char *mychar = (char *) &myfloat
[02:42:06] <ziph> lovre: Yeap, it should be fine.
[02:42:16] <lovre> ziph: thanks for your help :D
[02:42:29] <ziph> lovre: On the other end you may want to memcpy the buffer into a float (or a struct containing a float) so that you don't have problems with alignment.
[02:43:30] <lovre> ziph: i can just give the memory address to memcpy and it will write to it 'raw' regardless of type?
[02:44:07] <ziph> Yeap.
[02:45:05] <lovre> ziph: is this any different as doing the same as before, only writing instead of reading? For example: float data; char *c = (char*)&data; -> and then writing to c, which would be the same as memcpy to data?
[02:45:13] <lovre> ziph: just asking, not trying to complicate :D
[02:45:55] <ziph> Yeah, that's fine.
[02:45:59] <lovre> ziph: nice
[02:46:15] <ziph> Just don't do "float *my_float = some_random_char_pointer; *float"
[02:46:52] <lovre> ziph: i wont, but dont see quite why
[02:46:56] <ziph> Because if the pointer isn't aligned on a 4 byte memory address it will crash or give you bad data on some compilers/CPU's.
[02:47:10] <ziph> Some CPU's don't support unaligned reads.
[02:47:16] <lovre> ziph: ah, yes, sure
[02:47:22] <lovre> ziph: didnt think of alignment :D
[02:48:18] <lovre> ziph: since we are at it, is it possible to declare a char to be aligned? or you need to use trick like the pointer to a float variable, to achieve this? Not that one would really need this, just a thought
[02:48:49] <ziph> lovre: Most compilers have special options to control alignment.
[02:49:20] <ziph> lovre: There's three places alignment matters, though; members of a struct, global variables, and stuff on the stack.
[02:51:16] <lovre> ziph: i see...
[03:04:04] <CapnKernel> lovre: http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Variable-Attributes.html
[03:15:57] <grummund> lovre: why do you need to cast between pointer types?
[03:19:35] <Kevin`> to avoid compiler warnings, why else
[03:19:58] <ziph> He wants to move floats around.
[03:21:26] <lovre> grummund: want to send some floats over some wires :D but the implementation of protocols supports only 8 bits per funcation call :D never mind why, it just does :D
[03:22:20] <lovre> CapnKernel: nice, i didnt know this. I suppose its only supported on avrgcc, and im using codevision at the moment, but good to know, thanx
[03:22:33] * grummund sees trouble ahead...
[03:23:16] <grummund> platform/compiler dependent protocol implementation.
[03:23:29] <ziph> Like being able to access ports on an MCU?
[03:23:32] <ziph> Baaaad! Don't use it!
[03:23:35] <ziph> No ports for you!
[03:24:05] <grummund> not quite what i meant :)
[03:24:43] <ziph> How about address aligned DMA? Bit hard to use that without compiler alignment flags.
[03:25:07] <grummund> indeed, but still not what i meant :)
[03:25:16] <ziph> What did you mean?
[03:25:40] <grummund> allowing the compiler to define byte-ordering at the protocol interface
[03:26:07] <CapnKernel> lovre: Your compiler may have some sort of #pragma to enforce alignment.
[03:26:38] <lovre> CapnKernel: searching for it on google as we speak.. no luck yet.. i dont really need it atm, but would be nice to know
[03:26:47] <Kevin`> he's using the same compiler/platform at both ends. for a microcontroller, i'd rather do that than mess with less efficient encoding
[03:27:01] <ziph> grummund: There's nothing wrong with a protocol that assumes little endian.
[03:27:16] <lovre> grummund: protocol doesnt care about byte ordering, but it doesnt support floats, only char, thats why i needed those pointers
[03:27:31] <lovre> ziph: protocol doesnt care really, it just sends bits.
[03:27:33] <Kevin`> ziph: sure there is, it breaks when you try to talk the protocol using a new device
[03:27:45] <lovre> ziph: the receiver should parse accordingly
[03:27:53] <ziph> No, you just make the new device deal with little endian.
[03:28:09] <ziph> Or would you suggest a CORBA style endian handling for all protocols? :)
[03:28:40] <lovre> ziph: i dont know CORBA :D
[03:29:09] <ziph> ASN.1 BER/DER encoding then. :)
[03:29:13] <Kevin`> if you anticipate the problem occuring, there are standard functions for network byte order that can be used
[03:29:15] <lovre> ziph: making the new device deal with little endian is a specific instance of "making receiver parse accordingly" init?
[03:30:37] <grummund> well so long as all nodes on the bus use the same hardware, same compiler version, and compiler options... and it'll always be that way... then it's fine.
[03:31:05] <ziph> How many compilers and MCU's do you use that aren't IEEE floats and little endian ints?
[03:31:23] <lovre> grummund: yes that is all true for this case.. and there will be no other case :D
[03:31:38] <Kevin`> ziph: plenty
[03:31:38] <lovre> ziph: close to none?
[03:31:52] <lovre> Kevin`: like what
[03:31:56] <ziph> And should I be anticipating the use of EBCDIC?
[03:32:16] <Kevin`> lovre: mips and arm can be bit endian. I haven't seen much arm, but mips often is
[03:32:20] <Kevin`> big*
[03:33:10] <lovre> Kevin`: ah yes, i forgot about arm, didnt use it for a while. And i dont use mips
[03:33:14] <Kevin`> ziph: you don't NEED to worry about the specifics if you just handle it properly to begin with
[03:33:32] <lovre> ziph: ebcdic vs ascii?
[03:34:03] <ziph> Kevin`: So that's a yes to UTF-8 handling routines so that character counts can be correct on my AVR? :)
[03:34:32] <ziph> Most of the ARM's in use today are left permanently in little endian, too.
[03:35:00] <Kevin`> # uname -a
[03:35:00] <Kevin`> Linux OpenWrt 2.6.39.4 #1 Wed Nov 2 07:34:26 CDT 2011 mips GNU/Linux
[03:35:46] <Kevin`> using utf-8 is probably overkill, but sending numbers over a network in a defined way definitely isn't
[03:37:58] <ziph> So you should use macros around floats too?
[03:44:33] <CapnKernel> The ARM core can be either little or big endian, but certain on-chip peripherals can only be used in LE mode. (I can't give you a reference to that, it's just from my memory)
[03:45:15] <ziph> And most ARM devices are either left on or hardwired to LE.
[04:26:56] <jadew> Roklobsta, got a rigol :D
[04:33:18] <karlp> little or big endian rigol? ;)
[04:33:59] <CapnKernel> LOL
[04:34:01] <jadew> heh
[04:34:18] <jadew> pretty excited
[04:34:24] <jadew> waiting for it to calibrate right now
[04:34:56] <jadew> was always wondering what the wave looks like on the crystal oscilator
[04:35:04] <elektrinis> mine died in first 4 hours
[04:35:28] <jadew> well, that's good, it has a 3 years warranty
[04:35:35] <jadew> should be happy it didn't die after 3 years
[04:36:02] <elektrinis> I still lost like $100 on customs and $ rate change
[04:36:10] <elektrinis> and 2 months of hassles
[04:36:16] <karlp> what, you had to pay customs twice?
[04:36:44] <elektrinis> I did not pay it the second time, because I got my money back from seller
[04:37:02] <karlp> oh, you just returned it, rather than getting it replaced.
[04:37:13] <elektrinis> and I got most of the customs taxes back after two months off hassles
[04:41:12] <Roklobsta> jadew: you likey?
[04:49:26] <jadew> it's awesome
[04:50:10] <jadew> one question tho, if I play with both probes, do I need to connect both gounds?
[04:50:17] <jadew> or one would suffice?
[04:50:25] <elektrinis> rigol is crap.
[04:50:34] <elektrinis> well, for the money.. its ok
[04:50:52] <jadew> I wouldn't have bought anything more expensive than this
[04:50:54] <jadew> so it's great
[04:55:59] <jacekowski> elektrinis: it's not
[04:56:02] <jacekowski> elektrinis: that's the thing
[04:56:12] <jacekowski> elektrinis: cheap agilent scopes are rebranded rigols
[04:56:20] <elektrinis> i know.
[04:56:32] <elektrinis> maybe these newer rigols are ok
[04:56:42] <jacekowski> i've had a chance to look at old 1052 iirc
[04:56:46] <elektrinis> i have early one.. with LA
[04:57:00] <elektrinis> many bugs, too many
[04:57:04] <elektrinis> drives me crazy
[04:57:42] <jacekowski> and to be honest, it's the same ( possibly even better, like sample memory bigger then 16k ) as my tek that costs 4x as much
[04:58:02] <jacekowski> any my tek can't do FFT
[04:58:25] <jacekowski> it's like with japan not so many years ago
[04:58:52] <jacekowski> they started of doing crap stuff, but now if you want reliable hi tech electronics - japan is the place to go
[04:59:06] <jacekowski> and korea is going the same way
[05:05:38] <elektrinis> FFT on rigol - its like a fork in a power drill - you CAN mix some food with it, but its nowhere near a true mixer
[05:06:08] <elektrinis> (I tired both, FFT on rigol and the fork...)
[05:06:12] <elektrinis> similar results
[05:19:38] <jadew> hmm, I get a weird edge while checking the signal from an AVR
[05:19:45] <jadew> I made it output 1 and 0
[05:20:24] <jadew> and I get a sharp edge in the top left corner and another one in the bottom right, does that mean my probe isn't properly calibrated or that's expected?
[05:30:42] <ziph> Yes.
[05:31:02] <jadew> yes, expected or yes not calibrated?
[05:31:52] <ziph> It sounds like it isn't compensated.
[05:32:05] <jadew> I see
[05:32:17] <ziph> Is there a test signal source on your oscilloscope?
[05:32:24] <jadew> yeah
[05:32:30] <jadew> I did the compensation there
[05:33:07] <jadew> anyway, I'm still able to see really awesome details
[05:33:07] <ziph> Oh, then it's the signal.
[05:33:41] <ziph> jadew: You can usually save a screenshot to a USB key too if you need someone to look at something.
[05:33:42] <jadew> like the fact that in this simple program the code that decides to switch to 1 takes more than the one that decides to switch to 0
[05:34:13] <jadew> yeah, I don't have a usb stick ready yet and I'm sure it's not that big of a deal, I'm just excited right now
[05:34:15] <ziph> jadew: There's a couple of other tricks worth learning.
[05:34:31] <ziph> jadew: The first is using a spare pin on your AVR to trigger the scope at some point in time.
[05:34:49] <jadew> ah, and use the external trigger?
[05:34:53] <ziph> jadew: You can wire it in to the external trigger port and keep the signal channels free too.
[05:34:55] <ziph> Yeap.
[05:35:03] <jadew> neat
[05:35:42] <Roklobsta> jadew: try to keep the ground of the cro as electically close to the signal you are looking at
[05:35:42] <jadew> this is so freaking awesome
[05:35:57] <ziph> The other is that it's always a good idea to put a spare pin or two into a test pad/loop on your PCB so that you can create signals specifically for the purpose of looking at them on the scope.
[05:36:01] <jadew> good tip Roklobsta
[05:36:22] <ziph> Like PORTA = 1 at the start of an ISR and PORTA = 0 at the end will get you ISR timing and frequency details.
[05:36:33] <jadew> hah
[05:36:36] <jadew> neat
[05:36:48] <jadew> that's debugging at a whole new level
[05:37:05] <Roklobsta> jadew: I haven't done it yet but with usb you can control the whole thing from your own software, record signals and do your own ffts and signal analysis. I plan to make a THD analyser at some point.
[05:37:18] <ziph> jadew: And while you're thinking about grounds, never connect the ground to anything that isn't either floating or sitting on the same AC 120/240 ground. :)
[05:37:37] <Roklobsta> jadew: if you toggle a pin on and off at the start and the end of a routine you can time exactly how long it's taking.
[05:38:04] <jadew> ziph, thanks for the tip
[05:38:19] <jadew> Roklobsta, I was thinking of building my own singal analyzer (if it's going to be possible)
[05:38:26] <jadew> to get some logic info out of it
[05:38:49] <Roklobsta> if you can get the data into a pc you can do anything you like
[05:39:14] <ziph> With a bit of practice you can read most things anyhow.
[05:39:53] <ziph> jadew: That ext trigger trick is good for when you're looking at something like SPI too.
[05:39:57] <jadew> yeah, might not even be necesary, it's not like I can't tell which bit is what, but I'm guessing somtimes you need to follow a transfer
[05:40:10] <jadew> and you need the sfotware to tell you which bit means something
[05:40:15] <jadew> like... a stop bit for example
[05:40:36] <jadew> I guess I should get another probe for the ext
[05:40:38] <jadew> I only have 2
[05:40:47] <Roklobsta> exactly. i used it not so long ago to resolve some problems with I2C.
[05:41:13] <ziph> jadew: Or you can just get some RJ45 and a BNC and have whatever else you want on the other end.
[05:41:29] <Roklobsta> jadew: usually 2 probes is enough as you trigger off one of the channels.
[05:41:33] <ziph> 0.1" headers maybe.
[05:42:29] <jadew> I see
[05:42:56] <jadew> heh, I thought I'm improving the code, but instead I made it slower, this is interresting
[05:44:59] <Roklobsta> You'll like this: http://www.cibomahto.com/2010/04/controlling-a-rigol-oscilloscope-using-linux-and-python/
[05:45:24] <jadew> nice, thank you
[05:46:06] * inflex wonders if he should bother trying to fix this Marantz CD63 deck
[05:46:15] <inflex> something is pulling the 5V line down to 0.3V ... :\
[05:46:40] <Roklobsta> is it one of those big arse north queensland bugs shorting it out?
[05:47:09] <inflex> I pulled the electronics out, while there were about 4 gecko eggs in there, there wasn't anything obvious
[05:47:26] <inflex> I'm -fairly- sure it started up for a few seconds, then closed down
[05:49:22] <Roklobsta> might be a bung electrolytic
[05:51:04] <Roklobsta> why spend the time on it? is it particularly awesome?
[06:06:17] <_abc__> Is there a way to determine what version of avr-libc is installed in a studio4 windows install?
[06:08:04] <inflex> Roklobsta: well, it is a very nice CD deck
[06:08:13] <inflex> Roklobsta: matches very well to the PM57 amp
[06:08:20] <Roklobsta> oh
[06:08:23] <inflex> but I was mostly planning on eBay'ing the pair
[06:08:51] * inflex found them an excellent match for listening to his classical music
[06:09:11] <inflex> (with KEF Q30 speakers)
[06:13:38] <Roklobsta> do you have golden ears?
[06:14:43] <inflex> no, far from it - but the CD63 / PM57 / Q30 combo did sound very nice, but using the Yamaha 5-CD carousel otoh sounded too aggressive.
[06:15:15] <inflex> I also had a NAD amp but sold that a long time ago
[06:15:16] <Roklobsta> even though it's been around for a while I am still amazed i can sit here and watch nasatv and a live view from the ISS.
[06:22:02] <karlp> Roklobsta: I gave up tryign to use the rigol we have over usb. incredibly icredibly buggy
[06:23:00] <karlp> I was trying using the provided windows software, and trying to track down the right versions of the NIST stuff,
[06:23:01] <elektrinis> as i said.
[06:23:05] <karlp> goddawful mess.
[06:23:13] <elektrinis> ;]]
[06:23:14] <karlp> standalone, I've been very happy with it though,
[06:23:16] * inflex might try replace some of the main power caps - but if one has died, then I can only imagine the rest will follow in quick succession
[06:23:27] <karlp> yes yes, we heard your hatred the first 8 times elektrinis :)
[06:23:51] <elektrinis> good.
[06:25:00] <karlp> Roklobsta: I hadn't even _tried_ to use it in linux to be honest,
[06:25:12] <karlp> it's back on the shelf now anyway, my needs for it are over.
[06:26:54] <Roklobsta> interesting. i wonder if the latest firmware is so bad
[06:31:42] <karlp> might have been a windows 7 thing, not sure.
[06:32:06] <elektrinis> worst thing is that rigol stopper cooking new firmwares the moment newer model (1052) appeared
[06:32:23] <elektrinis> and i'm left with incredibly buggy brick
[06:33:24] <Roklobsta> did you try firmware 2.06?
[06:35:08] <karlp> yours is buggy even just standalone elektrinis?
[06:35:18] <elektrinis> yes
[06:35:43] <elektrinis> ds1022cd
[06:36:00] <elektrinis> d - with 16ch LA
[06:36:29] <elektrinis> its like 3-4 years old
[06:36:47] <elektrinis> and a year back I bought new 1052E
[06:37:04] <elektrinis> it died in first few hours of use
[06:37:08] <karlp> we have an 1102D, with fw 2.04, probably 18months old?
[06:37:16] <elektrinis> something happened to firmware
[06:37:32] <karlp> only problems when we tried usb controlling
[06:37:48] <karlp> the usb host interface, for thumb drives on the front is fine.
[06:38:48] <elektrinis> mine is not :)
[06:38:59] <elektrinis> does not work with many drives
[06:39:13] <elektrinis> no matter what file system they are
[06:39:35] <inflex> bleah, replaced the big cap next to the regulator, no go... off/static resistance is at ~300R so it's not enough to indicate a short
[06:39:43] * inflex wonders if perhaps the 7805 is just dying under load
[06:41:06] * inflex will buy another 7805, but if it doesn't work, then it's all going in the bin
[06:43:22] <inflex> that said, these 7805's aren't the sort of thing that normally fails
[07:04:14] <_abc__> Inflex get a lm317 and 1k2 and 3k3 resistors instead...
[07:04:45] <inflex> _abc__: nah, I'd rather just stick with the part they have onthe board already, esp since it has a PCB mounted heatsink as well
[07:05:07] <inflex> oh and I just don't have -any- TO220 type regulators, everything I have is SMD :D
[07:05:35] <inflex> I suppose I could wire up a temporary hack to find otu
[07:05:48] <_abc__> Heh
[07:06:49] <inflex> wish my boards from GP would arrive
[07:07:04] <inflex> they're already a day behind schedule :(
[07:13:14] <Roklobsta> who is gp?
[07:17:15] <karlp> gold phoenix (pcb manufacturer)
[07:54:53] <lovre> what would be the reason for memcpy working, and regular assignment doesnt? For example this works: memcpy(source, dest, 1); and this doesnt: *dest = source[1];
[08:14:30] <MrSunshine> wouldnt that be souce[0] to start with ? :P
[08:14:49] <lovre> MrSunshine: yes, i just typed that for example, doesnt really matter
[08:14:50] <MrSunshine> you copy one byte out of source that would be source[0] gets copied to dest[0]
[08:15:13] <lovre> MrSunshine: yes, but it doesnt seem to work
[08:17:02] <MrSunshine> what is dest and source? :)
[08:17:34] <lovre> unsigned char *source = (unsigned char *)&myFloatNumber;
[08:17:44] <lovre> sorry, thats is dest, not source
[08:18:14] <lovre> char source[] = {some numbers};
[08:19:44] <MrSunshine> well if dest is only a pointer it can only point at a value you are derefing it and trying to stick something into it? :)
[08:19:56] <MrSunshine> so dest = &source[0];
[08:19:57] <MrSunshine> would work
[08:20:17] <MrSunshine> char dest = source[0];
[08:20:21] <MrSunshine> would work
[08:20:31] <MrSunshine> not char *dest; *dest = source[0];
[08:20:33] <lovre> MrSunshine: that just changes it to point to another memory location, but why wont it copy the contents in the location it allready points to?
[08:20:55] <MrSunshine> ahh yes true it already points to a number :P
[08:21:12] <lovre> MrSunshine: thats whats weird.
[08:21:24] <MrSunshine> works in c++ =)
[08:21:25] <lovre> looks like it should work...
[08:21:26] <MrSunshine> or C
[08:21:32] <lovre> you tried it?
[08:21:54] <lovre> maybe its something specific about codevision compiler
[08:21:58] <lovre> dont know
[08:22:17] <MrSunshine> float aVal; char *source = "aa"; char *dest = (char *)&aVal; *dest = source[0]; printf("%c\n", *dest);
[08:22:43] <MrSunshine> and btw, a float doesnt fit in a char :P
[08:23:48] <MrSunshine> lovre, have not tried it unsing an avr tho :P
[08:23:51] <MrSunshine> just on the computer
[08:23:56] <_abc__> Including eeprom.h causes a code increase of 312 bytes in my project. Is this normal?!
[08:23:57] <lovre> MrSunshine: no, but it fits in 4 chars
[08:24:04] <MrSunshine> lovre, ofc :P
[08:24:31] <lovre> MrSunshine: pointer doesnt really care what fits, it just points to the first byte
[08:24:55] <lovre> so char *mychar = (char*)&myfloat; doesnt really care, it just points mychar to the first byte of myfloat
[08:24:58] <lovre> afaik
[08:38:33] <karlp> lovre, possibly allocating from stack, vs into a pointer higher up the stack, or from the heap?
[08:40:13] <lovre> karlp: i should shoot myself in the foot for being stupid.... I shifted the pointer BY THE NUMBER OF BITS INSTEAD OF BYTES...aaaaaa stupid stupid stupid.. SORRY FOR WASTING YOUR TIME
[08:45:21] <karlp> no sweat, we've all done it.
[08:45:30] <karlp> turn off lots of warnings,
[08:45:42] <karlp> -Wall and -Werror can sometimes tell you that you're bit shifting by more than the size of a variable
[08:46:37] <lovre> karlp: nice
[08:46:46] <lovre> karlp: thanx
[08:49:43] <karlp> that should have been turn _on_ lots of warnings.
[09:18:54] <grummund> and -Wextra
[09:19:44] <karlp> that's the one I meant, thanks grummund
[09:19:55] <karlp> -Werror just turns warnings into errors doesn't it?
[09:20:04] <grummund> yep
[09:20:28] <grummund> but only for the compiler. linker warnings stay as warnings
[09:22:12] <grummund> -Wl,--warn-common -Wl,--fatal-warnings for the linker
[09:38:03] <carp3> Hi, is it possible to program non isolated avr(from mains) using AVRISPKII (in circuit) ? is it possible to isolate mkii using opto couplers ?
[10:01:27] <jadew> why does the avr need 2 opposed clock frequencies?
[10:01:41] <jadew> *needs
[10:07:44] <jacekowski> jadew: no it doesn't
[10:07:47] <jadew> is it substracting them to get a more stable freq?
[10:07:57] <jacekowski> you just need one frequency
[10:08:12] <jacekowski> you may need second for clock or something like that
[10:08:22] <jadew> well, I'm watching the crystal on the oscilloscope and when one wave goes up, the other one goes down
[10:08:26] <jacekowski> like 1s signal from DCF chip
[10:08:39] <jacekowski> jadew: that's normal thing for crystal
[10:08:53] <jacekowski> jadew: that's how you make it oscillate
[10:08:58] <jacekowski> and any crystal will do it
[10:09:15] <jadew> but some crystals have only 2 pins
[10:09:19] <jacekowski> yes
[10:09:20] <jadew> how does that work?
[10:09:22] <jacekowski> all of them
[10:09:31] <jacekowski> 3rd one is shield
[10:09:44] <jadew> I see
[12:15:19] <OndraSter> http://clip2net.com/s/1uxEu
[12:15:24] <OndraSter> talking about it with another electronics guy
[12:15:46] <OndraSter> his idea: get rid of the caps on the left, they can make it only worse (induction on the line)
[12:31:37] <ziph> OndraSter: The 4700uF caps?
[12:31:41] <OndraSter> no
[12:31:44] <OndraSter> the 100uF
[12:32:41] <ziph> The ones next to each IC in each row?
[12:32:44] <OndraSter> yes
[12:33:05] <ziph> Yeah, you can put bulk capacitances like that almost anywhere on the board and have the same effect.
[12:33:28] <OndraSter> somebody here told me that it would be better to have at least for each chip (two lines) one extra cap
[12:34:03] <ziph> Yeah, but not 100uF electrolytics. :)
[12:34:23] <OndraSter> was it you? :D
[12:34:31] <ziph> I doubt it.
[12:34:37] <OndraSter> ok
[12:34:43] <ziph> What are the IC's?
[12:34:48] <OndraSter> which ones?
[12:34:54] <ziph> The ones next to the caps?
[12:35:17] <OndraSter> on the right? SP8J3
[12:35:18] <OndraSter> power mosfets
[12:35:25] <OndraSter> 4V drive
[12:35:30] <OndraSter> => good for my 5V logic
[12:35:48] <ziph> They're just acting as switches, not logic drivers?
[12:35:54] <OndraSter> ye
[12:38:37] <Travler1> Do u want to drive the mosfets via pwm? if u do, u should think about evt. heat problems
[12:38:56] <ziph> You might just want to leave 1208 or 0805 pads for caps and try it without populating them first.
[12:39:28] <ziph> At the frequencies where being that close to the IC's matter, the caps are an open circuit anyhow.
[12:39:48] <ziph> (100uF electrolytics that is)
[12:40:44] <Travler1> btw. whats the function of this layout something like a pong game?
[12:41:10] <ziph> Refusing to participate in the LCD revolution of the 80's? :)
[12:41:56] <ziph> (I'm joking, if those are the colour LED grids they're nifty..)
[12:44:09] <Travler1> could be little pwm/switching overkill for the µC if there are 3 colors + 24x48 chanels?
[12:49:55] <OndraSter> Travler1, more than that, it is directly connectable to USB, so the app itself will run on PC
[12:50:01] <OndraSter> but ye, pong is one of the target stuff I wanna make lol
[12:50:08] <OndraSter> ziph, just red & green
[12:50:16] <OndraSter> RGB modules were rather expensive
[12:56:29] <amee2k> ziph: you mean, a short circuit
[12:57:23] <ziph> No, caps are meant to be short circuits.
[12:57:50] <amee2k> yeah, but you said open circuit up there, no?
[12:58:12] <ziph> I said at higher frequencies they are open.
[12:58:36] <amee2k> at higher frequencies their impedance drops and they become more short-like o.O
[12:59:05] <ziph> Until resonance, at which point they open up again.
[12:59:45] <amee2k> ooh, you mean /that/ high frequencies
[13:01:15] <amee2k> i thought small ceramic or foil caps have pretty good high frequency behaviour
[13:02:22] <ziph> He's using highish voltage 10uF for IC level supply bypassing, the SRF of those isn't that high. :)
[13:02:42] <amee2k> o.O
[13:02:51] <amee2k> i'd say 100n tops for a single IC
[13:03:36] <amee2k> i tend to use whatever i have handy around 10..100n foil for general purpose bypassing
[13:04:45] <ziph> The SRF must be so low on a 100uF that I can't even find a datasheet with it mentioned. It's probably 50kHz or so though.
[13:04:56] <amee2k> lol
[13:05:35] <amee2k> unless they're specifically low impedance types, electrolytics suck for RF
[13:06:18] <amee2k> and then they just suck less >_>
[13:40:29] <amee2k> why are depletion mode MOSFETs so unpopular??
[14:18:23] <ben1066> derp question is derp, but MISO and MOSI are the same on avr as on my DAC yes?
[14:19:03] <LosFrijoles> does anyone here have any experience using the usbasp programmer on a 3V system?
[14:26:34] <amee2k> ben1066: i don't know your DAC, but i suspect so
[14:26:48] <amee2k> the designations are quite standard from my experience
[14:27:51] <ben1066> MCP4921
[14:28:02] <ben1066> I then realised it didnt have miso mosi but only sdi
[14:28:09] <ben1066> so does miso need a pullup?
[14:28:15] <amee2k> ben1066: note that MISO and MOSI are "absolute" with respect to direction... unlike the standard names RX and TX for uart-style communication
[14:28:25] <ben1066> Right
[14:29:29] <ben1066> also, if a name for a pin is overlined, its active low yes?
[14:29:30] <amee2k> MISO is master in slave out, mosi is master out slave in. so miso connects to mosi and vice versa. clock is common for all
[14:29:42] <amee2k> yes, generally
[14:29:46] <ben1066> YEa, but the dac has no serial out
[14:29:54] <ben1066> therefore, does it need a pullup?
[14:30:03] <amee2k> ben1066: SPI never needs a pull-up. all signal lines are unidirectional
[14:30:14] <ben1066> even if there is no connection?
[14:30:17] <ben1066> http://www.farnell.com/datasheets/663139.pdf
[14:30:29] <amee2k> you may want to put a weak pull-up on them in case no slave is driving the line
[14:30:51] <amee2k> but if your master's input pin can handle a floating input, you'd be fine without
[14:31:08] <ben1066> its an atmega168
[14:31:11] <ben1066> Can it? :P
[14:31:20] <amee2k> the input signal is guaranteed to only be significant while the line is actually driven
[14:31:34] <OndraSter> ARRGH
[14:31:38] <OndraSter> inductors in eagle = bad
[14:31:39] <amee2k> (well, unless the slave IC is malfunctioning, of course)
[14:31:45] <OndraSter> I can't find any that would fit any from farnell
[14:31:53] <OndraSter> (no local shop has 2.2uF 5A+ inductors)
[14:31:56] <OndraSter> err
[14:31:58] <OndraSter> 2.2uH
[14:32:02] <ben1066> OndraSter: I had this issue, then i noticed that farnell has some footprints :P
[14:32:08] <amee2k> ben1066: i never had problems with floating AVR inputs, but that doesn't mean there can't be any
[14:32:12] <OndraSter> not for inductors, ben1066
[14:32:18] <ben1066> OndraSter: none at all?
[14:32:21] <OndraSter> nope
[14:32:24] <ben1066> D:
[14:32:30] <Steffanx> Design one OndraSter
[14:32:40] <Steffanx> *amke
[14:32:42] <OndraSter> Steffanx, but there is so much numbers in the datasheet :(
[14:32:42] <Steffanx> *make
[14:32:46] <ben1066> amee2k: would I be safer adding a 10ohm pullup then or something?
[14:32:51] <amee2k> i never used pull resistors on SPI before and never had problems this way
[14:32:51] <OndraSter> 10Ohm?
[14:32:53] <OndraSter> more like 10kOhm
[14:32:58] <amee2k> you mean 10k, right?
[14:33:02] <ben1066> yea derpderp
[14:33:09] <ben1066> I missed my k :p
[14:33:11] <amee2k> should be safe i'd say
[14:33:23] <ben1066> if I dont need them i dont have to put them on..
[14:33:27] <amee2k> 10k is weak enough that almost any kind of pin driver should effectively override it
[14:34:04] <amee2k> if you have to order boards, put the footprints on and try leaving them unpopulated unless you run into issues
[14:34:07] <OndraSter> see Steffanx, that other electronics guy said that it would be better to have separate power supply for the LEDs, on smth like 3.3V (otherwise there would be huge losses on all the ICs)... and he suggested TPS54527 IC
[14:34:17] <OndraSter> small SO8, really 4 or 5 external passive elements needed
[14:34:28] <OndraSter> three caps, two ressistors, one inductance
[14:34:28] <ben1066> shall I do it on SS too?
[14:34:37] <amee2k> not really
[14:34:44] <amee2k> SS will always be driven by the master
[14:34:50] <amee2k> same as clock and MOSI
[14:35:03] <amee2k> only MISO pins on the slave side ever need to go high impedance
[14:35:17] <amee2k> since only the selected slave is allowed to drive it
[14:35:17] <ben1066> so only resistor on MISO?
[14:35:28] <amee2k> yep
[14:35:58] <amee2k> and the master won't check the MISO line's status unless he has selected a slave first, so in theory you shouldn't need any at all
[14:36:37] <ben1066> now, what about the fact the dac could be interfered by the isp?
[14:37:10] <ben1066> should I use CS on the DAC?
[14:37:35] <amee2k> make sure the DACs select line can't be high while an ISP transfer is in progress?
[14:37:49] <ben1066> except its active low :P
[14:37:59] <amee2k> oh, okay
[14:38:31] <ben1066> another 10k pullup it seems :P
[14:38:45] <amee2k> hmm i never checked, what do non-ISP pins do during ISP? go high impedance?
[14:39:15] <ben1066> i should hope so :P
[14:39:15] <amee2k> i was about to suggest an AND gate to AND the select output and the reset pin of the MCU
[14:39:27] <ben1066> that seems a bit overkill...
[14:39:48] <ben1066> worst it can do is change the voltageout
[14:39:51] <amee2k> i'd imagine you don't need ISP updates during regular operation, no?
[14:39:52] <ben1066> not to drastic
[14:40:02] <ben1066> no, but everything is smd...
[14:40:25] <OndraSter> that's why I prefer JTAG
[14:40:28] <OndraSter> it is on ADC pins...
[14:40:33] <amee2k> does that dac have any persistent state that could get scrambled?
[14:40:37] <OndraSter> or debugwire is on RESET line even
[14:40:40] <ben1066> No none
[14:40:57] <ben1066> and actually, come to think of it
[14:41:03] <ben1066> the registers have a latch anyway
[14:41:30] <amee2k> then worst case i'd say you screw up some volatile state that a power cycle would clear up
[14:41:41] <ben1066> Hm, but I have two devices on the SPI in the end
[14:41:46] <ben1066> so I do need a cs line :p
[14:41:48] <amee2k> only conflict i could see is the DAC's MISO pin driver coming up during SPI
[14:42:45] <amee2k> maybe put a 1k into the MISO line between MCU/ISP header and the DAC so the ISP programmer's pin driver will win if they both try to drive the line
[14:44:06] <ben1066> is it really worthwile/
[14:44:32] <amee2k> i'd say not really >_>
[14:44:55] <amee2k> you could put the footprint on and jumper it out unless you get issues
[14:45:10] <ben1066> http://www.kanda.com/avr-isp-circuits.html recomends 4.7k
[14:46:41] <amee2k> sounds like a plan then
[14:50:45] <ben1066> god this schematic is a mess
[14:51:00] <amee2k> yes, thats what schematics usually are
[14:51:01] <amee2k> ;)
[14:51:06] <ben1066> and im hardly half done...
[14:52:07] <ben1066> still need to add a 5 digit 7 seg display
[14:52:10] <ben1066> rotary encoder
[14:52:13] <OndraSter> and you know what's fun? When somebody tells you "do it this way"
[14:52:14] <ben1066> button
[14:52:15] <OndraSter> ergo totally different
[14:52:26] <ben1066> OndraSter: thats not fun :P
[14:52:32] <OndraSter> ...
[14:52:36] <amee2k> OndraSter: i know how that goes... unfortunately from both ends >_<
[14:52:36] <OndraSter> irony? :P
[14:52:49] <ben1066> whats so ironic
[14:52:51] <OndraSter> amee2k, the thing is, my feet are starting to burn slowly lol
[14:52:53] <ben1066> I wasnt really doing it wrong...
[14:52:57] <OndraSter> <OndraSter> and you know what's fun?
[14:52:59] <OndraSter> that was ironic
[14:53:00] <amee2k> o.O
[14:53:23] <ben1066> 74HC595 still best for driving some 7 segs?
[14:53:36] <OndraSter> I'd prefer some constant current LED drivers...
[14:53:40] <OndraSter> but they are not as cheap as 595
[14:53:48] <ben1066> how expensive?
[14:53:50] <ben1066> its a power supply
[14:53:51] <amee2k> OndraSter: having to watch someone draw one ugly son of a schematic that it makes you die inside a little is quite as awkward as having some smartass tell you what to do all the time
[14:53:58] <ben1066> everything else has been overspeced, why not the display too ;p
[14:54:06] <OndraSter> amee2k, I got even whole circuit changes
[14:54:11] <OndraSter> aka separate power supplies etc
[14:54:17] <amee2k> ben1066: for 5 digits you could consider multiplexing
[14:54:41] <ben1066> I was going to use some low power smd transistors or some array to switch the grounds
[14:54:45] <ben1066> cathodes*
[14:54:53] <ben1066> then drive the anodes with a driver
[14:54:56] <amee2k> OndraSter: remember that led board i was happily working on? the other day a friend of mine had a "suggestion" that keeps annoying the fuck out of me
[14:55:04] <ben1066> or vise versa, depending on the display I decide on
[14:55:21] <amee2k> because conceptionally his way makes sense, but i can't find a practical implementation >_<
[14:56:12] <ben1066> http://dl.dropbox.com/u/11197643/halfwaythere.png
[14:56:31] <ben1066> the output still needs current limiting
[14:56:39] <amee2k> ben1066: hmm i remember some TL... something led driver ICs with serial interface... lemme see if i can remember which ones
[14:56:40] <ben1066> and a voltage divider and adc to read the output voltage
[14:56:51] <ben1066> I also still need the led display to come off the avr
[14:56:58] <ben1066> and notet the 3 voltage regulators >_>
[14:57:31] <ben1066> 1 12v, two 5v, to try and isolate the digital 5v from analogue
[14:57:46] <ben1066> seeing as I have 2mv vrefs and such, I want low noise :P
[15:02:10] <ben1066> TLC59281 amee2k ?
[15:05:06] <ben1066> ill just use some 75HC585
[15:05:09] <ben1066> 595*
[15:05:13] <ben1066> simple enough
[15:05:45] <amee2k> ben1066: ben1066 like these but the ones i used only have 8 outputs which was quite handy
[15:06:07] <amee2k> because i used female headers to mount the displays a bit above the board and put the driver IC underneath
[15:06:40] <ben1066> ah..
[15:07:10] <amee2k> i also think it was only a 4-digit number after the "TL"
[15:07:52] <ben1066> meh, 74hc595 + some 0603 resistors
[15:07:56] <ben1066> thatll do me fine
[15:08:30] <amee2k> mmh, i can tell you in two days when i'm back home and can dig out the farnell bill when i ordered them
[15:08:46] <ben1066> you can login go my account my orders
[15:08:48] <ben1066> shows you there..
[15:09:13] <ben1066> Im gonna need 2 pcbs >_>
[15:09:42] <ben1066> one just for the led displays
[15:09:48] <amee2k> i don't have the password and stuff here either
[15:10:05] <ben1066> oh are you one of those silly people with passwords like as;ofuy[ar7[3h80r5a[89sty03t8raojF:*O£^ro;abuhF{*£T'auBNF{*£gtf
[15:10:26] <amee2k> no, i just don't remember passwords that i need three times a year >_>
[15:10:32] <ben1066> Oh :p
[15:10:39] <ben1066> I use farnell a bit more than that...lets see
[15:10:48] <amee2k> i don't have that much money :P
[15:11:01] <ben1066> i dont either, most of my orders are £30 ish
[15:11:29] <ben1066> I USED THEM 4 TIMES :P
[15:11:50] <ben1066> and once this year :P, although recently my rate has increased, which is....bad i think
[15:11:51] <amee2k> mine are generally around 50EUR to make the shipping more cost efficient
[15:12:03] <ben1066> uk gets free next day shipping
[15:12:10] <amee2k> nice
[15:12:30] <ben1066> Im gonna have to use digikey for my next lot though since I need some fancy heatsinks
[15:12:34] <ben1066> have to spend £50 there
[15:12:38] <amee2k> germany always is 6EUR. if there is a free shipping limit it was so high that i forgot it
[15:12:46] <ben1066> but should be able to get away with VAT and import tax...
[15:13:00] <ben1066> free shipping from digikey at £50
[15:13:04] <amee2k> digikey shipping to germany is 18EUR for orders <=65EUR >_<
[15:13:48] <amee2k> i've sent crap to australia for less before
[15:13:54] <ben1066> lol
[15:14:01] <ben1066> Not sure what their shipping non free is
[15:14:08] <ben1066> always make sure i spend enough for free
[15:14:22] <ben1066> "
[15:14:22] <ben1066> Limited quantity available in value add packaging; alternate packaging exists.
[15:14:23] <ben1066> Non-Stock"
[15:14:26] <ben1066> that makes NO sense
[15:14:44] <amee2k> i'll probably order from digi for my next project because they have some neat parts
[15:14:57] <ben1066> Yea, there are bits there I just cant get at farnell
[15:14:57] <amee2k> if i order a dragon too i might make it to the free shipping limit too
[15:14:58] <ben1066> at all
[15:15:19] <ben1066> it costs more to order there
[15:15:27] <ben1066> you suffer from costs quite badly...
[15:15:33] <amee2k> too bad digi doesn't seem to sell buspirates or i'd take one of these too
[15:15:40] <ben1066> Heh
[15:16:06] <amee2k> um... 18EUR for shipping is quite obscene in my book
[15:16:28] <ben1066> the only thing that sucks is
[15:16:29] <amee2k> even across the big pond
[15:16:30] <ben1066> http://search.digikey.com/uk/en/products/VOF-65-24/102-1337-ND/949774
[15:16:34] <ben1066> is .3A too little
[15:16:38] <ben1066> which REALLY annoys me
[15:16:49] <ben1066> I think im just going to use it and hope the magic smoke remains :P
[15:17:05] <ben1066> maybe try and get the voltage output closer to 20V and with a higher amperage
[15:17:22] <ben1066> 65W at 20V gets you just over 3A, 3.25 or so
[15:17:45] <amee2k> lol
[15:18:01] <ben1066> I highly doubt ill draw all 3a anywya
[15:18:18] <OndraSter> why not just grab some PSU from laptop?
[15:18:20] <ben1066> any suggestions for voltage controlled current limiting?
[15:18:24] <amee2k> my little wisdom about pre-made SMP modules is oversize by a factor of two >_>
[15:18:26] <OndraSter> they are cheap on auction sites (original, not chinese copies)
[15:18:49] <ben1066> OndraSter: not really, on ebay they are a few £ cheaper, not enough to be worthwile
[15:18:49] <amee2k> ben1066: shunt + shunt monitor IC + comparator?
[15:18:57] <OndraSter> okay ben1066
[15:19:10] <ben1066> first two bits, i understand, the last, i have never used before
[15:19:11] <ben1066> :p
[15:19:26] <OndraSter> I got 120W PSU for HP docking stations (19.5V, about 6? 7? amps) for 10€
[15:19:39] <amee2k> comparator is much like an opamp but with the linear region mostly designed away
[15:19:52] <ben1066> OndraSter: I need 20V+
[15:19:55] <OndraSter> oh
[15:19:56] <ben1066> most are 19.5V
[15:20:00] <ben1066> go figure >_>
[15:20:05] <amee2k> you can use opamps as ghetto comparators too
[15:20:26] <OndraSter> I needed something about 33V
[15:20:34] <OndraSter> so I grabbed small SMPS board from ebay for $5 or so lol
[15:20:49] <ben1066> They exist, at lower aperages
[15:20:52] <ben1066> which kinda sucks
[15:21:02] <ben1066> its also why I went with an opamp rather than a regulator
[15:21:06] <OndraSter> 33V, 3 - 3.5A was my request :)
[15:21:20] <ben1066> although instead of a regulator with a lot of heat, I have a transistor with a lot of heat >_>
[15:21:30] <amee2k> ben1066: TLC5916!
[15:21:44] <ben1066> TLC5916!
[15:21:49] <OndraSter> TLC5916!
[15:22:19] <amee2k> mh or 5917, i don't remember
[15:22:27] <amee2k> but that was the shift register + LED driver thingy i used
[15:23:40] <ben1066> still seems overkill for what im doing...
[15:24:05] <amee2k> they were like 1.50 on farnell or so
[15:24:23] <ben1066> same for digikey
[15:24:34] <amee2k> ben1066: when the current limit is reached, is the PSU supposed to shut down, or drop voltage in order to keep the current at max?
[15:24:44] <ben1066> drop voltage
[15:24:47] <ben1066> and light an led
[15:25:00] <ben1066> maybe sound a buzzer, although I can imagian that getting REALLY REALLY ANOYING
[15:25:20] <amee2k> the ghetto solution for current limiting is a shunt on the high side with a PNP across
[15:25:40] <ben1066> needs voltage controlled
[15:25:44] <amee2k> the PNP's base-emitter junction goes across the shunt, and the collector to the mid-point of the voltage feedback divider
[15:25:49] <ben1066> so a dac can change it
[15:26:37] <amee2k> when the current is high enough so the shunt drop exceeds a diode drop, the transistor starts conducting and leaks current into the voltage divider, suggesting a false-high output to the regulator
[15:26:49] <amee2k> are you sure you don't want PWM?
[15:27:09] <ben1066> PWM would work sure, but a DAC is a smoother output
[15:27:23] <ben1066> when aiming for 10mv precision TOP then it kinda matters :P
[15:27:54] <ben1066> i guess current isnt that important but w/e
[15:27:58] <amee2k> the eyes pretty much top out at 100Hz and everything above 400-500Hz is pretty much guaranteed to be invisible
[15:28:27] <ben1066> electrically its different...
[15:28:43] <ben1066> and to some things (not sure what but there must be some things) i imagian it matters :P
[15:28:46] <amee2k> is this for some kind of lab equipment? or a led driver for lighting use?
[15:28:59] <ben1066> lab equipment
[15:29:08] <ben1066> the led driver is for the display on the front :P
[15:29:09] <amee2k> hm. i see
[15:29:15] <amee2k> o.O
[15:29:34] <ben1066> power supplies need red on black led displays
[15:29:36] <ben1066> its a fact
[15:29:49] <ben1066> they also need white or black abs cases with fans :Pp
[15:29:58] <amee2k> if it is just for instrumentation lighting, that would count as lighting use ;)
[15:30:11] <ben1066> no
[15:30:14] <amee2k> i meant, lab equipment as in providing clean current regulated DC is the objective
[15:30:21] <ben1066> this is for the output of it
[15:30:25] <ben1066> its a power supply lol
[15:30:32] <amee2k> ah, okay
[15:30:57] <ben1066> 10mv precision would be rediculous for a set of leds :P
[15:31:31] <amee2k> in that case i'd build the current regulation loop the same as the voltage regulator
[15:31:50] <ben1066> and is it me or do agilent actually sell half the product to you and then sell the rest as "accessories"
[15:31:57] <amee2k> just that the feedback input doesn't come from a voltage divider but from a shunt monitor IC
[15:32:37] <ben1066> http://dl.dropbox.com/u/11197643/halfwaythere.png so replace the divider with a shunt monitor ic...
[15:32:41] <ben1066> thats it?
[15:32:44] <ben1066> surely not..
[15:32:59] <ben1066> also wouldnt it become horribly unstable with no divider
[15:33:18] <amee2k> mmh, not replace but add
[15:33:37] <amee2k> add a second error amp and DAC
[15:33:52] <amee2k> and arrange the error amps such that the lower output wins
[15:34:12] <ben1066> right
[15:34:29] <amee2k> the old school approach for that is to put a pull-up on the pass transistor's base and put diodes on each error amp's output, pointing towards the amplifier
[15:34:40] <amee2k> so the error amp that wants to pull the output lower will win
[15:35:53] <amee2k> hmm there also used to be a trick with some diodes to prevent the other error amp that is not driving the control loop from slamming into the opposite rail
[15:36:26] <amee2k> this way it'll be faster taking over the loop because it doesn't need to come out of saturation and slew all the way back to the operating point
[15:37:30] <amee2k> i don't remember how off the top of my head but when it went too low it would turn into a voltage follower and hover one diode drop below the feedback input
[15:43:10] <amee2k> did i kill the conversation again? :P
[15:51:26] <OndraSter> yesyoudid amee2k lol
[15:51:30] <OndraSter> aůů
[15:51:32] <OndraSter> appearantly
[15:51:45] <ben1066> Lol
[15:51:53] <ben1066> sorry, I was researching
[15:51:59] <ben1066> and im tired, its the wrong time to do it :P
[15:52:28] <ben1066> i wish there was a cheaper way for smd stencils
[15:52:34] <ben1066> kapton ones are still pretty pricy
[15:54:01] <amee2k> hehe
[15:54:45] <amee2k> when i'm back home i can post the schematic from my lap PSU
[15:55:13] <amee2k> it is purely analog and adjustable with variable voltage dividers, but the regulation works pretty much the same
[15:56:04] <ben1066> heh alright
[15:56:15] <ben1066> Yea, Ive got the voltage limiting fine, its just current now
[15:56:15] <ben1066> D:
[15:56:41] <ben1066> ive seen a lot of methods with an rsense
[15:56:45] <ben1066> but that doesnt really work :P
[15:56:55] <amee2k> current is pretty much the same as voltage except for where the feedback signal comes from
[15:57:02] <amee2k> why not?
[15:57:56] <amee2k> if you use more than one pass transistor, it is moderately easy because you can use the balancing resistors as shunts
[15:58:02] <amee2k> thats what my PSU does too
[15:59:08] <amee2k> bb in 20-ish... going for a shower while there is still warm water
[16:25:11] * amee2k reappears
[16:32:33] <amee2k> ben1066: is the poti from output to ground, err.. R2 i think, your voltage adjust knob??
[16:35:30] <amee2k> also, i'd use some switching regulator to step down 24V to 9V or something, then put the linear 5V regs on
[16:36:04] <amee2k> 24V is high enough for an MC34063 to do its thing and that one is pretty much dead easy to use imo
[17:13:57] <nofxx> trying to put together a list of serial monitor/terminal software... which one you use?
[17:19:56] <Tom_itx> there's only one
[17:19:59] <Tom_itx> realterm
[17:20:13] <amee2k> hmm cutecom and another one comes to mind
[17:20:22] <amee2k> forgot the name of the second one right now
[17:20:54] <amee2k> gtkterm i think
[17:22:06] <nofxx> Tom_itx, which OS is that?
[17:22:49] <Tom_itx> win
[17:23:18] <nofxx> Tom_itx, thanks, will add it up
[17:23:35] <nofxx> amee2k, installed, give it a try, thanks
[17:24:00] <Tom_itx> more than just a simple term program
[17:24:42] <nofxx> personally I like the scripting language ones... there's a python I forgot and I wrote mine in ruby
[17:24:59] <nofxx> really easy to do stuff "out of the box"
[17:25:04] <Tom_itx> realterm lets you do practically anything
[17:28:46] <Tom_itx> http://realterm.sourceforge.net/
[17:28:51] <Steffanx> hterm nofxx
[17:29:24] <Steffanx> No scripting, but it works (most of the time)
[17:33:54] <nofxx> Steffanx, ty, added too
[18:32:55] <jadew> hey, where can I find the definitions for the DDRx and PORTx registers, when using asm?
[18:35:18] <inflex> the datasheet :)
[18:35:46] <jadew> they're not defined anywhere in winavr?
[18:36:12] <izua> through a chain of includes
[18:43:01] <Guest49151> anyone know how to talk to an atmega where the wrong clock fuse bits have been set?
[18:43:07] <Guest49151> I've got an STK600
[18:43:47] <izua> supply clock in the "wrong" manner?
[18:43:59] <Guest49151> yeah that's what i was thinking
[18:44:01] <izua> it's usually an external clock signal, use a 555, or a different avr (not on the stk600 board)
[18:44:06] <Guest49151> i don't have any signal generators handy
[18:44:09] <izua> since that's value 0000
[18:44:47] <Guest49151> is there any way I can link the stk600 signal to the xtal of the atmega?
[18:45:03] <Guest49151> as in the stk600 produces a clock
[18:45:38] <Guest49151> but linking the "clock" header to the "XTAL1" header doesn't work
[18:47:00] <Guest49151> sorry what's a 555?
[18:47:02] <nevdull> do you have the stk600 clock switch set to INT when using the clock header?
[18:47:19] <Guest49151> no
[18:47:28] <Guest49151> should i?
[18:47:30] <nevdull> yes
[18:47:38] <Guest49151> ok
[18:47:59] <nevdull> set it to EXT to use the clock from the PC software, XTAL to use the onboard crystal, or INT to use the clock header
[18:50:02] <Guest49151> ok so this determines the frequency which the STK600 uses to talk to the MCU?
[18:50:03] <Casper> Guest49151: do you have a second avr?
[18:50:36] <Casper> if you do, you can make an insane led flasher
[18:50:36] <Guest49151> I have other avrs, but they're not hooked up to anything, they're all just to put onto the STK600
[18:50:56] <Casper> as in a led flasher with no delay
[18:51:01] <Casper> that make a good clock source
[18:51:19] <Guest49151> yeah, will probably have to do that
[18:51:28] <nevdull> Guest49151: the clock setting is used as the FCPU setting for the AVR that determines its system clock
[18:52:31] <Casper> F_CPU is not used
[18:52:38] <Guest49151> ok, but as my clock fuse bits are wrong, this is not getting through to the avr
[18:52:43] <Casper> it's inly for the software side
[18:52:56] <Casper> this is why you need to feed an external clock
[18:53:52] <Guest49151> ok, it looks like we have an arduino, hopefully I can use that to make a signal
[18:58:27] <Guest49151> also does anyone know why a bootloader program which works fine on the atmega2560, recompiled for atmega64m1 (no errors/warnings) would not have its interrupts working on the atmega64m1?
[18:58:52] <Guest49151> it was the reason i was messing around with the clock bits in the first place
[19:00:12] <inflex> perhaps you didn't do a clean before the make?
[19:00:16] <nevdull> Guest49151: you can output the atmega328p system clock on the CLKO pin
[19:00:17] * inflex has had that happen in the past
[19:00:31] <nevdull> which is PB0
[19:01:11] <Guest49151> my toolchain makes sure that it always cleans, it deletes all previous outputs and objects and everyhting
[19:01:19] <inflex> okay, np
[19:01:25] <Guest49151> oh thanks nevdull, I'll try that
[19:03:53] <nevdull> Guest49151: re the bootloader: the atmega2560 and the atmega64* have completely different interrupt vector tables
[19:04:22] <Guest49151> hmm i had a look at that
[19:04:41] <Guest49151> i used TIMER1_COMPA_vect for 2560
[19:05:18] <Guest49151> and in the datasheet it had TIM1_COMPA as the name for the 64m1
[19:05:54] <nevdull> check out your AVR compiler include directory for iomxx0_1.h for atmega2561 and iom64m1.h for the atmega64m1 and search for _VECTOR and compare them
[19:05:56] <Guest49151> but the compiler didn't like the TIM1_COMPA_vect, and had no complaints about TIMER1_COMPA_vect
[19:08:33] <nevdull> yah always double check with your atmega header file as its the one that mattters and the header files define TIMER1_*
[19:09:31] <Guest49151> well they have different numbers in the vector tables
[19:09:43] <nevdull> yep
[19:09:48] <Guest49151> but have the same name, so I would have thought the compiler/header files would sort it out
[19:10:23] <nevdull> well, chances are your bootloader is defining the IVT in asm
[19:10:40] <nevdull> and as you noticed, they're different between the two devices
[19:11:50] <Guest49151> but shouldn't the header file map them correctly?
[19:12:30] <Guest49151> i am recompiling, with mcu code atmega64m1
[19:15:51] <Guest49151> oh no, i'm writing the bootloader in C++
[19:16:23] <Guest49151> sorry i didn't know what you meant by my bootloader is difining the IVT in asm
[19:16:49] <Guest49151> I'm writing the bootloader myself
[19:16:53] <nevdull> ah gotcha
[19:17:03] <Guest49151> and i'm not doing any manual IVT definitions
[19:17:45] <Guest49151> unless I'm mistaken, gcc will make one for me (at least it did for the 2560)
[19:18:22] <Guest49151> I had a look at the .map file, it seems to have made one
[19:18:33] <Guest49151> or .out or whatever it was
[19:18:36] <nevdull> yeah, you can trim it down with a linker script
[19:19:32] <Guest49151> yeah, if i need to cut down on space I'll probably have to do it, but at this stage I'm only using 2kB out of the 4 available
[19:20:32] <nevdull> each IVT entry normally takes 4 bytes, so your IVT will take up 4 * (num of interrupts) bytes
[19:21:54] <Guest49151> ok. I've been reading that avrfreaks guide to writing your own bootloader, been really helpful, but I just can't work out why the interrupts are still not working on the 64m1
[19:22:22] <Guest49151> i've had interrupts working on application code before
[19:22:30] <Guest49151> on it
[19:22:40] <Guest49151> in fact was running freertos on it the other day
[19:26:38] <nevdull> Guest49151: could your bootloader-related fuse bits be miset on the 64m1?
[19:28:16] <Guest49151> BOOTSZ0 and 1 are both 0
[19:28:24] <Guest49151> as is BOOTRST
[19:30:26] <Guest49151> it definitely is running the bootloader
[19:30:55] <Guest49151> right now i'm just making it blink an led and then when I push a button it runs the application
[19:31:09] <Guest49151> the problem is the LED doesn't blink
[19:31:13] <nevdull> well that's a start at least
[19:31:30] <Guest49151> it stays solid
[19:31:47] <Tom_itx> maybe it just appears solid
[19:31:55] <nevdull> can you put a logic analyzer or multimeter on the output pin to see if its maybe a clock mismatch and blinking too fast to detect?
[19:31:58] <Guest49151> well, more than that, I've done fairly extensive testing to make sure it's not anything else, and am 99% the ISR is not being called
[19:32:55] <Guest49151> no I've gone and done a PORTD = ~PORTD; for the ISR, this always results in all the LEDs being lit up if the clock's going fast
[19:34:12] <Guest49151> as i said, the exact same program compiled for the 2560 works fine
[19:34:49] <Guest49151> there have been some other now resolved issues, such as trying to use porta for the button
[19:34:53] <Guest49151> when there is no porta
[19:36:18] <nevdull> can you run your *.elf file through a simulator/debugger and look at the interrupt registers and program counter address?
[19:36:47] <Guest49151> i may have to do that
[19:37:12] <Guest49151> i'm doing it all on linux, but am dual booting windows so can run avrstudio
[19:37:51] <nevdull> you can try simavr on linux
[19:37:59] <Guest49151> oh
[19:38:02] <Guest49151> never heard of it
[19:38:12] <Guest49151> is it good?
[19:38:22] <nevdull> then run that output through gtkwave to get a visual of what's going on
[19:38:25] <nevdull> yeah i like it
[19:39:00] <Guest49151> cool thanks, I'll give that a go, once I get my clock fuse bits set right again :S
[19:39:05] <nevdull> :)
[19:49:55] <jadew> can someone see what's the problem with this code? http://pastebin.com/3FKc2ws6
[19:53:07] <Casper> are you sure you can use R16 in out?
[19:53:58] <Kevin`> that code won't do anything except set all the pins high. is that what it's supposed to do?
[19:54:03] <jadew> don't know, didn't find any info on registers, I figured they are similar with the ones on x86, and I can't use anything below 15
[19:54:14] <jadew> Kevin`, yeah
[19:54:17] <jadew> but it's not working
[20:19:15] <Tom_itx> r16 should be ok
[20:20:03] <Tom_itx> jadew what are you trying to do?
[20:20:26] <jadew> to get a confirmation that the code works
[20:20:49] <jadew> at this point I just want to compile a simple asm code and run it
[20:20:54] <Tom_itx> just what you pasted?
[20:20:57] <jadew> yeah
[20:21:05] <Tom_itx> is this your first asm?
[20:21:11] <jadew> for avr
[20:21:40] <Tom_itx> you should have some init stuff at the beginning i think
[20:21:54] <Tom_itx> lemme point you to some samples i did
[20:22:00] <jadew> thank you
[20:22:03] <Kevin`> is there some reason you are using asm? c works nice on avr
[20:22:08] <Tom_itx> what chip is it?
[20:22:17] <jadew> here's the makefile I'm using: http://pastebin.com/uf4yKBxW
[20:22:21] <jadew> t2313
[20:22:22] <Tom_itx> Kevin`, i did it just to learn
[20:22:40] <jadew> I want to see how much faster can it get
[20:24:12] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/blinkled/asm/interrupt/
[20:24:16] <Tom_itx> there's one
[20:24:22] <Tom_itx> there are others in the avr dir
[20:24:39] <jadew> thanks
[20:25:05] <Tom_itx> you can get the chip header files from studio
[20:25:09] <Tom_itx> if you need one
[20:25:23] <Tom_itx> the .inc files
[20:25:36] <jadew> that would be helpful
[20:25:40] <jadew> didn't know where to find them
[20:25:51] <Tom_itx> do you have studio?
[20:25:55] <jadew> I don't have avr studio tho
[20:25:58] <jadew> no, is it free?
[20:25:59] <Tom_itx> hang on
[20:26:01] <Tom_itx> yes
[20:26:19] <jadew> I'll just download it then, thank you for the tip
[20:26:32] <Kevin`> there should be equivalent files included with avr-libc
[20:26:42] <jadew> I couldn't find them
[20:27:22] <Tom_itx> it's the avrassembler2/appnotes subdir
[20:27:27] <Tom_itx> i can paste it if you want
[20:27:37] <Tom_itx> is it a 2313a or plain?
[20:27:42] <jadew> plain
[20:27:50] <Tom_itx> one sec
[20:27:53] <Kevin`> jadew: http://www.nongnu.org/avr-libc/user-manual/assembler.html
[20:28:31] <jadew> Kevin`, I don't like this: _SFR_IO_ADDR(PORTD)
[20:28:49] <Kevin`> jadew: so don't use it
[20:29:07] <jadew> why are they using it?
[20:29:17] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/studio/
[20:29:20] <Tom_itx> it's in there
[20:29:27] <Tom_itx> tn2313def.inc
[20:29:33] <jadew> thank you
[20:30:01] <Tom_itx> so is studio4 btw
[20:30:34] <Tom_itx> my router seems sluggish tonight though
[20:30:39] <jadew> by looking at the inc file I can see that my port definitions are fine
[20:30:53] <Tom_itx> you should set up the ram space though
[20:31:00] <Tom_itx> like the sample file
[20:31:10] <jadew> let me check
[20:32:46] <Tom_L> .org 0
[20:32:46] <Tom_L> rjmp reset
[20:32:46] <Tom_L> reset:
[20:32:46] <Tom_L> ; setup stack pointer
[20:32:46] <Tom_L> ldi r16, low(RAMEND)
[20:32:47] <Tom_L> out SPL, r16
[20:32:47] <Tom_L> ldi r16, high(RAMEND)
[20:32:48] <Tom_L> out SPH, r16
[20:32:55] <jadew> yeah, saw it
[20:32:56] <Tom_itx> or similar
[20:33:39] <Kevin`> setting up the stack should only matter if you use it, no?
[20:33:46] <Tom_itx> probably
[20:33:56] <Tom_itx> but i figured i'd get him a template to go from
[20:34:16] <Tom_itx> your code is just gonna recursively jump to loop right?
[20:34:17] <jadew> that's what I was thinking, especially since I'm not triggering any functions
[20:34:21] <jadew> yeah
[20:34:23] <Tom_itx> it's not really doing anything
[20:34:38] <Tom_itx> so how do you know if it works or not?
[20:34:46] <jadew> I measure the pin output
[20:34:50] <Kevin`> one of the pins is driven high
[20:35:03] <Kevin`> but yeah, do something that actually does something
[20:35:20] <jadew> did that at first and it didn't work :P
[20:35:42] <inflex> hrmm... replaced my 7805 and things are almost back up
[20:35:51] <inflex> but now the CD won't spin, but the motors are fine
[20:43:25] <Valen> inflex: wth are you doing with a cd and a 7805
[21:08:45] <inflex> aw feck... looksl ike it's something with the decoder :(
[21:08:55] * inflex can put 5V on the motordrive control line and the CD spins up...
[21:27:04] <rue_house> nobody wants to hook ISA cards up to their avrs?
[21:27:09] <rue_house> like VIDEO cards?
[21:27:15] <rue_house> NETWORK cards?
[21:27:18] <rue_house> no?
[21:27:43] <rue_house> rue rue, what about serial cards, tell them about the serial cards
[21:27:53] <rue_house> dude, pls, some things are obsolete ya know
[21:28:21] <eatyourguitar> old = free
[21:28:29] <eatyourguitar> free is for me :)
[21:30:29] <eatyourguitar> but if you already have an ISA video card why not just leave it in the computer and turn it into an IRC server or linux box for test compiling stuff
[21:32:55] <Kevin`> some isa chips are useful for microcontrollers, but it's not exactly a common thing to get
[21:36:14] <eatyourguitar> this is the first time I heard of it.
[21:36:37] <eatyourguitar> I guess the serial speeds were slower back in the day of ISA
[21:39:20] <Kevin`> isa is a parallel bus, not serial
[21:43:18] <timemage> eatyourguitar, iirc, the baud rate divisor for a PC only accomodated speeds to 115200 and that was sort of the api of sorts.
[21:44:26] <eatyourguitar> so parallel meaning 8 bits/clock cycle?
[21:46:12] <Kevin`> eatyourguitar: or 16, yeah. and seperate address and data too
[21:47:10] <eatyourguitar> I remember the foooking good old days. IRQ numbers and shit
[21:48:13] <eatyourguitar> I hated IRQ conflicts
[21:48:34] <timemage> eatyourguitar, had prove to someone that they're modem was fine by wiggling their mouse once. =)
[21:48:40] <timemage> err, their
[21:49:11] <inflex> gnarr... CDplayer can't decide between a sled fault or a focus fault
[21:49:18] <eatyourguitar> some soundcards were not compatible with older motherboards cause the mouse IRQ was the same as the new soundcard.... FAIL
[21:49:34] <Kevin`> timemage: "but the mouse isn't connected to the modem, you wiggling it over the phone line doesn't prove anything, silly"
[21:49:42] <timemage> Kevin`, hehe
[21:50:40] <eatyourguitar> oh snap, I get it, you mean with trojans and stuff. yeah I wiggled a mouse or two when I was a little punk ass kid
[21:50:42] <timemage> Kevin`, fortunately the guy i was showing this too was relatively bright and he had known about irq setting at one point earlier, was just out of business for a while.
[21:52:24] <eatyourguitar> remember BO and subseven. you could move someones mouse and click on porn while they were on the computer lol
[21:54:02] <eatyourguitar> send stupid popup messages from windows telling them to feed the cat with the cats real name in the windows message. this had me ROFL when I see him reboot. nope that wont fix it
[21:57:28] <nofxx> Collection of scaffolds for avr fun! https://github.com/nofxx/avr_scaffold
[21:57:57] <nofxx> each one blinks the led, on just choose pure C, mixed C/CPP, mixed + arduino libs
[21:58:05] <nofxx> one just choose*
[22:00:38] <nofxx> would be nice to add some testing... but never did on C, do you use any libs? Ceedling? CMock, Unity, CException...
[22:48:35] <jadew> Tom_itx, my code worked fine in avrstudio
[22:50:09] <Kevin`> jadew: compare the makefile it's using, or at least the commands it prints in the console when compiling
[22:50:33] <jadew> well, it's using a different assembler
[22:53:59] <jadew> I didn't know atmel was so awesome and they used visual studio, else I would have gone for avrstudio since the begining
[22:54:24] <jadew> I thought they're using some eclipse crap or something similar so I decided to stay with winavr and notepad
[22:58:05] <Kevin`> notepad? icky
[22:58:13] <jadew> well, notepad++
[22:58:27] <jadew> I take that anytime over a java based IDE
[22:58:45] <Kevin`> I don't use avr studio myself much since I do most everything on linux, but if i'm on windows for some reason, notepad isn't much of a comparision
[22:59:19] <jadew> deffinitely
[23:00:34] <rue_house> I use nedit, it has a few good features
[23:00:52] <jadew> don't know it, win or nix?
[23:01:20] <jadew> ah, it's for linux
[23:01:26] <jadew> on linux I like geany
[23:03:01] <rue_house> the 8254 is a great chip to generate pwm with, but hte interface just SUCKS
[23:06:20] <rue_house> A program must not transfer
[23:06:20] <rue_house> control between writing the first and second byte to another
[23:06:20] <rue_house> routine which also writes into that same Counter. Otherwise,
[23:06:20] <rue_house> the Counter will be loaded with an incorrect count.
[23:07:09] <rue_house> I think they are saying that every time you want to access the counter, read or write, you need to reload the control word
[23:07:28] <keenerd> jadew: PSPad is the best free text editor I've found for Windows. (Assuming you are not a strong Vim or Emacs user, natch.)
[23:07:29] <rue_house> which would be a typically annoying hoop req'd for this chip
[23:08:02] <jadew> keenerd, haven't tried that one, will give it a go, I'm looking to switch my editor for a while already