Back
[01:07:24] <alabd> Good day all , will be so thankfull if you guide at
http://electronics.stackexchange.com/questions/22951/communication-between-avr-and-crous-ptz-device
[03:34:05] <abcminiuser> Heh
[03:35:22] <ziph> abcminiuser: Heya!
[03:35:36] <ziph> abcminiuser: Get your thesis in? :)
[03:36:08] <abcminiuser> ziph, yeah, presented Monday
[03:36:23] <abcminiuser> Missed out on the special industry presentation tonight as I've now got a cold and don't have a voice
[03:36:33] <abcminiuser> But a lecturer demo'd it for me
[03:36:46] <abcminiuser> Apparently I won a prize, and just got an email from a company that's interested in it
[03:38:31] <inflex> oh nice abcminiuser
[03:40:20] <abcminiuser> Yeah, wonder if said prize is the usual paperweight with a name on it, or if it's actually useful?
[03:40:47] <abcminiuser> I like trophies (since I'm useless at sports, can't get them any other way) but I wouldn't mind more free gear
[03:48:30] <abcminiuser> Speaking of which, I should probably give away some of my stuff, before I move
[03:50:28] <KebabBob> ahoy there
[03:50:36] <KebabBob> What was your thesis about?
[03:52:23] <abcminiuser> KebabBob, an Embedded Bluetooth Stack implementation for resource constrained devices
[03:52:30] <abcminiuser> www.fourwalledcubicle.com/ExplorerBot.php
[04:03:44] <karlp> it was more about the bluetooth than the robot right?
[04:22:47] <abcminiuser> karlp, yes
[04:22:57] <abcminiuser> The robot was to satisfy the hardware component of it
[04:23:02] <abcminiuser> But the stack was the main bit
[04:33:55] <tlvb> if I have PORTC |= _BV(PC1); PORTC |= _BV(PC2); does the compiler optimize it together into PORTC |= _BV(PC1)|_BV(PC2) ?
[04:41:34] <karlp> tlvb: maybe. best to check the generated code.
[04:43:19] <abcminiuser> karlp, no
[04:43:26] <abcminiuser> PORTC is marked as volatile
[04:43:37] <abcminiuser> So it will produce the exact code sequence you have given it
[04:43:54] <abcminiuser> It will never optimize the two together, even if they are logically equivalent
[04:44:54] <tlvb> I see
[04:45:07] <tlvb> that is good to know
[04:47:51] <abcminiuser> Woo, apparently I won "Best use of a Microcontroller", trophy and $200
[04:47:54] <abcminiuser> I'll take it :P
[04:50:40] <tlvb> nice
[04:51:09] <tlvb> what was the winning use?
[04:51:22] <ziph> abcminiuser: The company was interested in the stack, or the robot itself? :)
[04:51:30] <abcminiuser> ziph, the stack
[04:51:41] <abcminiuser> Was asking about getting it certified for use
[04:52:03] <abcminiuser> tlvb, my robot - embedded bluetooth stack, some i2c sensors, motors, etc
[04:52:42] <tlvb> cool
[04:54:31] <ziph> abcminiuser: Certified? That'd be a challenge given the limitations wouldn't it?
[04:56:35] <abcminiuser> ziph, yes, very much so
[04:56:41] <abcminiuser> No way it'll ever certify really
[04:56:53] <abcminiuser> Compatible yes, but not certified
[04:57:13] <ziph> abcminiuser: Offer to do it for an ARM Cortex for $150/h. ;)
[05:00:28] <abcminiuser> Hehe
[05:21:37] <amee2k> what is it with everyone going nuts for QFN lately?? >_<
[05:21:55] <mrfrenzy> QFN is nice
[05:22:32] <amee2k> SOIC is nicer imo
[05:23:20] <amee2k> i don't like packages with pads underneath
[05:26:24] <amee2k> at least they could use QFP more often... thats still more social for hand soldering than QFN
[05:38:45] <karlp> what does "certified" mean?
[05:39:38] <karlp> QFN has better thermal behvaiour right? (aside from just being smaller)
[05:51:39] <amee2k> karlp: yeah, qfn has a huge thermal pad on the underside, but incidentially that doesn't make soldering easier too
[06:08:31] <abcminiuser> karlp, "certified" means you paid an organisation a lot of money to confirm that you adhere to the published specifications
[06:08:42] <abcminiuser> "Compatible" means you went "yup, seems to work"
[06:09:12] <abcminiuser> While "certified" means it's gone through all the releveant testing phases and found to be correct according to the standard
[06:09:36] <ziph> abcminiuser: You're going to give away your worldly possessions with competitions? :)
[06:11:10] <abcminiuser> ziph, just some
[06:11:18] <abcminiuser> A man doesn't need 8 Micropendous boards I guess
[06:11:20] <Regenschein> hi
[06:11:20] <tobbor> Regenschein! like, totally tell us about the project!
[06:11:32] <ziph> abcminiuser: Hah.
[06:11:34] <Regenschein> :)
[06:12:13] <abcminiuser> Regenschein, tobbor is actually a huge jerk, avoid him
[06:12:20] <abcminiuser> He hates people
[06:12:32] <Regenschein> well.. I don't mind. thanks :)
[06:12:40] <abcminiuser> (It's a bot)
[06:15:11] <Regenschein> I assumed that
[06:24:08] <karlp> abcminiuser: sure, but certified should just mean lots of money on testing right? or do you really think it would never be able to pass the tests?
[06:24:40] <abcminiuser> karlp, some of the design choices I've made means it won't pass some of the more esoteric requirements
[06:24:47] <abcminiuser> It'll past lots of them, but not all
[06:25:05] <abcminiuser> One requirement is that if the L2CAP layer gets two identical requests, it must send two identical responses
[06:25:16] <ziph> You said at one point you really needed lots of malloc'ed memory to handle it didn't you?
[06:25:25] <abcminiuser> However, since RAM is at a premium, I don't cache the outgoing packets and just update the internal state immediately
[06:25:44] <abcminiuser> So when the second request is processed, the channel structures will be in the modified state and a different response will be generated
[06:25:53] <tlvb> I'm not sure how to state this question;
http://pastebin.com/iEn8yXyf ...I have foo.{c,h} where I have a variable declared that I want to be global. Therefor I have an extern declaration in the h file and use #ifndefs and #defines to occlude it when foo.c is compiled, basically, should the #undef at line 28 be present?
[06:26:02] <abcminiuser> ^ Yes ideally, but my stack uses no heap allocations
[06:26:33] <abcminiuser> tlvb, you don't need to guard the externs
[06:26:38] <ziph> tlvb: Do extern uint8_t foo_var in the .h and just "uint8_t foo_var" in the .c.
[06:27:02] <ziph> tlvb: The second definition in the .c file won't care about the extern declaration in the .h file.
[06:28:12] <tlvb> ...that actually worked, I had some trouble with this some time ago where the compiler complained about double definitons, but that must have been some other error... o_O
[06:28:48] <ziph> tlvb: The extern ... adds it to the symbol table, a non-extern one actually allocated memory for it in the .o that gets compiled from the .c
[06:31:14] <tlvb> yeah, I kind of know that, altough not with the correct terminology, although I wrongly concluded earlier that an externd and nonextern declaration would clash if present at the same time or something
[06:31:34] <tlvb> hmm, it seems that although is the word of the day
[06:32:11] <ziph> Nup.
[06:32:55] <ziph> C doesn't really care how many times something is declared as long as the declarations are consistent.
[06:40:03] <tlvb> I have also (as you can see in the pasted example) the habit of putting #ifndef foo_h / #define foo_h / ... / #endif in my h files, is this also something that is unneccesary?
[06:43:56] <ziph> tlvb: Yes, that's good practice. You may want to make it something like #define __FOO_H__ though.
[06:44:25] <ziph> tlvb: That way there's little risk you'll use __FOO_H__ accidentally as a variable name or something.
[06:44:44] <ziph> tlvb: Where is file_h or something similar might accidentally get used as a variable and then killed by the preprocessor. :)
[06:45:02] <tlvb> actually, what I would use is FOO_H, and I never use caps for variables, only for #defines
[06:45:19] <ziph> tlvb: And #endif /* __FOO_H__ */ at the bottom will make it clear what the last endif does.
[06:45:44] <ziph> tlvb: Some people go overboard and do a commend for every #endif, but I only do them when the matching #if is several pages prior.
[06:45:51] <tlvb> yeah, although (word of the day!!) currently my headers are not complex/big enough that there would be any confusion
[06:46:38] <grummund> hmm, shouldn't be using leading underscore in macro names
[06:47:13] <grummund> #define FOO_H or #define INCLUDED_FOO_H is better me thinks
[06:48:19] <ziph> grummund: It's very common to do so.
[06:48:33] <grummund> that doesn't make it right
[06:49:34] <ziph> grummund: It prevents collisions with configuration defines.
[06:50:10] <grummund> huh?
[06:50:17] <grummund> so does INCLUDED_FOO_H
[06:50:37] <ziph> Well, if you use that.
[06:51:09] <ziph> I can see INCLUDE_FOO_H colliding in a large project with many developers. :)
[06:51:44] <grummund> no more so than __FOO_H__
[06:52:47] <tlvb> #define INCLUDED_FOO_H_DEVELOPER_NAME_HERE_DATE_HERE ? :p
[06:52:58] <grummund> anyway, it's not the worst sin ever... but i think if you're offering advice on best practice then using reserved names is best avoided :P
[06:53:00] <ziph> And AVR libc does it, and the other rule I go by is to use the style of the largest framework/library you're using.
[06:53:13] <ziph> Reserved names?
[06:53:24] <grummund> but avr-libc is allowed to do so, aiui.
[06:53:44] <karlp> whee, itead is sending me a christmas gift!
[06:54:02] <karlp> I think that's the first time I've got anything in any of these online promo things
[06:54:37] <tlvb> can I use extern on PROGMEM variables as if they were normal variables?
[06:55:15] <ziph> Nope.
[06:55:57] <tlvb> hm, I almost suspected that...
[06:56:08] <ziph> tlvb:
http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html
[06:56:46] <ziph> tlvb: Have a browse through
http://www.nongnu.org/avr-libc/user-manual/modules.html, most of the things you need to know for AVR programming are one link from the page. :)
[06:57:17] <karlp> but you can have "int PROGMEM someconst" in one file, and "extern int someconst" in another right?
[06:57:34] <tlvb> I use it a lot for checking ISR names, but I'm kind of bad at searching for really really specific stuff
[06:57:51] <ziph> Yeah, but you need to make sure the qualifiers related to PROGMEM are on your extern declaration as well.
[06:58:27] <ziph> (And any pointers you might assign the PROGMEM addresses to)
[06:59:15] <ziph> LUFA uses #ifndef __LUFA_FUNCATTR_H__ style too.
[06:59:20] <ziph> I think the __'s win. ;)
[06:59:38] <grummund> ziph: sorry but that's just wrong
[06:59:45] <ziph> grummund: Why?
[06:59:58] <grummund> because the C standard says so. period.
[07:00:07] <ziph> Where?
[07:00:28] <tlvb> you would also well make note of that vim is the best editor there is
[07:00:46] <ziph> Nah, that's emacs.
[07:00:47] <ziph> ;)
[07:01:17] <abcminiuser> Single underscore is reserved for libraries, double for compiler
[07:01:25] <abcminiuser> But for include guards, I say use either
[07:02:38] <ziph> Are they talking about the preprocessor, or symbols?
[07:04:29] <grummund> any symbol
[07:05:03] <grummund> (and fwiw, i'm not convinced about the library vs. compiler distinction)
[07:05:26] <ziph> A macro name isn't a symbol. :)
[07:05:44] <grummund> s/symbol/identifier/
[07:05:52] <grummund> 12:55 < grummund> Is leading underscore permitted for header guard on a library header file (3rd party, not supplied by the compiler implementation)?
[07:05:55] <grummund> 12:55 < DuClare> No
[07:06:50] <ziph> The processor doesn't deal with identifiers either.
[07:07:25] <grummund> whatever... it's still not allowed. :P
[07:07:41] <ziph> Because DuClare claims it is in the standard? :)
[07:08:08] <grummund> no, because the C standard says so.
[07:12:34] <ziph> The restriction is for symbols, not the preprocessor. :)
[07:42:03] <tlvb> I have now split my project into 11 c and h files!
[07:44:45] <jakllsch> fancy
[07:46:34] <tlvb> indeed
[08:17:34] <tlvb> ...this is strange; my clock code that previously worked has now for some reason decided that the tens digit of the minute field should count backwards :S
[08:19:01] <tlvb> hm, no, how it counts seem to depend on how fast I run the update animation too
[08:19:15] <grummund> congratulations you built a time machine
[08:20:11] <ziph> Don't forget to pick up some bank notes from 1955!
[08:21:45] <tlvb> now it just updates wrongly... this is very odd
[08:29:37] <inflex> did you harvest any cronotons lately? Perhaps you've started creating time-skips
[08:31:01] <tlvb> I don't think so... I use regular breakfast cereal
[08:35:17] <tlvb> I really do NOT want memory corruption :(
[08:42:29] <tlvb> hm, I actually may have found the bug...
[09:01:01] <tlvb> don't take interrupt driven code and put it in the main loop without some kind of iteration limiter =_= stupid, stupid
[09:12:10] <Kevin`> what does the letter+number at the end of the xmega part numbers mean? eg A4
[09:15:17] <inflex> feature catagory afair
[09:15:29] <inflex> eg, the D series is a more budget/simplified one
[09:16:10] <Kevin`> yeah, but what do they actually mean? where's the table?
[09:18:59] <inflex> aw hell, I was reading it the other day
[09:19:05] <inflex> it's on the Atmel site, I know that much :p
[09:22:29] <mrfrenzy> anyone knows about contactor ratings?
[09:25:57] <inflex> on relays?
[09:26:19] <charolastra_> hi, what would be some standart resistor values with which to construct a voltage divider that takes 6V down to 5V?
[09:26:46] <specing> charolastra_: 1:6
[09:26:49] <specing> err
[09:26:50] <charolastra_> uhm, wrong channel
[09:26:51] <specing> 1:5
[09:27:38] <charolastra_> yes, the ration; but i need some standart resistor values; i already used my variable resistor for the other voltage divider
[09:27:50] <specing> charolastra_: R = U/I
[09:36:19] <charolastra_> specing: i found a 10kOhm resistor but i can't find a 2kOhm one; that's what i meant
[09:37:30] <specing> paralell them
[09:37:36] <Kevin`> I bet someone makes a calculator for this
[09:38:10] <charolastra_> about time
[09:39:36] <specing> charolastra_: If you have 6 10kOhm ones, you can serialise 5 of them to make the required 50kOHm
[09:40:57] <charolastra_> are you joking?
[10:35:32] <moe3> hi
[10:36:03] <moe3> ist it possible with the avr-gcc compiler to define that const variables should not be saved in RAM?
[10:41:08] <grummund> moe3: no, but you can use PROGMEM instead.
[10:43:33] <theBear> or just jam 'em in the/a eeprom and read 'em out manually in your code
[10:43:44] <moe3> i have a code where a lot of const chars are used
[10:44:00] <moe3> but i have not enough memory to run this on my µC
[10:44:22] <moe3> is there a simple way to get it run withou using RAM for the consts
[10:44:30] <theBear> depends what they are as to what makes most sense, and also how big they are and how much of various memories you have available/free
[10:45:25] <theBear> and how quick you gotta grab them, and if so, how many at a time
[10:45:41] <grummund> http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html
[10:45:42] <grummund> http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_flashstrings
[10:45:49] <grummund> http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array
[10:46:15] <moe3> they are ca. 2000 consts
[10:46:30] <moe3> with pgmspace i have to recode the program
[10:46:41] <moe3> I dont want to do that. Isnt there a simpler solution
[10:46:52] <grummund> not with avr, sorry.
[10:47:00] <moe3> f.e. a option in the compiler to make a const to a define
[10:47:29] <moe3> ok thx
[10:49:42] <karlp> well, one simpler solution is a bigger processor :)
[10:49:51] <karlp> otherwise, well, yes, you will have to recode.
[10:50:02] <karlp> you can't just wave a wand at it
[10:52:40] <moe3> but its just a compiler thing. cant the gcc just interprete a const a static text ?
[10:54:06] <karlp> it's not just a compiler thing.
[10:54:12] <karlp> your constants go in the .data section
[10:54:19] <karlp> to be useful on avr, that had to be loaded into ram.
[10:54:39] <karlp> if you want to put them in flash, and read them from flash on every access, you need to use pgmspace, or manually read them from eeprom
[10:55:16] <karlp> bear in mind, this _will_ have a performance impact.
[10:55:35] <karlp> are you sure you need 2000 different constants?
[10:56:30] <Kevin`> brute force programming :)
[10:58:45] <grummund> gcc can locate const in flash, just not on avr. :p
[10:59:11] <theBear> oh i know, i've don eit
[10:59:29] <theBear> 2000 constants sounds like a lookup table to me
[11:03:33] <moe3> yes, its a c code for a renesas controller. it seems the const thing is different there
[11:03:47] <moe3> and this code has 2000 consts
[11:04:42] <moe3> my avr even its bigger then the renesas hasnt enough ram for it. so the problem must be the consts
[11:05:32] <moe3> sorry I forgot some words there
[11:08:11] <grummund> editor search and replace: const int foo = n; --> #define foo n
[11:12:44] <ElMonkey> hmm, anybody have a good idea on how to implement a running clock on an avr that resolves down to a few milliseconds?
[11:14:47] <Kevin`> ElMonkey: timer overflow interrupt and a counter? I don't see the problem actually, milliseconds are quite long
[11:24:06] <ElMonkey> Kevin`, maybe that is the best way
[11:24:28] <moe3> http://winavr.scienceprog.com/short-introduction-to-c/constants-in-c-language.html
[11:24:39] <ElMonkey> i was just looking at some sample code, and thought i could modify the RTC impl to read out a counter register inline
[11:24:54] <moe3> Quote:By identifying the variable as constant will cause compiler to store this variable in program memory rather than in RAM
[11:24:59] <moe3> WTF
[11:25:05] <ElMonkey> but i havent even the faintest clue how much latency is involved with reading IO registers vs interrupts
[11:25:12] <ElMonkey> so probably premature optimization
[11:26:57] <moe3> @grummnd: Why is the avr page saying somethin different?
[11:32:59] <grummund> moe3: in what sense?
[11:33:16] <moe3> By identifying the variable as constant will cause compiler to store this variable in program memory rather than in RAM
[11:33:27] <grummund> where does it say that?
[11:33:33] <moe3> this stands on the site i linked
[11:33:52] <moe3> but you said, the const will be in .data
[11:37:16] <moe3> why do they say that on this page if its wrong?
[11:44:45] <moe3> grummund?
[11:45:35] <grummund> i could be wrong... but i think the page is not strictly correct.
[11:45:48] * grummund checking...
[11:49:11] <moe3> thx for checking!
[12:00:13] <moe3> grummund, any ideas ?
[12:01:06] <grummund> yes gcc locates const in .data
[12:14:07] <grummund> moe3: i'm fairly confident that website is incorrect. it would be nice to be proven wrong though ;)
[12:15:29] <grummund> moe3: although it doesn't spefically mention AVR. so it is correct for some other architechtures.
[12:17:19] <grummund> moe3: however if you define the consts in the same file as where they are used then gcc should optimise so as not to use ram.
[12:19:13] <grummund> with -Os
[13:18:05] <titona> Hi
[13:18:43] <Steffanx> lo
[13:19:03] <titona> lo as in hello?
[13:20:31] <Steffanx> Lo as in not Hi and Hello :)
[13:24:33] <titona> Ohh :-D
[13:29:41] <titona> Not much going on here?
[13:30:10] <Steffanx> Currently.. no
[13:44:37] <titona> Sounds a bit boring
[14:17:16] <amee2k> http://ompldr.org/vYmozOQ/driver2.png << this is the generic boost converter configuration of an MC34063 applied to a power LED driver -- anyone think this modification to improve efficiency of the power switch driver could actually work?
[14:18:57] <amee2k> the idea was to use a small secondary winding on the main inductor that works as a forward converter to add feedback. R3 + C5 will allow to the power switch to turn on, then feedback through L1/L3 provides the main drive
[14:21:15] <amee2k> this way the drive current only cycles through L3, U1, through ground, D11 and back to L3; taking R3 out of the power switch drive circuit which is the primary cause of driver loss in this circuit
[14:22:52] <amee2k> simulation indicates dissipation in R3 decreases from just under a watt to ~150mW
[14:25:43] <amee2k> any ideas?
[14:26:34] <Steffanx> Yes, but my idea's wont help you
[14:26:41] <Steffanx> So, no
[14:26:46] <amee2k> why not?
[14:28:38] <amee2k> considering whether this has enough chances of success to build a prototype
[14:50:23] <scuzzy> RikusW: hey!
[14:51:26] <RikusW> hi
[14:51:27] <tobbor> RikusW! like, totally tell us about the project!
[14:51:30] <Steffanx> hi
[14:51:37] <Steffanx> YANKIE
[14:51:45] <Steffanx> I mean CANUCK
[14:51:46] <tobbor> yankie, yankie, yankie.
[14:52:01] <scuzzy> how you doing man?
[14:52:03] <scuzzy> is it raining thee?
[14:52:18] <RikusW> not today
[14:52:23] <Steffanx> thee = tea :P
[14:52:25] <RikusW> or only a little
[14:52:45] <RikusW> scuzzy: how is it over there ?
[14:52:53] <scuzzy> perfect sunny days
[14:53:21] <RikusW> tested LUFACDC a bit ?
[14:53:47] <scuzzy> not today, I did a bit last night
[14:53:54] <scuzzy> work was busy today
[14:54:00] <scuzzy> when work is quiet, I work on my AVR projects
[14:54:07] <scuzzy> but, my boss was on my case today
[14:54:11] <scuzzy> so, I had to crank out teh code
[14:54:13] <RikusW> my father caught 2 little caracal kittens today ;)
[14:54:17] <Steffanx> poor scuzzy
[14:54:31] <scuzzy> Steffanx: yeah, poor me!
[14:54:37] <Steffanx> That is a good thing RikusW ?
[14:54:46] <scuzzy> RikusW: what? what are caracal kittens?
[14:54:55] <Steffanx> lynx-ish creature..
[14:55:00] <scuzzy> Ahhh right
[14:55:15] <scuzzy> RikusW: gonna keep em?
[14:55:17] <RikusW> rooikat
[14:55:34] <RikusW> scuzzy: there is probably somebody who wants them
[14:55:54] <scuzzy> right
[14:55:56] <Steffanx> It's a wild animal.. someone wants that as a pet?
[14:55:58] <scuzzy> they can get pretty big no?
[14:56:04] <RikusW> yes
[14:56:13] <RikusW> Steffanx: they do get tame...
[14:56:14] <scuzzy> I remember seeing a few around my ouse
[14:56:21] <Steffanx> Tame or .. less wild RikusW ?
[14:56:26] <scuzzy> they tend to lurk in the mountains
[14:56:42] <Steffanx> Even our tame cat bites me once in a while :P
[14:57:33] <scuzzy> it's amazing what you see when you spend a lot of time in the mountains
[14:57:51] <Steffanx> No mountains here :)
[14:58:05] <scuzzy> that sucks
[14:58:28] <Steffanx> NL is flat.. very flat
[14:58:35] <RikusW> Table mountain down there...
[14:59:04] <scuzzy> yeah
[14:59:09] <scuzzy> I live like at the base just about
[15:01:57] <Steffanx> I should go it SA once ..
[15:02:53] <scuzzy> http://maps.google.co.za/?ll=-34.026272,18.360901&spn=0.06203,0.132093&t=p&z=14&vpsrc=6
[15:03:03] <scuzzy> that's the area I live in, you can see how the terrain looks
[15:03:22] <Steffanx> Even google streetview overthere
[15:03:43] <scuzzy> yup
[15:03:48] <Steffanx> Whoa, me is jealous
[15:06:39] <RikusW> Steffanx: you don't have streetview ?
[15:06:48] <Steffanx> I mean.. the location
[15:06:55] <RikusW> ah
[15:06:59] <Steffanx> Nice mountains, nice sea
[15:07:10] <RikusW> cold water...
[15:07:35] <Steffanx> I don't care about the water temp.
[15:07:39] <RikusW> and very windy....
[15:07:58] <RikusW> rainy winters, no frost
[15:08:22] <Steffanx> Like here 200days/year? :P
[15:09:24] <scuzzy> lol
[15:09:30] <scuzzy> how do you know it's windy?
[15:09:35] <scuzzy> it's not half as bad as people say
[15:10:02] <scuzzy> RikusW is just jealous
[15:10:06] <RikusW> scuzzy: I used to live in Bredasdorp, 1987-1992
[15:10:14] <Steffanx> Here: compare it with this flatness
http://maps.google.co.za/?ll=-34.026272,18.360901&spn=0.06203,0.132093&t=p&z=14&vpsrc=6 :P
[15:10:30] <scuzzy> that's my place again
[15:10:44] <RikusW> scuzzy: it is when you have a hard time cycling downhil against the wind....
[15:10:44] <Steffanx> oeps
[15:10:54] <scuzzy> RikusW: Pfffft...
[15:11:07] <scuzzy> maybe it's just windy in bredasdorp then
[15:11:21] <RikusW> its close to CT....
[15:11:35] <scuzzy> not close enough apparently. (;
[15:12:12] <scuzzy> you stick out further than CT in bredarsdorp
[15:13:31] <Steffanx> http://maps.google.co.za/maps?saddr=Muntendammerdiep,+Nederland&hl=nl&ll=53.155392,6.862636&spn=0.016135,0.044847&sll=53.155006,6.864438 scuzzy :)
[15:13:35] <Steffanx> That flatness
[15:13:58] <scuzzy> holy moly
[15:14:01] <scuzzy> that is flat
[15:14:10] <scuzzy> even the terrain is the same colour everywhere!
[15:14:55] <scuzzy> I gotta go to bed guys
[15:14:57] <scuzzy> sleep well
[15:15:01] <Steffanx> bb
[15:15:16] <Steffanx> me is off too
[15:15:23] <scuzzy> night RikusW
[15:15:27] <scuzzy> chat tomorrow
[15:15:31] <RikusW> night
[16:54:19] <gkwhc> Hi, might anyone have experiences with Atmel's SAMBA boot? I'd like to know if its just like copying files to a thumbdrive?
[16:58:58] <specing> well sorta
[16:59:40] <specing> I've done it to put Linux on an AT91 about 6 months ago - don't remember much though
[17:05:39] <gkwhc> linux on an AT91?! thats pretty powerful
[17:08:29] <district> it's really not ;)
[17:09:15] <district> but there are arm7 and arm9 at91's
[17:10:58] <specing> gkwhc: 200 Mhz
[17:11:12] <specing> Its actually slow as ****
[17:11:24] <gkwhc> ah
[17:11:33] <specing> But it has a gazilion of IO
[17:11:50] <gkwhc> specing: do you know if the samba bootloader gets erased when new code is downloaded?
[17:12:21] <specing> gkwhc: I don't think so
[17:13:03] <specing> It just doesent execute if it finds an executable image somewhere on its many ports
[17:13:16] <gkwhc> i see
[17:13:38] <gkwhc> how did you debug on the at91?
[17:14:44] <specing> It has a debug module onboard
[17:14:57] <specing> unfortunately windows only....
[17:16:14] <Casper> can'T wine?
[17:16:31] <gkwhc> hmm right now im just thinking of ways to get started on bare bones at91 development. i can download code through samba, but debug...
[17:18:03] <specing> Get JTAG
[17:18:21] <specing> or upgrade yout brains to v2.0
[17:19:48] <gkwhc> :)
[17:22:01] <specing> Thats what I do with AVRs
[17:22:15] <specing> I just stare at the pages of code until I see the problem
[17:26:15] <gkwhc> i hope you are being sarcastic :) haha
[17:26:31] <specing> Im telling the truth
[17:26:40] <specing> poor man's avr development
[17:26:53] <specing> And Im getting good at it too
[17:27:11] <specing> Think walking debugger
[17:33:32] <Casper> a good way is serial output or lcd or even leds
[17:34:54] <specing> I usually brake stuff up on modules
[17:35:07] <specing> and test whatever I can as host code
[17:35:57] <specing> I'd be great if I could use some of those 100 IOs on the AT91 to JTAG AVRs
[18:18:35] <tlvb> http://www.youtube.com/watch?v=a9IPxpo4w2E
[18:18:45] <tlvb> it's aliiiive
[18:44:02] <karlp> fun fun :)
[18:46:57] <tlvb> yup
[19:19:41] <vanquish> abcminiuser: i know it's late, but i read your blog post. gratz on the new job :P
[19:19:50] <abcminiuser> Cheers :)
[19:20:41] <abcminiuser> I need to post a new one today I guess
[19:21:04] <Kevin`> abcminiuser: does lufa support xmega devices?
[19:24:30] <abcminiuser> Kevin`, not yet really
[19:24:41] <vanquish> abcminiuser: do you know what you'll be working on?
[19:24:43] <abcminiuser> I've got some demos running on my USB XMEGA, but there are issues still
[19:24:54] <abcminiuser> Have to wait for a USB bus analyser to solve it
[19:25:19] <abcminiuser> vanquish, AVR Apps, so I assume the same stuff I did last time - customer support, writing demos for new eval kits, working on ASF
[19:25:37] <vanquish> abcminiuser: excellent. all things that could use your help.
[19:26:22] <abcminiuser> Hehe
[19:26:41] <abcminiuser> Acutally, I plan on trying to make a few ASF things from scratch, get a feel for it
[19:27:07] <abcminiuser> I did some work last time and was just going "WTF" the whole time, but if I do a big project from scratch now I can identify the weak areas
[19:27:14] <abcminiuser> Since I haven't done all that much with it
[19:27:58] <abcminiuser> I had great fun last time working out why adding the clock managment module broke everything in my code -- apparently it was rigged to also turn off all clocks in the device for power savings
[19:28:56] <Kevin`> asf?
[19:31:15] <abcminiuser> AVR Software Framework
[19:31:25] <abcminiuser> Big code library from Atmel for XMEGA, AVR, AVR32
[19:32:08] <jakllsch> i'm not sure how high my expectations for that should be :-)
[19:34:52] <Tom_itx> abcminiuser, reinstall fixed the problem
[19:35:26] <abcminiuser> Tom_itx, hurrah, AS5 is definetely based on MS code :P
[19:35:42] <abcminiuser> jakllsch, it's a great idea, it's just lacking slightly in the implementation
[19:35:53] <Tom_itx> i already have more experience with it than i need
[19:35:59] <abcminiuser> When it works it works well, but when it doesn't there's usually a very odd problem source
[19:36:54] <karlp> what's vanquish?
[19:37:09] <vanquish> I am a meat popscicle
[19:37:38] <karlp> is ASF meant to be like arm's "standard peripheral drivers" so you can use the same apis for adc/dac/i2c/spi et al across all the parts, be it avr/xmega/avr32?
[19:38:06] <vanquish> abcminiuser: yes. the main reason i decided not to go with the avr32 for my project was my experience with the ASF
[19:38:52] <vanquish> and you say XMEGA, AVR, and AVR32, but really its just *almost* complete AVR32 code, some of which *may* work for XMEGA
[19:39:04] <vanquish> i didn't find anything in there written for 8bit AVR
[19:39:28] <vanquish> karlp: essentially, sort of. yes?
[19:39:39] <abcminiuser> vanquish: Dear god I love that movie
[19:39:49] <vanquish> :D :D
[19:40:07] <abcminiuser> karlp, it has several layers:
[19:40:21] <abcminiuser> 1) hardware abstraction drivers, for basic serial, TWI, that sort of stuff
[19:40:41] <abcminiuser> 1) component drivers, which implement higher level protocols like Dataflash and the sort
[19:40:46] <abcminiuser> Err, 2) rather
[19:40:49] <vanquish> abcminiuser: I still catch myself sometimes when i'm stumbling around in the dark for whatever reason shouting (to myself) Azis! Light!
[19:41:10] <abcminiuser> And 3) services, which sit above the other two and provide things like USB, CAN, MP3 decoding and the like
[19:41:25] <abcminiuser> vanquish: You gotta press the little yellow button
[19:41:45] <vanquish> multipass
[19:41:55] <abcminiuser> ^ vanquish: It was originally just for AVR32s, then expanded - XMEGA support is growing, and the AVR8 support was only decided upon this year
[19:42:07] <abcminiuser> XMEGA code is actually pretty decent, AVR32 is a bit of a crapshoot
[19:42:31] <vanquish> That's good to know. I didn't try any of the xmega code
[19:43:04] <abcminiuser> vanquish, I still do Leeloo's "Chikeeeeeen" whenever we eat chicken, too
[19:43:05] <vanquish> the avr8 support is a good move, it will lower the barrier of entry a bit further
[19:43:22] <vanquish> help the jump from arduino to big boy pants
[19:43:26] <abcminiuser> vanquish, yes seriously, my official analysis is "XMEGA decent, AVR32 horrorshow"
[19:43:53] <vanquish> it really is terrible. i tried to be nice, and i gave it an honest shot, but wow
[19:44:10] <vanquish> i pretty much *wasted* a month trying to get it to work
[19:44:10] <abcminiuser> My first experience with it was when I did my internship
[19:44:28] <abcminiuser> C only has an "int" datatype and nothing else, right? :P
[19:44:42] <tlvb> what?
[19:45:10] <abcminiuser> tlab, that's pretty much all they used in ASF for AVR32, ints
[19:45:39] <Tom_itx> what more do you need... sheesh
[19:45:49] <tlvb> uint
[19:52:33] <abcminiuser> <stdint.h>?
[19:56:14] <karlp> well, someone may have told them how badly some compilers do when you say "char" on a 32 bit machine.
[19:56:28] <karlp> and "always use int unless you have special reason to use something else"
[19:56:42] <vanquish> except they bundle the AVR Studio 5 with gcc
[19:56:46] <vanquish> so...*shrugs*
[19:57:10] <karlp> isn't ther esomething like int8_l_t or something? specifies at least 8 bits, but not fussed?
[19:57:17] <karlp> to provide better hints?
[19:57:24] <karlp> where did I see that?
[19:58:05] <karlp> yeah, avr-libc has it
[19:58:13] <karlp> int_least8_t
[19:58:57] <karlp> ok, so on avr-libc, asking for int8_t gives you int_least8_t already
[19:59:16] <karlp> so just don't use char, or int, or long. ever. always use <stdint.h>
[19:59:31] <karlp> yeah, like he said: >> 01:44 < abcminiuser> <stdint.h>?
[20:16:10] * tlvb always uses uint8_t unless I know I'm going to need signedness or more bits
[20:16:33] <tlvb> except for the return type for main
[20:23:46] <rue_house> .
[20:24:03] <rue_house> what is the most comprehensive avr flashing led source site anyone has seen?
[20:24:05] <rue_house> .
[20:24:17] <Tom_itx> mine
[20:24:29] <Tom_itx> .
[20:24:50] <rue_house> whats your url for htat?
[20:24:52] <Kevin`> his site really is pretty good about that
[20:25:37] <Tom_itx> rue_house you should have it memorized by now
[20:25:46] <Tom_itx> after all i stole your code for it... remember?
[20:26:02] <rue_house> yea, but as of latleys its all shows to be broken
[20:26:41] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/how_to/atmega168/mega168_led_blink_delay_index.php
[20:27:07] <rue_house> ok thats for 168
[20:27:18] <rue_house> I'm thinking a list of precompiled hex files for every avr
[20:27:38] <Tom_itx> why?
[20:28:11] <Tom_itx> it will work for alot of them as is, just change the makefile
[20:28:33] <abcminiuser> Honestly, you need a reference for a LED flasher?
[20:28:42] <Tom_itx> PORTB doesn't get screwed with as much as the others from one chip to the next
[20:28:54] * Tom_itx flashes abcminiuser
[20:29:41] <Tom_itx> abcminiuser, it's too darn bad you didn't get one of those free st arm dev boards
[20:29:53] <abcminiuser> Hrm, perhaps this afternoon I'll see just how convoluted I can make a flasher
[20:30:06] <abcminiuser> Might be a fun project, make it as big and complex as possible
[20:42:58] <inflex> lo folks
[20:43:09] * inflex wonders wtf his OLEDs will arrive
[20:43:19] <inflex> ... and how long after that before I cry knowing I can't hot-bar solder them
[20:43:53] <Casper> inflex: do you have on hand a good simple variable load that do not change based on the voltage?
[20:44:01] <Casper> that work down to like 2-3V?
[20:44:10] <inflex> No, sorry.
[20:44:31] <inflex> closest I can think of of course is the mosfet/shunt/opamp/DAC combo
[20:44:53] <inflex> you could use a LM317 in current-regulator mode
[20:44:53] <Casper> hmmm I might have an idea...
[20:44:58] <inflex> that'll get you down to perhaps 1.25V?
[20:44:59] <Casper> I need about 5A
[20:45:04] <inflex> oooh... big heatsink ;)
[20:45:08] <Casper> yup
[20:45:26] <Casper> I need a better setup than... lightbulbs
[20:45:35] <inflex> yeah, I'm in the same situation
[20:46:09] <Casper> but I might have a small idea
[20:46:21] <Casper> the low voltage requirement is the problem
[20:47:30] <Casper> was thinking of a simple 2-3V zener regulation to a pot to a darlington npn
[20:51:53] <inflex> try a TL431 rather than a zener... zener knees are too soft below 5V :(
[20:58:14] <Casper> bahh same
[21:05:11] <UnderSampled> how do I sleep for a few milliseconds?
[21:05:39] <UnderSampled> or, wait-as I want to keep the outputs going
[21:10:28] <Kevin`> UnderSampled: efficiently.. use a timer (can also wake from sleep modes). inn
[21:10:39] <Kevin`> eficiently, use _delay_ms(const)
[21:10:45] <Kevin`> inneficiently*
[21:11:44] <UnderSampled> by effciency in this case, do you mean power wise?
[21:12:09] <Kevin`> that and allowing other code to run while you are waiting
[21:12:40] <UnderSampled> where in the datasheet would that be under?
[21:13:01] <Kevin`> timer/counter
[21:13:01] <UnderSampled> and are there any tutorials you could suggest?
[21:13:17] <Kevin`> abcminiuser's tutorial is quite good
[21:14:24] <UnderSampled> is the _delay_ms in #include <avr/delay.h>
[21:14:38] <abcminiuser> UnderSampled, yes
[21:14:38] <Kevin`> something like that, check the avr-libc page
[21:14:43] <abcminiuser> Wait no
[21:14:46] <abcminiuser> <util/delay.h>
[21:14:48] <karlp> util
[21:14:53] <karlp> yeah, it moved.
[22:12:12] <tlvb> is there a c preprocrssor way of invoking an external command on certain parts of the code?
[22:14:39] <karlp> I don't know (or want to know) about making the c preproc do it,but you sure can with make and sed/awk/etc
[22:16:36] <tlvb> I could of course do it by writing the call as a part of the makefile...
[22:30:20] <inflex> wow, new OLED displays arrived... tiinnnnnyy -
http://dxp.me/i/oled.jpg
[22:30:46] <inflex> the OLED is the smallest one... and that's next to my already small 8x2 character display!
[22:30:53] <Tom_itx> is that good?
[22:31:00] <inflex> yes, it's great
[22:31:18] <inflex> the trick though is going to be connecting that FPC
[22:31:18] <Casper> I wonder if/when they will make oled tv
[22:31:19] <Tom_itx> color?
[22:31:24] <inflex> no, monochrome
[22:31:29] <Casper> and if they will suffer from screen burnin
[22:31:30] <inflex> 96x16 pixels
[22:32:05] <inflex> Casper: biggest problem was always the life of the blue LED
[22:32:07] <Tom_itx> casper, sony has one
[22:32:07] <Tom_itx> $$$$
