Back
[00:07:57] <rue_house> pff
[00:08:09] <rue_house> lies, I'v had machines up for over 2 years in a row
[00:08:13] <rue_house> (linux)
[00:15:18] <rue_house> I used to code
[00:15:24] <rue_house> code not watch tv
[00:15:28] <rue_house> code when I wasn't chatting
[00:15:32] <rue_house> code when it wasn't light
[00:15:37] <rue_house> ...and when it was
[00:15:46] <rue_house> and inbetween...
[07:36:17] <gmarsh> hey folks - bit off topic, but any of you guys develop for ATSAM's? I've got a project here that I'd typically throw an AVR32 at, but the SAM3s look a lot more price competitive. If so, curious what you guys are using for tools (don't really want to spend $ on a SAM-ICE)
[07:42:04] <megal0maniac_afk> gmarsh: I could be wrong, but I think that with the latest firmware, the JTAGICE3 supports some ATSAM models
[07:45:05] <megal0maniac_afk> I''m not wrong. It supports SAM D20 devices
[07:45:52] <gmarsh> hmm, trying to find a reference for that
[07:45:58] <gmarsh> I'm eyeing a SAM3N for a project
[07:46:40] <megal0maniac_afk> http://www.atmel.no/webdoc/jtagice3/jtagice3.whats_new.html
[07:47:21] <megal0maniac_afk> Seems to specifically be the D20
[07:47:29] <gmarsh> seems like it, and they're using SWD
[07:48:03] <megal0maniac_afk> Ooh, 32pin TQFP. I like
[07:49:35] <megal0maniac_afk> Also, abcminiuser knows the SAM stuff pretty intimately, but it might specifically be the D5
[07:51:43] <gmarsh> wow, the D20 is nice... unfortunately I need DMA for what I'm doing but I'm definitely keeping it in mind for other things.
[07:54:19] <w|zzy> cya guys.. im moving to NXP... :p
[08:00:02] <w|zzy> They are gaining some traction round here. Though i was joking.
[08:00:14] <w|zzy> They used eclipse for their IDE and didn't balls it like avr32 ;)
[08:20:36] <twnqx> mainly because they are more open on programmers than anyone else...
[08:21:19] <twnqx> and of course TI's stellaris
[08:21:24] <twnqx> too much to choose from in the end :X
[08:24:37] <gmarsh> I'd love for one of the vendors to support in-circuit debug with a cheap FTDI JTAG adapter
[08:25:45] <gmarsh> like a bus blaster, olimex dongle etc
[09:13:29] <rue_house> its amazing what a person can do building code up gradually and having one debug led
[09:14:17] <rue_house> esp if you have a scope
[09:15:09] <Tom_itx> what amazing code did this person do?
[09:15:29] <rue_house> code that worked perfectly the first time it was finihed!
[09:15:43] <Tom_itx> umm... it's not finished until it works
[09:16:00] <rue_house> opposed to the old 'write it all and try to work out why nothing works'
[09:16:40] * Tom_itx gives rue_house a box and a bible on modular code
[09:17:26] <Tom_itx> for buddy?
[09:17:57] <rue_house> no, gmarsh wrote all his code all at once, and now needs hefty debugging tools to try to understand why it dosn't work
[09:18:17] <Tom_itx> oh
[09:18:26] <Tom_itx> well he should have known better
[09:18:27] <rue_house> zlog
[11:00:28] <spec_> An LED for debugging is nearly useless. A scope at minimum, logic analyzer if you're at all serious
[11:01:41] <spec_> My last project would have been impossible to debug without a logic analyzer.
[11:05:07] <jadew> a LED is good enough sometimes
[11:05:20] <jadew> when you don't have an LED you can use a resistor and 2 wires to the toungue
[11:05:34] <jadew> you can even send serial and decode it in your head if the baudrate is low enough :D
[11:06:41] <spec_> Yes. TX @ 110 bps driving a relay. Totally slow enough to decode the clicks in y9our head.
[11:07:08] <jadew> you don't need the rely, you can just feel the little tingling on your toungue
[11:07:56] <jadew> the line would probably have to be inverted tho, so no tingling = high (idle)
[11:08:02] <spec_> I like to use needles in my skin for that. the twitching makes me feel closer to my project.
[11:08:22] <jadew> lol, you could even install a socket for quick access
[11:08:49] <spec_> Mmmm. Nerve socket.
[11:08:50] <jadew> the more sensitive the area the faster you can communicate
[11:09:02] <jadew> maybe two needles in the scrotum?
[11:09:16] <spec_> Sure. One step closer to the Matrix.
[11:09:20] <jadew> bzz bzz bzz, alright, it works
[11:10:27] <tzanger> hahaha
[11:10:33] <tzanger> wtf did I just walk in to here
[11:11:19] <jadew> we were thinking about how to debug a device with out an LED :D
[11:11:22] * tzanger envisions two guys, one with a pair of aligator clips kneeling by another guy in the process of taking is pants off and hearing "trust me, this is the fastest way to get the debug info you wanted since you didn't put LEDs or a UART in your design"
[11:12:26] <sirpatrick> is there a good location for code examples for atmega series of MCUs?
[11:12:26] <spec_> Debugging Abu Gorab style.
[11:12:50] <sirpatrick> I know TI you can download examples for different microcontrollers that shows all the different periphis
[11:12:52] <jadew> sirpatrick,
http://atmel.com/avr
[11:13:01] <tzanger> spec_: clearly you have not done any serious debugging. an LED is unbelievably useful even in complex debugging situations. Granted, a scope and maybe an 8-input logic analyzer is more useful/straightforward and can enable you to see a lot more at once, but "nearly useless" does a great disservice to anyone getting started
[11:13:11] <spec_> Code examples for what? there is no central repository. Google is your friend.
[11:13:22] <jadew> tzanger, this idea is so awesome it could become a thing, soon we might all have preinstalled scrotum sockets
[11:13:23] <tzanger> I really do enjoy using SignalTap to debug FPGAs but even that has its limits
[11:13:28] <jadew> no need for the aligator clips
[11:13:49] <tzanger> with little old ladies knitting nutsack cozies that you can embed the conductive foam into
[11:13:52] <spec_> "<tzanger> spec_: clearly you have not done any serious debugging." Give me an f'ing break.
[11:14:29] <tzanger> spec_: how can you state that an LED is nearly useless for debugging? it's pretty basic, sure, but nearly useless?
[11:14:33] <jadew> "tinfoil underwear for rf shielding! protect your data from hackers!"
[11:14:34] <spec_> Clearly *YOU* have not done any serious debugging.
[11:14:54] <tzanger> spec_: howso? I've been designing embedded systems for over 20 years now
[11:15:27] <tzanger> anything from little 8 bit systems to full-out PCIe-connected FPGA telecom systems for aerospace
[11:15:31] <spec_> Because a *single* LED can only relate *ONE* thing
[11:15:34] <spec_> Good for you.
[11:15:57] <tzanger> spec_: sometimes that is all you need: "I got to this point in the code" or "this blink pattern means situation A, and that blink pattern means situation B"
[11:16:30] <spec_> My statement still stands, a *single* LED is about as minimal as you can get in terms of feed back.
[11:17:04] <jadew> actually, in my experience outputting something is just as fine as looking at the state of everything at once
[11:17:09] <tzanger> hell that PCIe design had 5 LEDs just to relay the LTSSM bits for the link, which helped figure out wher I was. SignalTap couldn't tap the PHY because it was DDR and you'd break timing if you tried ot tap it, but I could tie 5 LEDs to the LTSSM output in the application clock space ot do it
[11:17:33] <jadew> however, most of the times you don't need to see it all and if you do, you can create logic that generates the output to give you an answer, yey or nay
[11:17:34] <spec_> What an enormous waste of time! Coding blink patterns to communicate one state or another, no doubt using code that blocks.
[11:17:41] <tzanger> now granted I also had to use a $250k oscilloscope to get ot the root issue, but the LEDs allowed me ot narrow down what was going on before I got there
[11:17:46] <spec_> ZZZZZZZZzzzzzzz................
[11:17:57] <tzanger> spec_: why on earth would you do it that way?
[11:18:06] <spec_> Please put your junk away. No one wants to see that.
[11:18:16] <tzanger> it sounds like you're taking the stance and using ridiculous assertions to back it up
[11:18:47] <jadew> you can certianly debug digital stuff with TRUE/FALSE output in different stages, that's how digital stuff is debugged anyway
[11:18:51] <jadew> granted, might take a bit longer
[11:18:54] <tzanger> using blocking code to blink anything is a junior approach to the solution
[11:18:55] <jadew> but it's just as effective
[11:18:56] <jadew> you'
[11:19:05] <GargantuaSauce> some people use architectures with real debugging interfaces
[11:19:08] <jadew> you'll need a scope for analog stuff, that's all
[11:19:12] <jadew> otherwise it's not mandatory
[11:19:36] <tzanger> GargantuaSauce: I find I can often get to the root with some LEDs and a UART faster than I can with a logic analyzer and JTAG.
[11:19:38] <twnqx> and pretty often neither a scope nor a logic analyzer will help you find programmign errors.
[11:19:56] <spec_> Putting a $20 logic analyzer across eight unused I/O pins blows a single LED flashing patterns totally and completely out of the water. An LED will *NEVER* let you diagnose millisecond or microsecond timing issues.
[11:19:57] <tzanger> for some cases you need to bust out gdb and JTAG, but that should be only after you've narrowed it down
[11:19:58] <spec_> NEVER.
[11:20:27] <spec_> That's great, when the UART is available. it's not always available.
[11:20:30] <tzanger> spec_: completely agreed, but even millisecond timing problems can often be narrowed down fairly quickly with a single LED
[11:20:53] <spec_> So would self flagellation.
[11:20:58] <jadew> yeah, the LED is the most useful debugging tool IMO
[11:21:05] <spec_> Just beat yourself long enough until you get it right.
[11:21:34] <tzanger> i.e. you can narrow down the scope of the problem and then determine "yes, I need to use a better tool to see/resolve this" -- but also a lot of times you can figure it out without getting tot hat level by observing an LED and saying "hm, I should not be getting here, why?"
[11:21:40] <jadew> spec_, it might take a different way of debugging and if you're not used to it, I guess it could look weird
[11:21:56] <jadew> but lots of people do it this way and not only in electronics
[11:22:09] <spec_> That's like saying a crescent wrench is better than an entire Snap On tool chest.
[11:22:31] <jadew> I've been remote debugging stuff for so many years, it's in my second nature to debug code by outputting a 1 or a 0 to check the state of something at a particular stage in the logic
[11:22:35] <spec_> Because it's only one thing and it fits so many different bolts.
[11:22:55] <jadew> when that's all you have, it deffinitely is
[11:23:32] <tzanger> spec_: not necessarily. I always have a crescent wrench set in the trunk though, and the tool chest is at home in the garage. you don't have to bust out the fully articulated triple square socket set for many cases
[11:23:33] <spec_> tzanger, or you could just use the better tool to begin with.
[11:23:40] <jadew> and sometimes even if you have all the tools, it might just happen that you need that crescent wrench for that particular job
[11:23:56] <tzanger> and the same is true with setting up even the $20 logic analyzer or breaking out openocd/gdb
[11:24:00] <theBear> or the stilson if yer lucky
[11:24:03] <theBear> damn they are cool spanners
[11:24:47] <tzanger> I'm definitely not saying that good tools are useless. I am contesting your statement that an LED is nearly useless for debug. You did not stipulate what kind of debugging, just any debugging, and that's plain old wrong.
[11:25:57] <theBear> mmmm, i tend to keep 'debugging' simple when i'm micro-ing, specially if i don't already have a uart of some kind involved in the setup/program that i can 'borrow' ... trick is small changes, pay attention, program often
[11:26:48] <theBear> i'm still fond of my 3 7seg little debug board, got a bcd driver, addressing for 3 digits, usually i jam it on a whole port and just have 1 of 2 fig8's handle each 4 bits
[11:26:56] <tzanger> theBear: yes, and I would add to that "commit often" -- before git came along (and specifically git add -p) I hated committing often, but now I can try thigns "pick apart" the changes and commit them piecewise
[11:27:30] <theBear> err <tries to sound professional and modern> yeah, of course, that's what we do now git is here <grin>
[11:27:50] <twnqx> and didn't with mercurial, or svn branches, or...
[11:27:54] <jadew> I don't know why the industry is going trough so many version control systems
[11:27:58] <jadew> it's freaking retarded
[11:28:03] <jadew> what was so wrong with svn?
[11:28:14] <twnqx> not that much
[11:28:19] <twnqx> is simply far inferior to git
[11:28:22] <spec_> Chances are that the uP is going to be flipping the bit on the LED so fast that you're going to need another tool to get anything useful from it. Even then, it's only communicating one condition. It's far more useful to see one state in relation to another.
[11:28:23] <tzanger> most of my designs start out as a skeleton with a 1ms timer that peels off 10,100,1000ms flags, and there's an LED ticking with either 100 or 1000ms to let me know the program's not hung. I usually then repurpose that LED to debug other things either by modifying the blink or by adjusting "duty cycle" of the blink (mostly on/half on/mostly off, not PWM)
[11:29:06] <tzanger> twnqx: I never got into mercurial, but svn has the same problem as cvs wherein you can't pick part of a change and commit it, you have to commit the entire file
[11:29:30] <spec_> Well, if you like the pain of debugging through the tiniest of key holes, then good on you.
[11:29:31] <twnqx> i wouldn't know how to commit parts of a file with git
[11:29:33] <theBear> yeah, but if yer stuck, got no serial/text options for debug without seriously altering the program, led can be good, even if it's just helping you debug why a fork/conditional doesn't get somewhere
[11:29:35] <tzanger> twnqx: and aside from the dvcses, they all require you to be online or have a local-only repo. git is great for not needing that
[11:29:51] <jadew> I don't think commiting part of a change is wise
[11:29:54] <twnqx> i am the one saying git rules :P
[11:29:58] <jadew> you should never commit broken code
[11:30:12] <jadew> as in... the code has to work before you commit it
[11:30:15] <theBear> in those kinda cases, i see it quicker to connect 2 pins to an led and just force some variables/mess with the conditional and see when the light does or doesn't come on
[11:30:51] <jadew> actually, I guess there are scenarios when that's not possible
[11:31:02] <tzanger> spec_: I prefer to look at it as cheap and effective visibility into the code without having to piss about with other hardware (UART drivers need to be debugged sometimes or the code "stomps" on the driver area, a logic analyzer or scope needs ot be set up, etc.) -- I *have* these tools and make very good use of them, but they're not the first thing I reach for most times
[11:31:18] <tzanger> jadew: I almost never commit broken code
[11:31:27] <spec_> Well, when your entire project is an interrupt driven state machine, an LED doesn't cut it. It becomes necessary to see which flags are set or not, and which segments of code are currently executing. Can't do that with a single LED.
[11:31:32] <jadew> tzanger, me neither, but sometimes the situation requires it
[11:31:53] <tzanger> I mean let's say you enable debugging, make a couple changes, make another change... now I can pick out the couple changes for A, pick out the other change for B and NOT commit the #if whatever for debugging
[11:31:57] <twnqx> spec_: for that you need jtag anyway
[11:31:59] <spec_> Knowing one at a time is *USELESS* They need to be seen in *relation* to each other.
[11:32:03] <twnqx> or debugwire or whatever
[11:32:19] <spec_> Nope. that's overkill.
[11:32:29] <tzanger> spec_: mostly agreed. but again, my argument was that you didn't qualify what kind of debugging. you only said that an LED is nearly useless for debugging.
[11:32:46] <tzanger> there are a great many cases where an LED won't help you and you need to break out better tools
[11:32:52] <twnqx> oh, something as trivial as a jtag port that you have anyway for programming os overkill
[11:32:55] <tzanger> but that is the exception IMO, not the rule
[11:32:58] <jadew> and for what it's worth, you don't usually need to see the state of each thing in there
[11:33:03] <spec_> Right, because it only lets you see one thing. A single state limited to visual perception.
[11:33:08] <twnqx> but a logic analyzer with microsecond resolution isn't
[11:33:13] <jadew> you usually need to know if x is 1 and y is 0 and z is 1 at a specific time
[11:33:14] <twnqx> yeeaaaaaah
[11:33:15] <spec_> Which BTW, is pretty bad in humans.
[11:33:43] <tzanger> twnqx: I try to not need JTAG/gdb. I've got it if needed, but I find it's more of a pain to use than just using the LED and/or UART to emit debugging info
[11:33:53] <twnqx> well, yes
[11:34:10] <twnqx> i have four LEDs for no particular purpose, a serial port and jtag on my last project :P
[11:34:52] <jadew> I juse use uart lately
[11:34:58] <jadew> but I did fine with an LED in the past too
[11:35:07] <jadew> I only take the LA out when I'm doing protocol debugging
[11:35:24] <spec_> Which is part of what I was doing.
[11:35:49] <spec_> DMX-like protocol on a 2313A
[11:35:51] <tzanger> UART is probably my #1 if available, followed by LEDs, followed by <problem specific>
[11:36:20] <tzanger> almost all of my DeviceNet stack design was debugged with printf()
[11:36:44] <spec_> Can't measure when a certain interrupt fires or routine is called in relation to a specific byte in a DMX frame with a single LED.
[11:36:45] <tzanger> clearly that doesn't work at wire speed, but I did not often need to print out individual CAN frames in realtime
[11:37:13] <tzanger> spec_: no, but timer values and a debug loop can. Honestly though I'd probably use a logic analyzer or scope for thatmyself
[11:37:45] <jadew> I'd go with the scope for timing
[11:38:44] <jadew> actually, I'd go with the scope for everything if it could decode various protocols
[11:38:50] <jadew> mine can't
[11:39:16] <spec_> I find that adding too much extraneous debug code only makes things worse. Enabling a bit at the beginning of a call and disabling it before the return can tell you *volumes* of information. Each call/ISR gets it;s own bit on a spare port and you can see the internals in action.
[11:39:23] <tzanger> the Usbee/Saleae logic can do that reasonably well and is expandable.
[11:39:47] <tzanger> spec_: completely agreed.
[11:40:52] <jadew> yeah, it's deffinitely a lot harder to finetune time critical code with an LED, but that doesn't make it a bad debugging tool
[11:40:57] <twnqx> do you oversize your chips that much on purpose? my last design had 0 unused pins
[11:41:02] <tzanger> I have developed libraries for debugging that are fairly lightweight and rely on spitting data to an intermediate RAM FIFO which is emptied by the TX empty interrupt. It's too heavy for some applications
[11:41:02] <jadew> almost as good as the scrotum needels
[11:41:03] <theBear> my eyes can decode all kinds of digital and even some high speed analog like pal video, all in realtime on my sexy old fairly standard dual 20mhz
[11:41:13] <spec_> I have the 8-bit Chinese Saleae knock-off. Best $20 I ever spent. Going to buy the official 16 channel from them as soon as I get paid on the next project.
[11:41:25] <learath> openbench :P
[11:41:56] <spec_> It probably wouldn't run on a 2313A. Only 128 bytes of RAM
[11:43:10] <tzanger> The pump controller I built is on a tiny13a; I actually have to use FETs to disconnect pins from the rest of the board when in the programming jig, as I have like -3 pins available already (using them for multiple functions within the normal operating mode of the code)
[11:44:14] <theBear> hmm, the implementation will make all the difference, but that sounds kinda cool, in a sneaky get-'er-done kinda way
[11:44:20] <tzanger> even on that though I managed to multiplex two LEDs on the design. They turn "on" for 5ms/8.3ms so I can turn them off and read a button and potentiometer during the other part of the cycle, but they're there and help me debug
[11:45:00] <tzanger> that's an example where you *can't* use anything else; all I/O is used up and I can't exactly connect the Dragon to it while it's running to use DebugWire because the design is floating on a 24VAC supply
[11:46:18] <tzanger> to say that an LED is nearly useless for debugging that project is patently wrong; it's the *only* way to gain visibility into the code in this case.
[11:48:19] <spec_> Still, visually interpreting the state of the LED can only tell you so much, which is the absolute minimum.
[11:48:50] <theBear> mmm.. last time i used it the board was doing lots of realtime r-c-trick to read a whole bunch of pots, outputting any changes (sometimes scaled to preference) as soon as they happen up the tx (single uart avr) and also sucking up 'special' packets on the uart input from a twin-device and adding the proper stuff to make them real packets then forwarding them out the tx with the local data.... there was mayb
[11:48:51] <theBear> e a half a free port, maybe a whole one, but even if i crippled the actual function speed wise adding a softuart just for debugging woulda changed so much it just couldn't be called debugging
[11:49:01] <theBear> and often the minimum is all you need
[11:49:02] <spec_> If I only had a single pin free, I'd probably bit bang debug data to a console.
[11:49:51] <spec_> Not that often.
[11:49:53] <tzanger> there is no pin free.
[11:50:17] <spec_> I'd rather see as much of what's going on as possible.
[11:50:33] <tzanger> http://www.mixdown.ca/dump/pumpcontroller.pdf
[11:50:35] <tzanger> that's the schematic
[11:50:37] <spec_> By monitoring *all* the other pins
[11:50:54] <tzanger> spec_: yes, you can watch the triac firing and zero crossing. that's about it
[11:51:04] <tzanger> thank god the program is pretty basic
[11:51:11] <theBear> if it's a niche or timing or compiler/optimisation problem, even adding minimal ultra-basic lightweight bitbanging will often be enough to alter or remove the problem, and err, ends up being useless and a waste of time
[11:51:21] <tzanger> it spends 95% of its time asleep, a zero crossing wakes it up and it counts zero crossings to tell time
[11:52:15] <tzanger> if W1 or W2 are not active in 24h, it fires the TT or PUMP triac for a minute to keep the pumps primed. If W1 or W2 *are* active, it fires the appropriate triac and resets the triac "last run time"
[11:53:06] <spec_> You've got *four* LEDs.
[11:53:19] <tzanger> that schematic is missing the second fet to disconnect the RST# line from the LED
[11:53:24] <tzanger> spec_: two are not under software control
[11:53:36] <tzanger> and two are multiplexed with the AC line crossing detection and button/potentiometer reading
[11:54:45] <tzanger> I guess I *could* turn W1/W2 into outputs and try to drive the LEDs but I don't think I can with the arrangement they're in. I had to connect them in a specific way so I could tell if the W1/W2 inputs were active or not (half the cycle you can't tell and the other half you have to be able to see if they're being driven)
[11:56:23] <spec_> I looked at that, but the resistor is too big. Of course if you put some sort of analyzer on there....
[11:57:20] <tzanger> I'm just using the other two LEDs to blink slowly green if the system is idle, blink slowly red if one of the pumps is on. The power supply is very weak, I have to duty cycle everything, including the processor. :-)
[11:57:39] <tzanger> the triacs are only fired for a few ms every cycle to ensure they're gated
[11:58:03] <tzanger> everything floats on the 24VAC rail too, not a good environment to be connected grounded equipment
[11:58:52] <spec_> How that circuit doesn't smoke or constantly reset is beyond me. What is the ripple look like on VCC?
[11:59:42] <tzanger> it's got about 1.5V of ripple when an LED is on, the processor is good down to 1.8V so there aren't any issues. The goal was *cheap*, which is why the circuit looks liek that
[12:00:36] <tzanger> I can probably drop a 100u cap and use SOT23 diodes (both SOT23 and SMB are supported on the board), and if I lose the LEDs and pot/button the cost comes down even more
[12:02:11] <tzanger> with some software rework I can probably sleep even more since I intentionally put the triacs on the timer output pins... wake up due to zero cross, determine what to fire, fire, set timer for +2ms and timer output=off, go to sleep
[12:02:24] <theBear> hehe, that's kinda cool (just looked at the circuit, i like breaking the rules now i know them all so well)
[12:02:34] <tzanger> wake up after 2ms, look at W1/W2 if it's the positive half cycle, go back to deep sleep this time since I don't need the ioclk anymore
[12:02:51] <tzanger> yes, that is exactly how I was thinking too... "this is so wrong... so wrong..."
[12:03:11] <spec_> What system is this for?
[12:04:04] <tzanger> it's an in-floor radiant heat pump module
[12:04:22] <tzanger> all it does is make sure the pumps don't lose prime
[12:05:29] <tzanger> Q1 disconnects the power supply from the AVR if it's being powered from the ISP pads (the dragon needs to quickly cycle power to the AVR and there's too much capacitance to do that without it) -- I use the body diode to power the AVR under normal operation
[12:05:31] <spec_> TT and W1/2 connect to what?
[12:06:14] <tzanger> TT/PUMP are just dry contact outputs that connect the respective pump to 24VAC. W1/W2 connect to the thermostat, whcih itself is just dry contacts that connect W1/W2 to hot
[12:11:50] <blathijs> Anyone who can think of a shorter way to do "TIMSK0 &= ~(1 << OCIE0B)" in assembly in an ISR than these 9 lines?
https://github.com/matthijskooijman/pinoccio-backpack-reference/blob/firmware-prototype/firmware/backpack.c#L298
[12:12:40] <blathijs> I'd like to use cbi, but the TIMSK0 register isn't low enough for that. So I use the more elaborate in; andi; out sequence, but that requires me to save SREG and another reg instead, creating this monster...
[12:12:59] <blathijs> Anyone know if there is some other shortcut for this?
[12:13:07] <tzanger> blathijs: supposedly TIMSK0 isn't changing on its own; keep the original value in a global var and just write the new value instead of RMW
[12:13:40] <tzanger> i.e. if the masked value is 0x12 and the unmasked value is 0x13 just write 0x12 in the ISR instead of read/and/write
[12:14:43] <theBear> actually.. hmmm
[12:15:43] <theBear> hehe, imagine how shocked they'd be if i copied that schem verbatim for something i been putting off the last week <grin> that'd show 'em
[12:16:16] <blathijs> tzanger: There are other places in the code where it can change. Now, normally, when this ISR fires, I think I know what bits are set in TIMSK0, but it might be asking for trouble later on if I'd just assume that here...
[12:16:25] <theBear> actually, technically it's a VERY similar application, sneaky hang-off-unisolated-mains micro supply, triac running a small pump <grin>
[12:17:09] <blathijs> tzanger: It could save 5 instructions I guess, leaving just the push; load immediate; out; pop
[12:20:16] <theBear> hmm, what's BUT_POT and what kind/what's the deal with D3 ?
[12:21:08] <theBear> oh, BUT_POT is zero crossing finetune ?
[12:24:21] <theBear> aww , and that's a really good schnitzel/cutlet recipe, with the nice sauce and all :(
[12:30:20] <tzanger> theBear: :-)
[12:31:00] <tzanger> theBear: no, but/pot is a button input and poteniometer input; the pot will probably go away as they don't seem to want to tune how long to wait before forcing a pump cycle anymore
[12:31:04] <tzanger> once a day is more than enough
[12:31:21] <theBear> just another 6 1/4 hours the shops will open and i can maybe get some veal... hmmm, surely i've still got a meat hammer in the kitchen ? it's been a while
[12:31:39] <theBear> tzanger, got it, just an arbitrary control knob
[12:31:50] <tzanger> yes
[12:32:27] <tzanger> the idea is that I can differentiate between a button press (ADC=0) and low-end wiper with the 10k series resistor creating a voltage divider
[12:33:16] <theBear> incase any trying to guess, i'm back to my poor coffee machine... all the mechanical stuff is still in better than new working order and cleanliness, but seems the long term questionable power finally cooked the little tiny err, EM78P153E micro in there, and it just seems wrong to jam in a simple timer/brainless pump switch circuit when the box proudly proclaims "FUZZY LOGIC - MICRO CONTROLLED" in big lette
[12:33:16] <theBear> rs :)
[12:33:36] <spec_> blathijs: Where is development for this board taking place?
[12:33:56] <tzanger> IN BIG LATTE
[12:34:40] <theBear> actually, unless yer don't mind pasting/sharing the code, i was considering just thismorning triac driving and zerocross detecting.... how you handling both the syncing to actual crossings, and the delay between the crossing and firing (assuming you didn't want a HARD on/off) time/angle ?
[12:34:53] <blathijs> spec_: It's for the pinocc.io project, see
http://pinocc.io and
http://pinocc.io/community
[12:35:08] <blathijs> spec_: Does that answer your question? :-)
[12:36:04] <tzanger> theBear: the t13a is asleep (deep sleep) and the zero crossing wakes it up. I know that the zero crossings (-ve to +ve) occur 60 times per second
[12:36:21] <theBear> i was thinking kinda a loose software pll pulling an interrupt triggering timer basically into sync, then cheating and altering the timer/interrupt setting around crossing time to trigger at firing time, then i don't need to worry about waiting/timing the angle seperately, i don't think that's too ugly
[12:36:30] <tzanger> the +ve -> -ve are also counted, giving me a wakeup every 8.33ms in north america/60Hz
[12:37:25] <tzanger> so I count them for wall time, and if I want to drive a relay, I fire the triac by driving the output low. I set the timer to wake/interrupt me in 2ms or so and doze (can't sleep since I need the I/O clock)
[12:37:36] <theBear> mmmm, i approve (generally) ... this has come a long way since the rumblings of pre-design i remember some time ago
[12:37:46] <tzanger> when I get woken again I shut off the triac (float the output) and go back to deep sleep for the rest of the cycle
[12:38:24] <tzanger> if you don't need super low current draw don't do it this way, you can just use a traditional supply and optoisolate the triac firing
[12:39:09] <tzanger> my application doesn't have critical phase timing or anything, I just want to fire as close to the crossing as possible to give the relay as much of the cycle as possible
[12:39:56] <tzanger> the design is a few years in the making due to it being a low priority project
[12:40:05] <tzanger> I had an earlier design which used a PIC12
[12:40:11] <theBear> i know, but i been trying not to use my last few opto-triacs, it's already gonna be more or less floating on non-isolated mains in a nice double insulated casing/controls/etc... i'll probly stiffen the psu a little, but i like your shortcuts, and recently it seems if a circuit isn't already a bit sneaky i can't help but waste my time breaking some rule or other :)
[12:41:14] <theBear> mmmm, this application for me doesn't really need anything accurate either, it's only a big fat heavy mains oscillating pump.... but one of these days i will get around to that half-done mess at the other end of the workbench, and that DOES want variable switching
[12:41:36] <theBear> and probly some kinda thermal fuse so it doesn't burn down my house when the code or the triac freezes up one day :)
[12:41:52] <spec_> blathijs: Not exactly. I gather you're in NYC?
[12:44:11] <tzanger> heh yeah a 555 circuit that times out and either crowbars the supply or disconnects it would be a good idea. don't use software to protect your software from itself
[12:44:37] <tzanger> my mentor had a saying "never make a circuit smarter than it absolutely has to be; they have a habit of using their extra smarts to fuck you."
[12:47:38] <theBear> it's true, but being young retired and going out of my mind doing very little slowly in general, i've had to develop new hobbies, including my ridiculously large tools/solder approach to TINY TINY TINY soldering/repairs, and sneaky/break-the-rules-but-only-cos-i-know-them-inside-out-from-following-them-for-years kinda stuff on anything i knock-up (was gonna say make, but most stuff recently is just quick, a
[12:47:38] <theBear> cat5<>pal balun and power cleanup here, a weird splitter rca cable with a dual gang pot halfway up it there)
[12:47:55] <blathijs> spec_: Well, I am in the Netherlands, Eric and Sally, who are the pinoccio founders are in Reno and Michigan I think
[12:48:06] <tzanger> https://plus.google.com/107280738832484622687/posts/6WLqDpsWmvs
[12:48:23] <tzanger> theBear: ^^ that's the original and the new. I deadbugged an AVR into the old PIC12 board for testing :-)
[12:48:50] <tzanger> theBear: young and retired? you poor soul.
[12:49:18] <theBear> huh ? i think you mean giapetto and a small village in italy ?
[12:50:32] <tzanger> Didn't you say you're young and retired?
[12:50:59] <theBear> tzanger, i'm err, temporarily <he said with a hint of remaining confidence> crippled.... can't sit or stand too long at a time, 24/7 medications, varying and constant pain, various legs can't be controlled depending which bits are getting squashed that day etc etc.... that's a more realistic picture than "young and retired" <grin>
[12:53:15] <tzanger> theBear: I wouldn't call that retired, I'd call that hell
[12:53:48] <tzanger> wtf happened to you?
[12:58:26] <theBear> various err, i think you call them congenital, defects, you know, few wrong shape bones, few bits grown long where they stopped doing it 1000's of years ago for whatever reason, etc etc, then BIG carcrash early '09, few years alternating between heavy (tho not fitness-steady-heavy) warehouse/repair work and REAL heavy work taking lights/staging/audio crap out in the big truck and 'running' school fetes/wedd
[12:58:26] <theBear> ings/whatever and eventually my little s4/s5 cushioney thing gave up completely, was on the couch watching movies and having a couple beers one saturday, bit of a funny stiff feeling one side of my bum-muscle, 8 hours later it was the most incredible shooting pain and the whole bum muscle/upper leg was cramped SOLID, even with the heavy medication that stupid thing stayed cramped for 9 months (last year i h
[12:58:27] <theBear> ad a limited period of back-to-barely-broken, and after a few months to get off the horrible painkillers without going psychotic or my heart stopping, i was ok till around christmas this year, even got myself an awesome new job i had to leave :(
[13:09:45] * N1njaway helpfully upgrade's theBear's human operating system!
[13:12:46] <tzanger> wow, sounds like you've had a rough time of it
[13:42:13] <theBear> yeah, been a pretty shitty couple years on and off, fortunately the weird not-quite-painkiller pills i got this round kinda make me dopey, a little spaced/slow, certainly not recreational, but enough that i can cheerfully ignore the state of things and just keep ranting at your poor bastards during the better periods :)
[13:44:05] <theBear> hmm, mixdown too eh ? interesting... i always been more of a live-ninja, recording generally bores me, except for maybe the bit at the start where you messing about polishing their turd instruments up to a nice metaphorical sheen, and of course your bit, where you actually DO something, rest of it is just sitting patiently and remembering to hit record and basically doing nothing as much as possible :(
[13:45:16] <theBear> but live is exciting and you can drink more and often smoke, sometimes you gotta kickass in less than no time, other times you can mess about and make stuff kickass at a regular speed, if you listen hard enough you can give yourself SOMETHING to do at any moment thruout the night
[13:52:53] <megal0maniac_afk> theBear: Try recording spoken word :P
[13:59:10] <theBear> lol, try doing it LIVE in a hot tent at a festival all day and night <grin>
[13:59:16] <theBear> i been around
[13:59:46] <megal0maniac_afk> I am actually working at a festival at the end of November :D
[14:00:01] <megal0maniac_afk> None of that, though. Thankfully
[14:02:57] <theBear> heh, that WAS a particularly miserable example, but on the upside i got to see my old buddies the wiggles and did a set for them over the other side :)
[14:04:01] <megal0maniac_afk> Festivals are seldom completely bleak
[14:05:14] <theBear> there's no denying it :)
[14:06:28] <megal0maniac_afk> Planned to make a wireless inclinometer to set the line array angles, using avr and nrf chips. Never got around to it
[14:07:23] <megal0maniac_afk> http://www.synergylive.co.za/capetown/themes/synergylive/images/fest_info/slider_mainstage_01.png
[14:07:27] <theBear> i assume you know there's a bunch of apps that do that (not just pure angle/level) in android and probly ifone land right ? it's actually the first app i ever saw on a modern/droid fone
[14:08:20] <theBear> megal0maniac_afk, ooh nice, a big one :) don't see those much anymore
[14:08:41] <theBear> last time i was at somewhere that big i saw what passes for public enemy these days.... still pretty awesome :)
[14:08:52] <megal0maniac_afk> That will be my baby (and home) for 4 days. And yes, I do. But the line arrays get hoisted up to lots of metres, and you need to know the angle without leaving the ground
[14:11:25] <theBear> yeah, but depending on the array and roadcasing/physical coupling setup, i'd be thinking a set of angles loaded in like a list, if it's a stack in/on the roadcase kinda little deal, find a spot, set one you know, maybe the top one as reference, hold phone to it, tap screen or little list, move to next box, tap to get new/relative value, repeat.... if it's a hoist and add one to the bottom deal, get it hangi
[14:11:26] <theBear> ng and i spose use the top box at the reference, then just tap tap tap to get out the values you calculated on the fancy software earlier
[14:14:22] <megal0maniac_afk> It's a JBL Vertec 4 rig. I don't remember the technicalities, just that they're currently using a box with a long wire, and I don't like long wires :)
[14:17:13] <megal0maniac_afk> theBear: The angle between boxes IS preset. So I can't remember the reason. I think just for very specific adjustment once they'd been flown
http://ultraevents.co.za/images/photos/11_235.JPG
[14:18:59] <megal0maniac_afk> And the whole lot is worked out with JBL Line Array Calc
[14:20:59] <theBear> vertec4 ooooh fancy :)
[14:21:39] <megal0maniac_afk> There's no picture that shows off the full set-up. I shall take one and bring it back here
[14:21:48] <theBear> heh, these days when i wanna see how serious a BIG array like that is, i just look how ridiculously heavy duty the little steel frame it hangs off is... that one has i-bars as big as any building :)
[14:22:42] <theBear> very good... i might have a fleeting glance of the system i used for a lotta years, small, mostly built by me and some other dude (yes we did the maths PERFECTLY, my boxes ALWAYS kicked ass) hmmm to the website
[14:23:47] <theBear> heh
http://testing.rememberit.com.au/pics/Tridentad.pdf i had to guesstimate/design/build a psu for a desk in that series and chassis a few years back, still kickin' ass it is !
[14:25:29] <theBear> that was serious business, 100's of watts of sexy linear power in a 2unit case with cute bezelled rail leds and matching fuseholders etc.... you do the maths, tl072, maybe 18 or 20/channel, maybe 32 input channels, 8 or 16 send/master kinda strips, another 16 or 24 return strips, lights for the big old meters.... those desks chewed power
[14:26:51] <theBear> http://testing.rememberit.com.au/pics/building/IMAGE_00126.jpg look familiar ? tesla_downunder dude lives right near my mum, it's in many of his pics of the HUGE bike headlight among others
[14:29:13] <megal0maniac_afk> Trident make beautiful stuff. I thought I'd seen one, but it was a Raindirk. Equally pretty
[14:29:15] <theBear> http://testing.rememberit.com.au/pics/building/newest/IMAGE_00033.jpg not exactly the speakers i was thinking of, but speakers nonetheless...
[14:31:28] <theBear> http://testing.rememberit.com.au/pics/building/newest/IMAGE_00054.jpg this is the back of a pot-matrix panel i had a bunch of for that place... rif and Tom_itx kicked ass designing, tuning, etching, assembling and delivering a whole bunch of them literally in a few nights (i had time for nothing that week) the boards that drove them
[14:32:04] <theBear> plus i got to specify a silk screen that included a POT MATRIX header (it just makes me giggle) Fat Talbot and err, soemthing else i forgot that makes me smile
[14:32:41] <megal0maniac_afk> Awesome :) What the hell is a pot matrix good for, though?
[14:37:18] <rlc> aref on the atmega16, What do I connect it to?
[14:37:53] <megal0maniac_afk> Datasheet says Vcc through an inductor. Unless you want a different vref
[14:38:09] <megal0maniac_afk> Oh I lie. That's AVcc
[14:39:56] <rlc> Then? Do I leave it floating?
[14:40:06] <megal0maniac_afk> Noooooo
[14:40:10] <megal0maniac_afk> Vcc
[14:40:16] <megal0maniac_afk> Or just read the datasheet
[14:40:22] <rlc> Directly?
[14:40:26] <megal0maniac_afk> Atmel put a lot of work into that
[14:41:12] <rlc> No time to read the datasheet.
[14:41:44] <megal0maniac_afk> Really, though?
[14:42:04] <megal0maniac_afk> Connect to Vcc, but datasheet will give you... better information
[14:42:11] <theBear> http://testing.rememberit.com.au/pics/building/newest/IMAGE_00023.jpg orright, btw, err,
http://testing.rememberit.com.au/pics/building/ has a bunch of pics mostly from building the studios that bear built, and err,
http://testing.rememberit.com.au/pics/building/newest/latest01.html has some more... anyway, that first one picture 23 there.... the black case on top is a o1v (mk1, we had a bunch of them, ha
[14:42:12] <theBear> d been using them for live and pretty much everything for a while, racks are heavy, o1v is not :), the two big amps are both wired up the wall with the data to a pair of very nicely 'treated' (i hate that word, no stupid kits ("treatments"), no bullshit, pure maths and science !) rooms with speakers like the ones in pieces at the start earlier, and a little atmega board in a little wooden frame/'box' VERY a
[14:42:12] <theBear> ttached to the wall in either room... top of the box is covered with one of those pot-matrixes (6*6 with a physical gap between the bottom two rows as i recall) which costs 'nothing' ... 6 inputs on the wall in nice solid little attached boxies, both go back to a half of the desk, avrs talk to each other in series, as i described without mentioning the application earlier re: debugging, any knob movements t
[14:42:17] <theBear> hey do any necesarry translation/virtual centre/0 etc etc and spit out reverse engineered o1v sysex... one feeds the other, it feeds all that back to the midi input on the desk, thats HIGH quality desk with optional 'untouchable and unknown' compressors/protection/whatever hidden in a little room down the hall, they can spill their cheap white wine all over my 'desk' attached to the wall, and at worst i gra
[14:42:22] <theBear> b a spare from the front desk and zoop zoop with the drillgun, new 'desk' all wired up and instantly working, then the next day i spray the pots and maybe replace a couple that got the drinks hard... awesome ! think we had 3 pairs of rehearsal rooms running like that, never got a desk for the final ones, but usually used them as extra/overflow recording rooms anyway
[14:42:27] <theBear> damn
[14:42:48] <Joggl> i would put 1V on the VREF pin
[14:42:55] <Joggl> or 2V
[14:43:01] <Joggl> or 1.23V
[14:43:18] <megal0maniac_afk> From a precision regulator
[14:43:24] <Joggl> or whatever i want to measure with the DAC
[14:43:27] <Joggl> that is <VCC
[14:43:42] <rlc> Ok, I connect it to Vcc. My Vcc is 5V. Would it be fine?
[14:44:05] <theBear> anyway, that's what a pot matrix is good for, and if you into that kinda thing, a bunch of the building pics are likely interesting, also a couple out my old kitchen windows over the container yard a few hundred feet from the end of the international runway :) poor old kitty, mums house, best factory made iced coffee in the world, keefie the master (ticketed) electrician/ex housemate, mr jay my good old bud
[14:44:05] <theBear> dy, assshole, crazy looking very shaved head guy would be my little bro... i'm the one been pulling cables and got all dirty
[14:44:27] <Joggl> maybe.
[14:44:33] <Joggl> ask your mum or the datasheet
[14:44:46] <Joggl> some µCs can just handle about 2,56V max
[14:44:53] <theBear> adjust torrents, glance glance, nobbad.... don't all decide to look at the same time tho, or you all get bored while pictures load
[14:45:12] <theBear> but there should be a solid 100k/s or so there now
[14:50:18] <megal0maniac_afk> rlc: Basically connect it to whatever you want. If you're connecting it for the sake of actually USING the ADC, then you should know what you want it to be
[14:50:38] <rlc> From what I understand, I need to connect a capacitor to aref instead?
[14:51:04] <rlc> FYI, I'm not going to use the ADC at all
[14:51:09] <megal0maniac_afk> theBear: Awesome! I love that kind of stuff. Had to tear down a studio recently. Bad debt :(
[14:51:44] <rlc> Can I leave it floating then?
[14:52:24] <megal0maniac_afk> rlc: Then ground it or float it or whatever. I recall something about giving pins a definite state to save power, but I don't know if that applies to AVcc
[14:57:36] <rlc> Ok, thanks. I will leave aref floating
[15:00:32] <theBear> i'm led to believe that so soon that AMAZING place has already been taken down.... meh... the several years of building and ridiculously hard work flat out forever to get it all going there was a lotta potential, but once i'd been sitting at the desk in the corner of a big cold warehouse all night every night for over a year, living upstairs, generally managing and maintaining and running the whole damned p
[15:00:32] <theBear> lace, all office depts, over 100 hours most weeks, then find out the asshole been cheating on his wife, lying to me about constant band practices (when he actually goes to practice, he takes two guitars and an amp, not nothing :) oh, and being that he owned a kickass studio complex they tended to practice there) and meetings and crap while i drove myself haggard running the shit... anyway, by that stage wh
[15:00:33] <theBear> en me and his wife (lovely lady, still visit her when i'm in town) worked out just how completely he was being a lying asshole, i wasn't so excited about possibilities for the future anymore, and things had been going well with my "highschool sweetheart" and gran had a stroke, so i decided to move across the country back 'home' ...
[15:00:57] <theBear> and that's likely the last rant for a little bit, as usual, i apologise for filling your screens
[15:08:16] <spec_> That's cool. Scroling text makes me look productive.
[15:10:35] <w|zzy> it's def something you are passionate about
[15:11:00] <theBear> hehe smooth ! i'll try slip in some rarely used brackets and the odd comparative operator so it looks productive AND intelligent :)
[15:12:14] <theBear> there's no denying it, i spent probably a surprisingly high % of my post-highschool life in musicland one way or the other, plus, it's so damned BORING being crippled, just when the pain eases off, you notice you never do ANYTHING and used to do LOTS of cool stuff ALL the time :)
[15:14:29] <theBear> some usual-suspect random-question-answering-website (you know,ask a random question in google land and it's often in the top 5) caught my eye yesterday.... considering having a go at signing up as an 'expert' in a few areas ...apparently i basically do what i do here, but one at a time with nice forms, and they err, pledge i suppose, money as to what they see the value of the answer being to them, the qual
[15:14:29] <theBear> ity/helpfulness of the expert, if they just wanna ticket back and forth or talk in a little realtime text popup to the actual expect etc etc..
[15:15:23] <w|zzy> worth a go.
[15:15:37] <theBear> whole damned site carefully hides the details of % what money goes where exactly, but it looks like it'd more than cover beer money if i just casually answered/used it like i already do around here
[15:20:05] <w|zzy> beer money! I need more of that
[15:31:09] <theBear> it's good stuff, beer money !
[15:52:51] <joshbillions> Anyone have experience hiring contractors on oDesk for AVR related programming love?
[15:54:56] <theBear> i don't even know what a odesk is ! but i do know all the other words :)
[15:57:31] <w|zzy> What about freelancer.com ?
[15:57:56] <w|zzy> most of those sites seem more aimed at less embedded design.
[15:59:27] <theBear> don't know any of them <grin> when i wanna contract the best avr dudes in the business, i simply come here and ask them really nicely :)
[16:00:31] <w|zzy> Isnt dean looking? :P
[16:01:13] <N1njaway> Finding good people to contract with is very much a two-way engagement. You want engineers who can develop fast and proficiently, and the engineers want clients who have enough technical knowledge to a> be realistic on time b> be realistic on budget c> can write a CONCISE scope of work document.
[16:02:00] <theBear> hmmm, dean, that's err, abc ?
[16:02:08] <twnqx> yeds
[16:02:09] <w|zzy> ya
[16:02:11] <twnqx> -d
[16:02:29] <N1njaway> There are a lot of people who approach me/us to work on AVR designs. A lot of them I won't take on simply on the basis that I know they would be a terrible client for some or all of the reasons above. No amount of money is worth the stress of dealing with someone who doesn't know what services they're trying to purchase beyond "Make this work so I can make money from it!"
[16:03:04] <w|zzy> Or make you sign a NDA
[16:03:14] <w|zzy> to hear their "idea"
[16:03:32] <N1njaway> NDA's aren't as big a deal with certain customers depending on how they are written.
[16:03:58] <theBear> N1njaway, it's a fine balance... i like to think i know how things look from both sides on that kinda thing that 'is what i do' , but i still find when it comes to work i struggle to deal with customers who just don't have the background to know exactly what they want... i don't go crazy or anything, just kinda, not much i can do, you tell me what you need and i'll make it happen, but if you don't do your b
[16:03:59] <theBear> it, i can't make anything happen :(
[16:04:08] <N1njaway> But general conversation will quickly let you figure out (I suppose if you have the experience of spotting red flags) if it's even worth considering an NDA stage, or if you just pass outright at that point.
[16:04:53] <w|zzy> N1njaway: Had a guy who had no background, no company try and make me sign a NDA he downloaded off the net to hear his "idea". I just said good luck mate and walked off.
[16:06:17] <N1njaway> theBear: I can certainly say that I prefer doing work for Fortune500's vs small-time operations, mostly because the bigger customers have more money and are more realistic about their expectations, and will provide reasonable budget. The smaller customers (the bad ones, at least) more work on the basis of "What can buy for $50?" and because it's just code, it's stuff you can just bang out like a
[16:06:17] <N1njaway> form-letter in MS Word.
[16:06:50] <N1njaway> The F100's are even better than the F500's in my experience. :)
[16:07:38] <N1njaway> But really, it's not about how big the customer is or how much money they have... it's about forging long-term relationships with people you work very effectively with, and where you BOTH benefit at the end of the day, hopefully monetarily :)
[16:07:52] <w|zzy> What frustrates me is that most large companies won't take innovation from inside the company. Well unless it is the persons job to innovate.
[16:09:36] <theBear> mmm, i've often/generally been around or in businesses towards the smaller end, there ARE reasons i'm more comfortable in that area than the big corporate series business, but i agree, and it's not just flatout penny-pinching, but things stretch and shift, all of a sudden you're filling in a 2nd distinct and very different job every 2nd day 'cos it needed doing and well, can't let something go to hell at wo
[16:09:37] <theBear> rk... one thing leads to another, 6months later you think hmmm, been a while since i been in MY nice office/workshop and actually done MY job
[16:11:21] <N1njaway> w|zzy: This is true to a degree, but it also depends on what market that company is in. Sometimes companies need things done that are peripheral or supportive of their business, but are not SPECIFICALLY their business. In those cases it can very often be extremely advantageous to go to a subcontractor who specializes in the area they need work done. It allows them to hold someone accountable to
[16:11:21] <N1njaway> being competent, delivering on schedule and budget, and getting the work done. Doing some/all of that in-house if you aren't the best suited to it can create the exact opposite effect. You want to do it in house to save money, but instead you wind up spending a hell of a lot more with inferior results and missed deadlines because you have no one you can as concisely hold accountable for. Every
[16:11:21] <N1njaway> situation is different, but I have seen what I've descibed time and time again. And sometimes we've gotten the job BECAUSE someone screwed it up really badly in-house :)
[16:12:59] <w|zzy> I was thinking more new systems, procedures, tools or whatever else developed by staff to make jobs more efficient.
[16:13:06] <w|zzy> Rather than company mandated innovation.
[16:13:07] <jadew> theBear, that's exactly how I'm feeling
[16:13:14] <jadew> execpt I'm several years later
[16:13:19] <w|zzy> Maybe ive worked for crap companies.
[16:13:22] <jadew> *except
[16:14:04] <theBear> mmm, well that's all i got... i'm several years later and crippled and several years after that, working, heck, even leaving the house in a timely manner, is like a blurry dream to me now, i can't believe i ever had that will every single day
[16:14:26] <jadew> wait, you're better now?
[16:15:14] <theBear> nup
[16:15:19] <jadew> ah
[16:15:23] <theBear> but i'm a bit drunk right now, which takes the edge off
[16:15:24] <jadew> thought you recovered
[16:15:35] <jadew> I always asume you are
[16:15:39] <theBear> i did for a time, but then i broke again :(
[16:15:47] <jadew> damn...
[16:15:54] <w|zzy> :(
[16:16:32] <theBear> heh, damn indeed
[16:18:10] <jadew> you know how some drugs are overloading the pain nerve channels with noise and that releaves the pain?
[16:18:18] <jadew> I wonder if you can do that eletrically
[16:18:51] <jadew> then you can turn the pain off with a switch
[16:19:41] <N1njaway> jadew: Prescription autisim? :D
[16:19:46] <N1njaway> i
[16:19:48] <N1njaway> -i
[16:20:07] <jadew> heh, just the pain, nothing else
[16:20:32] <w|zzy> sounds like a good idea jadew.. Get on it :P
[16:20:47] <jadew> I'm sure there are people already on it :)
[16:21:33] <jadew> I don't know which class of drugs work like this, but they're one of the most effective ones
[16:21:45] <joshbillions> Just turned back to the chat, thanks for the responses. I'm in the startup world, and feel the pain of NDAs, it's ridiculous.
[16:22:13] <theBear> someone in the other channel swears by hi (by muscle/body standards) freq tens for toothache numbing.... and one day soon i'll get one hacked up again and see how it goes, apart from anything else it'll help stop me wasting away thru disuse
[16:22:34] <joshbillions> I'm one of two embedded guys at our startup and need someone else to delegate some bootloader work to
[16:23:15] <joshbillions> oDesk and Freelancer are a bit of scary proposition because our team is so small.
[16:23:31] <jadew> theBear, I don't know what that is, got a link?
[16:24:02] <N1njaway> josh: Yeah, tricky situation. What kind of work do you need done? :)
[16:25:03] <joshbillions> We've got a pretty basic telemeter product (ATmega + GPS + GSM Modem) and want to be able to reprogram the micro from a file on the cellular modem
[16:25:49] <joshbillions> Reached out to some of the FAEs we're working with but all of the folks they recommended were slammed
[16:26:03] <joshbillions> s/were/are
[16:27:55] <jadew> joshbillions, so a one time project?
[16:28:02] <N1njaway> josh: That's fairly trivial to do. The hardest part is usually well-defining the bootloader needs, the way programming should happen, and then how to gracefully handle anything that could ever go wrong. (i.e. think through the "how can we never, EVER brick up this device? If X fails, how do we recover it?")
[16:28:36] <joshbillions> jadew: it would start that way, but we're growing. Just hired our first full-time EE. :D
[16:29:17] <N1njaway> I've done a multitude of bootloaders that reprogram via XMODEM or even RS485, and defining the above processes thoroughly are almost always more difficult than the actual bootloader reprogram code, which is usually only a dozen lines if that :)
[16:29:44] <joshbillions> N1njaway : Agreed. Personally the hardest part right now is just finding the time to sit down and get it done. I have what I consider a pretty robust plan mapped out. We have ample storage on the cellular modem (250MB+) so we could archive previous known-good hexs
[16:30:01] <N1njaway> josh: Excellent.
[16:30:31] <N1njaway> Who's GPS are you using, BTW, if I may ask? I have extensive experience with Garmin's OEM modules, and they are fastastic devices.
[16:30:45] <joshbillions> Ah, we're using U-blox for the positioning module and cellular modem
[16:31:10] <N1njaway> NMEA messages, or do they have a proprietary API?
[16:31:46] <joshbillions> NMEA with a mix of proprietary messages for their cellular triangulation API
[16:32:30] <N1njaway> Cool. Garmin does the same with injection of proprietaries that you can switch on and off.
[16:33:17] <joshbillions> Nice. I'll have to check out their offerings. I went with U-blox because the cellular modem and positioning module talk together to offer some pretty cool features.
[16:34:14] <N1njaway> Yeah, that's a nice route to go if it has everything you need. We've used Garmin 18X OEM's before since they have the features we needed, and are in a little IP-67 rated puck that you can just slap outdoors on a bracket without worry.
[16:34:56] <joshbillions> Nice.
[18:42:05] <MarkX> hi everyone
[18:42:23] <MarkX> i thought of a random question at work today while reading about adc and timers
[18:42:46] <MarkX> the manual says for ADC in free running mode, the first conversion takes 13 cycles.
[18:43:56] <MarkX> if i have an interrupt set for every time a timer reaches TOP
[18:44:16] <MarkX> does that stop the analog to digital conversions as well?
[18:44:32] <MarkX> if so, does it still take 13 cycles to continue those conversions once the timer is dealt with?
[18:44:45] <Tom_itx> probably so
[18:45:03] <MarkX> if i'm way off on my understanding, i do apologize. i just learned about timers last night :P
[18:45:41] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_timers_index.php
[18:45:54] <Tom_itx> his whole set is on the menu on my page
[18:46:18] <MarkX> got the pdf in the next tab :)
[18:46:28] <MarkX> that's what i've been reading/following to learn
[22:17:23] <spec__> Hi all. What's the fastest you can realistically bit-bang async serial?
[22:17:38] <spec__> Assuming a 16MHz clock
[22:18:16] <Casper> depend on the processing you need to do for each bits
[22:19:06] <Casper> if you hard code it, it can go at F_CPU
[22:19:23] <Casper> if you need time for each bits... it will drop significantly
[22:20:02] <N1njaway> I believe you can only toggle the ports at F_CPU/2, and that assumes no processing for anything else.
[22:20:46] <Casper> N1njaway: that wouln't be toggling
[22:20:48] <Casper> but setting
[22:21:13] <Casper> and afaik, sbi/cbi is 1 cycle
[22:21:28] <N1njaway> It's two. I just had to look at that recently.
[22:21:46] <Casper> oh?
[22:21:56] <Casper> then it's F_CPU/2 if 2 cycles
[22:22:19] <N1njaway> Which is what I said above
[22:23:02] <N1njaway> And yes, see pages 48/117 in the AVR Instruction set document :)
[22:23:09] <N1njaway> 2 cycles for cbi/sbi
[22:24:06] <N1njaway> spec: Assuming you have a 16 Mhz clock, at an async baud-rate of 57600 will be about 277 cycles per bit.
[22:24:11] <Casper> well, you could also just write the port value directly :D
[22:24:59] <N1njaway> Yep, assuming you didn't have to do any additional operations. But that's not going to be the case in any reasonable application :)
[22:25:58] <N1njaway> spec: You would probably want to at least use a timer to crank out the bits so you have less jitter in your timing.
[22:26:44] <N1njaway> The higher the speed, the less margin for error you have.
[22:27:11] <N1njaway> Beyond a certain speed, you will absolutely need a clock crystal, even if bit-banging.
[22:28:45] * Xark notes standard UART/USI can go at FCPU/2 per bit AFAIK (so may not need to bit-bang).
[22:30:02] <N1njaway> There's no way you'd ever bit-bang at close to FCPU/2 anyhow, because you would need to do shifting operations and such between bits, unless it's hard-coded. At that point, why not just use a higher-speed UART?
[22:31:34] <rue_house> UNROLL LOOPS
[22:31:36] <Xark> N1njaway: I tend to agree, but you can ASL ; OUT to sent byte at FCPU/2 (but then need extra cycles between bytes).
[22:32:02] <N1njaway> If you're going much higher than 1-2MBits, you might want to consider not using asyncronous serial :)
[22:32:04] <Xark> (That requires 7 bits of the port are ignore or something)
[22:32:16] <N1njaway> Xark: Yes, at which point, why? :)
[22:32:45] <Xark> N1njaway: Well, I know about that from bit-banging video with AVR
http://imgur.com/a/JO4Cq
[22:33:39] <N1njaway> Yes, though that's not asyncronous serial - you don't have to contend with jitter quite as much and it will still work :)
[22:33:42] <N1njaway> Very nice, BTW
[22:33:52] <Xark> N1njaway: And others have done similar with SPI
http://www.batsocks.co.uk/readme/p_art_SerialVideo.htm#Serial_Data
[22:34:29] <N1njaway> Xark: Yes but that wasn't the discussion. Obviously a UART or SPI is a better way to go than big-banging from a performance standpoint. :)
[22:34:34] <Xark> (Oops, correct section is
http://www.batsocks.co.uk/readme/p_art_SerialVideo.htm#Display_Line_Rendering )
[22:35:50] <Xark> N1njaway: Yes, and mostly I was just pointing out that AVR serial is effectively "full speed" (bit-banging doesn't make it faster).
[22:36:03] <N1njaway> Right-o
[22:36:40] <N1njaway> Someone really needs to code a video-outputting logic analyzer that is as easy to wire as that, because there's enough people on here that could really use one and won't purchase one :)
[22:36:47] <Xark> N1njaway: I think jitter is more of an issue with video, BTW. You are one cycle off and it is crap. :)
[22:37:17] <Xark> N1njaway: I have to do "cycle accurate" interrupts (basically poll full speed timer).
[22:37:47] <N1njaway> Well it's a case of video looking a little off vs corrupt data :)
[22:38:10] <Xark> Not really readable and many TVs won't sync it properly.
[22:38:37] <N1njaway> And that argument overall is kind of invalid unless you are talking about a specific datarate/pixelclock vs bit-perfect data communications :)
[22:39:27] <N1njaway> If I need higher-speed or higher-accuracy with clock-perfect transactions, I just move that heavy lifting off in to an FPGA :)
[22:39:42] <Xark> Whatever, just pointing out video is quite "jitter sensitive". Do not attempt without crystal. :)
[22:39:51] <N1njaway> Absolutely.
[22:43:29] <N1njaway> All good stuff :)
