#avr | Logs for 2012-01-30

Back
[01:38:13] <Roklobsta> jadew: how's the Rigol going?
[03:14:49] <skorket> Could someone give me a rough guide to implementing a jump table in avr assembly? loading the Z with an address then adding the appropriate amount, then 'IJMP'? Or is there a better way?
[03:27:33] <nevdull> skorket: i just pasted an example at http://pastebin.com/gGb19r0s
[03:28:30] <nevdull> and typically you'll use IJMP when you don't care to have a way back, else use ICALL
[03:33:49] <skorket> nevdull, yep, that's how I just did it as well. Kind of expensive though
[03:35:38] <nevdull> IJMP takes 2 clock cycles and ICALL takes 3 or 4, ADD takes 1, BRCC takes 1 or 2 (i forget)
[03:38:22] <skorket> add (1) + brcc (1.5) + inc (0.5) + ijmp (2) + rjmp (2) \approx 7
[03:39:16] <nevdull> i think its - in general - a more elegant and cleaner method than implementing a lot of branching
[03:40:42] <skorket> I was going to use it for a switch statement but I think it's just cheaper (in this case) to have a lot of branching
[03:41:18] <nevdull> is your code really that tight/constrained on cycles?
[03:46:08] <nevdull> 7 clock cycles on an 8MHz AVR should only take like .875 usec if i remember and did my clock timing right
[03:47:42] <nevdull> although i know in some applications (i've been playing around with generating 640x480 VGA signal on AVR lately) you are really constrained
[03:54:54] <skorket> nevdull, I'm running at 9.6Mhz (internal osciallator) and I'm driving 4 pwm signals for 4 servos. I'm controlling them mostly from the timer0 overflow. I've clocked each pwm change to about 20 clock cycles per servo (for the branching code), for a total of 80 clock cycles that need to be spent in the interrupt
[03:55:07] <skorket> seems a bit high to me and I was hoping to shave off as much as I could
[03:55:30] <nevdull> yah i can understand that
[03:57:27] <nevdull> what about a 20MHz xtal or something?
[03:58:49] <skorket> I like to keep things simple. No external clocks simplify the circuit. Besides, with the 4 pwm's, that only leaves 1 extra pin, which I use for input, so I wouldn't even have space
[03:59:07] <skorket> anyway, I got a functioning version of this going in C and I'm rewriting it in assembly
[03:59:27] <skorket> Maybe I can do some more tricks to shave off a cycle or two
[03:59:28] <nevdull> so your pwm changes are taking 2.5 usec
[03:59:55] <nevdull> oh are you running this on a attiny?
[04:00:19] <skorket> yes, all on the attiny13
[04:00:25] <nevdull> sweet
[04:05:18] <nevdull> you can always try some poor-man's peephole optimization by running avr-gcc -fverbose-asm -S against your *.c code with optimization flags on avr-gcc
[04:06:09] <nevdull> and/or after avr-gcc -c file.c you can try avr-nm --size-sort file.o and see what functions could be optimized
[04:06:44] <nevdull> although i've found the gcc compiler does a pretty good job at it itself. might be interesting or worth comparing the gcc generated assembler with our hand-written one
[04:07:22] <nevdull> s/our/your
[04:17:47] <skorket> I'm looking at the .lst generated with -Os. Seems pretty standard branching logic. Pretty much what I came up with when doing the same thing...
[04:18:54] <ElMonkey> have any of you done stepper control? i'm looking for an algorithm to generate variable speeds at a fixed interrupt rate
[04:19:18] <ElMonkey> essentially i need something like bresenham's line drawing algo
[04:19:29] <ElMonkey> but somebody must have done this before...
[04:21:35] <ziph> Why wouldn't you just use timers?
[04:22:03] <ElMonkey> because i need to drive multiple axes at the same time
[04:22:19] <ElMonkey> and even if i used a timer, i would still need to calculate how long each step should take
[04:23:20] <ElMonkey> right now the timer is just generating ticks when some logic is triggered that executes a step or not
[04:24:31] <ziph> What's the input?
[04:25:36] <ElMonkey> a linear path segment + speed, basically
[04:25:52] <ElMonkey> or for each axis its number of steps to execute in some number of ticks
[04:34:05] <ziph> Do you need long term accuracy?
[04:34:19] <ziph> (e.g. is this for an open loop telescope controller? :)
[04:37:40] <ElMonkey> its for a CNC
[04:37:51] <ElMonkey> so the number of steps is important :)
[04:38:20] <ziph> The time isn't though, just the approximate feed speeds.
[04:39:14] <CapnKernel> ElMonkey: Google "grbl"
[04:39:55] <ziph> I'd just figure out the number of ticks to the next step with 1/(steps per ticks) and divide that by your interrupt interval (in ticks), and carry the modulus over as an error to the next step.
[04:40:07] <CapnKernel> It's a 3-axis CNC controller which runs on the Arduino (but it's not an Arduino sketch). It uses the hardware timers to do simultaneous movement of the axes, with independent acceleration/deacceleration.
[04:40:07] <ziph> If I were doing it with fixed interrupt intervals, that is.
[04:40:28] <ElMonkey> CapnKernel, thanks, looking now
[04:40:34] <ziph> But I wouldn't because most motors and things attached to them hate jitter.
[04:40:49] <CapnKernel> I have used grbl, it's a very nice piece of work.
[04:41:00] <ElMonkey> ziph, the motor driver is microstepped, so jitter should be a-ok
[04:41:18] <ElMonkey> at least when i run off a 32 or 64kHz timer
[04:42:22] <ziph> What's your maximum steps/second?
[04:43:05] <ElMonkey> ziph, right now its 16kHz off the 32kHz timer for toggling the pulse output
[04:43:52] <ElMonkey> running the stepper at 16kHz with 8 microsteps is about max speed without ramping
[04:44:23] <ElMonkey> well, the stepper is running freely right now
[04:44:40] <ElMonkey> i expect it to get worse once it actually drives something
[04:44:45] <ElMonkey> but thats beside the point :)
[04:45:57] <ziph> So if you're running at 12kHz you'll have it alternating between 2 and 3 ticks?
[04:45:59] <ElMonkey> i'm trying to prototype this on a butterfly for now, but can use a faster AVR later, should it be necessary
[04:46:05] <ElMonkey> ziph, yea
[04:47:26] <ElMonkey> the 32kHz is also nice for keeping track of fractional error in a uint16 :)
[04:50:10] <ElMonkey> meh, grbl is gpl :/
[04:58:12] <ziph> Careful about dissing GPL in here, you'll get the freetards yelling at you. ;)
[04:58:31] <ElMonkey> force of habit :)
[04:58:39] <ElMonkey> i've been bitten by it before
[04:59:27] <karlp> someone rebuilt grbl for the maple or some other arm board didn't they?
[04:59:36] <karlp> started running it about 3 times as fast?
[04:59:58] <karlp> did teh grbl guys only use the arduino board because they thought people would have them lying around unused?
[05:00:17] <ElMonkey> i guess its a pretty good lowest common denominator
[05:01:38] <karlp> also, for something like grbl, unless you're planning on adding some serious features, why does it bother you that it's gpl?
[05:01:41] <karlp> it's a finished product
[05:01:52] <karlp> it's not like a gpl library or some of that nonsense.
[05:02:04] <ElMonkey> yea, if i could use it vanilla i wouldnt bother
[05:25:07] <CapnKernel> ElMonkey: The licence would only be a problem if you were looking to make a for-sale product.
[05:26:42] <ziph> If your day job involves dealing with commercial use of Open Source code you more or less just get into the habit of writing off GPL code automatically.
[05:30:57] <CapnKernel> I deal with the commercial use of open source all the time, and I don't see what the problem is.
[05:31:20] <CapnKernel> karlp: Are you looking for something to drive your mill, or are you developing a product for others?
[05:31:20] <ElMonkey> depends on who you work for, i guess
[05:31:50] <CapnKernel> It does?
[05:32:19] <ElMonkey> i develop software for research and prototyping purposes in the auto industry
[05:32:37] <ElMonkey> anything open source they frown upon
[05:33:09] <ElMonkey> MIT style licenses are tolerated, GPL gets you chased out of the building
[05:33:11] <CapnKernel> That's their cultural and policy decision. Seems to me there's no technical or legal impediment to using open source
[05:33:21] <ElMonkey> even thought the software will never be used in a commercial product
[05:33:41] <ElMonkey> they're afraid that some line of code might find its way and they'll get sued or i dunno what
[05:33:59] <ziph> ElMonkey: This is what I meant about freetardism, they can't imagine that a company lawyer might have some kind of objection about you shipping GPL libraries with your products.
[05:34:02] <CapnKernel> Their choice.
[05:34:19] <ElMonkey> personally, i don't like the GPL because DONT TELL ME WHAT TO DO ;)
[05:34:31] <CapnKernel> ziph: Freetardism is "all software should be free"
[05:34:40] <ElMonkey> i mean, most of the stuff i do, if its open source, its MIT/BSD
[05:34:42] <CapnKernel> Don't use the software then. Honour the licence or don't use it.
[05:34:58] <CapnKernel> That goes for proprietary, GPL, MIT or postcardware
[05:35:20] <ziph> Why are you telling him that? He just told you he doesn't. :)
[05:35:49] <CapnKernel> Lost cause, I'm out.
[05:36:06] <ElMonkey> debating opinions is always a lost cause :)
[05:36:16] <CapnKernel> ziph: I'm sure I don't know why you'd choose to discuss it in such inflammatory terms.
[05:36:39] <ziph> Freetard? Because it fits the definition exactly and it's a funny word.
[05:36:51] <CapnKernel> I'm guessing most of us here are engineers, not PHBs.
[05:37:27] <CapnKernel> I'm sensing a lot of fear derived from not really understanding what it's all about.
[05:37:40] <ziph> Real engineers wouldn't spend countless hours replacing vendor tools with free alternatives. :)
[05:38:15] <karlp> phbs?
[05:38:32] <ziph> Pointy Haired Bosses, it's a Dilbert reference.
[05:38:42] <CapnKernel> Pointy Haired Bosses. Dilbert.
[05:38:58] <ElMonkey> dont get me started about vendor tools ^_^
[05:39:21] <CapnKernel> By "vendor", do we mean proprietary tools, or tools developed in-house?
[05:40:49] <ziph> Either.
[05:41:10] <ziph> Assuming by in-house you mean from the semiconductor manufacturer.
[05:42:05] <CapnKernel> No. For example, car company writes software to solve particular domain-specific problem.
[05:42:30] <CapnKernel> For example, "i develop software for research and prototyping purposes in the auto industry"
[05:43:07] <ElMonkey> vendor tools would be what they sell us for several 10k (often per year) with half a guy working on it occasionally
[05:43:27] <ziph> Which half? :)
[05:43:41] <ElMonkey> mostly the wrong one, it seems
[05:43:49] <ziph> The bottom half then? :)
[05:45:06] <ElMonkey> anyway, i spend 30% of my time dealing with broken tools, another 30% rewriting broken tools, and maybe a third is left to do actual work
[05:45:22] <ziph> You use IAR compilers then? :)
[05:45:54] <ElMonkey> heh, i hardly write any embedded code
[05:46:08] <ElMonkey> thats for the product develepment peeps :)
[05:46:21] <ziph> How come you aren't trying to get into that department? :)
[05:46:23] <ElMonkey> we mostly use windows based "solutions"
[05:46:31] <CapnKernel> Even if he did, the same argument would follow. The rest of us use gcc, and ship products.
[05:46:44] <ElMonkey> rarely linux
[05:46:52] <ElMonkey> though then its mostly java :/
[05:47:07] <CapnKernel> Banks are an incredibly risk averse area, yet they are one of the largest commercial users of open source
[05:47:23] <CapnKernel> Why? Because they saw the open-source-is-dangerous FUD for what it was
[05:47:31] <CapnKernel> And realised their ROI was better with open source
[05:47:58] <Roklobsta> it depends if the company is using OIS to levedge their position. A bank probably doesn't care about Linux vs Windows it's about what will get the job done quickly and cheapyly and reliably.
[05:48:37] <CapnKernel> ziph: Despite your appeal-to-manliness "real engineers" jibe above, the main reason companies move to open source is simply a matter of ROI: If you can save money by doing so, and it's within what the license permits, you'd be a fool not to.
[05:48:54] <Roklobsta> on the other hand, many software and hardware companies tie themselves in knots with respect to IP and trade secrets so don't want to have to loose their edge by having a trade secret get out by way of GPL poison.
[05:48:59] <CapnKernel> Yes, quickly, cheaply, reliably. I'm not seeing a problem here.
[05:49:44] <ElMonkey> yea, car industry is incredibly worried about "IP"
[05:50:06] <Roklobsta> i have worked for a leading edge radar company who relied on trade secrets and being 10 years ahead of the competition. That said, it didn't stop us/them dumping a commercial PPC RTOS for eCOS.
[05:50:06] <ElMonkey> even though its FUD, its very ingrained
[05:50:08] <CapnKernel> I can understand that. Competitive advantage.
[05:50:45] <CapnKernel> Roklobsta: Why did they do that?
[05:50:55] <ElMonkey> if they werent so worried about the IP, we may get some research done one day :)
[05:51:04] <Roklobsta> i don't know if eCOS survived in the 10 years since I left but the system is now delpoyed in Navy ships.
[05:52:47] <Roklobsta> capnkernel: there were bugs in the commercial RTOS that weren't being dealt with by the company at all so they were flipped the bird. eCOS took about 2 days to get implemented and maybe a week was lost in the transition.
[05:53:11] <Roklobsta> but the time saved from having a working system and the ability to fix the code themselves and talk to an open forum helped a lot.
[05:54:06] <Roklobsta> i don't know how SDCC compares to Taskings 8051 compiler but I found quite a few interesting bugs in Taskings code.
[05:54:09] <Roklobsta> and tools
[05:54:11] <ziph> eCOS has an exception for commercial use.
[05:54:31] <CapnKernel> I ported a few ThreadX projects to eCOS.
[05:54:58] <CapnKernel> eCOS is still going strong.
[05:55:04] <Roklobsta> this was in 2000 so I don't know what the state is now.
[05:55:21] <Roklobsta> all i know is the DSPs I worked on ended up being ditched fro FPGAs.
[05:56:45] <Roklobsta> I give tasking credit for a quick fix but I found their scanf couldn't, wouldn't, convert "0", "0.0" or any way to care to write 0 in a text string into a float and set it as 0.
[05:57:23] <Roklobsta> 0, 0.0, 0.0000 etc just returned garbage into my float vaiable.
[05:57:38] <CapnKernel> Delightful.
[05:58:11] <Roklobsta> i found the bug in the library as they actually provded all the souyrce to their libraries.
[05:58:39] <Roklobsta> but there were linker issues with overlays in banks and so on.
[05:59:35] <Roklobsta> so it gave me a warm fuzzy feeling that commercial software was just as crap, er, faulty, as any given open source software.
[06:00:55] <ElMonkey> yea, except you cant fix it
[06:01:00] <ElMonkey> and nobody wants to talk about it
[06:01:11] <Roklobsta> other companies I have worked for also used stripped down linux and i don't think their were any plans to comply with the GPL. In fact, non compliance was the order of the day!
[06:01:25] <CapnKernel> If you don't ship it, you don't have to.
[06:01:33] <karlp> and if you only write linux apps
[06:01:43] <CapnKernel> Hang on, weren't we talking about the advantage of proprietary software being that there was someone to sue if need be?
[06:01:55] <CapnKernel> (I'd rather get the problem fixed than waste years in court, ANY DAY)
[06:02:02] <ziph> Except some of the interpretations of the GPL call using it in more than one site shipping it.
[06:02:03] <Roklobsta> Yeah, so long as they have assets or insurance with assets.
[06:02:09] <karlp> all that started in teh beginning was that someone didn't want to use grbl source as a base, because it's gpl.
[06:02:45] <ElMonkey> ziph, either way, you only have to provide source to the users
[06:02:58] <ElMonkey> not absolutely everyone
[06:02:59] <ElMonkey> afaik
[06:03:03] <Roklobsta> anyway, suing seems to be a north american passion. it doesn't seem to have caught on so much in the rest of the west.
[06:03:20] <ziph> So you have to provide source to your employees? :)
[06:03:21] <karlp> ElMonkey: sure, but you're not allowed to say that _those_ users can't give it to everyone :)
[06:04:04] <Roklobsta> charge $1000 per CD.
[06:04:08] <ElMonkey> karlp, complicated, what if they are NDA'd? i wonder what has precedence
[06:04:15] <ElMonkey> or if it just becomes plain illegal
[06:04:39] <karlp> try and avoid putting yourself in that situation :)
[06:04:51] <ziph> And here's the core issue; no one knows what the GPL actually means.
[06:05:05] <ziph> Where as a 3 term BSD is staggeringly less complex.
[06:05:15] <CapnKernel> Beg pardon, I have a good knowledge of GPL2
[06:05:34] <CapnKernel> GPL comes down to what constitutes "distribution". Letting your colleague use the software constitutes distribution.
[06:05:39] <Roklobsta> CapnKernel: GPL is like quantum mechanics, if you say you understand it you really don't.
[06:05:52] <karlp> lots of people think they know what distribution counts as.
[06:06:01] <CapnKernel> Shouldn't matter if other sites want to use it, if they're same company, what's the problem with sharing the sourcE?
[06:06:55] <CapnKernel> Distribution is making the binary available to others. Simple.
[06:07:39] <Roklobsta> it's all about money in the end - how to get a buck out of writing and distributing software.
[06:07:44] <CapnKernel> The thing that stunned me about the GPL v2 is that it was written in English and is easy to understand.
[06:07:51] <CapnKernel> (Note, the same can't be said about GPL v3)
[06:07:57] <ziph> Bull crap.
[06:08:00] <CapnKernel> It is? What is an it?
[06:08:06] <CapnKernel> ziph: What part isn't?
[06:08:08] <ziph> It has a 40 page FAQ with box and arrow diagrams to try and explain it.
[06:08:41] <karlp> CapnKernel: now, define "making the binary available to others"
[06:08:42] <CapnKernel> It has a preample to explain the reasons for it, and usually has something on the end which explains how to apply it to software you write.
[06:08:51] <ziph> Oh, and big matrices to deal with version numbers.
[06:08:57] <karlp> because some people, notably linksys, didn't feel that the binary burnt into flash inside an finished product counted.
[06:09:05] <CapnKernel> It certainly does.
[06:09:32] <CapnKernel> Providing a web service doesn't count, shipping it in a modem does.
[06:09:34] <theBear> sure they didn't think that
[06:10:08] <CapnKernel> It's possible that they're deluded. Let's not confuse what they think, in their deluded minds, with what the license actually says and requires.
[06:10:35] <CapnKernel> I'm happy to take one at a time, but it's actually two very different issues.
[06:10:52] <CapnKernel> It's like confusing people who think the earth is flat, with whether or not the earth really IS flat.
[06:11:23] <Roklobsta> bah, it's about push and push back. Linksys is pushing hard hoping you'll all give up and go away
[06:11:33] <karlp> regardless, even if _you_ know it very well. as you yourself said, there's lots of fud. lots and lots and lots of fud
[06:11:44] <karlp> so in many cases, rebuilding something is faster and safer than reusing it.
[06:11:46] <Roklobsta> until some judge says they must yield then they push back with some appeal in a higher court.
[06:11:47] <karlp> unfortunately.
[06:11:52] <CapnKernel> That doesn't mean the license gives them the right to do that. They've clearly been outside the requirements of the license several times, and have been called on it.
[06:12:26] <karlp> so some of us, even if they think it _should_ be ok, still just generally avoid gpl code outright.
[06:12:32] <CapnKernel> For commercial reasons they will try to get away with being as bad as they can. It doesn't mean the license lets them.
[06:12:46] <Roklobsta> it's like patents. it's all fine and well to spend a big sack of money patenting something but you need a bigger sack of cash to defend it.
[06:12:56] <CapnKernel> karlp: It's nice to live in a world of choice, and that's a valid choice.
[06:13:09] <karlp> doesn't always make me happy though :|
[06:13:19] <CapnKernel> Let's not confuse patents with the GPL. The GPL is based on copyright.
[06:13:24] <Roklobsta> and who on the side of GPL has a sack of cash big enough to take on all the offenders?
[06:13:36] <CapnKernel> And yes, the only power a patent has, is the threat of that sack of money.
[06:14:29] <Roklobsta> i agree about patent vs copyright but at the end of the day it's up to the patent and copyright creator to defend it, usually with the power of a big sack of cash.
[06:14:34] <CapnKernel> The GPL Violations website (http://gpl-violations.org/) has done a great job of getting compliance without needing a bag of money.
[06:14:47] <Roklobsta> public shaming does work, indeed.
[06:14:52] <CapnKernel> And the policy of the FSF is to get compliance through dialog and cooperation, rather than litigation.
[06:15:04] <CapnKernel> It works quite well
[06:15:14] <CapnKernel> It could be said to work a lot better than the US patent system!\
[06:15:23] <karlp> it works pretty well, because a lot of companies don't have the cash to fight back anyway,
[06:15:30] <karlp> and ltos of them genuinely didn't know.
[06:15:39] <Roklobsta> and they don't want to look like cunts.
[06:15:43] <ziph> So you think companies ignore the GPL to make money?
[06:15:53] <karlp> (which I will say can be partly attributed to the gpl not being as clear as you might think)
[06:15:58] * amee2k pops his head in
[06:16:12] <CapnKernel> It works because companies like The Register and ZDNet are desperate for stories and like nothing more than writing about big companies gone bad.
[06:16:16] <amee2k> oh, only "gpl vs. the industry" fapping again
[06:16:19] <CapnKernel> ziph: Absolutely.
[06:16:30] * amee2k idly grabs a banana and wanders off in the general direction of the bathroom
[06:16:38] <Roklobsta> richard stallman gooood, making money baaaaaad.
[06:16:44] <CapnKernel> No, it comes down to them not being clear about something which is clear.
[06:16:49] <ziph> amee2k: I even warned the person that started this not to start it.
[06:17:07] <CapnKernel> I never said that. You'll note I haven't said "free software" at all. I've said "open source". There's a very very important difference.
[06:17:11] <amee2k> ziph: want a banana? its fresh
[06:17:39] <amee2k> i've got condoms too \o/
[06:17:41] <Roklobsta> how does stallman make money anyway?
[06:17:53] <amee2k> selling his beard on ebay?
[06:17:56] <CapnKernel> Roklobsta: I've worked with a lot of companies who have made very good money from open source.
[06:17:59] <ElMonkey> he give speeeches
[06:18:01] <karlp> Roklobsta: speaking arrangements
[06:18:14] <CapnKernel> He was the recipient of the Macarthur Prize, which helps quite a bit.
[06:18:19] <Roklobsta> does he sell the froth from his mouth to put into high end baby lotion?
[06:18:48] <amee2k> he should open an open source pizza place *nod*
[06:18:58] <CapnKernel> Nice ad hominem attacks guys.
[06:18:59] <amee2k> with GFDL licensed menu
[06:19:04] <karlp> Roklobsta: way to keep the conversation high
[06:19:23] <ziph> amee2k: Are the condoms for me or the banana? :)
[06:19:29] <Roklobsta> i shouldn't drink beer while on #avr, huh?
[06:19:44] <amee2k> ziph: how about you two share?
[06:19:45] <CapnKernel> ziph: So, leaving the personal attacks and shrill screeching aside, which part of the GPLv2 do you think is unclear?
[06:19:46] * amee2k runs
[06:20:02] <ziph> CapnKernel: Most of it.
[06:20:10] <CapnKernel> No go on, which part?
[06:20:11] <karlp> what constitutes distribution, and to who exactly, an in what forms
[06:20:18] <karlp> (that's me personally)
[06:20:31] <CapnKernel> If you give something to somebody else, that's distribution.
[06:20:38] <ziph> CapnKernel: The needing a 40 page FAQ with box and arrow diagrams and matrices?
[06:20:57] <Roklobsta> has gpl been tested in court?
[06:21:04] <CapnKernel> Yes
[06:21:11] <amee2k> what exactly is wrong with continuing to license stuff under gpl v1 anyway?
[06:21:16] <Roklobsta> nothing
[06:21:22] <karlp> amee2k: nothing, your call as licensor
[06:21:28] <CapnKernel> Er, GPL 1 is about 20 years old.
[06:21:28] <Roklobsta> lincense anything you write any how you want.
[06:21:42] <CapnKernel> No software you've ever heard of is licensed under the GPL v1.
[06:21:52] <Roklobsta> emacs, once?
[06:22:06] <CapnKernel> A lot of software is under v2 (for example, Linux kernel) and newer software is under v3 (for example, Samba)
[06:22:08] <CapnKernel> Not any more.
[06:22:46] <CapnKernel> The 40 page FAQ is for people like you who won't go and read the thing. FAQs are devices for ensuring dumb people don't waste more time than is necessary
[06:23:19] <ziph> So where's the FAQ for the BSD/MIT licence?
[06:23:38] <amee2k> or to ensure smart people don't mentally throw up and run away on the first sight?
[06:23:53] <amee2k> or at least thats the general idea. doesn't mean it works :P
[06:24:03] <CapnKernel> Where's the FAQ for Microsoft's Windows 95 EULA? Fed if I know. I only know about the GPL v2.
[06:24:46] <ziph> CapnKernel: You've just called me dumb, flat out.
[06:24:47] * amee2k idly wanders off to write an FAQ about proper use of bananas
[06:24:52] <karlp> hmm. oh dear, it's one of those days. Reprogrammed with the working checked in friday code, led doesn't even blink today.
[06:24:55] <karlp> bah.
[06:25:02] <ziph> CapnKernel: Unless you actually consider yourself a freetard I haven't insulted you at all.
[06:25:10] <karlp> ziph: you did word it so that his line of reasoning required him to call you dumb.
[06:25:23] <amee2k> you guys are hilarious :P
[06:25:32] <karlp> you can't relly complain that it then happened.
[06:25:41] <ziph> karlp: How so, karl?
[06:26:07] <karlp> ziph: yoiu're right, I mixed you up with amee2k for s bit, my apologies
[06:26:47] <amee2k> thanks. i'm flattered \o/
[06:27:05] <ziph> karlp: I'm the one not sitting around trying to put condoms on bananas. :)
[06:27:11] <ElMonkey> in case anybody cares about the stepping: http://pastebin.com/rwjDhdGs
[06:27:24] <amee2k> ziph: you should try it sometime. its very relaxing
[06:27:26] <ElMonkey> with errorAccum inited to -ticks/2
[06:27:26] <karlp> stepping? who the hell do you think you are?! ;)
[06:27:59] <ziph> amee2k: Where are you again?
[06:28:14] <amee2k> on my desk, why?
[06:28:20] <ziph> Haha.
[06:28:46] <amee2k> >_>
[06:28:47] <ziph> Because the banana fetish makes you sound like a Queenslander. :)
[06:28:52] <amee2k> lol
[06:29:09] <amee2k> i have an orange fetish. the bananas are just entertainment
[06:29:17] <amee2k> and eating fruit is good :)
[06:29:19] <karlp> only southerners have fetishes for bananas. queenslanders just eat them
[06:29:24] <ziph> Eating, yes.
[06:29:31] <ziph> But that doesn't sound like what you're doing. :)
[06:29:45] <karlp> isn't it getting a bit late for east coast people to be on the interwebs?
[06:29:45] <amee2k> ziph: that was the general idea, yes >_>
[06:29:54] <karlp> go to bed! stop distracting me from my work!
[06:30:01] <amee2k> lol
[06:30:10] <skorket> in works on ports in the range of 0-63 but sbi/cbi only works on ports in the range of 0-31? Weird
[06:30:10] <amee2k> you like bananas and you know it!
[06:30:12] <ziph> Sydney weirds me out, if you go for an hours drive outside the city you drive past at least two dozen road side mango stalls.
[06:30:13] * amee2k idly turns orange
[06:30:31] <Roklobsta> dunno, what is east? i am south coast.
[06:30:46] <ziph> Antarctica? :)
[06:31:01] <amee2k> no coast for 1000+ km in any direction here
[06:31:17] <ziph> So, that would be.. not in Australia? :)
[06:31:23] <amee2k> lol
[06:31:28] <ziph> Or, you're a dingo.
[06:31:31] <ziph> Or a goat.
[06:31:31] <Roklobsta> i get to hear the ocean roar or cows moo, depending on the wind at night.
[06:31:47] <amee2k> i've never heard of goats with orange fetish who like bananas
[06:31:59] <ziph> amee2k: We'll find one for you on your birthday.
[06:32:06] <amee2k> lol
[06:33:00] <jadew> Roklobsta, it's great, found some bad noise before the ADC and was able to take it out
[06:33:19] <Roklobsta> wow, AVM was told to go bag their head by a german judge with respect to gpl.
[06:34:10] <Roklobsta> jadew: good. I don't know how any programmer can do hardware programming without a cro.
[06:34:56] <jadew> yeah, it's really useful, especially since I'm a noob at electronics, so I don't know what to expect
[06:37:27] <karlp> led no blinky.. ==> assert failure. serves me right.
[06:38:17] <jadew> yeah, but it's not that simple once you do analogic stuff
[06:39:02] <jadew> and I had an issue with digital stuff as well, where it worked when I tested it at home and failed when I actually wanted to use it (still don't know what was the issue there)
[06:41:45] <ElMonkey> that reminds me, i should fix up the tek 475 i have in the basement
[06:41:53] <ElMonkey> or rather, make one working one out of 2 borked ones
[06:42:45] <amee2k> hrm... anyone know of an example implementation how to track a rotary encoder that gives output at ~50kHz (100kHz max. i'd say)?
[06:43:10] <amee2k> rotary optical* encoder even
[06:43:13] <ziph> Quadrature?
[06:43:24] <amee2k> yes
[06:44:05] <ziph> wire count_enable = quadA ^ quadA_delayed ^ quadB ^ quadB_delayed;
[06:44:05] <ziph> wire count_direction = quadA ^ quadB_delayed;
[06:44:07] <amee2k> 2k pulses per rotation, so i'd need to track it in at least two 16 bit ints
[06:44:15] <ziph> always @(posedge clk)
[06:44:15] <ziph> begin
[06:44:15] <ziph> if(count_enable)
[06:44:15] <ziph> begin
[06:44:16] <ziph> if(count_direction) count<=count+1; else count<=count-1;
[06:44:16] <ziph> end
[06:44:16] <ziph> end
[06:44:20] <ziph> :)
[06:44:26] <amee2k> what is that?
[06:44:29] <ziph> Verilog.
[06:44:41] <amee2k> never used that :P
[06:45:10] <ElMonkey> hope you never will :)
[06:45:31] <amee2k> i've got a mega88 with 20MHz xtal here. if i need to, i
[06:45:48] <amee2k> 've got some 74hc00 and a bunch of other discrete logic ics too
[06:46:05] <ziph> amee2k: There's a logic diagram of that code on http://www.fpga4fun.com/QuadratureDecoder.html
[06:46:48] <amee2k> ziph: i know how the theory works, and i've done decoding encoder output before but never this fast
[06:47:07] <amee2k> and the code i have is nowhere near efficient enough to track that encoder
[06:47:16] <ziph> amee2k: A CPLD will be happy to do that speed. :)
[06:47:29] <amee2k> i know, but i don't have one >_<
[06:47:31] <ElMonkey> amee2k, or build a simple counter out of those logic ICs
[06:47:45] <ElMonkey> or use a counter IC :)
[06:47:48] <amee2k> are there DIP packaged CPLDs?
[06:47:54] <ziph> Nope.
[06:48:02] <ziph> Not from the majors, anyhow.
[06:48:14] <amee2k> ElMonkey: the implementation needs to be solid and especially handle bounce properly
[06:48:35] <amee2k> a simple counter clocked from one line and using the other as up/down pin isn't going to cut it
[06:48:50] <ziph> Don't any of the AVR's have quadrature decoders?
[06:49:03] <amee2k> none of the AVRs that i have at least
[06:49:06] <ziph> Looks like the XMEGA does.
[06:49:18] <ElMonkey> if you need to handle bounce, you just need some delays
[06:49:33] <ElMonkey> or clock the counters appropriately
[06:49:33] <amee2k> which would be mega8A/88 and tiny13/24/45
[06:50:20] <karlp> lots of the small arms hve quadrature decoders built in too.
[06:50:25] <amee2k> ElMonkey: that doesn't work. see, the encoder is on a servo motor so unlike a hand-operated encoder knob it can stop anywhere and has a lot of vibration
[06:50:54] <ziph> The ARM quadrature decoders do digital filtering.
[06:51:07] <amee2k> that it can stop anywhere means it can especially stop right next to a switching point and keep going back and forth at the slightest vibration
[06:51:16] <ElMonkey> amee2k, as long as the bounce is only of one of the two inputs, it doesnt matter
[06:51:22] <amee2k> that means the bounce time is effectively infinite
[06:51:27] <ElMonkey> you won't lose count
[06:51:43] <ElMonkey> if both bounce, you're proper fucked no matter what you do
[06:51:50] <amee2k> the naive approach using A and B outputs as clock and direction will lose count
[06:51:56] <ElMonkey> i mean, i fboth vibrate at the same time
[06:52:07] <ElMonkey> amee2k, indeed
[06:52:14] <ElMonkey> that diagram ziph linked should work though
[06:52:31] <amee2k> at low speeds my own code that i've used for encoder knobs before works just fine
[06:52:53] <ElMonkey> i mean this http://www.fpga4fun.com/images/QuadratureDecoder2.gif
[06:53:18] <amee2k> but it works by polling from a timer interrupt. i've cranked up the polling rate so much that it accounts for almost 2/3rd of the CPU time
[06:53:54] <amee2k> but i keep losing count if the input frequency is higher than maybe 20-30kHz
[06:54:44] <ElMonkey> at what rate does your polling run?
[06:56:04] <amee2k> ~40kHz i think. i'd have to measure if you want a precise figure
[06:56:34] <amee2k> that gives me only like 500 clocks per interrupt
[06:57:07] <ElMonkey> sounds like plenty to me :)
[06:57:23] <ElMonkey> updating a counter should not take more than a few cycles
[06:57:32] <amee2k> yeah but my algorithm apparently isn't very efficient
[06:58:14] <amee2k> i'm also tracking the encoder in a signed 8-bit var only so if i don't service the encoder driver before it overflows i'm hosed too
[06:58:31] <ElMonkey> http://www.helicron.net/avr/quadrature/?
[06:58:37] <amee2k> at 100kHz that would be just less than a millisecond
[06:59:16] <amee2k> ooh, assembly
[06:59:28] <ziph> What about doing an edge triggered interrupt on the next expected transition and when you get it flipping to an edge triggered interrupt on the other input.
[06:59:40] <amee2k> at this point i'm considering using a tiny13 or something small to do the encoder decoding
[06:59:57] <ElMonkey> thats probably a good idea
[07:00:02] <ElMonkey> as you cant have any other interrupts
[07:00:08] <ElMonkey> else you'll lose count
[07:00:23] <amee2k> that would mean i don't need to mix up hard real time stuff with the rest of my code
[07:00:36] <amee2k> exactly
[07:01:43] <ElMonkey> of course, if this is the only thing you do, just disable interrupts and loop it
[07:02:28] <ElMonkey> it seems like a good idea to try and output more than 8 bits
[07:02:39] <ElMonkey> else your other code is still very timing constrained
[07:02:45] <amee2k> the rest i want to do is converting the encoder count into number of rotations and angle, driving an LCD and a DC motor
[07:05:37] <amee2k> i can *probably* do it in my mega88 as it is, but it still feels cramped
[07:07:29] <ElMonkey> if your interrupt is delayed, that reduces the effective polling rate by a lot
[07:07:54] <amee2k> i know
[07:08:15] <amee2k> but the interrupt is taking up a lot of execution time as it is and the LCD is slow to update too
[07:08:35] <amee2k> my code can handle the encoder, but only if there isn't anything else around
[07:08:43] <ElMonkey> i update the lcd on the "main" loop
[07:08:51] <ElMonkey> the lcd interrupt just posts a flag
[07:09:10] <amee2k> yeah, but it still means the main loop will stall for so-many milliseconds
[07:09:18] <ElMonkey> so?
[07:09:25] <ElMonkey> everything else is interrupt driven, in my case
[07:09:26] <Kevin`> indeed, don't spend time in interrupts. if you do that, you can use as many as you want
[07:09:36] <amee2k> in that time i'm losing track because the encoder's internal counter overflows like 10x
[07:09:37] <ElMonkey> and the main loop just does the low-priority stuff
[07:09:48] <ElMonkey> well use a 16 bit counter
[07:09:54] <ElMonkey> that shouldnt make much of a difference
[07:09:55] <amee2k> hrm
[07:10:27] <amee2k> lemme try some stuff. i'll also see if i can get a precise figure on the encoder driver's cpu usage
[07:24:17] <amee2k> err that can't be right
[07:24:31] <amee2k> my encoder ISR only needs 600ns to execute??
[07:25:13] <amee2k> thats like 12 clocks or so
[07:30:25] <amee2k> my ISR is 80 bytes long according to the assembler output, including branches, how can that execute in VERY consistent 750ns ??
[07:32:33] <amee2k> err, i'm not accounting for like 50 clocks for push and pop instruction in my measurement >_<
[07:33:01] <nevdull> what's your clock speed?
[07:33:05] <amee2k> 20MHz
[07:33:43] <nevdull> so 50 instructions at 20MHz sould be like 2.5 usec or something
[07:34:51] <amee2k> its in an ISR though
[07:35:20] <nevdull> yah definitely want to keep them as short as possible
[07:35:34] <amee2k> i'm considering rewriting the ISR in assembly, actually
[07:36:16] <amee2k> some stuff that the compiler does there looks kinda wonky, but i don't think my asm is good enough to beat the compiler
[07:37:03] <nevdull> if you're worried about your 80 bytes being too long you can do a sort of poor man's peephole optimization and run avr-nm --size-sort file.o and look at the biggest ones
[07:37:26] <nevdull> yah i agree...the compiler can crank out some pretty optimized code
[07:37:29] <amee2k> i'm not worried about 80 bytes of flash but about execution time
[07:37:57] <amee2k> i'll need to fire that ISR at something like 100k ints per second
[07:38:01] <nevdull> you can always write it in c and then run avr-gcc -fverbose-asm -S file.c with optimization flags and see how gcc assembles it
[07:38:27] <amee2k> i'm looking at it with objdump in the object file now
[07:39:12] <nevdull> 100k ints per sec is smoking
[07:39:24] <amee2k> i know :/
[07:43:58] <nevdull> but if you're right about the ISR being 50 clocks, even at 100k ints you're looking at 2.5x10-6 * 100k = 0.25 sec
[07:48:24] <amee2k> what is, much to my disapproval, smoking as well is my voltage regulator >_<
[07:48:33] <amee2k> the LCD backlight pulls a lot of juice
[07:48:45] <nevdull> linear regulator?
[07:48:49] <amee2k> yes
[07:49:13] <nevdull> ah yah...voltage regulation through heat evolution. gotta love it.
[07:49:14] <amee2k> i've got one huge pecker of a heatsink on it already
[07:49:34] <nevdull> hehe
[07:51:34] <nevdull> i just got two switching regulators as samples from maxim last week but haven't gotten to solder them on anything yet
[07:53:09] <amee2k> nice :)
[07:53:36] <amee2k> i got some tiny SMT ones here somewhere that i got for free somewhere i don't remember
[07:53:37] <nevdull> what sort of LCD are you using? i picked up a handful of big LCDs for a commercial printer on surplus but they use CFL for backlight and hat just adds so much more complication
[07:53:45] <amee2k> and i have some 34063s >_>
[07:54:02] <amee2k> the generic 2$ modules that conrad sells for 20 >_>
[07:54:03] <Kevin`> why are you using a backlight?
[07:54:11] <amee2k> green LED backlight in the module
[07:54:23] <nevdull> oh like HD44870 or whatever it is?
[07:54:31] <amee2k> yeah, exactly thes4e
[07:54:56] <nevdull> i have to use a backlight because they are grey monochrome (transflective?) LCDs and you can't see a thing on them without it
[07:55:22] <Kevin`> shoulda got ones without backlights =p
[07:55:28] <amee2k> these are the "normal" ones that look like a pocket calculator or watch display
[07:55:33] <Kevin`> with a pure reflective coating
[07:55:35] <nevdull> yah i know but i got a box of 5 of them for $8
[07:55:46] <amee2k> they're readable without backlight too, but i like backlights :)
[07:55:48] <Kevin`> well that's a pretty good price
[07:56:05] <amee2k> yeah, when i see them for cheap i make a point of getting some
[07:56:36] <amee2k> got like 4 or 5 2x16ch ones around here and two graphical ones (22x100-someting pixels or so
[07:56:39] <nevdull> i like backlights too..especially those pretty colored ones. i have a couple of black background/blue lettering HD44870 LCDs i bought on ebay
[07:56:39] <amee2k> )
[07:56:49] <nevdull> ah sweet
[07:57:27] <nevdull> my fav LCD i own is a KS0108 chipset 192x64 graphical LCD but the way you write tot he screen is horked.
[07:57:59] <nevdull> nice thing about the ones you have is you can use a 4-bit interface if you're short on GPIO
[07:58:34] <amee2k> yep :)
[07:58:42] <amee2k> or too lazy to wire up all pins :)
[07:59:01] <amee2k> hmm something is borked about my encoder driver now >_<
[07:59:16] <nevdull> i just use a serial-to-parallel shift register in front of my HD44870's to save on GPIO
[08:00:01] <nevdull> what's an encoder driver?
[08:00:21] <amee2k> the driver software to decode the signals from a rotary encoder
[08:00:30] <nevdull> aah gotcha
[08:02:34] <amee2k> i also find it quite annoying that gtkterm doesn't do \r and \n correctly
[08:02:55] <Tom_itx> try realterm
[08:03:02] <nevdull> i use minicom
[08:03:03] <Tom_itx> windoz
[08:03:16] <amee2k> realterm isn't in my repo :/
[08:03:24] <Tom_itx> no it's windoz
[08:03:37] <amee2k> oh
[08:03:41] <amee2k> my condolences
[08:03:41] <Tom_itx> and probably the most versatile comm program you will ever run across
[08:04:36] <Tom_itx> at least check out what you're missing out on
[08:04:36] <nevdull> win: http://www.softpedia.com/get/System/System-Miscellaneous/AVR-Terminal.shtml
[08:04:55] <amee2k> minicom: cannot open /dev/tty8: Permission denied
[08:04:59] <amee2k> o.O
[08:05:02] <nevdull> sudo minicom -s
[08:05:13] <Tom_itx> you don't need sudo for realterm :)
[08:05:24] <nevdull> ctrl-a O
[08:05:27] <amee2k> what does a serial terminal need root for??
[08:05:36] <Tom_itx> permission
[08:05:41] <nevdull> ioctl calls probably
[08:06:09] <amee2k> cutecom/gtkterm work fine
[08:06:54] <amee2k> i set up the device perms so i can access the serial port as my user, which is /dev/ttyS0 and not tty8 anyway
[08:07:10] <nevdull> you you can use 'udev' to do that
[08:07:32] <amee2k> i've allready set it up so it should work
[08:08:50] <nevdull> i have a wonky setup through an ftdi2232 usb-to-usart chip and it always creates /dev/bus/usb/004/00#
[08:08:57] <nevdull> or so sayeth 'usb-device'
[08:09:07] <amee2k> my box still has a real serial port
[08:09:23] <amee2k> and i'm glad as fuck for it
[08:09:35] <nevdull> i installed a real 2-port MosChip serial card *and* a parallel card in my box, too
[08:09:51] <amee2k> err, got minicom to run as user. how do i save configuration in a place other than /etc??
[08:09:58] <nevdull> on my mini2440 arm dev board i have to have an rs232 and a usb connection to program it
[08:10:02] <amee2k> (i'm in minicom -s now)
[08:10:27] <nevdull> ctrl-a P i think and there's an option to save elsewhere
[08:10:52] <amee2k> aah brb phone
[08:13:00] <amee2k> nevdull: does nothing
[08:13:28] <amee2k> i only have "save setup as dfl" and "save setup as..."
[08:13:46] <OndraSter> mornin
[08:15:05] <nevdull> k one sec, lemme run it here and see
[08:16:12] <nevdull> so when i run 'sudo minicom -s' it automatically shows me a curses menu where i can select to save 'dfl' to a different location
[08:17:44] <amee2k> save to dfl only says "cannot write to /etc/blah" or something for me
[08:17:56] <amee2k> minicom 2.5 btw, i just noticed
[08:18:42] <karlp> save setup as defl requires root, save setup as... gives a named file in your home dir somewhere.
[08:19:02] <karlp> minicom often still ships with some weird init and reset stuff it tries to do.
[08:20:01] <amee2k> save as... asks for a name, then tries to save to /etc/minicom/minicom.$NAME or something
[08:20:16] <amee2k> the error message disappears too quickly to read >_<
[08:21:17] <nevdull> you can remove the -s and use -o to skip initialization
[08:21:29] <nevdull> and the -s btw is what tries to save it to /etc/minicom/blah
[08:22:34] <amee2k> hmm putty works fine but the font is a bitch lol
[08:22:48] <nevdull> yah i hate putty's font selection
[08:23:09] <nevdull> i use Pragmatta TT for all my coding (i can't use a font for coding that doesn't put a slash or dot in the zero character)
[08:23:14] <nevdull> but putty won't use it
[08:24:29] <nevdull> if you're an IDE sorta guy, you can use the RXTX plugin for Eclipse when programming your AVR to connect to your AVR's USART
[08:24:38] <amee2k> the font itself is fine, but it is very small
[08:25:09] <amee2k> i also can't seem to remember how to get to the config dialog from the terminal window...
[08:25:20] <amee2k> i used to use it like 10 years ago when i was still using windows
[08:26:14] <nevdull> h hmmm
[08:26:23] <karlp> picocom and screen both work too...
[08:26:49] <karlp> except, different escape chars for all of them :)
[08:26:56] <nevdull> in win putty you just right click on the window decoration
[08:27:21] <nevdull> i've seen TerraTerm, too, but don't have much experience with it
[08:28:38] <amee2k> hmm right clicking anywhere does nothing in this version
[08:29:22] <amee2k> version says "dev snapshot 2010-12-08" >_<
[08:56:34] <amee2k> this is annoying
[08:57:28] <amee2k> if i crank up the timer enough to reliably not lose any rotations anymore, CPU load is 40% from the encoder ISR alone
[08:59:05] <nevdull> how does your timer work with your encoder?
[08:59:58] <amee2k> timer fires interrupt at ~220kHz rate. interrupt polls the encoder lines, converts to grey code, then to binary, then adds to counter variable
[09:00:25] <amee2k> i can pastebin the code... found it online somewhere in rather pityful condition
[09:01:50] <amee2k> i originally used the code for manually operated encoder knobs where it worked fine as long as the ISR was executed like once per millisecond or so and efficiency wasn't important
[09:01:56] <nevdull> ah i see. i don't know much about encoders, so this may seem silly, but can't you connect it to INT0 for edge triggering or something?
[09:02:35] <amee2k> i'm not sure how i could use that as an advantage
[09:03:24] <amee2k> since you can't use hardware debounce with snap-less (right term?) encoders like in a servo motor
[09:03:46] <nevdull> you can cause the interrupt to fire only when encoder changes without having to poll
[09:04:07] <amee2k> since the motor can stop in any position, bounce time is essentially infinite
[09:05:10] <amee2k> hence why i was asking earlier if someone knew a reference implementation for encoder decoder code suitable for servo encoders
[09:05:10] <nevdull> oh and the encoder reflects the motors stator/rotator position?
[09:05:16] <amee2k> yes
[09:05:21] <amee2k> 2000 pulses per rotation
[09:05:43] <amee2k> my code can handle it fine, but turns out it can't do pretty much anything else anymore now >_>
[09:05:50] <nevdull> hehe
[09:06:20] <nevdull> what syncs up the encoder and the motor?
[09:06:31] <amee2k> "sync up"?
[09:06:36] <nevdull> you use hall sensors or anything like that?
[09:06:50] <nevdull> hmm, i mean, like how do you "zero" the encoder to the motor position?
[09:07:12] <amee2k> i've got a zero button for the moment (which really is the MCU reset in disguise)
[09:08:43] <nevdull> ah gotcha
[09:09:14] <amee2k> i'll probably implement a proper zero button later. in software that would only be like "position = 0;"
[09:09:38] <amee2k> i'm counting encoder steps in a 32 bit var, then converting to rotations and degrees for display
[09:10:40] <amee2k> so i get output like "pos: -45 + 248°"
[09:12:11] <nevdull> your servo use like the standard 1.5ms pulse width?
[09:12:25] <nevdull> or a range thereof
[09:12:33] <amee2k> no way lol
[09:13:07] <amee2k> output is quadrature encoder style, and i'll need to handle up to 100kHz properly
[09:17:25] <nevdull> how many tracks (is that what they're called?) does your encoder have?
[09:17:36] <amee2k> "tracks"?
[09:17:52] <nevdull> rings?
[09:17:57] <amee2k> "rings"?
[09:18:48] <nevdull> like in single-track grey encoding
[09:19:01] <nevdull> i may not have my head wrapped around the concept well enough
[09:19:36] <amee2k> its just a quadrature encoder, like the shitty chinese encoder knobs
[09:19:45] <amee2k> it just goes waaaay faster since it is driven by a motor
[09:20:30] <nevdull> ah haha. how many bits do you use for angular encoding?
[09:20:43] <nevdull> or is there a standard for quadrature encoders?
[09:21:03] <amee2k> i'm tracking steps in a uint32_t, then converting to full rotations and degrees
[09:21:38] <amee2k> that should last for like 2.1M rotations, but the conversion code will overflow at 32k rotations in either direction
[09:22:42] <nevdull> is that because of a signed 16-bit value?
[09:23:07] <nevdull> or you use two's complement to represent negative direction?
[09:23:56] <amee2k> signed 16 bit for the rotations
[09:24:00] <nevdull> well, if there is a "negative" direction (assuming it would be right or left of "zero")
[09:24:12] <amee2k> i think that'll give enough range but changing it to use 32 bit would be easy enough
[09:25:02] <nevdull> i guess it depends on how much angular resolution you're shooting for or is required
[09:25:20] <amee2k> 1° resolution is more than sufficient
[09:25:41] <amee2k> i'm considering using an external tiny13 or something to do the encoder decoding
[09:25:57] <amee2k> that gives 1 pulse per degree and a direction signal to my main mcu
[09:27:19] <nevdull> sounds reasonable. are there ever any problems with quickly turning the knob?
[09:27:50] <amee2k> problems?
[09:27:51] <nevdull> or a limit on angular rotation of the knob
[09:27:57] <amee2k> as in, whether it can occour?
[09:28:10] <amee2k> or whether losing steps would be a serious issue?
[09:28:21] <nevdull> yes, the latter
[09:28:39] <nevdull> i was wondering how fast is too fast to turn the knob without losing information
[09:28:57] <amee2k> losing a step every now and then is not a problem but if it gets more than say 1% off it would be bad
[09:29:41] <amee2k> nyquist ftw. input frequency > half the interrupt frequency == lost steps for sure
[09:30:15] <nevdull> can your system detect when the encoder needs zeroing to the motor?
[09:30:24] <amee2k> where the input frequency would count double though
[09:30:43] <nevdull> ah yes
[09:30:46] <amee2k> zeroing will be triggered manually. i only need to keep track of the position
[09:31:30] <nevdull> it sounds like you've put a lot of thought into your project. sounds pretty cool.
[09:32:06] <Kevin`> you are putting way too much work into the project more like. can't you just have it trigger once per revolution?
[09:32:07] <amee2k> yeah, i make a point of that
[09:32:24] <Kevin`> haha :D
[09:32:29] <amee2k> sometimes i think i like doing the conceptual stuff too much and it only ends up getting in the way because i can't make up my mind anymore :/
[09:33:19] <nevdull> well at least you have it in the right order. too many people start a project without sufficient clue/concept
[09:33:40] <amee2k> yeah, true too
[09:35:09] <nevdull> brb taking my dog out
[09:35:11] <amee2k> hm. lcd not worky. :/
[09:41:42] <amee2k> oooh
[09:41:53] <amee2k> lcd *is* worky but contrast is sucky >_>
[09:44:50] <OndraSter> so you got it working?
[09:47:20] <amee2k> kind of... i'm working on it >_>
[09:47:44] <amee2k> the character table is a bit weird
[09:53:11] <nevdull> you have a voltage divider between 5V and GND on your contrast pin of your lcd or some other prob?
[09:53:35] <nevdull> or a potentiometer/rheostat more likely
[09:53:43] <amee2k> i have
[09:54:17] <amee2k> contrast is kinda ok when looking straight down on the panel, but viewing angle is really shitt on this one
[09:54:27] <nevdull> ah gotcha
[09:54:35] <amee2k> towards the sides is ok too, but up and down is the worst
[09:55:00] <OndraSter> just as on the normal ones
[09:55:03] <OndraSter> you gotta watch directly
[09:55:08] <OndraSter> few ° out, nothing
[09:55:22] <amee2k> yeah
[09:55:37] <amee2k> but i've still had modules that weren't nearly as sensitive to viewing angle as this one
[09:57:01] <nevdull> i'd like to pick up a nice, smallish OLED
[09:57:10] <nevdull> they're really crisp
[09:57:32] <amee2k> uploading a video of what works right now
[09:59:22] <amee2k> i used some paper tape to make an alignment mark on the motor and driveshaft... when i turn it on in the video, the marks are aligned. that is hard to see from the camera position but important at the end
[10:00:57] <amee2k> and the heatsink on the top left of the board is the vreg... smaller heatsink in the top center is the current limiter for the motor driver
[10:01:51] <amee2k> http://ve504.cugnet.net/~amee2k/sandbox/CIMG8925b.avi (12MB; 1:07)
[10:05:19] <nevdull> that's a bright backlight you got there
[10:05:30] <eatyourguitar> I don't know what it does or why but it looks cool
[10:05:41] <amee2k> hehe
[10:06:04] <Kevin`> it's a masochistic transformer winding counter
[10:06:18] <amee2k> your mom is a masochist
[10:06:45] <Kevin`> :/
[10:07:05] <amee2k> whats it with you and masochism anyway?
[10:07:30] <Kevin`> it just happens to be true
[10:07:43] <amee2k> how so?
[10:08:54] <Kevin`> if just making it work was your goal it would already be done using a photointerruptor from old parts and far simpler code ;p
[10:09:31] <amee2k> i am using a photointerruptor from old parts. its an old servo motor i got on ebay with optical encoder >_>
[10:09:36] <Kevin`> or a mechanical counter
[10:10:01] <Kevin`> it's cool anyway
[10:10:31] <amee2k> but yeah, trying to learn something from a project is a rather masochist attitude. the arduino community agrees too :P
[10:11:13] <keenerd> The arduino folks would say that just for using a plain AVR.
[10:11:45] <amee2k> lol
[10:11:52] <Kevin`> I doubt this is doable with just the arduino libraries, the timing is rather tight
[10:12:22] <amee2k> i know. for the moment it works, but i'm not sure if i have to start using assembly at some point
[10:13:35] <Kevin`> what all are you doing in the isr?
[10:14:12] <amee2k> just tracking the encoder output, and decrementing a counter variable if != 0
[10:14:27] <amee2k> i'm using the counter variable for timing stuff in the main loop
[10:14:45] <amee2k> with this much interrupt load, the busy_waiting delays are wonky
[10:17:18] <amee2k> Kevin`: the problem is i'm using not optimized code for the encoder that i found online a while ago for tracking manual encoder knobs
[10:17:33] <amee2k> not very* optimized anyway
[10:18:15] <amee2k> hence why i'm blowing around 40% cpu time on just executing the ISR
[10:29:47] <nevdull> amee2k: do you have any/many spare GPIO ports on your AVR?
[10:30:34] <amee2k> nevdull: i've got 4 pins left, plus the three SPI pins for ISP
[10:30:56] <amee2k> the 4 pins are all on port C
[10:31:10] <amee2k> SPI pins are port B or D i think
[10:31:22] <nevdull> how many bits do you need for your counter variable in your ISR?
[10:31:30] <amee2k> 16
[10:32:44] <nevdull> ouch...well, i was going to suggest a neat trick i saw that is twice as fast as using SRAM or the stack by using IN and OUT instructions on a PORT as if it were a register
[10:34:14] <amee2k> hmm i'm not using the 16 bit counter in timer1
[10:34:40] <amee2k> i could use the OCR1* registers for it
[10:34:56] <nevdull> and i did see a trick using SUBI and SBCI for fast additions in very tight loops/ISRs when you need to add a constant 8bit value (ie 1) to a 16bit register. you save a register and load instruction using SUBI/SBCI instead of ADD/ADC
[10:34:57] <Kevin`> some chips have unused io registers too
[10:35:00] <amee2k> thats actually a pretty neat idea
[10:35:34] <amee2k> how do i add an assembly ISR to an otherwise C-only project?
[10:35:40] <amee2k> any good links on that?
[10:35:54] <amee2k> compiler is gcc
[10:37:32] <amee2k> my ISR uses two 16 bit local vars, but one could be reduced to only 8 bit... i could abuse the timer1 registers for storing all that
[10:37:58] <karlp> amee2k: you mean, like this: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html
[10:38:04] <karlp> and http://www.nongnu.org/avr-libc/user-manual/group__asmdemo.html
[10:38:19] <nevdull> amee2k: externally link the asm isr function prototype in the c file
[10:38:32] <nevdull> then call it as normal i believe with avr-gcc
[10:38:53] <Kevin`> amee2k: couldn't you use a single 8-bit register in the isr and have the rest of the counter in the main loop only? if the counting really takes that much time
[10:39:05] <amee2k> i'm especially concerned about the C<->asm interface... i know how to do c-only and (a bit of) asm-only
[10:39:56] <amee2k> Kevin`: 8 bit counter in the ISR means -127..128. at 100kHz that'll overflow in less than a millisecond
[10:40:09] <Kevin`> So? :)
[10:41:32] <amee2k> updating the display alone takes like 5ms
[10:41:34] <Kevin`> asm() has several parameters for defining the interface to the surrounding c code
[10:42:02] <amee2k> (and yes, i just measured that)
[10:43:18] <karlp> so, save the position in state, and only update the display ever 500ms or so.
[10:43:26] <karlp> there's no reason to try and update the display in the isr
[10:43:36] <amee2k> thats what i'm doing
[10:43:47] <karlp> or yeah, sorry, missed your overflow.
[10:43:52] <karlp> so, use more bits :)
[10:44:01] <amee2k> LOL
[10:44:10] <amee2k> thats exactly why i'm using 16 bits :P
[10:49:02] <nevdull> amee2k: yeah, you should read up on the avrlibc docs re: the calling convention to find what registers are used for function parameters, return values, stack frame, etc. IIRC r0 can be used as a temp reg but you need to save and restore it; r1 must always be set to 0; r2-r17,r28,r29 are used by avr-gcc for storage. r18-r27,r30,r31 are free to use and guaranteed not to be clobbered by avr-gcc
[10:50:14] <nevdull> and i'm used to building the IVT in ASM with RJMPs and writing the ISR in ASM with RETI
[10:50:17] <amee2k> hu?
[10:50:33] <amee2k> gcc ignores over 10 registers??
[10:52:05] <nevdull> if i recall correctly
[10:52:44] <amee2k> okay
[10:52:59] <amee2k> then i don't need timer registers, i can just use these
[10:53:02] <Kevin`> you can tell gcc that you are about to clobber registers and it will work around them
[10:53:23] <nevdull> this was in my bookmarks. it's a good read, especially for what you're doing. http://myweb.msoe.edu/~barnicks/course/CE-2800/documents/Mixing C and assembly language programs.pdf
[10:53:46] <Kevin`> 404
[10:53:48] <amee2k> 404
[10:53:50] <amee2k> lol
[10:53:54] <keenerd> Note the spaces...
[10:54:02] <Tom_itx> re abcminiuser
[10:54:07] <Tom_itx> how's it goin?
[10:54:08] <Kevin`> even with the spaces
[10:54:08] <amee2k> i did
[10:54:19] <amee2k> not even the documents directory seems to exist
[10:54:19] <Kevin`> which was annoying to copy, since urls aren't supposed to have spaces
[10:54:25] <nevdull> i've only seen clobber lists used with inline asm in avr-gcc
[10:54:36] <Tom_itx> woot! finally got a new batch of programmers in
[10:54:42] <Tom_itx> now to assemble
[10:54:44] <nevdull> sorry s/course/courses
[10:55:04] <nevdull> i typed it by hand as i only use linux at console and my browser was on another computer ;)
[10:55:05] <keenerd> http://myweb.msoe.edu/barnicks/msoe-myweb/courses/CE2810/documents/Mixing%20C%20and%20assembly%20language%20programs.pdf
[10:55:50] <abcminiuser> Hey Tom_itx
[10:56:00] <abcminiuser> Been looking for you doe a whileish
[10:56:33] <Tom_itx> been out of the country a while
[10:56:49] <ElMonkey> huh...
[10:57:25] <amee2k> running from authorities?
[10:57:26] <amee2k> >_>
[10:57:36] <Tom_itx> uh huh
[10:59:16] <abcminiuser> Had a report of the programmer failing to program EEPROM again
[10:59:19] <abcminiuser> But this time with an example
[10:59:26] <Tom_itx> hmm
[10:59:39] <Tom_itx> i gotta run but i'll read the log
[10:59:39] <abcminiuser> I think I've fixed the problem, but I was wondering if you could test since I don't have any gear
[10:59:45] <Tom_itx> sure can
[10:59:46] <abcminiuser> Ah okies no worres
[10:59:51] <abcminiuser> Next time, not a priority
[10:59:54] <Tom_itx> but i gotta go shopping right now
[11:00:01] <Tom_itx> is the git current?
[11:00:04] <nevdull> amee2k: also in my bookmarks: http://www.nognu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage (more description on what registers avr-gcc uses)
[11:00:08] <Tom_itx> i'll grab it and test it when i get back
[11:00:28] <abcminiuser> No I'll update it
[11:00:30] <Tom_itx> i'll need an eeprom test program
[11:00:37] <Tom_itx> bbl
[11:00:49] <amee2k> err what the fuckerbunny
[11:01:02] <amee2k> could it be that gcc's 32 bit int support is buggy as hell?
[11:02:03] <nevdull> doesn't it use GMP lib?
[11:02:39] <nevdull> are you having a uint32_t problem?
[11:02:46] <amee2k> i don't know, but i'm getting screwed up results when calculating angular velocity
[11:03:00] <ziph> How would it use GMP for 32 bit integer code generation?
[11:03:01] <nevdull> in c?
[11:03:04] <amee2k> like it shows 25k rpm while the shaft is standing still
[11:03:13] <amee2k> yes, C
[11:03:34] <abcminiuser> Tom_itx, for when you get back: Guy said that programming a large EEPROM file into the MEGA8 was timing out prematurely, since it's done per-byte (and is thus very slow)
[11:03:36] <timemage> amee2k, do you have code posted?
[11:03:40] <amee2k> turning it over by hand reads reasonable values (100-150rpm, which matches about what i can manage by hand)
[11:03:55] <amee2k> but when i power the motor the readings go all nuts
[11:04:05] <abcminiuser> Tom_itx: so I've updated it to reset the watchdog each time an ISP programming section completes and when data is received in PDI/TPI mode
[11:04:11] <amee2k> timemage: how much code do you want?
[11:04:20] <abcminiuser> Tom_itx: Guy says this works, want to make sure it doesn't break anything else obvious
[11:04:33] <abcminiuser> Tom_itx: Also note other relevant changes to AVRISP clone in latest GIT, see changelog
[11:04:35] <timemage> amee2k, just thought you might want someone to look at where you think integers have gone wrong.
[11:04:48] <nevdull> ziph: i think gcc uses GMP for mostly signed and rational arithmetic
[11:05:19] <ziph> How?
[11:05:23] <amee2k> timemage: i haven't posted any code yet, but i can. just checking how much you want. some people get angry if i only post relevant sections, some start bitching if i post everything ;)
[11:06:22] <timemage> amee2k, well, i'm not set with avc-gcc on this machine. but the closer to compilable the better.
[11:06:44] <amee2k> http://paste.debian.net/154086/
[11:07:13] <amee2k> the relevant calculations that are going wrong are lines 25 through 30. the result of which is displayed in line 42
[11:07:24] <amee2k> the position calculation before that works fine
[11:07:41] <amee2k> if declarations for any variables are missing by accident, please do tell
[11:08:58] <nevdull> looks like you're missing a right paren on line 25?
[11:09:18] <amee2k> the if() is tied to a timer interrupt through busy waiting and entered 4 times per second
[11:09:23] <amee2k> ooh, err yeah i am
[11:09:56] <timemage> hmm, not a paste error?
[11:09:57] <amee2k> there also is a slash too much on that line
[11:10:29] <amee2k> hrm.
[11:10:35] <amee2k> for some reason it seems to work now
[11:10:38] <timemage> because that line shouldn't have survived the compiler.
[11:10:40] <nevdull> woot
[11:11:25] <amee2k> it didn't. i'm working on that code tight now and just pasted what i had at that moment :/
[11:11:44] <timemage> heh
[11:13:05] <Tom_itx> abcminiuser, i don't have a mega8 to test. i have a mega 128 32 168 328 if those produce the same results i can test it
[11:13:21] <Tom_itx> k, bak in a while
[11:14:11] <amee2k> i've had issues with 32 bit int code and gcc before that disappeared by what i thought was just harmless refactoring
[11:15:45] <timemage> amee2k, you might want to use "%" PRId16 for your snprintf for rotations and speed.
[11:16:04] <amee2k> "PRId16"?
[11:16:41] <timemage> amee2k, yeah, there are macros in <inttypes.h> for printf format specifiers for types like int16_t
[11:17:03] <timemage> amee2k, %d is meant for plain int. for an avr it won't many any difference.
[11:17:23] <amee2k> ooh, interresting
[11:18:04] <timemage> if you port the code back to a platform with 32bit ints it will continue to work with the macro.
[11:19:05] <amee2k> i don't have any 32 bit MCUs
[11:19:42] <amee2k> since i'm kind of with my back against the wall clock wise, i'd use anything faster anyway i suppose
[11:21:19] <nevdull> also, i think if variables 'position' and 'last_pos' in tmp = (int16_t)(position - last_pos) is greater than sizeof(int16_t) you'll only get the lower 16-bits of the computer 32-bit value
[11:22:33] <nevdull> that is, position = 65000 and last_pos = 2000, (position - last_pos) = fffff618 while tmp = f618
[11:22:58] <amee2k> hu?
[11:23:27] <amee2k> i changed the line to "speed = (position - last_pos) * 3 / 25;" by now, but in the old line, the subtraction should be all 32 bit
[11:23:30] <nevdull> you're casting a 32-bit int into a 16-bit int you lose the high order 16-bits
[11:24:26] <karlp> I've had those problems. int being 16bit on avr causes some things that look like they shoudl work to only work if you put them on multiple lines to make sure the casting worked the way you assumed :)
[11:24:27] <amee2k> nevdull: an overflow there would indicate more than 32k pulses per 1/4 second
[11:24:51] <amee2k> that would be 64ki turns per second, or about 4krpm
[11:25:05] <amee2k> err, wait
[11:25:51] <amee2k> 64ki pulses* per second. 4krpm is correct
[11:26:26] <amee2k> with the current circuit the motor manages barely 800-1000 rpm
[11:26:31] <amee2k> unloaded
[11:26:50] <nevdull> you could modulo MAX_INT16 (ie tmp = (position - last_pos) * 3 / 25 % MAX_INT16 to prevent overflow if it'll be a problem
[11:27:04] <amee2k> but since i changed the whole calculation to 32 bit now, it would work up to 64kiRPM
[11:27:22] <nevdull> ah good
[11:28:16] <amee2k> well, the calculation will work up to 85Mrpm, then it will truncate to 16 bit ;)
[11:28:49] * amee2k scratches his head
[11:28:58] <nevdull> and is that ((position - last_pos)*3)/25) or ((position - last_pos)*(3/25)) ? you might wanna use extra parens to specify
[11:29:02] <amee2k> i need a different display format. i'm running out of characters
[11:29:20] <amee2k> evaluation order from left to right seems to work
[11:29:34] <amee2k> * and / have the same precedence
[11:29:52] <nevdull> gotcha i forget my order of precedence and left/rigth associations
[11:30:24] <amee2k> i've reduced all the fractions in the meantime as well to prevent overflow in intermediary results
[11:30:49] <nevdull> what is the division by 25 about?
[11:30:59] <amee2k> 4*60 / 2000 = 3 / 25
[11:31:45] <amee2k> 4 because it is executed every 1/4th second, 60 because i want RPM and 2000 because i have 2k pulses per rotation
[11:36:07] <nevdull> amee2k: if your 25 value were a power of 2 instead you could shave off some cycles (and a few extra instructions) by right shifting instead of dividing
[11:36:47] <amee2k> i know
[11:36:50] <amee2k> but it isn't
[11:37:09] <nevdull> although it gets a little tricky with signed ints since shifting extends the sign bit thru the result
[11:38:42] <karlp> anyone know how to work around or solve my makefile problem: http://www.pastebay.org/306521
[11:39:00] <karlp> I want to rebuild a bunch of .elf/.hex files with different defines for the different hardware.
[11:39:33] <karlp> the files get built, but if I then try and use "make HARDWARE=BLAH program" it sees that the main.o file is potentially newer than the final elf file, so it relinks it. (using whatever hardware was last)
[11:39:45] <karlp> if I manually flash the hex files, I can see tha tthey were all built properly.
[11:40:11] <karlp> I guess I should build the objects into separate directories for each hardware as well?
[11:40:22] <karlp> so I don't have a single main.o that keeps getting rebuilt?
[11:41:30] <nevdull> hmm, are you using .PHONY targets?
[11:41:37] <karlp> program is in PHONY yes.
[11:42:16] <karlp> it relinks the elf and extracts the hex when I call make HARDWARE=wop program
[11:42:22] <karlp> but it doesn't recompile anything.
[11:42:44] <abcminiuser_> Tom_itx, MEGA168 will do
[11:43:09] <karlp> so it always ends up with the main.o from the final compile for STRIP_8P_1X8
[11:43:18] <nevdull> what if you include 'touch *.c' in your program: target?
[11:44:00] <karlp> that would just cause it to recompile the whole thing wouldn't it?
[11:44:06] <karlp> the hex and elf files are already ok,
[11:44:15] <karlp> it's just that when I call program, it relinks them, instead of using them.
[11:44:35] <karlp> I presume, because main.o is a dependency of the elf.
[11:44:58] <nevdull> i thought you wanted to recompile your source with the given define?
[11:45:07] <karlp> well, it was recompiled,
[11:45:14] <karlp> the make dist correcty recompiles everything
[11:45:28] <karlp> but make program for a single hardware triggers a relink of the elf
[11:46:17] <karlp> I'd like to be able to do "make dist; make HARDWARE=A program; make HW=B program;" and have it compile them once.
[11:47:48] <nevdull> why not take out the prerequisites for the program target then? (ie $(TARGET).hex and $(TARGET).eep so that it only runs avrdude with the premade hex? would that work?
[11:48:22] <karlp> yeah, trying that now actually.
[11:48:44] <karlp> just tell people they have to run dist first.
[11:49:03] <karlp> that's probably far and away the shortest
[11:49:17] <karlp> it means that make program by itself will never retrigger a compile though.
[11:49:22] <karlp> but that's probably ok too.
[11:49:59] <nevdull> yeah i think 'make program' is more intuitive if it only programs the mcu and not makes/compiles a target (that's what all: or dist: is for)
[11:50:19] <karlp> well, it can be nice if you can just keep pressing make program,
[11:50:25] <karlp> and it rebuilds if needed.
[11:50:39] <karlp> but with multiple hardwares now, that's not quite as reasonable.
[11:52:01] <nevdull> hmm, would this work:
[11:52:05] <nevdull> program: dist
[11:52:06] <karlp> I guess an alternative would be to have different main objects built for each hardware.
[11:52:11] <nevdull> $(AVRDUDE) ...
[11:52:58] <nevdull> make the dist target a prerequisit of the program target?
[11:53:35] <nevdull> so you only need to invoke 'make HARDWARE=x program'
[11:53:58] <karlp> yeah, yeah, that works. but it rebuilds all hardwares allt he time.
[11:54:07] <karlp> pros and cons I guess.
[11:54:15] <specing> Meh
[11:54:15] <nevdull> it shouldn't i don't believe if nothing has changed
[11:54:19] <specing> just use SCons
[11:54:52] <karlp> speccing, so, if I paste my makefile, you'll give me back a working scons one, and provide support for it?
[11:54:53] <OndraSter> ok, need some last words about my boards, gotta order ASAP :)
[11:54:54] <OndraSter> http://dl.dropbox.com/u/3936936/boards2/driverbrd.png
[11:54:59] <OndraSter> http://dl.dropbox.com/u/3936936/boards2/inputbrd.png
[11:55:06] <OndraSter> http://dl.dropbox.com/u/3936936/boards2/ledbrd.png
[11:55:10] <OndraSter> http://dl.dropbox.com/u/3936936/boards2/logicbrd.png
[11:55:16] <OndraSter> http://dl.dropbox.com/u/3936936/boards2/powerbrd.png
[11:55:37] <nevdull> i'm starting to love cmake personally but i've more experience with make so that's what i use more often
[11:56:07] <karlp> nevdull: nah, it's rebuilding evyerhitng.
[11:56:17] <karlp> dist is phony and has no deps, so it just runs the whole lot
[11:58:14] <karlp> specing: I looked at scons a few years ago, and it just looked like different pain.
[11:58:31] <karlp> do you have a decent base file for avr projects we could look at?
[11:58:46] <specing> karlp: SCons is basicaly just a python wrapper
[11:59:08] <nevdull> hmm, how about dist: $(SRC:%.c=%.o)
[11:59:24] <specing> < karlp> speccing, so, if I paste my makefile, you'll give me back a working scons one, and provide support for it?
[11:59:34] <nevdull> assuming you have something like SRC = file1.c file2.c etc
[11:59:44] <karlp> nevdull: I think that would only work if I had different .o for the different hardware.
[11:59:46] <specing> Can't do that since I can't be bothered to learn to write/read Makefiles
[11:59:55] <karlp> but they all come from the same main.c
[12:00:19] <karlp> specing: yeah, and I don't really feel like replacing mostly working stuff with, "might work, not as commonly used, noöone in the company has ever seen it before"
[12:00:50] <nevdull> it would for every *.c in SRC make the same filename with .o a prerequisite of dist: and should be checked then before compile i think
[12:01:09] <karlp> nevdull: I think I'm just going to take the deps out of program.
[12:01:42] <nevdull> karlp: yeah i would definitely do that
[12:02:06] <nevdull> since $(TARGET).hex backchains dependencies
[12:02:20] <karlp> the obs list is already defined as that SRC map anyway, and that's the dep for the elf, which is where it decides taht the main.o is uptodate, but the elf is not.
[12:02:41] <karlp> anyway, I've got something that works. thanks for the ideas.
[12:03:33] <nevdull> but including the *.o as a dep and not the *.elf should only require the *.o to be uptodate and not the *.elf. but good luck with what you decide!
[12:03:48] <specing> karlp: Atleast Im not the one using outdated stuff :D
[12:05:36] <karlp> outdated is relative :)
[12:12:42] <OndraSter> http://clip2net.com/s/1xqyh
[12:12:47] <OndraSter> time to place an order eh
[12:15:35] <Steffann> Good luck OndraSter
[12:15:39] <OndraSter> thanks
[12:15:44] <OndraSter> so nobody has any points to my designs?
[12:15:47] <OndraSter> the logicboard is real mess
[12:15:57] <OndraSter> :P
[12:25:05] <amee2k> wheee it works!
[12:26:25] <nevdull> woohoo
[12:26:55] <Steffann> Free cake or beer for everyone amee2k ?
[12:27:12] <amee2k> if any, free pizza
[12:27:21] <amee2k> and speaking of pizza, i still need to go get some
[12:27:25] <amee2k> http://ve504.cugnet.net/~amee2k/sandbox/CIMG8932b.avi
[12:27:29] <nevdull> omg i love it: http://youtu.be/yHJOz_y9rZE
[12:27:30] <amee2k> wat u think?
[12:27:39] <amee2k> (3MB, 0:32)
[12:28:14] <amee2k> the debug output on the right of the second line is duty cycle (8 bit hex) and turns remaining
[12:28:38] <amee2k> what you can hear clicking in background is the direction relay because it overshot a bit
[12:29:03] <amee2k> the speed control is still open loop using preconfigured duty cycle settings :/
[12:29:09] <Steffann> At least i've no idea what i'm looking at amee2k
[12:29:18] <Steffann> And i'm too lazy too read everythink you said :P
[12:29:22] <amee2k> lol
[12:29:51] <amee2k> Steffann: < amee2k> http://ve504.cugnet.net/~amee2k/sandbox/CIMG8925b.avi (12MB; 1:07) << the less unfinished version of this!
[12:30:48] <Steffanx> What's it for?
[12:31:14] <amee2k> winding stuff like coils or transformers... i'm sick of winding so-many hundred turns by hand >_>
[12:31:19] <OndraSter> hehe
[12:31:24] <OndraSter> and how will you be handling the wire?
[12:31:28] <OndraSter> so it doesn't overlap 'n such
[12:31:41] <amee2k> but should be usable for winding pretty much everything else
[12:31:45] <Steffanx> So this is amee2k famous workbench?
[12:31:53] <Steffanx> *'s
[12:31:59] <OndraSter> I should clean up my tables
[12:32:02] <OndraSter> and create workbench too :P
[12:32:06] <Kevin`> I like the atx power supply
[12:32:07] <amee2k> Steffanx: yep >_>
[12:32:19] <amee2k> OndraSter: i've got a vague idea of using the head positioning mechanism of an old optical drive, but no concrete plans how to control it
[12:32:27] <OndraSter> ok
[12:32:45] <amee2k> only having to guide the wire on the bobbin and not having to move for every turn and count turns in my head will make stuff a lot easier
[12:33:12] <amee2k> right now it is probably a bit too automatic for practical use though
[12:33:16] <Steffanx> After that you make one that can wind this one amee2k ? http://i01.i.aliimg.com/photo/v0/305181319/Ferrite_coil_Toroidal_coil.jpg
[12:33:25] <OndraSter> I've seen profi choke/coil/... winder
[12:33:28] <OndraSter> for about 10 grand
[12:33:28] <OndraSter> euro
[12:33:31] <OndraSter> maybe 20 grand
[12:33:50] <amee2k> i want a switch to do back and forth and only use the counter to lock out manual controls once the set count is reached
[12:34:38] <amee2k> makes correcting minor winding mistakes easier, and allows me to quickly stop the spool in case the wires get tangled up or something
[12:34:55] <amee2k> i once had a roll of magnet wire unwind itself on my desk while winding a choke >-<
[12:34:58] <amee2k> >_<
[12:35:40] <Steffanx> :D
[12:36:21] <OndraSter> LAMBO DRIVERS ARE WOMEN! http://a8.sphotos.ak.fbcdn.net/hphotos-ak-snc7/s720x720/418088_218835068209311_126617240764428_436715_675308987_n.jpg
[12:36:25] <amee2k> not sure what to use as direction switch yet
[12:37:07] <amee2k> wtf is that from?
[12:37:27] <OndraSter> no idea
[12:37:28] <OndraSter> facebook
[12:37:37] <Steffanx> Yeah fbcdn.net is facebook crap
[12:37:40] <amee2k> wal mart parking lot when they had 5000$ gold plated dildos on offer?
[12:37:44] <Steffanx> I refuse to click on like like that :p
[12:37:58] <Steffanx> *links
[12:38:38] <amee2k> Steffanx: its a bunch of cars parking in like 10 rows and criss cross on a parking lot
[12:38:59] <Steffanx> :P
[12:39:23] <amee2k> anyway
[12:39:29] <amee2k> gonna run get some pizza now
[12:39:35] <Steffanx> pizza ..
[12:39:38] <amee2k> then i'll go over my junk box to find a useful switch!
[12:40:44] <OndraSter> I found cheap rotary encoders on iteadstudio
[12:40:46] <OndraSter> $3.50 for piece
[12:40:52] <OndraSter> or is it anywhere cheaper? :P
[12:40:56] <OndraSter> with switches in them!
[12:41:05] <OndraSter> (push buttons)
[13:02:09] <Bushman> hmm...
[13:07:39] <Bushman> OndraSter: i haven't found cheaper here so i guess it's cheap enough
[13:07:52] <Bushman> (also, i haven't found them at all)
[13:15:36] <RikusW> anyone implemented a soft uart using edge detection instead of over sampling ?
[13:17:11] <specing> I have
[13:17:14] <specing> I think
[13:17:24] <specing> I'm 99% sure it didnt work
[13:18:12] * RikusW is thinking about edge detection + timer to measure pulse length
[13:19:02] <amee2k> sounds kinky
[13:19:08] <specing> @_@
[13:19:12] <amee2k> lots of interrupts >_>
[13:19:31] <RikusW> actually no interrupts, polling
[13:19:43] <amee2k> okay
[13:19:50] <RikusW> up to 156kbps
[13:19:57] <amee2k> but where is the advantage over using regular sampling then?
[13:20:06] <RikusW> thats only 100 clocks per bit
[13:20:18] <RikusW> variable baud soft uart for dW
[13:20:38] <amee2k> hmm i see
[13:21:09] <RikusW> 20MHz / 128 == 156kbps
[13:21:30] <amee2k> the normal UART doesn't work?
[13:21:48] <RikusW> no autobauding there....
[13:21:58] <RikusW> mine needs to detect dW baud
[13:22:12] <RikusW> which can be anything
[13:22:19] <amee2k> you could measure the baud rate by sampling and then configure the uart to match for improved efficiency
[13:22:54] <RikusW> for my board I'll use 16MHz, but the target avr can use any crystal...
[13:23:13] <RikusW> think I'll be able to cover 300kHz to 20MHz in a single range
[13:23:42] <RikusW> so 2kbps to 156kbps
[13:24:22] <amee2k> hmm don't some atmegas go up to 24MHz though?
[13:24:49] <RikusW> I only know of 20MHz ones
[13:24:59] <RikusW> and most megas don't have dW anyways
[13:25:08] <RikusW> they have jtag
[13:25:38] <Steffanx> Get a stm32F4Discovery for cheap, then you have enough horse power RikusW :P
[13:25:38] <RikusW> the m..8 and m..u2 does have dW
[13:26:00] <RikusW> or I could use my 3a3 xplain board ;)
[13:26:10] <RikusW> but I want it to work on 32u2....
[13:26:40] <amee2k> corecode is working on a 5$ ARM USB stick board
[13:26:55] <amee2k> hmm didn't he use to hang out here too?
[13:26:58] <RikusW> thats rather cheap :)
[13:27:10] <RikusW> how fast can it go ?
[13:27:16] <specing> When you thought 25$ was cheap...
[13:27:23] <specing> RikusW: probably 5 Mhz ;D
[13:27:29] <amee2k> iirc 50MHz ARM based MCU but he is still considering several
[13:27:30] <RikusW> ugh
[13:27:43] <amee2k> lemme dig up the project link
[13:27:52] <RikusW> 50MHz would be nice
[13:27:55] <specing> amee2k: linux?
[13:28:19] <Steffanx> !google corecode
[13:28:22] <amee2k> lol no idea
[13:28:31] <amee2k> https://github.com/corecode/mchck/wiki
[13:29:21] <amee2k> ah, 32MHz STM32 vs. some 50MHz one i've never heard of
[13:29:33] <RikusW> amee2k: after a break dW sends 0x55 to allow baud detection
[13:29:33] <Steffanx> Oh, .. stm32 :(
[13:29:37] <amee2k> they have working prototypes but still putting together a bootloader
[13:29:52] <RikusW> Steffanx: whats wrong with stm ?
[13:29:56] <amee2k> whats wrong with stm?
[13:30:05] <amee2k> lol
[13:30:24] <RikusW> seems my typing echos around ? ;)
[13:30:30] <Steffanx> Nothing but its slow compared to that 25$ board
[13:30:41] <amee2k> like minds and stuff? :)
[13:30:46] <Steffanx> Or .. didn't you talk about the raspberrypi
[13:30:47] <Steffanx> ?
[13:31:08] <amee2k> how about it is only 1/5th the price?
[13:31:18] <amee2k> ARM != linux*fap*fap*fap*fap*
[13:31:18] <Steffanx> And more than 5 time slower :P
[13:32:43] <Steffanx> It doesn't look that special.. that board
[13:32:55] <Steffanx> Just a pcb with a stm32F151
[13:33:04] <Kevin`> it doesn't have to be special
[13:33:19] <amee2k> 5$ for a board that'll fuck an arduino up the serial port sounds special enough for me
[13:33:20] <Steffanx> I prefer a stm32FxxxDiscovery :)
[13:33:32] <Kevin`> Steffanx: that's a bit more expensive
[13:34:07] <amee2k> which is like 2-3x the price at RS
[13:34:09] <Steffanx> More features .. for ~2-3 times that price?
[13:34:27] <specing> amee2k: ARM + LINUX = fap*fap*fap*fap :D
[13:34:38] <amee2k> lol
[13:34:43] <Kevin`> specing: which one does linux now?
[13:35:26] <amee2k> that USB ARM stick one doesn't probably
[13:35:34] <specing> Kevin`: ?
[13:35:43] <amee2k> well, depends on how small you can get the kernel. you can probably make it run 2.0 or something
[13:36:07] <specing> My current ARMv5te kernel is just under 900KB
[13:36:15] <Kevin`> you need a few mb of ram to run linux
[13:36:36] <specing> about 16
[13:37:07] <amee2k> uclinux should run. doesn't have anything to do with normal linux, but still >_>
[13:37:17] <Steffanx> Ofcourse it has..
[13:37:40] <amee2k> from what i hear the name
[13:37:54] <Steffanx> it's a 'real' kernel
[13:38:19] <Steffanx> http://www.uclinux.org/description/
[13:38:34] <Essobi> I'll just take a rasberry pi
[13:39:07] <Kevin`> uclinux is more about the mmu thing than about how much ram you have
[13:39:27] <Steffanx> me too Essobi :P
[13:39:59] <Essobi> I've ran uclinux..
[13:40:02] <Essobi> Meh..
[13:40:12] <Essobi> I'd rather run *BSD.
[13:40:27] <Essobi> or even one of the other linux mini distros..
[13:40:37] <amee2k> how about porting DOS to ARM
[13:40:41] <specing> DSL?
[13:41:03] <Kevin`> amee2k: that's nasty.
[13:41:17] <RikusW> DOS ?! eww
[13:41:24] <amee2k> :P
[13:41:50] <amee2k> all the arduino fans would love it
[13:41:54] <RikusW> DOS isn't portable :-P
[13:41:59] <amee2k> just port QBASIC too
[13:42:28] <Kevin`> you realize you'd be writing all of this from scratch, right?
[13:42:32] <Kevin`> no porting
[13:43:11] <RikusW> and the D must be dropped, because the is no disks on arm ;)
[13:43:27] <RikusW> sa morph that from OS to OS/2 ;)
[13:43:41] <amee2k> right. lets use an sd card and make it SDOS >_>
[13:43:53] <Kevin`> hah
[13:43:53] <RikusW> oooh
[13:43:54] <Essobi> :DD
[13:44:25] <Essobi> http://www.hawkboard.org/
[13:44:27] <Essobi> Meh..
[13:44:53] <Kevin`> on a serious note, you have the oppertunity to pick a better storage interface than sd. sd was specifically designed to work with old dos stuff that couldn't be updated
[13:44:55] <amee2k> umm
[13:45:21] <amee2k> "hey our board sucks balls and likes to crap itself" on the front page is not exactly effective advertisement
[13:45:38] <Essobi> amee2k: no shit.. I was laughing at that.
[13:45:51] <amee2k> Kevin`: sd cards are dead easy to interface with from what i've seen
[13:46:16] <amee2k> also, what else would i want to use instead?
[13:46:22] <amee2k> CF cards?
[13:46:39] <Kevin`> amee2k: cf cards are the same, flash emulating an old hard drive
[13:46:43] <Kevin`> amee2k: use the flash directly
[13:46:59] <Essobi> holy shit..
[13:47:03] <Essobi> CuBox looks promising.
[13:47:18] <Essobi> http://en.wikipedia.org/wiki/CuBox
[13:47:28] <keenerd> But that is a lot of extra work. Let the SD controller worry about wear leveling. Most of the time you don't need the performance boost from a DIY controller.
[13:47:50] <Kevin`> keenerd: for me it's more about reliability
[13:48:27] <amee2k> hmm isn't there some flash card format that is basically an NAND flash chip in a fancy package?
[13:48:35] <amee2k> i *think* it was Smartmedia
[13:48:42] <Essobi> 2"^3 in size... that's pretty sweet.
[13:48:46] <Kevin`> amee2k: xd (or smartmedia, yes), but that's a dead format
[13:49:05] <amee2k> using a naked flash chip was your idea, remember? :P
[13:49:26] <Kevin`> amee2k: not from an xd card though
[13:49:30] <amee2k> i don't think anyone these days would want to use a controller-less card anymore anyway
[13:49:56] <Kevin`> just the chip itself
[13:50:00] <RikusW> Essobi: thats really small
[13:50:17] <amee2k> they still make usefully large flash in socketable packages? o.O
[13:50:30] <Essobi> RikusW: no shit... for an 800hz arm with 1Gig of DDr3? O_O
[13:50:40] <Essobi> I'm SOOO JELLY!
[13:50:52] <Essobi> that's what I paid for my ARM920T. :(
[13:50:59] <Kevin`> amee2k: socketable? I suppose they make 16mbyte socketable flash chips, but I didn't mean socketable
[13:51:08] <specing> Essobi: which one?
[13:51:08] <Essobi> http://www.omgubuntu.co.uk/2011/12/meet-cubox-a-tiny-arm-powered-media-centre-capable-of-running-ubuntu/
[13:51:13] <Essobi> I WAAAANTS
[13:51:21] <amee2k> then how the fuck do you want to swap it? sell a hot air station with the board or what?
[13:51:23] <specing> < Essobi> that's what I paid for my ARM920T.
[13:51:36] <Kevin`> where are the pictures of that thing?
[13:51:53] <Essobi> Kevin`: http://www.omgubuntu.co.uk/2011/12/meet-cubox-a-tiny-arm-powered-media-centre-capable-of-running-ubuntu/ the little box next to the euro.
[13:52:11] <Kevin`> Essobi: that's the same picture on their front page, it doesn't show anything. more angles.
[13:52:33] <Essobi> Kevin`: ... it's 2"^3.... you want 3D models?
[13:52:45] <Kevin`> Essobi: the ports.
[13:53:34] <amee2k> Kevin`: the whole idea of a memory *card* is that it is easily (physically) portable
[13:53:50] <Essobi> Kevin`: http://www.solid-run.com/
[13:54:16] <amee2k> haha
[13:54:22] <amee2k> the board pic looks ridiculous
[13:54:28] <Kevin`> amee2k: the industry is kind of backwards right now. don't build that into a new os :(
[13:54:31] <amee2k> like run over by a car and folded up
[13:55:08] <amee2k> don't build what into a new os? removable storage?
[13:55:30] <Kevin`> .
[13:55:34] <Kevin`> you arne't listening
[13:55:53] <amee2k> well, i don't get it
[13:56:15] <amee2k> what is supposed to be wrong with memory cards
[13:56:23] <amee2k> i mean, existing ones
[13:57:15] <amee2k> and why shouldn't i support removable flash storage media
[13:57:31] <Kevin`> you should support it, but you shouldn't run an operating system form it
[13:57:33] <Kevin`> from*
[13:57:43] <amee2k> why not?
[13:57:44] <karlp> Kevin`: I've just read the backlog, and I'm not sure I know what you want to do instead?
[13:58:35] <amee2k> provided the interface is stable i don't see a difference between running it off a memory card and running it off soldered-on onboard flash
[13:58:37] <Kevin`> amee2k: because it's crap. the controller kills performance and guaranteed the device will die after some random amount of activity
[13:58:55] <Kevin`> karlp: in what context? I forget what I recommended
[13:59:03] <amee2k> so you want to implement your own wear leveling and whatever?
[13:59:15] <Kevin`> amee2k: no, i'd use software that already implements it
[13:59:22] <amee2k> and i'm the masochist for writing my own software driver for optical encoders :P
[14:00:11] <karlp> Kevin`: it seemed you were against sd cards, as they were a carryover from dos?
[14:00:21] <karlp> but I don't know what you were suggesting as an alternative.
[14:00:23] <nevdull> there are several flash filesystems that implement wear leveling, b-trees, address painting, etc.
[14:00:45] <karlp> and all of those things are filesystems on top of raw flash, but have nothing to do with dos...
[14:00:55] <Kevin`> karlp: a new interface standard needs to be created for removable flash. if you want to install an os though, you have the option of using non-removable flash, which works fine
[14:01:17] <karlp> what would be the differences in the new interface standard?
[14:01:29] <karlp> spi, and 4xspi doesn't really seem to me to be anything tied to dos?
[14:01:38] <Kevin`> karlp: it would expose the flash layout instead of emulating a hard drive. cheaper to make, faster, and more reliable.
[14:01:46] <karlp> the fact that lots of them used to be shipped from the factory formatted as fat, sure.
[14:02:15] <nevdull> the arm mini2440 maintains a bootable linux jffs or yaffs filesystem on removable flash
[14:02:28] <nevdull> with a bootloader in NOR
[14:02:35] <Kevin`> nevdull: removable on what, xd?
[14:02:35] <amee2k> the fact that sd and other cards have intelligent controllers makes them dead easy to use because the FS is simplified
[14:02:50] <nevdull> Kevin: sd
[14:03:04] <Kevin`> nevdull: using a flash filesystem on sd is pointless
[14:03:04] <nevdull> most sd cards are easily accessible thru a simple spi interface
[14:03:13] <nevdull> why is that?
[14:03:38] <Kevin`> because it's an emulated hard drive. you aren't taking advantage of any of the filesystems features, you are just spamming data at the controller
[14:03:58] <Kevin`> it'll probably fail SOONER because the controller is optimized for fat16 only
[14:03:59] <nevdull> the filesystem provides a layer of abstraction for the OS
[14:04:00] <amee2k> no it isn't
[14:04:31] <amee2k> http://www.amazon.de/RAM-Components-Pocket-eSata-Stick/dp/B001NEO5QW << that is flash emulating a hard drive
[14:04:35] <amee2k> >_>
[14:04:55] <karlp> Kevin`: isn't SDIO meant to "do the right thing" for your purposes?
[14:04:57] <Kevin`> I suggest you do some research
[14:05:10] <karlp> I think I know what you mean now at least :)
[14:05:23] <Kevin`> karlp: there's nothing wrong with the PHYSICAL interface, but there's no standard for the logical interface, and thus no way to access the flash on a removable flash device
[14:05:40] <Kevin`> you could make one pretty easily, like, in a day
[14:05:41] <amee2k> i'm not going to use much more than FAT on a tiny MCU anyway
[14:07:16] <Kevin`> amee2k: i'm more concerned about use with computers and mobile devices, tbh. using an sd card with a microcontroller project for datalogging or such is fine, if you are aware that it will fail eventually and randomly
[14:09:27] <karlp> Kevin`: the controllers are meant to take care of the wear levelling, as far as I knew. I get blocks to address, and sometimes, those blocks might be different on the flash itself...
[14:09:28] <izua> is there a lightweight filesystem for microcontrollers?
[14:11:22] <nevdull> atmel has a paper about one they wrote
[14:11:53] <nevdull> and there's a journalling flash filesystem, a transactional flash filesystem, logging flash filesystem, and others i can't think of
[14:11:55] <Kevin`> karlp: they do. that's the problem by itself. once enough blocks have failed, the controller can no longer present a disk of the original size to you, so it stops working
[14:12:17] <karlp> right, whereas xd is simply a nand flash chip in a plastic case.
[14:12:39] <nevdull> most modern flash filesystem use a bitmap to mark bad blocks or pages
[14:12:44] <Kevin`> you could use xd with a random filesystem, sure, but xd is dead
[14:12:59] <karlp> nevdull: yeah, but what kevin's saying is that is _on top_ of the controllers decisisons
[14:13:06] <nevdull> and you have ~10k writes per address location
[14:13:18] <karlp> xd was dead when it came out...
[14:13:25] <Kevin`> also most pc readers for xd, and all windows ones, do not support raw access, they work like a normal usb-storage device with the controller in the host side isntead
[14:13:25] <karlp> only supported by fuji and olympus
[14:13:35] <nevdull> yah i guess i'm not following the 'controller' part
[14:13:58] <Kevin`> karlp: a flash filesystem is designed for use without a remapping controller
[14:14:19] <karlp> so Kevin` you'd rather see a bit more sw on the host, a flash filesystem, and a raw flash chip, rather than an sd card.
[14:14:33] <karlp> yeah, the way most linux routers have a straight up spi flash chip
[14:14:46] <Kevin`> yeah, like that
[14:15:08] <Kevin`> they can do that because it's soldered onto the board though. there's no standard for REMOVABLE or modular flash, so computers can't do it yet
[14:15:25] <karlp> I think I've got it now :) and I agree, that would be nice.
[14:15:42] <karlp> I'm not convinced I'd put it before world peace or anything though ;)
[14:15:57] <nevdull> what's the standard for non-removable flash?
[14:16:15] <karlp> whatever the board designer chose :)
[14:16:19] <karlp> didn't need to be standard
[14:16:19] <Kevin`> nevdull: jedec has standand interfaces for it
[14:16:27] <Kevin`> nevdull: which most chips use
[14:16:46] <karlp> that's for the pinout though right?
[14:16:48] <nevdull> i suppose most flash i've seen supports SPI
[14:16:53] <Kevin`> karlp is essentially correct though, there's no requirement to follow a standard when designing it on-board
[14:17:06] <nevdull> i've seen jedec support for jedec ID's in flash chips
[14:17:11] <nevdull> and signatures
[14:17:15] <Kevin`> nevdull: only the smaller nor flash devices. spi nor flash is incredibly standardized though
[14:17:41] <Kevin`> (for something in the industry, that is)
[14:21:32] <amee2k> Kevin`: that stuff can fail randomly is kind of normal, really
[14:21:40] <amee2k> and has been for the better part of a decade or so
[14:21:53] <Kevin`> just because you are used to it does not mean it's normal
[14:22:17] <Kevin`> or does it? by definition? maybe. in any case, it's not necessary for it to fail, and you could be notified well before it does fail
[14:22:27] <amee2k> how about i got used to it because it is kinda normal?
[14:22:29] <Kevin`> (rather, before you run out of space)
[14:23:17] <amee2k> there is money to be saved by not being overly careful while implementing *that* part
[14:23:25] <amee2k> i mean take SMART as an example >_>
[14:23:31] <karlp> amee2k: nand flash fails wayyyyyyy more than that though.
[14:23:43] <karlp> nand doesn't even always arrrive in 100% ok condition.
[14:23:46] <amee2k> i have yet to see a single hard drive that has actually indicated a failure before it happened
[14:23:49] <Kevin`> amee2k: smart could work VERY well on ssds, actually. even if it's a stupid hack.
[14:24:01] <karlp> amee2k: really?
[14:24:08] <karlp> I've had a few,
[14:24:17] <karlp> in fact, the only drive I have that died in use died that way.
[14:24:19] <Kevin`> amee2k: on spinning drives, I like smart for indicating failures after they happen :D
[14:24:30] <amee2k> i've seen lots of drives that still indicated health OK considerable time after they started showing clear signs of failure
[14:25:20] <Kevin`> with spinning drives, or with current-generation ssds, raid is the solution
[14:25:25] <nevdull> i think i've seen a SMART driver for linux for drive temp
[14:25:44] <amee2k> i had a drive fail two months ago this way. it would take ages and reads would time out constantly but all self tests reported good health
[14:27:18] <amee2k> actually even the self tests were flaky. they took almost twice as long to complete as the drive indicated
[14:27:41] <Kevin`> when's the last time you saw a raw flash chip fail while it wasn't being abused? ;p
[14:28:05] <Kevin`> (abused like writing a single sector 200,000 times and expecting it to keep working)
[14:28:11] <amee2k> with progress randomly jumping from 50-60% back up to 80% remaining or so
[14:28:31] <amee2k> do i look like i have a money shitting donkey to buy piles of SSDs?
[14:28:43] <Kevin`> ssds aren't raw flash
[14:29:08] <amee2k> or why would i want to use any more raw flash than that?
[14:29:23] <Kevin`> I mean like in a microcontroller or a cell phone or something that currently uses it
[14:29:24] <amee2k> what does it have to do with SMART sucking anyway?
[14:29:35] <karlp> so you can have less layers of indirection, haven't you been paying attention? :)
[14:29:44] <amee2k> i only us sd cards with micros
[14:29:59] <amee2k> i don't have less layers
[14:30:09] <amee2k> instead i have to implement more layers myself instead
[14:30:10] <Kevin`> don't you use those avr chips that run code from rom?
[14:30:30] <amee2k> hu?
[14:30:41] <amee2k> i'm not using the program flash for data
[14:30:53] <Kevin`> your using it though
[14:31:18] <amee2k> seen some people do it, probably makes sense for some things with like a mega2560 or so
[14:31:58] <nevdull> you mean like with the PROGMEM or EEMEM __attribute__ ((__section())?
[14:32:01] <amee2k> but if i need mass storage and can't just shove it off to a computer i just stick a memory card on SPI
[14:32:28] <Kevin`> nor flash isn't an ideal example, since it's actually NOT supposed to fail, unlike nand. but it's kind of interesting that you don't even think about using it ;p
[14:32:38] <amee2k> nevdull: well, using the self-flashing ability to store settings and stuff in the program flash
[14:35:04] <nevdull> yeah, i like using the PROGMEM label on data structures that would normally be put in SRAM since the flash:sram ratio is like 16:1
[14:36:59] <nevdull> then there's FRAM. it acts like non-volatile memory with the characteristic speed of SRAM, but from what i've read after it wears it becomes volatile.
[14:39:09] <keenerd> And FRAM wipes clean at like 70C. Drop the board in your tea when the feds come knocking.
[14:39:22] <nevdull> lol
[14:39:26] <nevdull> i didn't know that
[14:40:00] <keenerd> The whole tech is thermal based. I am surprised at how little juice is needed to write.
[14:41:19] <nevdull> and it's still pretty spendy byte for byte compared to SRAM or flash and i haven't seen it come in any really large sizes
[14:41:27] <keenerd> Oh man, digikey stocks like 25x as much FRAM as they did a few months ago.
[14:41:44] <keenerd> And there are some that operate up to 125C now. Yay!
[14:42:43] <nevdull> yay that's reaching industrial/military specs
[14:43:09] <OndraSter> did I mention that I have here tube with 25 A6275 LED drivers... :P
[14:43:13] <OndraSter> and second one on the way
[14:44:11] <keenerd> Biggest FRAM you can get easily is still 256KB. Darn.
[14:44:37] <karlp> still way pricey
[14:44:45] <karlp> I was looking at it for a board recently.
[14:45:02] <karlp> went with an external eeprom from microchip, and only writing every 5 minutes or so.
[14:45:25] <karlp> played with their eeprom lifetime modelling tool for a while.
[14:45:27] <keenerd> FRAM does hold up pretty well for writes, they do just as much damage as the reads.
[14:46:01] <nevdull> if i don't need to write byte for byte i usually go with flash and do page or sector programming and erases (although atmel's dataflash sorta bridges that gap) else i go with eeprom
[14:51:13] <karlp> I just wanted to write to often.
[14:51:31] <karlp> write too often.
[14:55:20] <Bushman> on an unrelated note:
[14:55:26] <Bushman> Yo mama's food's so repulsive it hovers
[14:57:19] <OndraSter> guys, when my project is powered from two sources:
[14:57:24] <OndraSter> external DC PSU
[14:57:25] <OndraSter> and USB
[14:57:30] <OndraSter> what if their GNDs don't match?
[14:57:39] <OndraSter> I figured that it would be easiest to grab something like 1117-5.0
[14:57:41] <OndraSter> 800mA
[14:57:43] <OndraSter> to power the lgoic board
[14:57:50] <OndraSter> and put some transformers for USB :)
[14:57:53] <OndraSter> data lines
[14:58:23] <nevdull> you could use an optoisolator to isolate the two power supplies
[14:58:56] <Bushman> if the GND don't match you shoudl connect them
[14:59:10] <OndraSter> Bushman, what if the PSU(s) aren't floating?
[14:59:16] <Bushman> hmm...
[14:59:35] <Bushman> who builds non-floating DC PSUs nowdays?
[14:59:41] <OndraSter> dunno
[14:59:43] <OndraSter> safety measure :)
[14:59:43] <Bushman> that's so 1970
[14:59:49] <OndraSter> don't wanna board blow up really :P
[14:59:52] <SilicaGel> wow, mom jokes on irc
[14:59:54] <SilicaGel> That's a first!
[15:00:00] <Bushman> SilicaGel: huh?
[15:00:06] <Bushman> why first?
[15:00:16] <SilicaGel> beacuse irc is such a civilized place!
[15:00:25] <Bushman> oh, yea, you'r right
[15:00:29] <Bushman> ... NOT!
[15:00:30] <Bushman> :D
[15:00:36] <SilicaGel> This breach of decorum will not stand!
[15:00:57] * Bushman puts a random stain on the wall and lables it "modern art"
[15:00:58] <SilicaGel> Why, where would it lead? Next thing you know there will be farts! and dick jokes!
[15:01:15] <nevdull> and chuck norris remarks
[15:01:21] <SilicaGel> The horror!
[15:01:21] <Bushman> btw dick jokes that reminds me this joke about...
[15:01:24] <Bushman> ;>
[15:01:40] <SilicaGel> I got (stole) one of those sparkfun USB Weather v2 boards
[15:01:41] <Bushman> Ritchard
[15:01:50] <SilicaGel> I wouldn't have bought one because the thing is * overpriced
[15:02:04] <SilicaGel> and the software in it is so horrible
[15:02:07] <SilicaGel> well here let me show you an example:
[15:02:11] <keenerd> Sparkfun? Carry overpriced stock? Never!
[15:02:16] <SilicaGel> SHT Temperature=072.21 Firmware v2.0
[15:02:41] <SilicaGel> that is the temperature of my lab, 72.21, and part of the firmware revision string left over in the buffer because they didn't bother to terminate the string
[15:02:46] <SilicaGel> isn't that great?
[15:04:07] <SilicaGel> it also says the humidity is 13.51% which I don't believe.
[15:04:43] <OndraSter> so, nobody nothing simple about isolating USB data lines :)
[15:06:29] <hetii> hello :>
[15:06:42] <OndraSter> ey
[15:06:50] <OndraSter> why can't it be simply isolated by using two optocouplers?
[15:07:08] <OndraSter> they are bidirectional
[15:07:09] <OndraSter> but still
[15:07:55] <hetii> Q: i know its not a best # for such question but such uC like PIC32MX695F512H will be enought to handle PCI bus ?:)
[15:12:01] <karlp> OndraSter: there's some good info on the lufa-support mailing list froma few months back.
[15:12:19] <OndraSter> I think I will just ignore it... and if it won't work, I will grab diff power supply :P
[15:12:29] <karlp> it's the same basic, "which part are you trying to protect, how much does it cost, and what are the consequences if certain things go badly"
[15:13:21] <OndraSter> oh
[15:13:23] <OndraSter> cost :)
[15:14:05] <karlp> nothing's free.
[15:18:42] <OndraSter> oh well, screw it
[15:18:48] <OndraSter> gotta hope it is floating :P
[15:18:58] <OndraSter> cheap USB hub as protection should work
[15:20:00] <OndraSter> now diff Q: shall I buy soldering paste (not flux) in syrringe with really small tip
[15:20:08] <OndraSter> there is a lotta ICs
[15:20:10] <OndraSter> to solder
[15:20:17] <OndraSter> pain to solder with soldering irons
[15:24:03] <amee2k> hetii: i don't know about that mcu, but PCI is pretty fast by MCU standards
[15:24:21] <OndraSter> amee2k, http://clip2net.com/s/1xtsw
[15:24:23] <OndraSter> I can do this, right?
[15:24:28] <OndraSter> so the signal goes on both bottom and top
[15:24:32] <OndraSter> to all 3 lines
[15:25:30] <amee2k> hetii: can it bit-bang a 32 bit parallel bus with half or one dozen control lines at 33MHz?
[15:25:47] <amee2k> OndraSter: sure, why not?
[15:25:53] <OndraSter> ok, just making sure =)
[15:25:58] <amee2k> i mean you can run traces "though" normal pads too :)
[15:26:05] <OndraSter> yeah, that's what I ment
[15:26:07] <OndraSter> thanks :D
[15:26:16] <OndraSter> don't want to throw away $105 for PCBs :P
[15:26:20] <amee2k> nobody said that a via can only have one trace on each end
[15:26:31] <OndraSter> it's just that Eagle did some weird stuff
[15:26:33] <OndraSter> in autorouting
[15:26:47] <amee2k> thats what autorouting usually does, yes.
[15:27:33] <karlp> hetii: normally if it can do pci, it says "PCI" in the list of features
[15:27:41] <karlp> if it doesn't, you're very much in experimental land.
[15:27:41] <hetii> hmm
[15:28:45] <amee2k> PCI has very little benefit for MCUs, except that cheap peripheral hardware for it is readily available due to conventional PCI being a legacy technology
[15:29:05] <hetii> but the problem is that i cannot find any chip that have on his spec a PCI bus
[15:29:37] <amee2k> i doubt lots of manufs still make conventional PCI stuff
[15:30:23] <nevdull> pci also requires a 33MHz clock and pci-e a 100MHz clock so you'd have to distribute that clock source from an external component
[15:32:40] <hetii> yep :)
[15:33:50] <amee2k> i'd say if your MCU doesn't run at least 66MHz it isn't practical, and if you can't run 33MHz then you'll need fairly complicated external circuitry or an FPGA or CPLD to pull it off
[15:34:35] <amee2k> what you could do is look out for old ISA cards which are much easier to handle timing wise
[15:34:41] <hetii> this PIC what i type here work with clock 80MHz
[15:34:52] * nevdull agrees with amee2k re: ISA
[15:35:15] <hetii> but the point is really to run PCI :)
[15:35:19] <amee2k> since ISA stuff wasn't too precise about the clock frequency usually, anything from <4 to 8 and sometimes up to 16MHz or so will work
[15:36:05] <amee2k> with 80MHz you would stand a chance. you may get an advantage by underclocking it to 66MHz though
[15:36:28] <amee2k> since this way two CPU clocks equal one PCI clock
[15:36:47] <Valen> most people who seem to want PCI use fpga or dedicated IC's
[15:36:54] <Valen> some dual port ram
[15:37:41] <amee2k> i assume the reason to use PCI is being able to use readily available comodity hardware. PCI cards are a dime a dozen these days
[15:37:49] <karlp> amee2k: plenty ofpci still out there.
[15:38:01] <karlp> used on all those home wifi routers :)
[15:38:04] <Valen> you actually want to "host" pci?
[15:38:34] <amee2k> if you design from scratch you'd be infinitely better off using a serial bus like SPI
[15:38:50] <hetii> the point is to run SB live card on LAN, its some small challange for me :)
[15:39:07] <amee2k> o.O
[15:39:13] <Valen> usb SB "card" + usb > ethernet
[15:39:40] <amee2k> why exactly an SB live?
[15:39:46] <hetii> i know that i can use I2S or USB card but its realy not my purpose
[15:39:55] <amee2k> ah, i see
[15:40:22] <amee2k> what about using some embedded x86 system board to build it on?
[15:40:26] <hetii> Because i have one, the quality of it its realy good and it will be very cool if i be able to design such system :)
[15:40:41] <amee2k> lots of thin clients have PCI slots inside
[15:41:06] <hetii> its more to cath some knowladge then have some players :)
[15:41:08] <nevdull> i've found http://www.interfacebus.com/Interface_Bus_Comparison_Table.html to be useful in the past
[15:41:44] <amee2k> hetii: is using that MCU a requirement as well?
[15:41:53] <amee2k> i mean, /only/ that MCU
[15:41:57] <hetii> no
[15:42:07] <amee2k> then you should take a look at FPGAs
[15:42:37] <amee2k> they're fairly expensive, but infinitely better suited to interfacing with a PCI bus than an MCU
[15:42:59] <nevdull> yeah you can get a Spartan-3E based fpga (Basys2) with 100k (i think) gates for $49 with student discount from digilent.com
[15:43:33] <nevdull> and xilinx makes an excellent toolchain for it
[15:44:06] <amee2k> so you'd end up with something like ethernet MAC --(spi bus)--> MCU --(4xspi or something)--> FPGA --(PCI bus)--> SB live
[15:44:40] <nevdull> an fpga is also a pretty common way to handle generating higher resolution VGA signals and timing
[15:44:50] <amee2k> or for a pci network card MCU <--(4xspi or something)--> FPGA <--(PCI bus)--> SB live / network card
[15:44:52] <karlp> I think you're going to spend a hellll of a lot of money rebuilding a 15 yo computer,
[15:45:09] <Kevin`> isn't an sb live just a sound card?
[15:45:13] <karlp> Kevin`: yep.
[15:45:14] <amee2k> aaaand here comes the resident party pooper
[15:45:16] <Kevin`> sound isn't exactly hard to generate
[15:45:28] <Kevin`> why bother with the fpga and the sound card, just do it directly from an mcu
[15:45:45] <karlp> Kevin`: you missed the point, the only _required_ bit here is that it use the pci SB live :)
[15:45:55] <Kevin`> wut.
[15:46:03] <karlp> talk to hetii :)
[15:46:04] <amee2k> who don't acknowledge educational projects as valid goals because they ate wikipedia for breakfast
[15:46:51] <Kevin`> there are microcontrollers with pci and ethernet macs
[15:46:56] <_hetii_> re
[15:46:57] <_hetii_> :(
[15:47:05] <amee2k> wb
[15:47:07] <Kevin`> 15:37 < Kevin`> there are microcontrollers with pci and ethernet macs
[15:47:14] <Kevin`> making a board for it will still be a pain though
[15:47:15] <_hetii_> what i miss ?
[15:47:27] <amee2k> not much... the K-duo bashing your project idea
[15:47:30] <Kevin`> you might have missed a lot, when did you leave
[15:47:38] <_hetii_> about with MCU you talk ?
[15:47:51] <karlp> amee2k: do I really come across as bashing everything?
[15:47:53] <_hetii_> when someone start talkin about FPGA
[15:48:01] <amee2k> karlp: sometimes? yes.
[15:48:02] <karlp> I hadn't realised I was doing that.
[15:48:16] * amee2k blinks
[15:48:19] <karlp> thanks for pointing it out, I'll try and be more positive/not comment sometimes :)
[15:48:34] <karlp> I didn't think I was bashing _everything_
[15:48:34] <Kevin`> _hetii_: http://pastebin.com/zL5akMzc
[15:48:37] <nevdull> you have a good attitude karlp
[15:48:50] * amee2k seconds that
[15:49:26] <karlp> at least I say, "that's going to be a lot of work to build something that's been done"
[15:49:33] <karlp> rather than, "that's a stupid idea!"
[15:49:56] <amee2k> well, some time ago i realized that wanting to do some task in a very particular way, like with a very specific part or using a particular algorithm or something, is a valid desire, really
[15:49:58] <karlp> anyway, beer time...
[15:50:50] <amee2k> doesn't need to be smart or cheap or a particularly good way to do it in general for that. sometimes people just want to see if they're skilled enough to pull it off
[15:50:57] <Kevin`> I should get that ethernet <-> china rf adapter bridge project finished
[15:51:08] <nevdull> i often tackle projects that have no more practical application than to further my understanding of how something works.
[15:51:55] <amee2k> like tracking a 100kHz optical encoder in software is kinda ridiculous... my MCU spends literally half the time just wiping the encoder's pins >_>
[15:52:07] <nevdull> hehe
[15:52:10] <nevdull> but its a challenge
[15:52:14] <amee2k> yep
[15:52:23] <amee2k> and so far it seems to run reasonably well, actually
[15:53:32] <Kevin`> amee2k: actually, what else would you track it with. fpgas aren't designed to be used by anyone and raw logic is probably more expensive than an mcu ;p
[15:53:52] <Valen> people have used mcu's to run ISA cards
[15:53:52] <amee2k> i know i could have done that the ghetto way half a year ago by violating an old dashboard for the mechanical mile counters or something, but that wasn't how i wanted to do it
[15:54:27] <_hetii_> some of the price of FPGA chip are insan
[15:54:28] <_hetii_> e
[15:55:02] <Essobi> I want a NetFPGA :D
[15:55:15] <amee2k> Kevin`: well, the point that was important to me was doing the whole counting thing in an MCU. so with that servo motor with encoder i'm pretty much on track
[15:56:18] <amee2k> i could just as well have done it with an FPGA i think. the important part is tracking the encoder. some fpga mcu core could have done driving the display and what not
[15:58:04] <amee2k> hmm speaking of driving...
[15:58:14] * amee2k pokes rue_bed ... you there by chance?
[15:59:13] <amee2k> ...
[16:01:42] <_hetii_> i found such chip EPF8282ALC84-4N
[16:02:05] <_hetii_> cost around 10$
[16:04:13] <amee2k> could have been worse :)
[16:07:16] <_hetii_> you think its possible to handle my idea ?:)
[16:07:41] <amee2k> do they have a dev/eval board for that IC available?
[16:08:00] <amee2k> technically sure its possible. doesn't mean it is easy either ;)
[16:08:14] <amee2k> and all depends on how far you want to go to pull it off
[16:08:34] <OndraSter> hmm I like Altium Designer better than Eagle, at least from visual side
[16:08:40] <OndraSter> plus it has 3D preview :P
[16:08:42] <_hetii_> in pdf we can read 2,500 to 16,000 usable gates what is strange for me :>
[16:08:42] <OndraSter> somewhat cool
[16:08:46] <amee2k> lol
[16:08:52] <amee2k> even kicad has 3d preview :P
[16:08:58] <OndraSter> does eagle have 3D preview? :P
[16:09:07] <amee2k> no idea
[16:09:11] <amee2k> i don't use eagle
[16:09:22] <OndraSter> I use eagle only because it is the only thing I know a bit how to use :P
[16:09:23] <_hetii_> i`m not sure if the board is avaiable :) so i will design own :)
[16:10:22] <OndraSter> oh well, I shall be ordering 2morrow my boards
[16:10:25] <OndraSter> time for bath!
[16:13:21] <amee2k> ok, ast three GPIO pins are gone now too >_>
[16:13:52] <Kevin`> _hetii_: oh, important question, do you have driver specs for an sb live? is it supported by oss linux or something? I remember some of the newer sb cards as having only windows binaries, and you couldn't exactly run those
[16:13:55] <amee2k> gonna need to violate the SPI pins in the end too
[16:14:37] <Kevin`> _hetii_: why are you doing this, anyway?
[16:15:05] <amee2k> fun?
[16:15:14] <amee2k> thats what we masochists do, really.
[16:15:17] <_hetii_> fun and glory :)
[16:15:21] <_hetii_> hehe :)
[16:15:31] <_hetii_> thx o_0
[16:16:00] <eatyourguitar> how many interrupts can I use on the 328P? I dont need any timers
[16:16:15] <eatyourguitar> I just need two pin change interrupts
[16:16:23] <Kevin`> what do you mean how many?
[16:16:42] <eatyourguitar> is there a limit
[16:16:50] <_hetii_> Kevin`, i belive sb live should have some dirver specification. It was one of the popular card :)
[16:16:58] <eatyourguitar> the datasheet shows 5 interrupts
[16:17:01] <Kevin`> eatyourguitar: I think you have a misunderstanding about how interrupts work
[16:17:10] <Kevin`> (on avr, at least)
[16:17:41] <eatyourguitar> like you cant have an interrupt on every pin
[16:17:56] <eatyourguitar> the datasheet shows 3 for pin change and 2 for ext
[16:18:06] <eatyourguitar> http://www.atmel.com/dyn/resources/prod_documents/doc8271.pdf
[16:18:09] <eatyourguitar> page 67
[16:18:15] <Kevin`> eatyourguitar: I think you can, actually, they will just all go to the same isr
[16:18:39] <eatyourguitar> ok so how many ISR's can you have?
[16:18:54] <Kevin`> one for each hardware interrupt
[16:19:22] <eatyourguitar> so how do I know from the datasheet
[16:19:54] <amee2k> thats probably not the answer to your question, but 328P has 26 interrupt vectors
[16:20:01] <Kevin`> eatyourguitar: see "external interrupts", page 72
[16:20:52] <amee2k> from what i can see, megaX8 can have an interrupt on every single pin
[16:20:54] <amee2k> even reset
[16:21:35] <Kevin`> i'm kind of suprised I haven't seen a package with no vcc and gnd pins, just protection diodes on everything
[16:21:45] <Kevin`> well, aside from rfid chips
[16:21:50] <eatyourguitar> if your using momentary buttons can you just debounce with a cap and a diode and set it for low = interrupt
[16:22:09] <eatyourguitar> my buttons are common ground
[16:22:19] <eatyourguitar> 2 buttons
[16:22:45] <amee2k> Kevin`: hmm doesn't 1-wire do that kind-of?
[16:22:59] <grummund> eatyourguitar: maybe explain the reason for your question "how many interrupts" and then people will have an idea what you mean...
[16:23:22] <eatyourguitar> well I know there are 2
[16:23:27] <eatyourguitar> int0 and int1
[16:23:44] <eatyourguitar> I have 2 buttons so I don't have a problem yet
[16:23:46] <amee2k> i mean, it only has two lines. lines pulled togehter means low, lines pulled apart means high. device is powered by the signal lines
[16:24:19] <grummund> eatyourguitar: so you want to know how many pins you can hook up with pushbuttons and have interrupt on each one?
[16:24:21] <amee2k> eatyourguitar: the only difference between INT and PCINT interrupts is that the PCINTs share a single interrupt vector among several
[16:24:31] <Kevin`> eatyourguitar: read the datasheet, it makes it pretty clear
[16:24:32] <eatyourguitar> yes grummund
[16:24:32] <amee2k> and you need to figure out in software which pin caused the PCINT to fire
[16:24:38] <eatyourguitar> I think its 2 right?
[16:24:55] <amee2k> megaX8 has a PCINT on every (non-supply) pin
[16:25:06] <Kevin`> eatyourguitar: you could have every pin cause an interrupt
[16:25:14] <grummund> usually INT0 & INT1, but as mentioned there ae also PCINT.
[16:25:30] <eatyourguitar> but then you need to check your IO register to get 26 interrupts
[16:25:50] <grummund> yeah
[16:26:01] <eatyourguitar> so int0 has all your interrupts inside it
[16:26:03] <amee2k> you can have an arbitrary number of buttons by checking for changes in a timer interrupt, then using callbacks to fake hardware interrupts
[16:26:12] <grummund> only INT0/INT will have dedicated ISR
[16:26:19] <grummund> only INT0/INT1 will have dedicated ISR
[16:26:43] <eatyourguitar> I could just use INT0 and INT1 since I only have 2 buttons
[16:26:48] <eatyourguitar> quick and easy right?
[16:26:55] <amee2k> sure
[16:27:06] <grummund> INT0/INT1 are generally easier to use than PCINT
[16:27:15] <eatyourguitar> but if I need to debounce momentary buttons, do I do it in hardware or software
[16:27:37] <amee2k> well, if you want to use INTs to begin with. clever use of polling can get you around hardware debounce circuits
[16:28:01] <Kevin`> eatyourguitar: software debounce is pretty easy in an mcu
[16:28:16] <eatyourguitar> my first guess was that the code is totally different if I do it with a timer interrupt
[16:28:24] <amee2k> both soft and hardware debounce are practical. which one you pick depends on your application
[16:28:52] <amee2k> software debounce doesn't need extra parts, so if that is practical to implement it usually is the preferred solution
[16:29:02] <eatyourguitar> right
[16:29:16] <eatyourguitar> I need to work just a bit harder on my code
[16:29:40] <amee2k> as a side note, polling will implicitly do the debounce if your polling interval is longer than the switch's bounce time
[16:29:42] <grummund> disable the interrupt from inside the ISR and then re-enable it sometime later
[16:29:49] <grummund> that way you just get the first edge
[16:30:09] <eatyourguitar> amee2k the problem is oscillations shorter than the poll
[16:30:20] <amee2k> i know
[16:30:23] <eatyourguitar> I had it like that and showed it to someone
[16:30:42] <eatyourguitar> they didn't like it so now I'm trying to learn about the different ways
[16:30:45] <OndraSter> wondering if it would be smart to have an interrupt routine that would check some specified memory location for address to which to jump to... programmable vector addresses
[16:30:47] <OndraSter> for certain tasks
[16:30:56] <Valen> I use ISR's for buttons
[16:31:06] <OndraSter> not sure if the avr-gcc can handle pointers on functions
[16:31:16] <amee2k> eatyourguitar: but the converse argument is: by selecting suitable polling intervals you can solve problems with oscillations up to a certain length
[16:31:18] <eatyourguitar> there are probably lots of ways to write libs for all this stuff
[16:31:26] <Valen> first thing the ISR does is remask the triggers to disable the interrupt for that pin
[16:31:40] <Valen> then after a suitable time it gets re-enabled
[16:31:40] <eatyourguitar> arduino cant do interrupt on pin high but you could hack it
[16:32:04] <eatyourguitar> using the rising and falling triggers
[16:32:41] <amee2k> so if your switch specifies a bounce time of, say, 10ms, then polling every 50ms will implicitly debounce it
[16:32:51] <eatyourguitar> true
[16:33:03] <eatyourguitar> unless the bounce time was in a range
[16:33:04] <grummund> but also miss rapid click of pushbutton
[16:33:35] <amee2k> grummund: depends on your application as to whether that would be a problem though
[16:34:00] <eatyourguitar> http://www.mammothelectronics.com/4SFS3PDT-MS-I-p/800-1007.htm
[16:34:03] <amee2k> for a telegraph key? probably. for a light switch? not likely
[16:34:15] <eatyourguitar> something like that is what most people use with guitar equipment
[16:34:26] <Valen> since when has good been enough ;->
[16:34:31] <grummund> amee2k: well pushbutton was mentioned...
[16:34:41] <eatyourguitar> but generally we dont use momentary or AVR's
[16:34:52] <amee2k> haha love the "extended information" ... "The best switch at the best price"
[16:35:05] <amee2k> clearly the best price. they even saved up on the datasheet >_>
[16:35:39] <amee2k> http://www.mammothelectronics.com/Wiring-Board-for-4SFS3PDT-Switches-p/1100-401.htm << what the fuck, 90 cent?
[16:37:57] <_hetii_> huh something tell me that it will be not so easy as i thought :>
[16:42:49] <amee2k> _hetii_: hehe :)
[16:43:24] <amee2k> it would probably get a lot easier if you could find some embedded board with PCI, or at least a dev board with similar functionality
[16:44:09] <Kevin`> an embedded board with sound support :D
[16:44:22] <OndraLappy> just use some audio DAC :)
[16:44:26] <OndraLappy> or what do you want to connect?
[16:44:28] <OndraLappy> into the PCI
[16:44:32] <amee2k> or at least with a PCI slot
[16:44:36] <amee2k> http://en.wikipedia.org/wiki/File:Alix.1C_board_with_AMD_Geode_LX_800_%28PC_Engines%29.jpg << like this one
[16:45:45] <_hetii_> OndraLappy, SB live ;)
[16:45:51] <OndraLappy> oh
[16:45:57] <OndraLappy> that classic SB Live? :P
[16:45:58] <amee2k> 33MHz isn't really "high speed" anymore but its not low speed either so designing a board for that from scratch would involve a considerable amount of work and money
[16:46:17] <OndraLappy> do you have datasheet how to interface it?
[16:46:21] <OndraLappy> or are you gonna take drivers apart
[16:47:32] <_hetii_> OndraLappy, to be onest now i just focus on hardware part. About rest will worry on next step :>
[16:47:57] <OndraLappy> if there are linux drivers, it might be doable
[16:48:08] <OndraLappy> but disassembling windows drivers
[16:48:09] <amee2k> no point in selecting hardware if you have no idea how to program for it ;)
[16:48:09] <OndraLappy> hmm
[16:48:11] <_hetii_> as i remmeber there was
[16:48:24] <OndraLappy> I took apart few WinMo drivers
[16:48:26] <OndraLappy> from HD2
[17:01:57] <_hetii_> ok my mind have enought for today :)
[17:02:06] <_hetii_> have a nice night/day :>
[17:02:13] <amee2k> will do :)
[17:02:14] <_hetii_> Cu :>
[17:02:19] <amee2k> bye
[17:02:24] * amee2k aves
[17:02:30] * amee2k waves* even
[17:02:42] <_hetii_> yep ;-)
[17:10:21] <OndraLappy> gn
[20:28:57] <dirty_d> have any of you used simavr?
[20:46:10] <koo3> greetz
[20:48:34] <Tom_itx> hmph
[21:03:06] <ftc> hello