Back
[00:57:27] <Deskwizard> quick question... lets say I have 3 functions sharing almost the same code, should I combine them in one, or have them separate ?
[00:58:06] <Deskwizard> and as a follow up, will the compiler figure it out like a big boy and end up having bigger instead of smaller code?
[01:03:16] <Casper> 3 identical function result in 3 times the code
[01:04:24] <Deskwizard> mkay, follow up then
[01:04:47] <Deskwizard> which is faster if I have 3 "choices", Ifs or switch?
[01:06:16] <Casper> for 3, if may be faster
[01:06:25] <Casper> it tend to generate less code
[01:06:42] <Deskwizard> aight, thank you very much Casper
[01:06:52] <Deskwizard> appreciated a lot
[01:19:09] <Deskwizard> Casper: saved 20 bytes, ty :)
[01:19:19] <Haohmaru> can a serial-to-uart converter (one that uses ft232) be used with a parallel port instead of a serial port?
[01:20:01] <Casper> pp and serial is very different, different converter must be used
[01:20:20] <Haohmaru> crap ;]
[05:34:40] <Lambda_Aurigae> Haohmaru, there are usb-parallel adapters but they don't really work like a regular parallel port..not nearly the configurability and functionality. I just acquired half a dozen of them.
[05:38:10] <nuxil> i was woundering. would it be possible for a atiny85 react to sound in a room. im do not mean the amount of sound. (db). i mean like. is it possible to make it trigger stuff at frequenses ? lets say i play a tone on my guitar. E. 82.41 Hz and then a octave E * 2 ? but will not trigger "Code" on 83 Hz. ??
[05:39:44] <Lambda_Aurigae> hmmm.
[05:39:48] <Lambda_Aurigae> yes, it could be done.
[05:40:01] <nuxil> ideas how. ?
[05:40:13] <Lambda_Aurigae> well,,,back in the day we did it without microcontrollers
[05:40:20] <Lambda_Aurigae> band pass filter and an opamp
[05:40:38] <Lambda_Aurigae> used that to make remote controls out of my walkie talkies.
[05:40:50] <nuxil> :)
[05:41:07] <Lambda_Aurigae> multiple buttons for multiple resistors to feed a 555 timer and feed that into the walkie transmitter.
[05:41:27] <nuxil> :D
[05:41:36] <nuxil> the legendart 555 :)
[05:41:45] <Lambda_Aurigae> other end had several band pass filters,,,LC circuits,,,hooked to several op-amps which fed circuits to turn on transistors to drive motors.
[05:41:58] <Lambda_Aurigae> 555 rocks.
[05:42:01] <nuxil> *Legendary
[05:42:28] <Lambda_Aurigae> in theory you could also do band-pass in software.
[05:42:45] <Lambda_Aurigae> I can imagine a way to do it but would have to work at it.
[05:43:14] <nuxil> hmm
[05:44:06] <Lambda_Aurigae> but a hardware bandpass filter for 80ish Hz,,,,that's gonna be humongroulous.
[05:45:07] <Lambda_Aurigae> somewhere in the area of 20F caps?
[05:45:11] <nuxil> so if i use a high speed timer or something and do some sort of compare of the signal knowing that freqN = somecycles / something ? lol.. no idea where to start on this
[05:45:18] <Lambda_Aurigae> or my math-fu is really bad this morning.
[05:45:33] <Lambda_Aurigae> think PLL.
[05:45:57] <Lambda_Aurigae> you can tune a PLL, hardware or software version, to sync to a specific frequency.
[05:47:29] <Lambda_Aurigae> look up digital pass filter on avr
[05:48:05] <nuxil> found a pdf
[05:48:26] <nuxil> AVR223: Digital Filters with AVR
[05:50:24] <nuxil> omg.
[05:50:32] <Lambda_Aurigae> math
[05:50:39] <nuxil> Equation 1: General Difference Equation for Digital Filters.
[05:50:55] <Lambda_Aurigae> http://www.atmel.com/Images/AVR223.zip
[05:50:56] <nuxil> im not even gonna post that formular here
[05:50:58] <nuxil> :p
[05:51:00] <Lambda_Aurigae> the software to go with that.
[05:51:51] <nuxil> i never seen these knind of symobls used in the formular before :p
[05:51:58] <Lambda_Aurigae> it's calculus
[05:55:01] <nuxil> IIR2.c
[05:55:11] <nuxil> why do it got this at the end of the main
[05:55:12] <nuxil> // Do nothing..
[05:55:12] <nuxil> for(;;){ }
[05:55:24] <nuxil> isnt that really bad
[05:56:02] <x29a> so main wont stop
[05:56:13] <mrx1_> nuxil: nope, infinite loop in main is normal in embedded systems
[05:56:14] <x29a> i assume the other operation is interrupt driven or something
[05:56:39] <nuxil> ok
[05:58:01] <nuxil> this is going to be hard :p
[06:00:18] <nuxil> why do you want main to do nothing after it has done its tasks ? it is because some isr(blah) can make it do other stuff. or even the watchdog in some cases?
[06:01:05] <nuxil> or i dont really get why you would want main to run when it has done its stuff, if its not required to do more why have it running.
[06:03:07] <nuxil> never mind.. after thinking.. in somecases you might what you want after all. :p init some ports to some state, and leave them as that :p
[06:04:34] <Lambda_Aurigae> you want main to stop in a loop,,otherwise if it just ends, the chip might continue processing through memory and do all kinds of random things.
[06:04:47] <Lambda_Aurigae> it's not like on a PC where, when main ends it returns to the OS.
[06:05:26] <mrx1_> exactly.
[06:05:49] <Lambda_Aurigae> then do a while(1); at the end just to have the chip not go off on a wile hare.
[06:05:51] <Lambda_Aurigae> wild
[06:06:38] <Lambda_Aurigae> on a microcontroller you do not want your main() to ever terminate....you loose the grue that way.
[06:07:38] <nuxil> thanks :)
[06:09:33] <Lambda_Aurigae> and, as anyone who has ever seen the grue will tell you, it's not a good thing.....but,,,if you see the grue you won't survive to tell about it,,,,so,,,
[06:10:25] <nuxil> right ;)
[06:34:20] <nuxil> oh well screw that idea. since the input isnt constant(freq & volt vary). ie. it may be times when the voltage of 82hz is the same as 84hz at a lower db or other frequenses, i think it be hard to do this using the tiny85 :/
[06:39:27] <Lambda_Aurigae> you want more of a dsp type chip for doing that kind of work
[06:39:35] <nuxil> i was thinking. the atiny85 have just enuf pins to make a quitar tuner :p
[06:39:36] <Lambda_Aurigae> but if that's all the chip is doing, an attiny85 could do it.
[06:39:56] <Lambda_Aurigae> oh...you just want a frequency counter then?
[06:40:06] <nuxil> yea in a way
[06:40:28] <Lambda_Aurigae> avr205
[06:40:32] <nuxil> like when its at 82. hz put pb0 high
[06:40:59] <Lambda_Aurigae> done with an attiny13a in the document
[06:42:47] <nuxil> was thinking something along the lines of. E = (both) on pb0, A on Pb1, D on PB4, G on PB3 and B on PB5. making it no more writeble too :p
[06:43:00] <nuxil> and using led to light up
[06:43:14] <Lambda_Aurigae> you mean using the reset as an i/o pin?
[06:43:27] <nuxil> yea. but that has to be done last. :p
[06:43:29] <Lambda_Aurigae> it's still writeable, you just have to have a high voltage serial programmer to do it.
[06:43:41] <Lambda_Aurigae> or a fusedoctor to reset it.
[06:43:50] <nuxil> can mess around with it during testing :p unless you got like tonz of them :p
[06:44:07] <nuxil> i dont have one.
[06:44:08] <Lambda_Aurigae> just build a fusedoctor
[06:44:33] <Lambda_Aurigae> http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en
[06:44:40] <nuxil> i only have a write i made myself. hooked it up to my raspberrys gpio ports
[06:44:47] <Lambda_Aurigae> http://www.instructables.com/id/AVR-Attiny-fusebit-doctor-HVSP/
[06:45:30] <Lambda_Aurigae> first one does atmega and attiny
[06:45:38] <Lambda_Aurigae> second one only does a subset of the attiny chips.
[06:46:50] <nuxil> nice
[06:47:20] <Lambda_Aurigae> good for fixing fuxed up fuses...or resetting the fuses on a chip when you turn off the reset pin.
[06:47:41] <Lambda_Aurigae> someone in here was making a HVSP board too...don't remember who it was.
[06:47:48] <Lambda_Aurigae> think he was going to sell them though.
[06:48:14] <nuxil> what does hv mean ?
[06:48:21] <Lambda_Aurigae> high voltage
[06:48:31] <Lambda_Aurigae> you feed 12V to the reset pin and do programming
[06:48:41] <Lambda_Aurigae> like the original pic chips did.
[06:49:00] <Lambda_Aurigae> and still do, but it's generally not needed on pic these days.
[06:49:04] <nuxil> umm. 12v isnt what i think of as high voltage :p but ok :)
[06:49:57] <Lambda_Aurigae> compared to normal programming at 3.3V or 5V, yes, it is.
[06:50:00] <Lambda_Aurigae> read your datasheet
[06:50:03] <Lambda_Aurigae> it's all in there.
[06:50:08] <Lambda_Aurigae> explained in gory detail.
[10:03:01] <Jartza> yea. I made me high voltage tpi programmer with st662a -chip
[10:03:07] <Jartza> just connected reset-line through it
[14:26:38] <ub|k> i am experiencing a weird phenomenon. i'm using PWM on OC1A, connected to a small speaker. i can play musical notes and it's mostly working fine
[14:27:01] <ub|k> but sometimes the speaker buzzes without apparent reason. even after setting OCR1A = 0
[14:29:02] <cehteh> likely some bug in your code
[14:31:12] <cehteh> speaker directly on a output might be a bit much to drive too
[14:40:57] <Martin90> I would like to put small linux on stm uC and my question is which linux and on which uC do you recommend ?
[14:41:05] <Martin90> or AVR
[14:45:53] <ub|k> cehteh: works pretty fine so far
[14:45:59] <ub|k> apart from the buzzing
[14:46:14] <ub|k> it's a pretty small speaker
[14:46:46] <ub|k> http://uk.farnell.com/kingstate/kssg2308/speaker-micro-pin-easy-mt-88db/dp/2215102
[14:50:58] <ub|k> maybe i shouldn't be disabling it by setting OCR1A to 0
[14:59:03] <cehteh> ub|k: when you want silence you possibly want to stop the timer and turn the output off
[14:59:13] <Krampus> Any ideas on what might be causing my AVR's spi controller (not the USART in spi-mode) to be adding a glitch 'spike' to the end of every byte sent?
[14:59:27] <Krampus> it's completely within a clock transition, but I think it's pissing my endpoint off. :)
[15:00:33] <cehteh> i'd guess going to sleep and/or turning the SPI off, but dunno
[15:01:40] <Krampus> Doesn't look like that's the case. I was thinking one of the other threads was diddling with the port, but that doesn't look to be the case. Also, I'm having the code wait on the xmit complete rather than tasking out and waiting for an interrupt, so I don't think that's the case.
[15:02:20] <Krampus> and I'm pretty sure I'm not drawing more than the regulator can supply... but pretty sure isn't totally sure, so maybe I'd best probe for voltage rail drooping.
[15:02:30] <cehteh> Martin90:
http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit :D
[15:02:40] <Martin90> thanks
[15:04:46] <Krampus> nope, rock solid 5.12V.
[15:05:09] <Casper> Martin90: linux do not belong on AVR, it belong to ARM
[15:05:32] <Casper> same goes for most microcontroller
[15:05:34] <Martin90> Casper, why ?
[15:05:43] <Krampus> Martin90: Some crazy person did that. It was impressively useless.
[15:05:51] <cehteh> see the link i gave
[15:06:19] <Casper> too little ressources
[15:06:29] <cehteh> acr's are slow 8 bit microcontrollers without a mmu
[15:06:33] <cehteh> avrs
[15:06:47] <Krampus> cehteh: Yep! That one. "I need instructions from ARM, but I'm on AVR. What can I do? Let's EMULATE it!"
[15:07:51] <cehteh> dunno if some biggier STM32 can run linux, maybe there is a port, but thats really not a good target
[15:08:03] <cehteh> if you want a linux get a raspberry pi
[15:08:34] * Krampus is impressed that someone did such a thing though.
[17:24:23] <jben> good news
[17:24:37] <jben> programming xmega works fine now
[17:24:39] <jben> shame on me
[17:24:46] <Tom_itx> hah
[17:25:46] <jben> it was the first time I made a PCB with SMD, I did'nt notice the xmega had *tho* circle on corners
[17:26:13] <jben> But one is *not* the pin 1 label
[17:26:20] <jben> shame on me, again
[17:27:17] <LeoNerd> Oopsie
[17:27:21] <jben> thank you for all your advice, it was only me who was a prat
[17:27:23] <LeoNerd> Yeah those pin1 markers
[17:28:21] <jben> my (design by myself) pcb works, and the first try to program works
[17:28:54] <jben> I have done the electronics "hello word" (a.k.a. blinking a led)
[17:29:26] <LeoNerd> Nice :)
[17:29:37] <jben> fun fact, I have a lot of stuff, but I did'nt have a normal led (not a smd one)
[17:29:41] <LeoNerd> I think I still have a photo of my first blinky-LED ATtiny board
[17:30:08] <jben> I did'nt use a led, but my oscilloscope
[17:30:37] <LeoNerd> I usually use my scope just for analog stuff... Saleae (clone) for digital
[17:30:39] <LeoNerd> 8 channels :)
[17:31:34] <jben> I don't have digital analyzer, so I do all with my scope
[17:32:14] <jben> (but it has some stadart function usefull for digital stuff, like analyze UART, I2C...)
[17:32:45] <LeoNerd> Eh... those are still fairly rubish in my opinion
[17:32:57] <LeoNerd> On a really good day I can get my Rigol to decode bytes of SPI or I²C and print numbers
[17:33:22] <LeoNerd> Running Sigrok against my saleae clone, it decodes SPI and I²C bytes, and register names of chips I have connected, and bitfields, and... allsorts
[17:33:51] <Deskwizard> my saleae clone is one of the best purchases I ever made, love the thing
[17:33:59] <LeoNerd> Yah it's nice
[17:34:13] <Krampus> I have a real Saleae mixed signal. Awesome piece of kit, but the software needs work. How are the knock-offs?
[17:34:15] <LeoNerd> Admittedly a /real/ saleae might be nicer still, but that's like.. $300 vs $20 or so for this clone
[17:34:24] <Deskwizard> can be a bit dicky, but once you know...
[17:34:27] <LeoNerd> Ah, dunno about mixed signal,.. my clone is purely digital
[17:34:27] * Krampus didn't pay for it.
[17:34:39] <Deskwizard> yeah, if I wasnt broke Id get the real thing for sure
[17:34:44] <LeoNerd> One reason I like Sigrok - it understands both the saleae and the rigol scope
[17:34:50] <LeoNerd> So I can display both types of signals together :)
[17:35:12] <Deskwizard> Sigrok?
[17:35:16] <Krampus> The mixed signal one saved me a day of debug time since I was able to see a runty signal.
[17:35:26] <LeoNerd> opensource software project, for doing analysis of logic probes, scopes, that kind of thing
[17:35:33] <Deskwizard> I gotta lool into that :) ty man
[17:35:53] <Deskwizard> oh man, I have like 1000 new ideas..
[17:36:00] <Deskwizard> not helping :| lol
[17:36:01] <LeoNerd> :)
[17:36:06] <LeoNerd> Yeah.. I have that trouble
[17:36:18] <LeoNerd> I just got myself an ATmega128A devboard and a 8x8 LED matrix in the post the other day...
[17:36:24] <LeoNerd> I have work to do, but this look shiny..
[17:36:32] <Deskwizard> lmao so very true
[17:36:53] <jben> oh, my rigol si supported by sigrok
[17:36:59] <jben> s/si/is/
[17:36:59] <LeoNerd> Should be.. most are
[17:37:03] <Deskwizard> I got my RFID reader like a week ago, im stumped I havent openned it yet, but I want to finish this damn code reference thing first
[17:37:10] <LeoNerd> The 1054Z definitely is, because that's the one I use
[17:37:18] <jben> LeoNerd: same
[17:37:20] <LeoNerd> :)
[17:37:27] <Deskwizard> moving out of the arduino stuff turns out to be a bit more teadious than I expected
[17:37:36] <jben> LeoNerd: cheap and nice scope
[17:37:39] <LeoNerd> Though you do have to firmware update it, the older firmware has a USBTMC bug in it
[17:37:53] <LeoNerd> Deskwizard: Eh... I find it's actually easier, aside from USB
[17:38:12] <jben> LeoNerd: oh shit, updating firmeware can be done on Linux ?
[17:38:15] <LeoNerd> I've been growing myself a nice collection of little libraries and stuff...
[17:38:32] <LeoNerd> jben: It doesn't involve the PC. You put the new firmware image on a USB key, and stick that in the front
[17:38:36] <LeoNerd> Then there's a menu option for it
[17:38:42] <Deskwizard> LeoNerd: yeah precisely what I am doing atm, I just knew a lot less about C than I thought hehe
[17:38:44] <LeoNerd> Suuuuper easy
[17:38:44] <jben> oh, right, nice
[17:39:01] <N1njaneer> Mmm, RFID. I have a board on my desk that I've designed that uses TI's TRF7970A for that stuff. Works like a champ. :D
[17:39:09] <jben> I hate device which need a PC (on windows) to be updated
[17:39:15] <LeoNerd> Yah
[17:39:16] <Deskwizard> im with jben
[17:39:42] <LeoNerd> I've been looking at laser printers lately, too. There's lots of cheap home-targeted network capable printers, that *work* fine without a network but need a (Windows) PC to configure networking initially
[17:39:45] <LeoNerd> Which is silly
[17:39:58] <jben> today I updated my avrispmkii, I had to use atmel studio and boot on windows, I don't have one. I use my lab comupter.
[17:39:59] <LeoNerd> Er.. work fine without a PC, even
[17:40:17] <Deskwizard> and this is why a VM is useful
[17:40:54] <jben> Deskwizard: I don't have a licence or a windows image
[17:41:08] <Deskwizard> jben: if you pm me I can give you a .. trick ;)
[17:41:34] <jben> but my lab computer have a double boot, I had never use windows on this, except this morning
[17:41:34] <Deskwizard> legally activated windows 10 straight from ms
[17:42:30] <jben> Deskwizard: I don't need. Ok, I have used my work computer, I should'nt do that, but I prefer that.
[17:42:48] <Deskwizard> np :)
[17:42:52] <jben> thanks anyway
[17:43:32] <Deskwizard> yeah I get the point, having to boot windows to update a programmer is a bit ridiculous
[17:43:50] <flyback> <flyback> aoyue 2930 vs hakko fx-888
[17:43:58] * flyback bites rue_*.*
[17:44:46] <flyback> normally i would only consider the hakko but some people have kinda convinced me this model isn't a cheap knockoff
[17:45:25] <Deskwizard> flyback: can you get the tips for both locally ?
[17:45:58] <Deskwizard> its always my first question when buying an iron, if I'm screwed, can I get a tip NOW
[17:45:59] <Deskwizard> hehe
[17:46:05] <flyback> well the same place I got my aoyue 968 v0 (not the A which has a sufficient 70w digital iron) for $12 each
[17:46:16] <flyback> I can't get any tips locally anywyas
[17:46:21] <Deskwizard> oh okay
[17:46:41] <flyback> it does use integrated heater tips :/ but this guy says it's worth it
[17:56:47] <studdentt>
[17:58:39] <N1njaneer> Flyback: I have been using PACE stuff here exclusively for 15 years. It's a bit pricier but it will last like nothing else!
[17:58:55] <N1njaneer> And spare parts readily avaliable for nearly everything in the systems
[17:59:03] <flyback> yeah well i'm not going to be able to buy pace with a $100 gift card i got for doing data recovery work
[17:59:29] <N1njaneer> Needing hot-air rework stuff, then?
[18:00:09] <N1njaneer> Depending on what you are doing, a $20 heat-gun also works if you're very careful :)
[18:00:28] <flyback> no my aoyue 968 classic is still strong for hot air
[18:00:35] <LeoNerd> My heatgun is greeeeat
[18:00:42] <LeoNerd> I have the 858D that eeeveryone has
[18:00:46] <LeoNerd> I believe Dave has the same one
[18:00:48] <flyback> but the 35w iron was too weak, the sparkfun 50w is having problem and not buying another $15 wand for a $40 iron
[18:01:02] <flyback> I am going to replace the heater in it withone from a 968A
[18:01:07] <flyback> cause it's a better hot air core
[18:01:11] <flyback> $15
[18:01:18] <flyback> it's 5+ yrs old so getting about due anywyas
[18:01:57] <N1njaneer> I love Pace's WJS-100. Goes from room-temp to ready in 12 seconds!
[18:02:26] <N1njaneer> The tips are also integrated assembly that is tip-heater-thermocouple and they're usually less than $10/ea. Hot-swappable, too.
[18:02:28] <flyback> I doubt doubt it's worth every penny
[18:02:34] <flyback> just not in my reality right now
[18:02:40] <flyback> don't doubt
[18:02:46] <N1njaneer> I've had other irons they charge you like $7 for just a metal tip :)
[18:03:22] <flyback> LeoNerd, I tore the solder sucker off my 968
[18:03:33] <N1njaneer> Well, if you are expecting to do a lot of soldering in the future, I urge people to consider spending a bit more. The quality of work and lack of frustration makes it worth if it you are doing it regularly. :)
[18:03:34] <flyback> to me sucking in hot vapor thru the pump sounded like bad idea
[18:03:43] <flyback> I might make a inner-cooler for vac
[18:03:50] <N1njaneer> A good iron is one of the few things I always suggest people not cheap out on where possible :)
[18:03:55] <flyback> no this is just hobby use
[18:04:00] <flyback> occasional repair of something
[18:04:06] <flyback> like recapping some lcd monitors for myself
[18:04:42] <N1njaneer> flyback: Actually there are a LOT of nice Pace irons used on eBay for well under $100
[18:05:02] <LeoNerd> I recapped my 1980s TTi bench PSU a month or so ago
[18:05:15] <LeoNerd> ... and replaced the front panel switches. and pots.
[18:05:19] <LeoNerd> ... and recalibrated it
[18:05:26] <LeoNerd> But it's still the same PSU, honest. :)
[18:16:25] <N1njaneer> LeoNerd: Are you turning it in to the Ship Of Theseus?
[18:17:24] <LeoNerd> Mmmm... maybe if I have to replace the FETs someday
[18:22:31] <Lambda_Aurigae> for those into the atmega328,
http://www.atmel.com/devices/atmega328pb.aspx?tab=overview
[18:22:47] <LeoNerd> Yup.. the PB
[18:23:11] <LeoNerd> Two SPIs, two I²Cs, two UARTs, five-count-them-seriously-five timers...
[18:23:28] <LeoNerd> Still only one ADC. Still no DAC. Still no crossbar or reassignable peripheral pins of any kind
[18:24:14] <Lambda_Aurigae> it says it's the first to include the qtouch controller.
[18:24:22] <Lambda_Aurigae> but I've used qtouch stuff on other AVR chip.
[18:24:44] <LeoNerd> It has dedicated hardware
[18:24:49] <LeoNerd> The datasheet doesn't explain it though
[18:24:49] <Lambda_Aurigae> guess it's somenew hardware for it.
[18:24:52] <LeoNerd> I dislike it
[18:25:01] <Lambda_Aurigae> no,,you have to use the qtouch library which isn't open source.
[18:25:04] <LeoNerd> They've gone all weird. They say you can use their library...
[18:25:05] <LeoNerd> meh.
[18:25:11] <Lambda_Aurigae> I like pic's touch sensor better.
[19:14:05] <Deskwizard> *sigh* any of you know of any good IR receiving code that aint blocking... I'm trying to convert some blocking polling code to interrupt based but I'm doing something wrong...
[19:14:10] <Deskwizard> as usual hehehe
[19:17:02] <N1njaneer> Any UART reception code will work.
[19:17:39] <N1njaneer> Lots of examples of serial reception using interrupts on AVR out there :)
[19:17:48] <Deskwizard> O.O
[19:17:58] <Deskwizard> I even have that already
[19:18:00] <N1njaneer> I have also done IR reception through a soft UART as well using interrupts.
[19:18:06] <N1njaneer> No real difference.
[19:18:17] <N1njaneer> What is the challenge you are having?
[19:19:03] <Deskwizard> N1njaneer: trying to convert a 0-32 loop to the interrupt, theres probably something I missed along the way
[19:19:43] <Deskwizard> somehow it comes out with random values and dont update when its supposed too, could be various things tbh
[19:20:24] <Deskwizard> I got part of it working, ie. protocol detection, but it effs up at reading the data
[19:21:29] <N1njaneer> Well, suggestions -- keep sending the same data at it over and over and see if you are getting the same or approximately the same (wrong) reception.
[19:22:03] <N1njaneer> If you ARE, then start comparing that to the data you are EXPECTING to see, and try to figure out if it's just single bit errors, missing bytes, misframed bytes, etc.
[19:22:54] <N1njaneer> That will help lead you to what is going wrong in the code. Is the code not servicing the UART RX register fast enough and dropping bytes? Are you having issues detecting start of framing? etc
[19:24:05] <Deskwizard> just making sure I understood what I read correctly, interrupts are disabled when entering and ISR and re-enabled once you exit, right?
[19:24:38] <Deskwizard> but yeah, honestly, if you say I can use UART code for that, I honestly wont bother and use that instead, or some variation of it anyway
[19:24:57] <Deskwizard> it'll keep me from going in circles for hours
[19:27:05] <Deskwizard> I tried various incarnation of various IR codes, most of them working in some way, all of them also flawed in some way... latest I found seemed easy eough to understand so I figured id convert that
[19:27:12] <Deskwizard> and you know the rest...
[19:30:13] <Deskwizard> N1njaneer: thx for the pointers, I'll go bang my head a little more :)
[19:41:44] <N1njaneer> Deskwizard: Sorry, occasionally idle here.
[19:42:18] <N1njaneer> I assume you are receiving IR through a Vishal or similar that is decoding the pulsed IR operation in to demodulated TTL?
[19:44:04] <N1njaneer> Also yes, interrupts are turned off when entering an ISR. You should ALWAYS keep ISR code as short as possible and return out quickly. If this is absolutely just not feasible, you can always wrap other ISR processing code in a function call, then do polling checks inside of your "long" ISR so you can service other events.
[19:44:45] <N1njaneer> There is something of a tradeoff with ISR stuff in that if you have TOO much ISR activity it becomes far less efficient and deterministic (i.e. thoroughly testable) than if you just used polling outright.
[19:45:56] <N1njaneer> So my reccomendation is to ALWAYS try to go the polling route first, and only use ISRs if necessary, and use the minimum number required. This also prevents asynchronous issues from arising, which can be nearly impossible to track down and understand if you don't have a lot of experience with multithreaded coding.
[19:47:55] <N1njaneer> Obviously certain really timing-critical stuff like timers and edge-captures simply NEED ISRs, but really... try to avoid them if you can :)
[19:49:17] <N1njaneer> I did an application that had to parse four saturated streams of 250kbps serial receive, and produce four more streams of 250kpbs data, and meet timing closure, all on a 16Mhz Atmega w/o using interrupts. In fact it wouldn't have likely been possible to even do it with ISRs because of the timing cycle overhead.
[19:51:09] <N1njaneer> But anyhow, let us know if we can be of further assistance :)
[19:52:15] <Deskwizard> you already have been of a lot of assistance :) ty
[19:53:02] <Deskwizard> I try to stick to my first idea for some reason, I noticed that and I have to try to stop... i probably stuck on an ISR because the first code I used was bulletproof and was using interrupts
[19:55:11] <Deskwizard> if you can manage those 4 streams, I could probably manage one ir receiver (yeah its one of those demodulated TSOP 36 khz IR receiver)
[19:55:36] <N1njaneer> And your IR reception is going to be at 2400 baud instead of 250,000 :)
[19:56:25] <N1njaneer> You should be good to go either way, honestly :)
[19:57:40] <Deskwizard> yeah, at some point I just have to stop and think about it, and all your tips really helped a lot
[19:58:08] <N1njaneer> I'm sure you'll figure it out. Just suss it out item by item.
[19:58:41] <N1njaneer> And if you are using an IR remote you can easily get repeating sequences so it should be easy to check things.
[19:59:31] <Deskwizard> lmao exactly what I was gonna say, I'll just do it step by step, I always say step by step is teh way to success, I should practive what I preach... I'm just sick of getting nowhere for like a week so I rush it, and fail when I do so, I should know better hehe
[19:59:52] <Deskwizard> yeah of just set up an arduino beside it with all the working IR stuff and compare ...
[19:59:58] <Deskwizard> *roll eyes*
[20:03:20] <Deskwizard> wait.
[20:03:35] <Deskwizard> N1njaneer: you werent cheating and using ASM were you? :P~
[20:03:36] <Deskwizard> jk
[20:03:57] <N1njaneer> No, though there are certain times when it is appropriate to do so :)
[20:04:39] <N1njaneer> At very least it's useful to be able to roughly read assembler even if you don't write it, because if you look at the annotated .lss files you can see what assembler output the compiler is creating from your code.
[20:05:04] <N1njaneer> Sometimes it doesn't always quite do what you expect it to, and it's useful to sanity check if you have really critical areas.
[20:05:11] <N1njaneer> ALSO --
[20:05:34] <Deskwizard> *listening*
[20:06:03] <N1njaneer> Remember that if you are exchanging data between ISRs and normal code, be sure to read up on "volatile" as well as understand the usage of atomic operations and/or creating your own with sei() and cli()
[20:06:30] <N1njaneer> If you get split-transactions from interrupts they are nearly impossible to suss out unless you get a good feel for what kinds of oddities they can cause.
[20:06:41] <Deskwizard> I did actually lol
[20:07:04] <Deskwizard> so know I know about using sei() and cli(), volatile I knew already
[20:07:07] <N1njaneer> That is my biggest grievance with AVR's instruction set is that there is no test-and-set atomic single-cycle instruction.
[20:07:47] <N1njaneer> So just be aware of things like writing "if(a == 1) { a++; }"
[20:07:49] <Deskwizard> I am assuming others do?
[20:08:03] <Deskwizard> Oh I see
[20:08:12] <Deskwizard> let me check my code a sec
[20:08:29] <N1njaneer> Because it's entirely possible to test "a == 1" as true, then have an interrupt occur, change the value of a to NOT be == 1, and then return and still run the a++ operation and wind up with a value that is NOT 2
[20:08:50] <N1njaneer> Or any combination of such operations.
[20:09:20] <N1njaneer> Some operations it doesn't matter, but generally if you are doing reads and writes of the same variables from inside of both the ISR and in the mainline code, you can run in to the issue.
[20:09:35] <Deskwizard> I see... yeah I clearly see why you say its a grievance now
[20:09:51] <N1njaneer> There are some rare exceptions that you'll always be safe in, though, such as some ways of writing circular buffers and such. But always best to air on the side of caution.
[20:09:57] <N1njaneer> WORSE YET --
[20:10:20] <Deskwizard> yep, thats precisely what was happening, how did I know? LED wasnt flashling right and I knew overflow was taken care of hehe
[20:10:25] <N1njaneer> Variables that are NOT a single 8-bit number have to necessarily be handled as multiple operations since AVR is 8-bit
[20:10:51] <Deskwizard> yeah I didnt think of that but it explains a lot
[20:11:20] <N1njaneer> So if you are doing something like a = b + c and these are all 16 bit variables, the code becomes several lines long to do this, and b or c could have their value altered in the middle of the arithmetic.
[20:11:25] <Deskwizard> a little question...
[20:11:57] <N1njaneer> THAT causes really hard to track down problems which do not occur determinstically, and may in fact only occur on really rare occasions. Like once your board is deployed in the field and working fine for three weeks :D
[20:12:11] <Deskwizard> might be redundant but ill ask anyway... lets say ISR INT1_vector just fired (still inside) and TIMER1_COMPA_vect fires
[20:12:13] <Deskwizard> what happens ?
[20:12:38] <Deskwizard> N1njaneer: lmao oh do I catch a glipse of first hand experience there ;)
[20:12:53] <N1njaneer> The first ISR will finish, hit the "reti", return, and then once interrupts are turned back on, then TIMER1_COMPA will be serviced.
[20:13:03] <N1njaneer> AVR doesn't have nested interrupt vectors.
[20:13:25] <Deskwizard> mkay, thats what they meant in ISR_NAKED description
[20:13:46] <N1njaneer> Also, something worth noting if you deal with ISRs --
[20:13:55] <Deskwizard> must have been my read/writes to the buffer then
[20:14:48] <N1njaneer> The ISR vector table is filled out with a dummy jump for all of the unassigned ISRs. If you are clever you can route that code to a function call that does something noticable with the board, like flashing an LED a certain way. So if you accidentally enable an interrupt you don't hook, you can figure out what is happening versus the process just appearing to lock up.
[20:15:42] <N1njaneer> And know to step through and see which interrupt vector you accidentally enabled without meaning to, or attaching the wrong hook name :)
[20:16:34] <Deskwizard> the BAD_ISR_Vect (iirc?) ?
[20:16:34] <N1njaneer> ARM is really nice for that, since there are several interrupts that occur on particular kinds of errors, and inside of those you can send debug info and dump the stack trace so you can see exactly where and why the code went awry. :)
[20:16:42] <N1njaneer> I believe that's it, yep.
[20:17:41] <Deskwizard> I have yet to work with ARM on a lower level like that, must been quite easier indeed
[20:17:59] <N1njaneer> It's fun, but there's also more to go wrong XD
[20:18:05] <Deskwizard> lol good point
[20:18:24] <Deskwizard> considering my current level of knowledge, i'll stick to AVR for now hehe
[20:19:17] <N1njaneer> It's a good place to start for sure!
[20:20:13] <Deskwizard> in my case, its more of a re-start hehehe
[20:20:36] <Deskwizard> used the arduino stuff for years figured I was ready for the big leagues
[20:20:42] <Deskwizard> not so much apparently lol
[20:21:59] <N1njaneer> As I like to say it's not particularly difficult, it's just particularly *detailed*
[20:23:15] <Deskwizard> very well said indeed
[20:23:57] <Deskwizard> I sure do know a lot more than when I started thats for sure
[20:24:28] <N1njaneer> And that's all you can ask for. No one ever woke up knowing this stuff :)
[20:27:58] <Deskwizard> N1njaneer: would you mind if I should you the code I have once I'm done with the IR? I'm kind of making myself some "reference" code that's a bit universal so that I have a consistant codebase
[20:31:23] <N1njaneer> Sure.
[20:35:04] <Deskwizard> ty, I appreciate the help very much
[20:35:31] <N1njaneer> No problem! Go forth and make awesome stuff.
[20:35:59] <Deskwizard> thats the idea :)
[20:36:53] <Deskwizard> I got USART working, buttons and rotary encoder (thanks to danni really...)
[20:37:12] <Deskwizard> USART I based on atmel app note initially, kept changing along the way hehe
[20:38:29] <Deskwizard> I still have something wrong with the baudrate setting, im sure my math is wrong somehow
[20:38:54] <Deskwizard> but it works good enough once you dont let interrupts mess with writing/reading the buffer hehe
[20:43:20] <N1njaneer> What crystal are you using?
[20:43:38] <N1njaneer> Frequency
[20:45:06] <N1njaneer> For 2400 baud, assuming 8Mhz then you want UBRR to be set to 207, or 416 for 16Mhz
[20:45:33] <N1njaneer> The datasheet for your AVR has a handy set of tables for common baud rates and crystals under the UART Registers section
[20:45:42] <N1njaneer> Or use something like WormFood's calculator :)
[20:46:08] <Deskwizard> yeah yeah thats not the issue :P
[20:46:18] <Deskwizard> I've bookmarked that hehe
[20:46:45] <Deskwizard> calculating a UBBR value from a value like 57600 is where it goes boom
[20:47:17] <Deskwizard> works for some values/freq and not others
[20:50:34] <N1njaneer> Well there are some combinations that are a bit odd that you want to stay away from for sure, but generally an error rate of 1-2% is perfectly fine
[21:47:12] <Deskwizard> N1njaneer: I don't think I can thank you enough for telling me just to poll it... started from nothing when we spoke about that, and now I have pulse count and width, and theres clealy "long" and "short" ones :)
[21:47:29] <N1njaneer> Excellent.
[21:47:47] <N1njaneer> What exactly are you counting pulses for, though?
[21:48:21] <Deskwizard> because it was the second step ;)
[21:49:05] <N1njaneer> If you are receiving in to the UART, though, you should just be getting fixed clumps of databytes returned? Or are you doing something else right now?
[21:49:26] <Deskwizard> not doing it with the usart, just straight polling the pin
[21:49:36] <Deskwizard> as basic as you can get
[21:49:45] <Deskwizard> well, with a counter hehe
[21:49:58] <N1njaneer> But with that you're going to need to write a precision-timed state machine in order to lock on, resolve, and decode the bits.
[21:50:37] <Deskwizard> thats like step 15, if I get there :P
[21:50:46] <Deskwizard> it was just for basic detection at first tbh
[21:51:19] <N1njaneer> True, but you should only need about 5 lines of code to set up to start pulling in your bytes and processing them:)
[21:51:34] <N1njaneer> Via USART
[21:52:03] <N1njaneer> Are you using a part with multiple serial ports so you can print out text somehow?
[21:52:19] <Deskwizard> nah theres only one, thats why i dont use the usart for IR ;)
[21:53:05] <Deskwizard> start pulse is very long, then its either long or short, I'll just match the pattern somehow, I just wanted to come by half-way through the work to say ty
[21:53:23] <N1njaneer> You should be able to find source for a soft-UART to use with this if you don't feel like writing one. It's going to be a bit challenging if you don't have a logic anaylizer
[21:53:48] <N1njaneer> I actually have IR soft-UART receiving code up on screen right now here for something I'm working on, but it's too in-depth to be able to copy and paste as an example.
[21:53:56] <N1njaneer> But here's a hint --
[21:54:09] <Deskwizard> I have a logic analyser thankfully, but as I said, I'm getting a pattern here, so I'll just give the code arbitrary values from the long pulses (1) and short (0) and be done with it
[21:54:15] <Deskwizard> thats my thinking anyway
[21:54:24] <N1njaneer> Yes but that won't really work for decoding it.
[21:54:25] <Deskwizard> ie. lets make something work, then expand
[21:55:04] <Deskwizard> N1njaneer: you know, I just took that as a challenge ... :P
[21:55:09] <N1njaneer> And you can't do that (easily at any sane level) via polling - the timing tolerance is too jittery
[21:55:09] <Deskwizard> bbl ;)
[21:55:35] <Deskwizard> timer is a counter *wink*
[21:55:56] <Deskwizard> hey it might not work, wont stop me from trying hehe
[21:57:03] <N1njaneer> The standard way to do this is to initialize a timer at either 8 or 16x the baud rate, and then look for the edge of the start bit, then run in half a bit length, check to make sure the start bit is still zero. If it is, you reset the counter and state machine and then start picking up the bits ever 8 or 16 firings of the counter, or dynamically adjust the counter to 1/8th or 1/16th and pick them
[21:57:03] <N1njaneer> up.
[21:57:13] <N1njaneer> That's how a basic SOFTWARE UART works, anyhow.
[21:57:40] <flyback> ewww
[21:57:44] <flyback> software uart
[21:57:47] * flyback pukes all over N1njaneer
[21:57:53] <Deskwizard> yeah, I remember reading that somewhere
[21:57:56] <N1njaneer> You COULD do sampling and symbol matching, but you're going to have a pretty big symbol table and potentially some problems with jitter otherwise because of where your start bit comes in.
[21:58:03] <flyback> I guess it's better than nothing and ok for rare use
[21:58:38] <N1njaneer> Deskwizard: That's exactly how a UART works in hardware, with a 16x oversample of the incoming async data. You can also do other things to check data integrity, noise, faults, etc by sampling three middle-bit times and doing majority voting, etc.
[21:58:40] <flyback> so how many people here have canucked with ble
[21:59:07] <flyback> I got my mom for xmas a set of led icicles with like 300 patterns controllable with a bluetooth tablet/phone
[21:59:18] <N1njaneer> Anyhow, if you want some ideas on that look up the specifications for a good old 16550 UART. I think the AVR USART chapter may cover that as well.
[21:59:18] <flyback> they used ble although kinda pointless
[21:59:40] <flyback> N1njaneer, they have spi and i2c to uarts also :p
[21:59:57] <Deskwizard> yeah, the Atmel app note on UART/USART are pretty complete when you add the datasheet into the mix
[22:00:07] <Deskwizard> hell, thats like the first thing I got working
[22:00:14] <N1njaneer> I prefer hardware UARTs where possible, but low baud-rates for applications that require multiple serial ports on something small like a 328P can really benefit from the augmentation.
[22:00:20] <Deskwizard> couldnt have been hard hehe
[22:00:43] <Deskwizard> oh wait...
[22:00:52] <N1njaneer> flyback: I know, I've been writing them in to FPGAs for many years :)
[22:01:12] <Deskwizard> theres both USART and USI on this... I guess we now have a plan B! :)
[22:01:23] <N1njaneer> What processor are you using?
[22:01:44] <Deskwizard> tho it probably needs a timer clock in uart mode as well
[22:01:47] <Deskwizard> attiny4313
[22:01:50] <flyback> N1njaneer, how do you feel about ble so far
[22:01:55] <flyback> I think it's going to keep getting bigger
[22:02:02] <flyback> zigbee shot themselves in the ass
[22:02:21] <N1njaneer> flyback: zigbee and BLE are two completely different things for different purposes.
[22:02:34] <flyback> no theya re both low power long range standards
[22:02:39] <N1njaneer> I have worked with and implemented both for various applications. They can work well depending on what you are doing.
[22:02:52] <flyback> I like them both though and dash7 looks fun also
[22:03:52] <N1njaneer> For Zigbee I defer to using mostly Digi's XBEE modules because it makes development fast and easy. For BLE I usually use Nordic's parts.
[22:04:05] <N1njaneer> Both are exceptionally well-supported.
[22:05:12] <flyback> the ti ble part looks good
[22:05:20] <flyback> 8051 fast core, aes engine
[22:05:31] <flyback> but yeah digi stuff looks good
[22:05:34] <flyback> and nordic also
[22:05:42] <N1njaneer> 8051 needs to just die already :)
[22:05:45] <flyback> someday I will actually do something mabye late this year
[22:05:47] <flyback> na
[22:06:03] <N1njaneer> Nordic stuff is mostly Cortex M0, which makes it exceptionally nice
[22:06:16] <flyback> yeah m0 was one of arm's smartest moves ever
[22:06:52] <flyback> pefect for something like a radio controller
[22:06:59] <flyback> not expensive or power hungry
[22:07:08] <flyback> did you see the dialog semi m0 with ble
[22:07:15] <flyback> 4.9ma tx/rx
[22:07:21] <flyback> they have newer parts since this one
[22:08:16] <N1njaneer> I only know the parts I've implemented in to designs :)
[22:08:26] <flyback> i'm not bashing anything you chose
[22:09:51] <N1njaneer> The whole trick is to find the parts and the toolchain that lets you work quickly, effectively, and efficiently. And pisses you off the least. No one part or toolchain is ever perfect, but I've spent 15+ years going through more than a half-dozen toolchains and finding out which things work best for me. :)
[22:09:59] <flyback> I love the power scaling shit
[22:10:05] <flyback> it's like you can go down to a crawl
[22:10:07] <flyback> it sucks ass
[22:10:13] <flyback> but you survive when it all goes to hell
[22:10:25] <flyback> running out of juice etc
[22:19:20] * N1njaneer wishes new baby goat would be born soon!
[22:19:56] <N1njaneer> Because production helpers!
https://www.dropbox.com/s/yq6ymvsw0o9nlzc/ProductionHelper.jpg
[22:26:02] <flyback> hehehe
[22:27:09] <N1njaneer> Need to take a picture of the new baby on top of the newer SMT line, because reasons.
[22:27:48] <flyback> is that real?
[22:27:54] <N1njaneer> Of course.
[22:28:01] <flyback> be careful they will chew anything
[22:28:03] <theBear> baby + smd ? that's a recipe for smd boogers
[22:28:10] <N1njaneer> Baby goat :)
[22:28:11] <flyback> including toxic smt materials and electrical cables
[22:28:29] <flyback> I suggest you get one of those animal control solutions made from hot peppers etc
[22:28:42] <N1njaneer> I know, I have owned goats for two years. :)
[22:28:45] <flyback> hurts but no mental trama etc
[22:28:49] <flyback> they just go "fuck this"
[22:29:25] <flyback> theBear, you should be proud
[22:29:31] <flyback> they saved many bears with pepper spray
[22:34:42] <Deskwizard> N1njaneer: lmao
[22:34:47] <Deskwizard> nice helper
[22:35:30] <N1njaneer> Now he's a 65 pound bleating machine :D
[22:36:02] <theBear> i dunno bout proud... i'm kinda quietly pleased with how pepper spray doesn't take me down if i'm in a good mood... it's all in the mind, like ignoring any pain yogi style
[22:36:31] <theBear> i bet these days yer could get a electric bleating machine that weighs a lot less than 65 pounds <grin>
[22:38:18] <N1njaneer> But not half as much fun.
[22:38:43] <N1njaneer> https://www.youtube.com/watch?v=PeZtoQfDo8M is some nice HD slow-mo video of them at the park.
[22:44:23] <Deskwizard> hehehe they look like happy-go-lucky little things
[22:47:28] <N1njaneer> They very much are!
[22:47:58] <Deskwizard> are they the kind that freezes up and fall if they get scared?
[22:49:59] <N1njaneer> Nah, those are myotonic/fainting-goats. These guys are pygmy goats. :)
[22:50:04] <N1njaneer> Very similar though!
[22:50:55] <Deskwizard> mkay :)
[22:51:45] * Casper wants a flyback transformer to do some testings...
[22:52:15] <Casper> I want to see if I can make an argon fluorescent tube without mercury
[22:52:31] <flyback> you know you can use a cfl ballast to drive a tv flyback
[22:55:57] <Casper> technically, the fluo tube should be made... but don't have an high enought voltage source to strike it
[22:56:22] <flyback> http://www.instructables.com/id/How-to-get-100KV-out-of-your-flyback-VERY-SIMPL/
[22:56:27] <flyback> owns your "canuck"
[22:56:32] * flyback smacks Casper
[23:00:45] <flyback> night
