Back
[00:10:12] <braincracker> tzanger<= ;)
[00:10:27] <braincracker> [171444] <braincracker> okey, sw pwm smoothly ramps up down with the led :) now i'd need some magic
[00:11:29] <braincracker> 8MHz sw pwm with timer0 overflow int comparator works fine, gives 122Hz PWM at 8 bit resolution
[00:11:58] <braincracker> currently tested wit 3 channels, will do 8 channels today
[01:37:35] <Enma_Hinobara> I have a question
[01:38:15] <Enma_Hinobara> How in the world does Atmel stay in business, selling MCUs like the ATmega at more than twice the price of vastly more powerful chips like the MKL25Z128VLK4?
[01:40:52] <jerkey> because those other chips are harder to program and less durable
[01:41:03] <jerkey> if you can't get through development you don't want to use it in a product
[01:42:54] <Enma_Hinobara> Harder to program? What do you have in mind by that?
[01:42:59] <Casper> Enma_Hinobara: never hear of that one
[01:43:23] <Enma_Hinobara> http://www.freescale.com/files/32bit/doc/data_sheet/KL25P80M48SF0.pdf
[01:43:34] <Casper> who care about the datasheet
[01:43:46] <Enma_Hinobara> We're using it in this class (used an ATmega in the previous class), and just today I was shocked to learn this is way cheaper
[01:43:58] <Casper> price per chip isn't the only factor
[01:44:21] <Casper> first of, PIC is the best selling one
[01:44:24] <Enma_Hinobara> 32-bit, 50 MHz, ARM, and more integrated components than an ATmega
[01:44:30] <Casper> second is atmel
[01:44:43] <Casper> then you have the ARM based one
[01:44:50] <Casper> which is another category
[01:45:38] <Enma_Hinobara> The only possible thing I could think of that ATmega maybe (I don't know the numbers off the top of my head) has going for it is power consumption. I really can't think of a single thing it wins on besides that.
[01:46:09] <Casper> can't say for that one, but usually ARM cores are quite basic, often even lacking onboard ram or flash... and usually very little peripherical, if any
[01:46:36] <Enma_Hinobara> I wouldn't know in general. This one is an MCU and has all that
[01:48:24] <Casper> also, there is some reliability issues sometime
[01:48:36] <Casper> atmel and pic has been proven to be very stable and reliable
[01:48:42] <Enma_Hinobara> Possible. I wouldn't know anything about that
[01:49:12] <Casper> there is ton of code for both, the programmers knows them inside out
[01:49:29] <Casper> today, the cost of the product is not the only factor
[01:49:36] <Casper> the time to market is even more important
[01:54:12] <Casper> and Enma_Hinobara... the chip you linked to... seems to not have 10% of the feature of an xmega (which is in the same category)
[01:54:35] <Enma_Hinobara> Hmm. I'm not familiar with xmega
[01:55:03] <Casper> and the reliability data look suspicious
[01:55:50] <Enma_Hinobara> Looking on Wikipedia...
[01:55:52] <Casper> I'ld expect way more failure than pic and avr
[01:56:01] <Casper> wikipedia don't say much really
[01:56:30] <Casper> but bed time for me, I'm almost 3 hours late
[03:18:14] <jerkey> what's the highest frequency the atmega328p can output without taking away cpu cycles?
[03:22:01] <Tom_itx> 1
[03:24:33] <w|zzy> true.that only takes a single cycle
[03:25:09] <jerkey> no i mean like can you set it to output the crystal / 8 or something like that on a pin?
[03:25:45] <w|zzy> pwm?
[03:25:52] <jerkey> no just on/off
[03:26:04] <w|zzy> that takes cycles.
[03:26:27] <jerkey> i was thinking more like program one of the timers to automatically flip one of the outputs.. like a PWM with one bit of resolution
[03:27:49] <jerkey> ICR1 = 1
[03:43:05] <spec_> Anyone around?
[05:20:04] <mike_papa> Hello. I have two atmega 168pa chips. Same program using UART works fine on one chip, and on second all I get are transmition errors. Fuses are the same on both chips. Is it moment when I should throw it away, and pick up third one, or is there something else I'm missing?
[06:36:16] <Tom_itx> mike_papa, if everything is the same, something is wrong there
[06:46:39] <malinus> mike_papa, before you throw it away. remember - you probably didn't penta-double-check everything, and everything isn't exactly the same :). At least that's my experience :)
[06:47:29] <mike_papa> Tom_itx: Yeah. I've found 2560 I have forgot about. It's working fine even with that one, so... seems this 168 is broken.
[06:52:16] <mike_papa> malinus: I have no idea what else I could check. Same program, same prototype board, same fuses, same clock...
[06:53:01] <malinus> mike_papa, is it a breadboard or a "protoboard"?
[06:54:21] <mike_papa> malinus: stk-600 actually
[07:02:36] <mike_papa> and one more question. Is quartz or resonator enough for UART, or I should go for oscillator (which is much harder to get)?
[07:18:02] <Tom_itx> probably so, the thing about them is you want one that closest matches the baud
[07:18:45] <Tom_itx> http://www.wormfood.net/avrbaudcalc.php
[07:26:39] <mike_papa> Tom_itx: yeah. I found it before. It's just more I read about them, the more I find arguing about resonator or quartz accuracy, and opinions if it's actually stable enough for UART. It's my first expirience with UART, so... I think I'll have to try all of them and check it myself. I'll start with most available, and cheapest.
[07:51:27] <tzanger> Enma_Hinobara: freescale has a reputation of throwing people under the bus
[07:51:38] <tzanger> oh I was scrolled back, that's why it wasn't autocompleting
[09:05:08] <The_Coolest> hey guys.. I've got a problem I'm not sure what is causing it.
[09:05:45] <bss36504> alright, care to elaborate?
[09:05:56] <The_Coolest> so, if I do a soft reset by using the wdt, my atmega328p gets stuck in a reset loop
[09:06:04] <The_Coolest> the moment it hits the first _delay_ms
[09:06:21] <bss36504> because you aren't resetting the wdt i'm guessing
[09:06:32] <bss36504> "feeding the watch dog" if you will
[09:06:48] <The_Coolest> after the reset?
[09:06:53] <bss36504> right.
[09:06:56] <The_Coolest> I tried resetting it, disabling it
[09:08:46] <The_Coolest> the method from which the delay is called, before the delay i called wdt_reset(); then wdt_disable();
[09:09:08] <The_Coolest> i tried adding another reset call after disabling it
[09:09:10] <The_Coolest> still no go
[09:09:22] <The_Coolest> I think the bootloader some screws things up
[09:09:29] <The_Coolest> somehow*
[09:09:36] <The_Coolest> I'm using a usbasp loader
[09:11:04] <bss36504> Which controller are you using?
[09:11:21] <The_Coolest> atmega328p
[09:11:32] <bss36504> did you write wdt_reset()/disable() or did you get them from somewhere?
[09:11:38] <bss36504> do you have a debugger?
[09:11:49] <The_Coolest> nope, no debugger
[09:11:57] <bss36504> (Side note, if you dont, the JTAGICE3 is more than worth the price)
[09:12:03] <The_Coolest> the methods are taken from atmels libraries?
[09:12:13] <bss36504> ok.
[09:12:14] <The_Coolest> I'm using atmel studio 6.1
[09:12:29] <bss36504> hmm...let me look for a moment.
[09:14:01] <bss36504> have you read this thread?
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=79071
[09:16:40] <The_Coolest> i forgot to mention. even doing a hard reset doesn't work. only a power cycle
[09:17:18] <bss36504> did you check your fuses?
[09:17:55] <The_Coolest> what should i look for?
[09:19:39] <bss36504> WDTON, RSTDISBL
[09:19:48] <The_Coolest> right
[09:19:55] <The_Coolest> they are both noot set
[09:20:05] <The_Coolest> the reset button works
[09:20:29] <The_Coolest> it's just after a reset it's still stuck in the reset loop
[09:20:32] <bss36504> but you just said that the reset button did *not* work. 10:00a
[09:21:25] <The_Coolest> i meant doing a hard reset doesn't 'solve the issue'. after I release the button it goes back into the reset loop
[09:21:38] <The_Coolest> wdt is not set. i'll recheck
[09:21:48] <The_Coolest> wdton fise
[09:21:53] <The_Coolest> fuse*
[09:22:50] <bss36504> what is your watchdog timeout set to? If it's too low, it wouldnt matter even if you pushed the reset button since the watchdog timer could still expire
[09:23:07] <bss36504> I'd try setting it as high as it will go, then tweak it down from there.
[09:23:35] <The_Coolest> 2s
[09:23:55] <The_Coolest> it resets the chip after 2 seconds when wdt is enabled
[09:24:07] <The_Coolest> but after it restarts it's stuck in the reset loop.
[09:24:10] <The_Coolest> gah
[09:24:25] <The_Coolest> must be something to do with the bootloader
[09:24:37] <bss36504> what bootloader is on tehre? why not just erase it?
[09:24:46] <The_Coolest> usbasp
[09:25:03] <bss36504> oh right.
[09:25:03] <The_Coolest> the first thing the bootloader does is disable the wdt
[09:25:16] <The_Coolest> int __attribute__((noreturn)) main(void)
[09:25:16] <The_Coolest> {
[09:25:16] <The_Coolest> wdt_disable(); /* main app may have enabled watchdog */
[09:27:07] <bss36504> I've never used usbasp, looks like it's designed to make a programmer, not to self program. Not saying its not possible, just maybe there is something amiss with a modification you made.
[09:28:04] <The_Coolest> yes, it's a programmer. This is a modified version which 'simulates' a usbasp device, and self programs the chip
[09:28:22] <The_Coolest> But it supposedly disables the wdt as the first thing it does
[09:28:47] <The_Coolest> and after a power cycle everything works just fine until I enable wdt for a softreset
[09:31:51] <bss36504> kind of a side question: why do you need the wdt to reset the target? the USB junk all lives in the boot section, so if you wanted to re-program, it's almost certain that some human intervention would be required, thus you could just use the reset pin. Also, have you tested it with the same code, minus the wdt stuff, and just reset manually to test that it works ok?
[09:33:07] <The_Coolest> I'm working on an LCD backpack, similar to crystalfontz displays only on a standalone module. I thought it would be a good idea to add a reboot/reset command
[09:34:12] <The_Coolest> since it also has usb I'm using the usbasp bootloader for easy programming
[09:35:51] <bss36504> Id hate to make you change everything, but have you considered an USB mega? Something like the 32U2 would be a good replacement for the 328, and Dean has a LUFA demo for a USB boot loader already.
[09:36:51] <The_Coolest> well can't change it for this version. I doubt this is because of the usb part
[09:37:28] <bss36504> no, I wasnt suggesting a problem with the USB, but I know that the LUFA demo works like you want it to.
[09:37:42] <bss36504> but that requires a USB mega
[09:37:54] <The_Coolest> the firmware itself doesn't have usb support right now. And the problem happens even if usb isn't even connected
[09:38:34] <The_Coolest> i can live without the soft reset, I'm just baffled at why this happens
[09:39:20] <bss36504> yeah this is tricky. Does the manual reset work when the wdt code is removed?
[09:39:32] <The_Coolest> yeah
[09:39:47] <bss36504> ok
[09:40:17] <The_Coolest> it's as if the wdt gets stuck in the on position.
[09:42:24] <The_Coolest> and the timeout changes
[09:42:32] <bss36504> have you tried manually configuring the wdt instead of using the premade functions? also, did you try that suggestion in the avrfreaks thread about not calling wdt_reset_mcu() and instead letting it naturally overflow? You mentioned that it does in fact overflow and reset.
[09:43:25] <The_Coolest> http://pastebin.com/QUAKefuH this is the code I'm using
[09:44:35] <bss36504> Well that is certainly straight forward enough...
[09:44:59] <The_Coolest> hehe
[09:45:11] <The_Coolest> I wonder, maybe cli() somehow breaks it
[09:46:11] <bss36504> I dont believe it would.
[09:46:34] <The_Coolest> yeah its not it
[09:48:15] <The_Coolest> blag
[09:48:17] <The_Coolest> h
[09:48:22] <The_Coolest> well bbiab :\
[09:48:33] <The_Coolest> bss36504 thanks for your time :)
[09:49:21] <bss36504> no problem. sorry I couldnt help more. Haven't done a whole lot of wdt stuff, so I've never personally experienced the pitfalls. Most of my knowledge on the subject is strictly datasheet readings.
[10:09:49] <tzanger> I've never had a WDT fail, that kind of defeats the purpose :-)
[10:10:26] <tzanger> The_Coolest: is the WDT disable-able? on many MCUs including some AVRs you cannot disable the WDT once it's been enabled
[10:10:54] <tzanger> some chips have a config bit that you can set to drive this function as well (i.e. config bit says whether WDT can be disabled or not)
[10:16:27] <The_Coolest> tzanger idk, but I think it's disable-able
[10:17:45] <kline> http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html#gab3784e1b871d61ed338da5658184b725
[10:17:51] <kline> wdt is disableable
[10:18:16] <kline> (in some cases)
[10:18:18] <tzanger> The_Coolest: if you don't know, get to a point where you do know
[10:18:43] <ambro718> you can program via ISP even if a SPI device is connected there, right?
[10:19:38] <The_Coolest> ambro718 if you have pullups on the CS lines of the devices, it should be doable.
[10:22:41] <bss36504> It should work like that as long as you have no circuitry that could make the MCU MISO pin connected to anything other than a highZ pin on another device. i.e, if you have a level shifter in the middle, you'll need to tristate the pins on it in order for ISP to work
[10:23:59] <ambro718> ok thanks
[10:29:34] * The_Coolest bashes head against desk. what's going on?
[10:30:04] <bss36504> The_Coolest:
http://en.wikipedia.org/wiki/Rubber_duck_debugging
[10:30:55] <The_Coolest> lol.
[11:38:08] <beaky> hello
[11:42:04] <N1njaneer> Hi Beaky!
[11:46:20] <beaky> hello ninja
[11:55:35] <N1njaneer> Have you ported Linux to your ATTINY yet?
[11:56:35] <beaky> nope
[11:56:46] <beaky> btw is port based io effected in a single cycle on avr
[11:57:00] <The_Coolest> tzanger kline, I managed to fix the problem. Of course it was an issue with the bootloader not handling a wdt reset properly.
[11:57:08] <The_Coolest> fixed that, reflashed everything and viola :D
[11:57:21] <The_Coolest> issuing a reset works. and only resets once
[11:57:29] <kline> The_Coolest: you mean the thing i bang on about every single time someone mentions wdt in #arduino ? ;P
[11:57:51] <The_Coolest> kline the bootloader I'm using is USBASP loader
[11:57:54] <The_Coolest> not arduino
[11:58:09] <tzanger> kline: heh
[11:58:17] <The_Coolest> optiboot manages it properly, btw, and my arduino's have been updated to optiboot
[11:58:25] <kline> ah, worth knowing
[11:58:44] <braincracker> hey
[11:59:04] <braincracker> :)
[11:59:23] <braincracker> N1njaneer beaky tzanger salute
[11:59:52] <braincracker> where our friends Horologium, badaboom be ? :(
[12:00:10] <N1njaneer> beaky: If you do a "PORTx =" set, yes, it runs in one clock cycle.
[12:00:24] <beaky> wow i love port-based io
[12:00:33] <beaky> what about PORTx ^= foo;
[12:00:48] <N1njaneer> Hey braincracker long time no see
[12:01:00] <beaky> if toggling io port is in a single cycle then I will have an orgams
[12:01:01] <braincracker> yeah, i'm lost in space too
[12:01:10] <timemage> beaky, you can have the compiler stop at the assembly generation stage. examining the output and looking at the avr instruction guide will tell you the answer.
[12:01:16] <N1njaneer> breaky: That will take a few clock cycles, as it will need to read the value of the port, xor, and write back out.
[12:01:22] <beaky> oh yeah i frogot about the objdump of avr
[12:01:46] <beaky> maybe atxmega can do single cycle flipping of io ports
[12:01:51] <beaky> atxmega does everything
[12:02:00] <braincracker> beaky<= ;) the software pwm works fine, eats most cpu time, but works at 122Hz 8 bit from 8MHz int osc
[12:02:01] <N1njaneer> Yes, look at the assembler output to see what it's actually generating, then pull up the AVR Instruction set document and look to see how many cycles each instruction takes.
[12:02:19] <N1njaneer> Awww, still no bss around
[12:02:21] <beaky> software pwm ftw
[12:02:58] <braincracker> one can have 8 channel led pwm for example on a mega ;)
[12:03:15] <braincracker> a byte for each led brightness
[12:03:52] <beaky> i love using pwm for status indication
[12:04:11] <beaky> i make my leds breathe like my macbook
[12:06:34] <N1njaneer> Yeah as long as you don't mind flickery PWM and you don't need much precision at the low-end and consuming a lot of CPU cycles, software PWM isn't bad.
[12:07:07] <N1njaneer> Bit-Angle Modulation is another alternative to PWM that has a higher carrier rate and has significantly lower CPU overhead.
[12:08:01] <braincracker> i did noot notice flickering.... it worked at 122Hz 8 bit pwm
[12:08:13] <N1njaneer> Move your head and/or the LED around :)
[12:08:32] <braincracker> used timer0 div/1 mode, ovf interrupt to increment the pwm counter and compare
[12:08:48] <braincracker> 122Hz is fair.
[12:08:58] <N1njaneer> If it works for your application, go for it. :)
[12:09:01] <braincracker> 50-60Hz is flickering
[12:10:15] <N1njaneer> BAM is nice if you don't want the overhead of a timer interrupt occuring every single tick of PWM increment, though. You get 8 interrupts per cycle rather than 256 interrupts. Way less CPU overhead, especially if you're letting gcc wrap the interrupt calls with all of the crazy stack preservation overhead :)
[12:10:24] * The_Coolest does the "it finally works as expected" dance
[12:10:30] <braincracker> tried 256Hz / 5 on 7 segment+dp display :) it is noticable if you move your head for example
[12:10:38] <braincracker> but mostly fine
[12:10:50] <tzanger> bit-angle modulation? never heard of that one
[12:11:23] <N1njaneer> To me, anything less than 500-1000Hz on PWM is flickery, but that's because we work on some very specific criteria for LED lighting and display. Our nominal modulation rate for PWM is at 62Khz :)
[12:11:39] <N1njaneer> tzanger: The basic idea is kind of spread-spectrum PWM'ing
[12:11:48] <braincracker> N1njaneer okey i'm being lazy now, this is low end decoration hacking in short time
[12:11:58] <tzanger> ahh binary code modulation
[12:12:06] <tzanger> http://www.batsocks.co.uk/readme/art_bcm_3.htm
[12:12:13] <tzanger> you just load your pattern and shift it out
[12:12:31] <tzanger> er no
[12:12:36] <tzanger> they're using the bit position for time delay too
[12:12:43] <tzanger> little more complex than I'd mentioned
[12:12:44] <N1njaneer> Basically each slot time is proportionally stretched to the significance of the bit in the value
[12:13:10] <N1njaneer> So a 4 bit BAM/BCM would be: 011222233333333
[12:13:16] <tzanger> yep
[12:13:45] <N1njaneer> You call your interrupts on ascending 2^n intervals, so an 8 bit BAM only requires 8 interrupts, not 256.
[12:14:53] <N1njaneer> The other added benefit is that is effectively produces a spread-spectrum PWM that increases the modulation rate so the flicker is less perceptible. The only major downside is that when crossing 2^n boundaries you will tend to see a bit of a 'pop' if the overall rate is not fast enough, especially passing the 50% mark.
[12:15:02] <tzanger> it actually also helps that guy from yesterday
[12:15:10] <N1njaneer> Yup :)
[12:15:24] <tzanger> he can have an ISR (I wouldn't generate variable ISR or multiple ISR, just yoru 1 bit time ISR) and let it fire
[12:17:57] <N1njaneer> Then you lose the benefits of CPU savings.
[12:18:16] <braincracker> hmm
[12:18:20] <braincracker> interesting idea
[12:19:03] <N1njaneer> It's simple to do in the ISR with a switch statement that handles the bit interval and simply resets the timer to a different value for each bit, so it takes longer before the next ISR fires. The CPU savings are practically exponential.
[12:19:18] <braincracker> so set 8 ocr comparator timing and just pwm out the bits and get 8 int insted of 256
[12:19:32] <FoxGT> Tom_itx! I don't see a signature on this thing!
[12:19:42] <FoxGT> This is a lot smaller than I expected it to be. :|
[12:20:21] <N1njaneer> I've used it for a number of non-critical applications. For all of the critical applications I do PWM in hardware via FPGA or something like TI's LED driver chips, since often times we are driving thousands of LEDs at once that need dimming down to 0.01% without and flicker.
[12:20:24] <N1njaneer> +any
[12:21:23] <N1njaneer> The dimmer you need to run an LED, the harder it gets to do so without flicker/jitter as well as corrected linearity, rather than just falling off to zero immediately. Especially if you need to maintain exceedingly-tight color matching between thousands of LEDs.
[12:21:55] <N1njaneer> But if you DON'T need to do that, software BAM can be a nice alternative to getting reasonable intensity control over LEDs without eating your CPU alive. :)
[12:27:26] <braincracker> N1njaneer<= thanks, cool new approach to sw pwm
[12:33:53] <tzanger> N1njaneer: yes and no
[12:34:11] <tzanger> let's say you've got a 100us ISR and most of that ISR is just IRET
[12:34:30] <braincracker> btw try push-pull driving of your led if you want more correct pwm
[12:34:36] <tzanger> you lose *some* but not much. I bet you'd be hard pressed to need to adjust the ISR rate unless you were really hammering that chip
[12:34:51] <braincracker> leds have capacity, and if you drive leds using open-collector, they will just fade away slowly
[12:35:38] <N1njaneer> Well, it's really application specific depending on your needs. Also worth examining the ISR overhead in the assembler output, as gcc will often wrap the ISRs with a ton of push/pop overhead, etc. if you need to pick up more performance.
[12:35:39] <braincracker> this will introduce errors especially at low values
[12:36:14] <tzanger> I know it's not hard to adjust the timer rate but it may not be necessary, and in fact if you keep it constant you can also do things like monitor a comm bus if you select an appropriate ISR rate that is fast enough to handle the fastest LED time and maybe the 4th or 5th power is fast enough to handle the peridoic background tasks
[12:36:23] <tzanger> like you said though, application dependent
[12:36:27] <N1njaneer> All of our critical applications use constant-current drivers per LED, else you will not get anywhere near reliable color matching.
[12:36:56] <N1njaneer> But again, application specific :)
[12:37:30] <tzanger> that is a really need method, I'll have to store that away for future
[12:38:00] <N1njaneer> All about having the diverse palette of tricks, and knowing when to apply which :)
[12:38:26] <N1njaneer> It's just a useful way to get back a lot of CPU cycles if you have an application that is really maxing out the AVR
[12:38:32] <braincracker> but decreasing current shifts chromaticity
[12:39:12] <N1njaneer> braincracker: Depends on the part you are using, how you are driving it, and your requirements.
[12:40:55] <N1njaneer> The LEDs we use for the critical applications have incredibly tight tolerance with regard to wavelength binning and V/I curve matches, so it's a non-issue.
[12:41:25] <braincracker> super binned led display type ? ;)
[12:41:59] <N1njaneer> Also, as the brightness decreases, the human eye sensitivity to color deltas also decreases. At a certain point you can tell there is "light" but you cannot discern color.
[12:42:20] <braincracker> yeah tried that in dark
[12:42:31] <braincracker> dakr sight is black and white
[12:42:33] <bss36504> N1njaneer definitely knows about lighting/lighting controls
[12:43:24] <N1njaneer> Yeah, the LEDs we use are the tightest color binning avaliable on the market right now. We also bring them in >12,000 at a time to ensure bin-matching, since you can't specifically order one color bin vs another.
[12:43:53] <braincracker> just order some spares for 1280x1024 display and you are ok
[12:43:57] <braincracker> :)
[12:44:37] <N1njaneer> Believe it or not, for the color display manufacturers that need millions of them for large displays, they get around the binning by literally throwing many bins in to a hopper, mixing them, and then taping them back out. It homogenously randomizies the differences throughout the display to significantly lessen the mismatch.
[12:44:43] <N1njaneer> Hey bss!! :D
[12:44:54] <braincracker> ;>
[12:44:56] <N1njaneer> My network stack now has UDP working and responds to pings :D
[12:45:27] <bss36504> well thats getting pretty fancy. I've wanted to learn more about networks, but ain't nobody got time for that.
[12:45:43] <bss36504> Between work and my senior project and classes, I'm totally swamped.
[12:45:49] <ambro718> lwip ftw, and if you want network on an AVR you're crazy anyway
[12:45:55] <N1njaneer> Eh, I've been doing it laying on the couch in the living room while vegging out, and not doing Solidworks :)
[12:46:03] <braincracker> natural randomization, this sounrds a bit like when intel shakes a box full of pins so they fall into the cpu bottom pinholder slots ;)
[12:46:16] <N1njaneer> ambro718: This is on a SAM4E. :)
[12:46:26] <ambro718> good for you :)
[12:46:27] <bss36504> N1njaneer: You're a solidworks guy? I prefer Inventor myself
[12:47:46] <N1njaneer> bss36504: Solidworks seems to be the defacto standard with every other company we work with, and every machine shop we've approached. I tried Inventor, didn't like it nearly as much. But I'm pretty much a novice. I know it well enough to design extrusions and stuff that needs milling :)
[12:48:52] <bss36504> I'm no pro, but I've had a surprisingly fair amount of experience with both, and I just find inventor's layout and general user experience to be more enjoyable. However, I'd agree that most people are solidworks folks.
[12:48:55] <N1njaneer> Again, lets me get my task done quickest of everything I've tried, so I use it. I still pull out Visio for quick dimensioned concepts when I'm working out ideas. Much faster for sketching up thoughts than Solidworks.
[12:49:36] <N1njaneer> Visio is also great for fast concept art for clients when taking a first stab before you want to start committing to serious time in the design :)
[12:50:07] <bss36504> I've never played with visio actually. My school computers dont have it and I dont feel like buying it.
[12:50:49] <N1njaneer> SolidEdge is also really good - a couple of our guys here use it. It's very akin to Visio for doing quick mechanical sketches and stuff, and the 2D version is absolutely free.
[12:52:08] <bss36504> ooh neat. I'll file that away for later.
[12:52:35] <N1njaneer> Yeah, check it out. The 3D version isn't terribly expensive, but I'd rather go Solidworks, again for easy interchange with other peoples.
[12:54:06] <bss36504> What I'd really like to get is Altium, but I doubt my boss will let me justify that.
[12:54:47] <braincracker> how about xilinx ?
[12:54:57] <bss36504> how about them.
[12:55:11] <bss36504> I like the design tools, thats about as far as I made it.
[12:55:11] <braincracker> you wouldn't like to use those?
[12:55:16] <N1njaneer> Love Xilinx to death. I do Spartan stuff semi-regularly.
[12:55:37] <bss36504> I dont mean to imply something bad happened to make me stop, just the project was cancelled.
[12:55:56] <bss36504> I *hate* altera. So there is that.
[12:55:58] <N1njaneer> Annoying that they dropped Spartan2 support out around 10.x I think. And the older versions that support it won't run on Win7. So VM'd Xilinx ISE solves it nicely :)
[12:56:17] <braincracker> the new altera cplds sound fun
[12:56:56] <N1njaneer> Xilinx does have a bad habit of releasing a bit too soon and continually breaking stuff on the first release of any major new series. Generally have to wait for the first service pack to come out before it's worth messing with if you expect to be productive.
[12:57:05] <bss36504> I think their hardware is sound, it's just that Quartus was just such a piece of garbage, I couldn't handle it.
[12:57:33] <braincracker> but currently fpga manufacturers race in who can make the most bloated useless and most expensive software ;)
[12:57:34] <N1njaneer> I think they're trying to overdiversity sometimes. I just stick to Spartan stuff and it all works great. :)
[12:58:20] <N1njaneer> Eh, all the Xilinx tools are completely free unless you are using all but the highest-series parts. And if you can afford a $500+ FPGA, you can afford the toolchain to develop it :)
[12:58:31] <braincracker> nothing is free dude ;)
[12:58:31] <bss36504> I once was doing a lab with Quartus II V.12 Web pack, and literally every time I tried to push a key, it would crash. It did that until I restarted the computer.
[12:58:49] <braincracker> at this time you are not even allowed to live free
[12:59:06] <N1njaneer> brain: That's why I'm not afraid to spend money where necessary :)
[12:59:44] <N1njaneer> If I need to develop something and need commercial support (see Digi Intl) I put a support contract in place with them so I can pick up the phone or email when something is snagging up development. Deadlines are nice motivators.
[12:59:50] <braincracker> my point is, if i can afford a $20 fpga i should afford the sw to develop it :)
[13:00:28] <braincracker> or the other side, if i can afford 10k x $500 fpgas why can't i have my dev sw as a gift?
[13:00:29] <N1njaneer> Well Xilinx ISE is free to download, but you'll want to at least invest in the USB platform cable to efficiently develop with the parts :)
[13:00:56] <N1njaneer> braincracker: If you are buying that much product, you talk to an FAE, and magically stuff starts showing up at your door.
[13:01:22] <bss36504> 10K fpgas sounds like a low volume asic run would be better
[13:01:43] <braincracker> unless you want it reconfigurable
[13:01:48] <N1njaneer> bss36504: Depends on the applications. ASIC's aren't updatable in the field when your customer suddenly needs a new feature.
[13:02:03] <bss36504> I suppose so...
[13:02:17] <bss36504> And so, we have circled back to the old "It depends on the application"
[13:02:58] <braincracker> And devs just love when customer decides he rather wants a completely different function :)
[13:03:17] <N1njaneer> It's why I get upset when people think any single solution is the end-all be-all to everything ever. Such an opinion reveals a lack of experience and healthy dose of naievty :)
[13:04:44] <bss36504> My Control Systems teacher (he's a very experienced PE, designs lots of control systems, worked on the Boeing 777 etc), feels that graphical programming is the end-all be-all for programming. We have some heated debates.
[13:09:31] <N1njaneer> Graphical programming works great for some things, not-so-great for a lot of others.
[13:09:55] <bss36504> Thats just it. He loves labview, but somebody has to make those little blocks work.
[13:11:04] <jerkey> ick
[13:11:08] <N1njaneer> Having spent a number of years writing real-time nodal-based graphical programming stuff, I can say that it's a superior way for tacking certain problems that require effectively 'parallel' tasks that treat datastreams as something to be processed and manipulated (audio, video, graphics shaders, etc) but it suffers the same difficulty that FPGA/VHDL implementations do when you suddenly have the
[13:11:09] <N1njaneer> need for sequential operations, state machines, etc.
[13:11:15] <N1njaneer> +tackling
[13:11:41] <N1njaneer> Highly linear vs highly parallel
[13:12:37] <bss36504> Thats a good point, and once again, we can say that it is application specific. there is never one answer to any open-ended design question.
[13:13:02] <The_Coolest> bss36504
[13:13:08] <The_Coolest> I ended up fixing it
[13:13:20] <bss36504> The_Coolest: oh really? do tell.
[13:13:42] <The_Coolest> the silly bootloader didn't handle the wdt time out correctly
[13:14:02] <bss36504> ah, so it was in there. See, you have absolved yourself of blame :P
[13:14:15] <The_Coolest> lol yeah
[13:14:22] <The_Coolest> but so much time wasted :(
[13:14:38] <N1njaneer> bss36504: Exactly. The best engineers have an entire toolkit of solutions, but more importantly they can identify THE WEAKNESS to any approach just as readily as the strenghs. Those factors guide the descision of which to use.
[13:14:54] <N1njaneer> The_Coolest: But did you learn a bunch in the process of whatever it was you were doing?
[13:15:04] <The_Coolest> but now it's really cool. I can send it a reboot command or a restore defaults + reboot command
[13:15:18] <The_Coolest> I learned a few things
[13:16:03] <N1njaneer> Then it's never time wasted :)
[13:16:18] <The_Coolest> N1njaneer I used arduino for the crude prototyping, and now I've moved to clean C to write the actual firmware. So had to learn how to use PWM, and timers, and stuff like this
[13:16:29] <The_Coolest> Now I know how to use the WDT as well
[13:16:53] <tzanger> N1njaneer: that's why you always instantiate a little MCU in your FPGA... to handle those things. :-)
[13:16:53] <bss36504> theBear: See, there's a legit usage of the Arduino
[13:17:06] <tzanger> I'm working on an FPGA design right now actually
[13:17:22] <tzanger> I *might* get to use that awesome dual ARM core SoC that Altera has
[13:17:41] <bss36504> Does Atmel still make the FPSLIC chips?
[13:17:46] <N1njaneer> tzanger: Exactly, if it's too complicated a task to handle directly with a state machine. Xilinx is doing marvelously with their MicroBlaze and PicoBlaze stuff
[13:17:51] <tzanger> yep
[13:17:57] <tzanger> same with altera and NIOS
[13:18:19] <N1njaneer> And of course if you really want to feel at home, you can synthesize an AVR in there :)
[13:18:20] <tzanger> it's funny, almost all USB controllers have a little 8051 embedded in them to handle the USB state machine
[13:18:46] <tzanger> I'm not at home with AVR assembly, so I don't much care what CPU is embedded for most things
[13:18:58] <N1njaneer> Yes, that baffled me. The 8051 is ubiquitous, but old. That's why I'm glad AVR has the 32U2 and 32U4
[13:19:23] <N1njaneer> Had to deal with that on a TI USB streaming controller recently. Dust off the old 8051 skillz
[13:19:39] <tzanger> for tiny 8-bit processors you can't beat the 8051... if you want to do anything with it though you want a better proc
[13:19:46] <tzanger> 8051 is terrible when it comes to memory access
[13:20:56] * tzanger shrugs... if you're going to go 32-bit, jump to ARM and stop playing with the others
[13:21:14] <N1njaneer> I love the SAM4 series parts :)
[13:21:21] <tzanger> I love the AVRs but at least today the ARM stuff is best
[13:21:24] <tzanger> me too
[13:21:29] <tzanger> I have a SAM4L kit
[13:21:39] <tzanger> also have an STM32F4 kit which is very nice too
[13:22:55] <tzanger> there's always the J1 too, which I wouldn't mind playing with:
http://excamera.com/sphinx/fpga-j1.html
[13:23:01] <tzanger> there are a lot of FORTH processors
[13:25:53] <tzanger> there was a really nice one that 've lost the link to
[13:27:51] <N1njaneer> Can someone help me bury Delphi? It really just needs to go away already.
[13:30:54] <tzanger> http://www.ultratechnology.com/4thvhdl.htm
[13:30:58] <tzanger> there's a little vhdl one
[13:31:28] <N1njaneer> OMG WHY WON'T MY FPGA RUN RUBY-ON-RAILS THIS IS STUPID
[13:33:46] <N1njaneer> bss36504: My next challenge is playing with the DSP blocks in the Spartan6 devices and doing a little MCU'esc state machine to let my effectively create a little programmable DSP processor for dealing with streaming data :)
[13:35:06] <hjohnson> N1njaneer: why not grab one of the simple risc type CPUs from open cores?
[13:35:12] <bss36504> ooh that would be neat. What sort of data do you want to stream through it? I'm not real up on my DSP, that class is next semester.
[13:35:22] <bss36504> (also my last semester, woot!)
[13:35:38] <N1njaneer> Alesis had these BRILLIANT little DSPs (since discontinued) for processing audio data. You literally sent the device a 48Khz wordclock, and 4 stereo pairs in/out (total of 8 channels) and it internally PLL'd the wordclock up x1024, and you effectively got a 1024 instruction "table" that was linearly run for each sample that passed through. Simple, eloquent, worked STUPIDLY well for geometric vector
[13:35:39] <N1njaneer> corrections, which is what I was using it for. And was like $3
[13:36:04] <N1njaneer> hjohnson: For which task?
[13:36:22] <hjohnson> N1njaneer: for what you're talking about
[13:36:30] <hjohnson> no sense in reinventing the wheel
[13:36:46] <N1njaneer> bss36504: This was primarily for adjusting things like gain, offset, slewing, and then vector corrections for things like shear, pincushion, linearity, bow, etc. :)
[13:36:58] <N1njaneer> hjohnson: Do any of those specifically use the Spartan6 DSP blocks?
[13:37:16] <bss36504> That sounds complex, but neat.
[13:37:27] <hjohnson> N1njaneer: I was thinking more for the basic state machine part, rather than the DSP side of things
[13:37:56] <N1njaneer> bss36504: It was stupidly simple in the Alesis parts, as long as you didn't mind wrapping your brain around their rather esoteric instruction set :D
[13:38:28] <N1njaneer> hjohnson: For general CPU stuff, Xilinx already completely supports microblaze and picoblaze in their toolchains :)
[13:38:39] <N1njaneer> hjohnson: I was more specifically speaking of the DSP stuff
[13:43:29] <hjohnson> ahh
[13:44:18] <tzanger> N1njaneer: that's ok, we had a guy in ##fpga want to make a web server in an FPGA, and was unhappy when I asked him to make an led blinker first
[13:44:19] <bss36504> N1njaneer: Oh, I'm sure when you know about DSP, it's not too bad. I just don't know much about DSP other than, you know, that it's digital signal processing.
[13:44:27] <tzanger> he figured it was the ultimate in security
[13:46:13] <N1njaneer> bss36504: Really at the core of everything DSP is the idea of multiple and accumulate operations, doing them fast, and having certain functions like saturated math and barrel shifters and such.
[13:49:55] <N1njaneer> That and efficiently handling stuff like floating point and fixed integer maths. The core operations of most DSP stuff is really pretty minimal, truth be told :)
[13:52:49] <N1njaneer> tzanger: Yeah, gotta learn how to crawl before you plan for world domination :)
[13:52:58] <hjohnson> well, most DSPish stuff is n't done in floating point
[13:53:16] <hjohnson> for most actual signal processing stuff, fixed point/q15 notation is more than adequate.
[13:53:31] <N1njaneer> hjohnson: Depends on what you are doing, and the application, and what you consider to be floating point. :)
[13:54:10] <hjohnson> well, floating point is pretty self explanatory (ie do you have a mantissa end exponent? then it's floating point)
[13:54:20] <N1njaneer> hjohnson: Generally I defer to fixed point for most of what I need, but many higher-end DSPs (such as TI's C6xxx series) handle floating point natively.
[13:54:39] <hjohnson> true
[13:54:57] <hjohnson> then again, the only DSP shit I'm doing these days is stuffing PVDMs into cisco routers, so I should just shut up. ;)
[13:55:10] <N1njaneer> I suppose it's a misnomer in that I usually say "floating point" whenever I express a value with a decimal point in it, but you are absolutely correct about mantissa/exponent.
[13:55:52] <N1njaneer> What's PVDM? It sounds exciting. :D
[13:56:13] <hjohnson> N1njaneer: Packet Voice DSP Module or some shit like that
[13:56:35] <hjohnson> basically its a set of 1-4 TI C5010 DSPs on a SIMM that you stuff into a cisco router to do voice things
[13:56:51] <hjohnson> (G177-G729 transcoding, echo cancellation, conference bridging, etc....
[13:57:38] <N1njaneer> Oh nice :)
[13:57:50] <N1njaneer> Yeah, I could see C5x stuff being well suited to taht.
[13:57:51] <N1njaneer> that
[13:59:17] <hjohnson> I'm in the process of deploying a cisco voip solution... the beauty of old cisco gear is that it's really cheap, and pretty good... doing a 25 phone rollout, with voicemail, VHF radio integration, etc... for about $2500 all in
[14:00:31] <bss36504> I'm looking forward to DSP. Should be a fun time. Oh hey, opinions: I'm going to have my BSEE this spring, and in 2015 my school is starting a MS in Software Engineering. Given my particular inclination to take extra SE classes, the dept head said he would admit me. Should I do it? I plan on doing embedded apps for my career (or at least for the foreseeable future) and I feel like a BSEE+MSSE would be pretty great
[14:00:51] <mike_papa> Is there any way to calibrate internal oscillator without frequency meter or oscilloscope? I just have dragon here, stk-600, some arduinos... I've got to point where 19200 bps on UART gives me about 5 bytes of error every ca 16 kB transmitted just by "trial and error" method.
[14:01:39] <hjohnson> mike_papa: you need to compare it to some frequency standard
[14:01:50] <hjohnson> (well, compare it to something with a known stable/accurate frequency)
[14:01:59] <N1njaneer> bss36504: That sounds like a good plan. That and just do a metric $#ittonne of stuff on your own with projects and things, and you'll be far ahead of most embedded engineers I've run in to. (i.e. feed your passion to the point of technical gluttony, not just a 9-5 engagement!)
[14:02:31] <bss36504> That's how I roll anyway. I read datasheets before bed :P
[14:02:39] <hjohnson> heh, that's what I studied in university... wound up being a field engineer in the satcoms field instead
[14:02:49] <hjohnson> but it's been a hell of a ride... now I need to find my next thing
[14:02:52] <N1njaneer> mike_papa: That may be tricky to do. With higher baudrates it's advisable to just use a super-cheap ceramic resonator, and then it will work 100% of the time, reliably, with zero calibration.
[14:02:57] <mike_papa> hjohnson: I thought about comparing it to frequency given by stk-600. But... thinking is easier than actually doing it. Is there any library for it, or example?
[14:03:15] <hjohnson> (but I'll tell you, being a field engineer was a hell of a lot of fun... )
[14:03:26] <N1njaneer> hjohnson: You were the guy building the GPS/Iridium thing for the boat, right?? :E
[14:03:27] <N1njaneer> :D
[14:03:33] <hjohnson> N1njaneer: yes
[14:03:40] <N1njaneer> How's that project going?? :D
[14:03:44] <hjohnson> that's me keeping my toes into the ahrdware field
[14:03:48] <N1njaneer> I thought your name looked familiar :)
[14:04:03] <mike_papa> N1njaneer: finally I'll do that. But it's hard to get one at 9 o'clock in the evening with whole night on my own ;)
[14:04:06] <hjohnson> N1njaneer: well, givent hat I'mcurrently unemployed, I now have all the time in the world to work on it, and none of the money to actually build it
[14:04:24] <bss36504> And thanks for the support N1njaneer. I enjoy software a lot, but I'd never forgo my hardware knowledge.
[14:04:37] <hjohnson> kinda sad that I'll never get to go back to the sandbox
[14:05:01] <N1njaneer> mike_papa: True enough! Though doesn't the STK-600 have some sort of quartz crystal or something you can use? I admittedly only have an STK-500 here that's been collecting dust for the better part of a decade :)
[14:05:16] <mike_papa> N1njaneer: And what do you mean by higher baudrates? Is 19200 high bit rate?
[14:05:18] <hjohnson> anyhow, I need to get going.. gotta meet up with a guy and start working on this voip project
[14:06:06] <N1njaneer> bss36504: I think embedded is a nice place with a match made in heaven between hardware and software knowledge. Most engineers are suprisingly polarized to extremes of the spectrum - it's the rare individual who covers both overlaps proficiently :)
[14:06:21] <N1njaneer> hjohnson: Cool, keep us up to date on that project. It sounded really cool.
[14:06:45] <mike_papa> N1njaneer: It has one... But I need to code two avr talking to each other. stk-600 has only one quartz. Or should I... just crossed my mind I could use same clock on both chips. atmega can output clock on pin, doesn't it?
[14:07:19] <N1njaneer> mike_papa: It's starting to get up there. The faster the rate, the less tolerate it is to oscillator drift and rate mismatches. The internal oscillator is going to be an additional challenge since it will also vary with temperature.
[14:08:01] <N1njaneer> mike_papa: Yes, you could easily use the CLK_OUT on one (enabled by fuse) to clock in to the second, which you would set to use an external TTL clock via fuse.
[14:08:30] <N1njaneer> mike_papa: You could also skip async and go to something like SPI or I2C where the clock rate differences don't matter
[14:09:37] <N1njaneer> Generally the latter is preferred if you have parts all on one board and aren't concerned about signal transport out in to offboard Big Scary World.
[14:09:52] <N1njaneer> SPI will also let you send far faster than async
[14:10:32] <N1njaneer> Plus SPI already incorporates a framing mechanism, so you don't have to write one in to a higher-level in an asyncronous comm method.
[14:10:33] <tzanger> SPI can go very, very fast indeed
[14:10:55] <N1njaneer> But really at the end of the day it depends on what the overall goal is, and what the requirements are.
[14:11:00] <tzanger> it's also nice and deterministic
[14:11:02] <bss36504> ooh yeah, wicked fast. probably faster than your PCB traces can support (w/out extra design)
[14:12:17] <mike_papa> N1njaneer: that saved my night. :) Well... since final stage of my (more-than-I-can-so-I-need-to-learn-a-lot) vacuum pump controller/half of engine monitor for my Chevelle '71 will have about 1,5 meter long link. In the car. So I'd prefer to use something that can handle those distances. And I don't really care about speed. As I estimate 3000 bytes/s is all I could ever use...
[14:13:16] <bss36504> maybe just dial back the baud rate
[14:15:22] <mike_papa> bss36504: yes. I'll go for 9600 for a moment, and try one clock for both chips. That should make it, at least for the night.
[14:15:38] <mike_papa> Thanks guys.
[14:15:56] <N1njaneer> I'd try using the slowest baud-rate that will work for the application. Worst case if you're still fighting it, add an external resonator or quarz crystal.
[14:16:04] <N1njaneer> No prob, let us know how your project goes. :D
[14:20:04] <bss36504> mike_papa: without looking at the datasheet, I cant say for certain, but some baud rates have more or less error than others based on the clock frequency
[14:21:03] <N1njaneer> bss36504: Also very true, but I've seen the exact issue he's having even at 4800 and 9600 baud. Which then prompted me to never do async without a resonator, since I had to go back and tack on crystals to many, many boards :)
[14:21:51] <bss36504> Oh yeah, I soldered a crystal+caps to a TQFP32 with no available vias. Straight to the legs
[14:22:01] <bss36504> such a pain to get it to hold up
[14:22:19] <N1njaneer> Been there! I share your pain.
[14:28:57] <beaky> i love avr
[14:29:22] <bss36504> oh hello beaky
[14:29:33] <N1njaneer> What else do you love, beaky?
[14:33:52] <Duality> hey
[14:37:20] <Duality> I've got a chip where I set the whole port to output and high, but won turn high, it wil turn high if i do it with a xor
[14:37:32] <Duality> oring bits in to the port doesn work
[14:37:37] <Duality> any ideas ?
[14:39:44] <N1njaneer> code?
[14:40:49] <Duality> http://pastebin.com/0qvNR8GJ
[14:41:11] <Duality> works but using |= instead of ^= doesnt work
[14:41:47] <N1njaneer> Er, use while(1); not a call to main();
[14:42:00] <N1njaneer> You're going to stack overflow instantly and get unpredictable behavior.
[14:42:03] <Duality> N1njaneer: yea I know :) just a test
[14:42:09] <Duality> same result with while(1)
[14:42:31] <jerkey> http://runningahackerspace.tumblr.com/post/68895399385/arduino-user-meets-actual-embedded-programmer
[14:42:46] <N1njaneer> PORTB |= 0xFF; should work just fine.
[14:43:04] <Duality> N1njaneer: doesn
[14:43:10] <Duality> doesnt
[14:43:14] <bss36504> did you try PORTB=0xff?
[14:43:31] <Duality> same result
[14:43:42] <N1njaneer> Something is wrong somewhere, then.
[14:44:03] <Duality> port d doesn work it on either
[14:44:03] <N1njaneer> What is the part, are you use the toolchain is working correctly, any odd options, target processor set correctly, etc?
[14:44:11] <N1njaneer> +sure the
[14:44:38] <Duality> just stoped working out of the blue
[14:44:56] <Duality> I haven touched my compiler or linker or hexifier
[14:45:04] <N1njaneer> I would check your hardware first. There isn't much to go wrong in that code.
[14:45:36] <Duality> nothing wrong with hardware no pins loose just one led connected to the port
[14:45:51] <bss36504> well this is odd.
[14:46:08] <Duality> maybe the chips is just broken
[14:46:23] <N1njaneer> Try code to toggle the LED on and off with a delay to see if you are getting any odd behavior, resets, freezes, etc
[14:46:41] <N1njaneer> Also make sure you aren't tapping overlapped JTAG pins without having disabled JTAG
[14:47:34] <N1njaneer> JTAG-capable AVRs ship with JTAG enabled by default, so those pins are unusable for GPIO until you turn off JTAG via the fuse
[14:47:39] <Duality> I have disabled jtag, but using a different port though
[14:47:45] <N1njaneer> What part?
[14:48:04] <Duality> using port b, jtag is on port D
[14:48:07] <beaky> how do i reenable jtag after i disable it
[14:48:17] <N1njaneer> Set the JTAG fuse
[14:48:22] <Duality> burn fuse for it i thing
[14:48:24] <Duality> think
[14:48:59] <Duality> any other port I try has the same result
[14:49:12] <N1njaneer> Try a different chip. Something is definatly whacked
[14:50:38] <Duality> different chip works
[14:51:36] <N1njaneer> Throw out previous chip. Profit and relaxation!
[14:51:50] <bss36504> Magic
[14:53:22] <Duality> thanks for the help !! :)
[14:55:57] <N1njaneer> Sure :)
[14:57:12] <beaky> how fast is the analog comparator on avr
[14:57:29] <bss36504> 14 clock cycles.
[14:57:35] <bss36504> it says in the datasheet
[14:57:39] <beaky> wow that is fast
[14:57:45] <beaky> (it says that?)
[14:57:48] <bss36504> yes.
[14:57:52] * beaky flips through the datasheet
[14:57:56] <Duality> the datasheet says everything
[14:59:00] <bss36504> in the atmega328 datasheet, in the Prescaling and Conversion Timing Chapter
[14:59:17] <bss36504> 13 clocks*
[14:59:20] <bss36504> "A normal conversion takes 13 ADC clock cycles. The first conversion after the ADC is switched on (ADEN in ADCSRA is set) takes 25 ADC clock cycles in order to initialize the analog circuitry."
[14:59:43] <beaky> oh i meant analog comaprator
[15:00:02] <bss36504> i think that's instant?
[15:00:09] <bss36504> somebody back me up
[15:00:19] <N1njaneer> Beaky, I am going to print you out every AVR datasheet and stick them in to your stocking for Christmas
[15:00:44] <bss36504> But it's a comparator, so I'm pretty sure it would be like a couple clocks at most.
[15:00:58] <beaky> i love comparators they are lightining fast
[15:01:04] <N1njaneer> ... speaking of Santa... Hi Dean!
[15:01:09] <bss36504> nothing is that fast :P
[15:01:23] <beaky> avr is 1 mips per second
[15:01:23] <bss36504> Dean is Santa?! OMGOMGOMG!
[15:01:31] <beaky> 1 mips per mhz*
[15:01:33] <bss36504> avr is 1 mips per mhz
[15:01:43] <bss36504> yes, single clocks per instruction
[15:01:49] <beaky> thats as fast as it gets :D
[15:02:23] <bss36504> but the logic surrounding the analog comparator is not really a lot of sequential actions, so for all intents and purposes, faster than you'll likely be able to sample it, it will refresh.
[15:02:38] <beaky> so i should use an interupt for the analog comparator
[15:03:08] <bss36504> yeah, probably. depends on what you plan to do with the information.
[15:03:32] <beaky> i want to toggle my IO port
[15:03:38] <beaky> i wish togling was single cycle
[15:04:01] <bss36504> well technically the XOR is a single clock, but you have to load registers and such.
[15:04:02] <N1njaneer> It's two cycles. Run your AVR twice as fast. Problem solved.
[15:04:26] <beaky> my attiny can run twice as fast thanks to intenral pll
[15:04:40] <N1njaneer> What else do you love, beaky? We are making a list.
[15:04:48] <N1njaneer> 1> AVR, 2> Fast Comparators
[15:04:56] <N1njaneer> 3> ATTINY?
[15:05:04] <beaky> i love my attiny
[15:05:38] <bss36504> Its interesting how possessive he is. It's always "my attiny" not "attinys"
[15:05:46] <bss36504> Maybe his is special.
[15:05:46] <bss36504> \
[15:06:16] <bss36504> beaky: PLL or not, you still can only go to 20Mhz
[15:06:27] <N1njaneer> Well, ATTINY is generally less maintenance than a cat.
[15:06:33] <bss36504> which is super fast for toggling a bunch of pins.
[15:06:42] <bss36504> N1njaneer: very true.
[15:06:48] <N1njaneer> bss36504: LOL "bunch of pins" and "attiny"
[15:07:04] <beaky> yeah attiny has only 6 pins (5 with RESET enabled)
[15:07:18] <beaky> attiny85
[15:07:18] <bss36504> oh right. beaky, why not just use some discrete logic chips or an op amp or something?
[15:07:41] <beaky> is 74hc faster than avr?
[15:08:03] <bss36504> maybe AHC. thats the fastest speed of the 7400 chips.
[15:08:08] <bss36504> how fast do you need?
[15:08:11] <bss36504> specifically.
[15:08:19] <N1njaneer> Unless it's an ATTINY48/88 or so, which can have 28 pins :)
[15:08:20] <beaky> above 1Mhz for my smps
[15:08:30] <bss36504> good lord, you have plenty of speed.
[15:08:34] <N1njaneer> bss36504: Beaky needs infinite speed.
[15:08:34] <jerkey> i think it depends on what 74HC part you're talking about, some of them have more propogation internally. but they can all do 10MHz at least
[15:08:45] <bss36504> stop worrying about a couple clock cycles.
[15:09:00] <jerkey> i used to use 74AC parts in FM transmitters at up to 110 MHz
[15:09:03] <bss36504> jerkey: absolutely, but AHC is the fastest speed grade, HC is slightly slower.
[15:09:20] <N1njaneer> beaky: You should overclock your ATTINY by LN2 cooling it.
[15:09:32] <beaky> nah that is overkill
[15:09:55] <jerkey> beaky i fully support your over-the-top power supply design but only if you open-source it and make it buildable by a novice
[15:10:11] <bss36504> no way, all the amateurs are doing LN2 cooling
[15:10:38] <N1njaneer> I fully support using an off-the-shelf DC/DC converter which requires a coil, diode, cap, and a couple resistors. Done.
[15:10:47] <beaky> btw when i power on an avr, is all its peripherals on or do i need to turn off lots of stuff to save power?
[15:11:12] <N1njaneer> You should put it in to deep sleep mode to save the most power.
[15:11:32] <N1njaneer> Upload nyquil.hex via the serial port.
[15:12:01] <bss36504> oh and btw, beaky, if youre using the Analog comparator to try and closed-loop control your smps, your transient response will be really sloppy. you probably want to use the a2d and do some simple control algorithms.
[15:12:08] <N1njaneer> Because Nyquil is the coughing-sneezing-aching-how-the-hell-did-I-wind-up-on-the-kitchen-floor medicine. (for those in the US familiar with those commercials)
[15:12:27] <bss36504> hehe
[15:12:40] <bss36504> and beaky, about default states, read the datasheet.
[15:12:58] <bss36504> if you love the tiny as much as you say, you'd do well to literally read every word, cover to cover.
[15:13:30] <N1njaneer> And memorize the instruction set, so you can win big on the AVR Gameshow.
[15:13:54] <beaky> wont the a2d be slower than the comparator
[15:13:59] <beaky> for smps control
[15:15:33] <bss36504> yes, but with the comparator you have very little information to use. Voltage too high, reduce duty. Voltage too low, increase duty. Well, if you have no hysteresis, you'll bounce between two PWM values an awful lot. You'd do better to do regular samples off the output with the ADC and develop a formula that correlates the voltage out (of the SMPS) to the duty of the PWM.
[15:15:52] <bss36504> duty=ADC_VALUE*SOME_GAIN
[15:16:37] <bss36504> do you see what I mean? You can compensate for the slowness (even though it's really not that slow) by putting a cap on the output of the smps, which you should have anyway.
[15:16:40] <N1njaneer> PID loop, baby :)
[15:16:50] <beaky> yeah i have a huge cap
[15:16:52] <bss36504> basically, but I didn't want to slam him with PID.
[15:17:00] <bss36504> figured straight P would be fine for this.
[15:24:58] <bss36504> alright, I;m out for a bit. ttyl guys.
[15:25:47] <beaky> how do i wake up from deep sleep
[15:27:34] <N1njaneer> beaky: Usually with an interrupt
[15:29:21] <megal0maniac_afk> Beaglebone Black, Cubieboard/Marsboard, or one of those TV dongles?
[15:29:47] <beaky> will a uart_rxc_interrupt work to wake my avr up
[15:29:57] <megal0maniac_afk> beaky: Datasheet
[15:30:01] <N1njaneer> beaky: Read the datasheet
[15:30:50] <N1njaneer> Alternatively you can call the front desk, and they will send your AVR a wake-up call
[15:34:23] <OndraSter> why don't people read datasheets..
[15:34:36] <N1njaneer> Because it's too much work.
[15:35:52] <tzanger> beaky: you have to answer a few other questions before you an answer that one
[15:36:00] <tzanger> and reading the datasheet isn't always straightforward
[15:36:37] <tzanger> 1) what do you mean by "wake up" - how "asleep" is your AVR? There are different levels of sleep and each has tradeoffs.
[15:37:04] <tzanger> 2) Does the UART hardware receive power/clock in the sleep mode you've selected?
[15:37:19] <beaky> i want my avr to idle with all peripherals off except timer0 and uart
[15:37:36] <tzanger> beaky: well, consult the datasheet to see what you can do
[15:38:09] <tzanger> I want my AVR to execute an infinite loop in under 500ms but so far I've been unable to do so
[15:39:24] <jerkey> i went through the datasheet one time with the aim of understanding all the timer shit very well, and so i took notes. the page numbers refer to the atmega168/328 PDF
http://spaz.org/~jake/TIMERS-ATMEGA168.txt
[15:39:29] <N1njaneer> tzanger: Use -O999
[15:39:58] <tzanger> heh
[15:40:02] <beaky> why are they called timers when they are actually counters
[15:40:09] <tzanger> -Oso_fast -Omuch_speed -Ozoom
[15:40:12] <N1njaneer> Be careful not to rip space-time in the process, though
[15:40:30] <tzanger> er sorry, those options only exist with -mdoge
[15:43:08] <megal0maniac_afk> tzanger: Typically, answering a question with another question (like what kind of sleep) will result in no response at all, or another totally unrelated question
[15:43:49] <tzanger> hat's ok
[15:44:11] <megal0maniac_afk> Which is why "datasheet" is often the better answer for beaky, because getting more information out of him is annoyingly painful
[15:44:16] <tzanger> I feel it is up to me to encourage them to think and, failing that, hope they trundle off
[15:44:30] <N1njaneer> megal0maniac_afk: RTFB? :D
[15:44:33] <tzanger> oh I wasn't going to use the info he gave me. the answers were for himself :-)
[15:45:07] <tzanger> ie. "what's my sleep mode" "oh, the ioclk is stopped for that, so there's no way rxd can wake me"
[15:45:41] <tzanger> then I say "ahh yes, young grasshopper, but you can connect the RXD signal to the RXD pin *and* the EXTINT pin, and use EXTINT to wake you"
[15:45:48] <tzanger> and watch them goggle at the idea ;-)
[15:46:01] <megal0maniac_afk> tzanger: Yeah, but he's already forgotten the question by then.
[15:46:10] <megal0maniac_afk> And that's a clever idea. I'm going to use that :)
[15:46:32] <tzanger> CSRs chips had a really nice feature where if you told them you were going to sleep, they would send a BREAK before starting/resuming the BCSP session so you could get your bearings before the first data byte came in
[15:46:56] <tzanger> megal0maniac_afk: again.. that's ok. it's about the journey. :)
[15:48:14] <megal0maniac_afk> I suppose
[15:48:39] <jerkey> attention: here is helpful info for dealing with the timers:
http://spaz.org/~jake/TIMERS-ATMEGA168.txt
[23:38:07] <Dagger2> er
[23:38:07] <Dagger2> ...whoops, wrong window