Back
[02:48:21] <Qantourisc> The datasheets of ATmega32 do not mention 16MHZ crystal ?
[02:58:13] <Qantourisc> Maybe they just coppied the document and fergot to up the 8MHZ to 16MHZ :p
[03:03:15] <Qantourisc> PS do the AVR's have a "timer" ?
[03:03:27] <Qantourisc> I mean a "ran CPU cycles"
[03:09:51] <Qantourisc> Hmmm looks like I just have configure a timer, and read that
[03:10:10] <Qantourisc> Also has a few other advantages
[03:42:34] <rue_house> there is something you can use as that yes
[03:46:42] <megal0maniac> 'Lo all. I want to use standard DB9 serial port to read whether or not a relay contact is closed. Would it make sense to set DTR on (-12V) and RTS off (+12V), pull CTS or RI up to RTS and connect it to DTR through the relay contact?
[03:47:04] <megal0maniac> And then obviously read CTS or RI
[03:48:13] <rue_house> ri might be your better bet
[03:48:48] <megal0maniac> rue_house: So that configuration should work?
[03:49:40] <rue_house> number of variables, check voltages with meter to be sure code is working right
[03:49:58] <megal0maniac> Using DTR and RTS is my crude plan for using an "internal reference". So it conforms to whatever logic level the serial port likes :)
[03:50:11] <megal0maniac> rue_house: Cool. Will do that
[03:50:22] <rue_house> you could use a pullup from one signal and the other signal as the low volt ref
[03:51:10] <rue_house> check circuits used in UPS'
[03:51:21] <rue_house> number of them are optically isolated
[03:54:43] <megal0maniac> I'll check it out. Thanks :)
[03:55:09] <megal0maniac> Luckily still have a laptop with hardware RS232
[04:35:31] <BusError> is there a replacement for the attiny85 somehow? I notice farnell no longer stocks the 85-20PU in soic8...
[04:44:31] <RikusW> a45 and 25 ?
[04:44:38] <RikusW> t45 t25
[04:44:55] <RikusW> PU is DIP
[04:46:17] <BusError> SU, whatever, and 4KB if flash is not the same as 8K. Is the 85 really discontinued by atmel, or is it just farnell?
[04:50:47] <twnqx> check mouser or digikey
[04:51:29] <twnqx> isn't farnell the most expensive of the bunch anway?
[05:00:24] <megal0maniac> I'm an idiot :)
[05:01:17] <megal0maniac> rue_house: PL2303HX modules go for ~USD2. They have all the handshaking lines and operate on 5V or 3v3 IO
[05:01:24] <BusError> twnqx, often, but it also ship in <24h, and I often have a 'cart' there that I trigger when it goes over the free shipping level :>
[05:01:50] <twnqx> BusError: both true for digikey and mouser
[05:01:52] <megal0maniac> Just tested RI with a 10K pullup to 5V and a pushbutton. Works perfectly
[05:02:04] <megal0maniac> RikusW: :)
[05:02:09] <twnqx> 36h from ordering in the US to delivery in europe, normally
[05:02:10] <megal0maniac> No need for RS232
[05:02:13] <RikusW> hi megal0maniac
[05:02:26] <twnqx> and free shipping to europe from 65€ :P
[05:02:28] <RikusW> so what new plan do you have ?
[05:02:34] <megal0maniac> Read up
[05:02:57] <RikusW> using the RI pin ?
[05:03:02] <megal0maniac> Yip
[05:03:08] <BusError> twnqx, plus customs. I NEVER order from te us anymore. if it's not in europe already, I pick another part. been had a couple of times with VAT+Customs etc
[05:03:12] <megal0maniac> Now I can stick with 5V logic
[05:03:21] <twnqx> digikey has all customs included
[05:03:33] <megal0maniac> No more 24V drop
[05:03:54] <twnqx> and at least for germany, they take VAT straight from the credit card, so it's hassle free :)
[05:04:12] <twnqx> just mentally add the 19% to the prices
[05:04:14] <RikusW> megal0maniac: so you put 0-5V directly into the RI pin ? should work
[05:04:28] <twnqx> i could check with a friend for mouser
[05:04:32] <RikusW> the level read on the PC will be inverted though
[05:04:44] <twnqx> last time i didn't order because i wanted parts that weren't on their linecard :(
[05:05:08] <megal0maniac> Well 5V --- 10K ---RI --- relay contact --- GND
[05:05:30] <megal0maniac> But yeah, tested it now
[05:05:36] <RikusW> where do you get the 5v from ?
[05:05:39] <megal0maniac> This simplifies things
[05:05:45] <RikusW> that small adapter of yours ?
[05:05:56] <megal0maniac> The module has TX/RX/5V/3V/GND outputs
[05:06:13] <megal0maniac> And I just soldered a small wire to the RI pin on the actual chip
[05:06:27] <RikusW> ah, clever
[05:06:46] <RikusW> what will be connected to the relay input ?
[05:06:53] <RikusW> and how many V
[05:06:59] <RikusW> twnqx: VAT in ZA is 14%
[05:07:08] <twnqx> lucky you
[05:07:12] <megal0maniac> Output from the broadcast mixer. It's 12V high, 0V low
[05:07:15] <twnqx> know imagine we have the lowest in europe :P
[05:07:19] <twnqx> now*
[05:07:30] <megal0maniac> Have a small finder relay with a 12V coil. Will work just fine :)
[05:07:56] <RikusW> megal0maniac: you do remember the flyback diode right ?
[05:08:27] <RikusW> the one in parallel with the relay...
[05:09:14] <RikusW> and is the mixer 0V disconnected or pulled low ?
[05:17:56] <RikusW> megal0maniac: its a pity they don't breakout those pins, wouldn't have been much of an effort
[05:18:03] <RikusW> s/y/a/ :-D
[05:19:28] <megal0maniac> RikusW: I don't even know what a flyback diode is
[05:20:04] <megal0maniac> Luckily it's on the outer side, not right next to the crystal. That would have been much worse
[05:20:10] <RikusW> you need to put a diode in parallel to the relay coil to absorb the back emf
[05:21:10] <RikusW> else there will be a brief HV surge each time you switch off the realy
[05:21:10] <megal0maniac> To prevent "bounce"?
[05:21:11] <RikusW> *relay
[05:21:18] <RikusW> back emf
[05:21:38] <RikusW> like this
http://www.mantech.co.za/Techtips.aspx?q=%28Cat1%29%20=%20%27FAQs%27%20AND%20%28Cat2%29%20=%20%27DIODES%27%20AND%20%28Cat3%29%20=%20%27SUPPRESSION%27
[05:22:05] <RikusW> aka freewheeling diode
[05:22:22] <RikusW> just a normal 1n4007 will do
[05:22:24] <megal0maniac> Ah.. Cool :)
[05:22:31] <megal0maniac> Will keep that in mind
[05:22:39] <megal0maniac> Now to see what the boss says...
[05:22:58] <RikusW> if you connect an AVR IO pin directly to a 5V relay it won't last long without that diode
[05:23:49] <megal0maniac> But for that I'd probably use an optoisolator
[05:24:04] <RikusW> you still need the diode in parallel to the coil
[05:24:05] <megal0maniac> s/isolator/coupler ?
[05:24:13] <megal0maniac> Got it
[05:24:18] <RikusW> both term are correct :)
[05:24:25] <RikusW> s
[05:26:41] <megal0maniac> The RTS and DTR lines can only drive ~5mA. Would I use optocouplers for those if I wanted to drive higher current?
[05:27:05] <RikusW> or transistors
[05:27:17] <RikusW> you want output now too ?
[05:28:11] <megal0maniac> Just wondering. It's easy to add in software
[05:28:12] <RikusW> if you do use an opto and connect +-12V put a diode in parallel to the opto but the other way round
[05:28:22] <RikusW> leds don't like 12V in reverse
[05:28:30] <megal0maniac> Not for long :D
[05:28:48] <RikusW> so one way the led is on the other the diode conducts
[05:29:03] <megal0maniac> Funny. It makes sense to have the diode there but I've never seen it implemented
[05:29:15] <megal0maniac> RikusW: But it's only 5V/0V
[05:29:29] <RikusW> when you get he cable you ordered
[05:29:58] <megal0maniac> Ah
[05:29:58] <RikusW> for 0-5V only add the obvious resistor
[05:30:09] <megal0maniac> Probably won't use that for this project now..
[05:30:36] <twnqx> flyback? i always though those were called free wheeling
[05:30:46] <twnqx> also, is that related to flyback transformers?
[05:31:16] <RikusW> flyback is when the inductor is disconnected from the power source
[05:31:47] <RikusW> current still have to flow and the voltage goes to infinity (theoretically)
[05:31:55] <twnqx> and beyond
[05:32:16] <RikusW> http://www.circuitrework.com/features/682.shtml
[05:35:10] <twnqx> coooool
[05:35:15] <twnqx> :)
[05:35:55] <twnqx> so i kinda did a dead bug rework, eh
[05:36:08] <twnqx> (just not dead)
[05:37:31] <RikusW> http://www.chiaki.cc/Pyxis2010/images/pyxis2010-fpgasol1.jpg
[05:38:05] <twnqx> while quite challenging, not a problem with the right tools
[05:38:35] <twnqx> i can't do it because my hands shake too much, though :(
[05:38:46] <twnqx> i managed 10 or so pins before i made a mess
[05:39:11] <RikusW> I might try someday, have a whole lot of northbirdges to practice on
[05:39:36] <twnqx> you need the right wire, don't forget that
[05:39:54] <RikusW> I have wire wrap wire
[05:39:57] <twnqx> good, that's what i used, too
[05:40:21] <RikusW> also the strands in multistrand cable seems to work nicely, not stripping needed
[05:40:41] <twnqx> hm
[05:40:46] <RikusW> or maybe enameled inductor wire
[05:40:53] <twnqx> i need no stripping with my wire wrap wire
[05:41:07] <RikusW> how so ?
[05:41:07] <twnqx> straight solderable
[05:41:14] <twnqx> insulation burns away on contact
[05:41:15] <RikusW> just melt the plastic ?
[05:41:17] <RikusW> a
[05:41:19] <twnqx> what plastic
[05:41:34] <twnqx> resin coating
[05:41:35] <RikusW> my wrapping wire got black plastic
[05:42:13] <twnqx> forgot the exact material... and just read about the various coatings yesterday :X
[05:43:52] <twnqx> RikusW:
http://www.litz-wire.com/pdf%20files/Copper_Wire_Film_Insulation_Enameled_Guide.pdf <- overview
[05:44:02] <twnqx> some coatings you have to strip, others just go away
[05:44:24] <RikusW> that would be nice
[05:44:40] <RikusW> stripping to the right length is very time consuming
[05:46:44] <RikusW> nice link :)
[06:05:15] <RikusW> https://plus.google.com/photos/111970087351022277696/albums/5879020221200740113/5879020228701293874?authkey=CLb3vfWVzsz8_QE
[06:39:43] <twnqx> lol @ this schematic
[06:39:52] <twnqx> that's a funny idea
[06:40:22] <twnqx> soundcard turned into a ~20mhz oscilloscope for repetitive waveforms
[07:50:50] <theBear> err, it's not that funnier idea, and it's not just for repetitive waveforms, tho anything viewed in 'oscilloscope' style display only really makes sense for repetitive waveforms, unless yer really sneaky
[08:03:14] <kobsu> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=132744
[08:03:58] <theBear> hehe, i gotta agree with the first 2 responses
[08:04:37] <theBear> wouldn't mind if you were just giving something away, poaching people is a bit different tho
[08:05:12] <kobsu> ouh ok :/
[08:05:31] <thetruthisoutthe> h
[08:05:55] <theBear> h indeed !
[08:12:46] <kobsu> bad idea then
[08:13:31] <theBear> i think h really says it all
[08:14:30] <kobsu> sorry for my ignorance, but what does "h" mean?
[08:14:42] <megal0maniac> kobsu: Don't you know?
[08:15:01] <kobsu> nope
[08:16:07] <kobsu> (googling)
[08:17:05] * theBear laughs a lot
[08:17:12] <theBear> should i tell him ?
[08:17:18] <megal0maniac> Hmmm...
[08:17:23] * theBear can't stop giggling
[08:17:25] <theBear> i'm getting dizzy
[08:17:26] <megal0maniac> I guess you can
[08:17:32] <megal0maniac> If you must
[08:18:01] <megal0maniac> Can't keep a secret forever ;)
[08:18:32] <twnqx> w
[08:19:04] <theBear> kobsu, err, it was a typo, h has no meaning, not like w
[08:19:13] * theBear giggles some more
[08:19:23] <megal0maniac> Wild-goose chase. Sorry :)
[08:19:35] <megal0maniac> That board looks quite nice
[08:19:48] <kobsu> ehh... i guess i don't understand your inside jokes ;)
[08:20:24] <theBear> it wasn't a joke until you started googling for it :)
[08:20:35] <megal0maniac> kobsu: thetruthisoutthe made a typo, and then I trolled
[08:20:59] <kobsu> ok i see it now :)
[08:21:09] <twnqx> theBear: you know the meaning of w? i'm impressed nw :P
[08:21:56] <theBear> hey, i been around
[08:22:11] <theBear> and i just like agreeing with things that don't make sense
[08:23:03] <kobsu> well i'll go to watch some ice-hockey now... if someone is really interested in to get rev0 (which we have ten extra hanging around without use) pm me
[08:23:36] <theBear> anyone know what these things actually are ?
[08:24:32] <twnqx> klick the link?
[08:24:35] <twnqx> look fun
[08:24:51] <twnqx> but i don't like taking things i have no use for from people who might have a use for them
[08:25:08] <theBear> i clicked the link and saw spam spam i think this is spam
[08:25:23] <twnqx> http://www.aery32.com/ clear link...
[08:25:28] <theBear> and i feel the same way, kinda how i feel about abusing samples
[08:25:41] <theBear> oh, that wasn't the link before
[08:25:51] <twnqx> it's in the post
[08:26:39] <theBear> hmm, i like the artwork
[08:27:28] <thetruthisoutthe> RikusW<= hahaha that kangaroo thing got lucky with the bus
[08:27:37] <twnqx> it's a deer >_>
[08:27:53] <RikusW> bus wasn't so lucky ;)
[08:28:29] <theBear> huh ? all i see is a little kid in a octopus kitty costume
[08:28:51] <megal0maniac> theBear: Where are you finding these links?
[08:28:52] <theBear> asian kid, you can tell by the cartoon-hamster eyes :)
[08:29:03] <theBear> twnqx pasted it 4 minutes ago :)
[08:29:22] <theBear> i should say the profit inducing eyes of a cartoon hamster
[08:29:23] <twnqx> what
[08:29:27] <theBear> down the bottom
[08:29:36] <megal0maniac> http://www.aery32.com/?
[08:29:38] <theBear> next to powered by open source
[08:29:39] <theBear> yeah
[08:30:04] <megal0maniac> Oh! That's the github kid, no?
[08:30:32] <thetruthisoutthe> RikusW<= why? it is alive, and even ran away
[08:30:50] <RikusW> I said the _bus_
[08:30:50] <megal0maniac> theBear:
https://github.com/404
[08:30:57] <RikusW> broken window...
[08:30:58] <theBear> github had a child !
[08:31:08] <theBear> awesome !
[08:31:31] <theBear> these are not the droids you are looking for <waves octopus arm>
[08:36:28] <twnqx> while we're at selling stuff, anyone needs a board with at90can + sja100 (dual CAN) + USB + 32kB extra ram? 50€ + shipping *g*
[08:36:44] <twnqx> or maybe 40, need to recalculate the component price
[09:57:10] <ambro718> what is the most efficient way to extend the resolution of a (16-bit) timer by software? Currently I have this: there is a "volatile uint32_t offset", and the timer overflow interrupt increments offset by 2^16. The problem now is how to get a sample of the time. You can't just do (offset+TCNT1) because e.g. the timer could overflow after offset was read but before TCNT1 was read, resulting in a bad sample.
[09:57:14] <ambro718> so I have this:
http://ideone.com/vqsIdl
[09:57:48] <thetruthisoutthe> ambro718<= set prescaler
[09:58:17] <thetruthisoutthe> that will extend the time
[09:58:36] <ambro718> thetruthisoutthe: how does that solve anything? It just makes the timer slower.
[09:58:43] <thetruthisoutthe> yes
[09:58:55] <vectory_> and lowers the resolution
[09:58:58] <ambro718> it doesn't prevent the race condition, just reduces likelyhooh
[09:58:59] <ambro718> *d
[09:59:04] <ambro718> and I need the resolution
[09:59:11] <thetruthisoutthe> ok, well you can not enhance the resolution of the timer then.
[09:59:13] <vectory_> your idea doesnt touch the resolution at all
[09:59:27] <thetruthisoutthe> the timer advances in every clock cycle. not faster
[09:59:37] <ambro718> I need my code to work with any prescaler
[09:59:40] <vectory_> to increase the resolution beyond prescale of one you need to run the chip at higher freq
[10:00:11] <thetruthisoutthe> ambro718<= use magic then
[10:01:18] <thetruthisoutthe> are there any sorcerers around there ? ask them for some spell
[10:02:01] <ambro718> maybe I wasn't clear, I don't need to "increase the resolution", but turn a 16-bit timer into a 32-bit timer. I'm just asking if there's a way to capture the current time more efficiently that what I'm doing
[10:02:40] <jacekowski> no
[10:04:43] <vectory_> you just have to make sure the timer doesnt overflow inbetween
[10:05:44] <thetruthisoutthe> pause button!
[10:07:42] <vectory_> you dont need to use a 32 bit uint anyway, its enough to save the high byte in 16 bit and take care of the conversion when you add. wht even add instead of dealing with both vars seperately
[10:07:58] <vectory_> *why
[10:08:26] <thetruthisoutthe> http://dictionary.reference.com/browse/separately
[10:08:35] <vectory_> thx
[10:08:55] <thetruthisoutthe> np, common
[10:09:20] <ambro718> got 2 more ideas:
http://ideone.com/PQwtzd
[10:09:35] <ambro718> but none looks faster than what I'm doing
[10:09:50] <thetruthisoutthe> i'd use a TSC
[10:10:04] <thetruthisoutthe> that is a 64 bit counter variable ticking at CPU speed
[10:10:18] <ambro718> AVR has that?
[10:10:18] <specing> ambro718: the datasheet features a section on how to handle the "race" condition
[10:10:41] <thetruthisoutthe> pentium+ has that
[10:10:41] <thetruthisoutthe> ;/
[10:10:41] <specing> other than that, just make an overflow interrupt increment the third byte and so on
[10:11:57] <thetruthisoutthe> ATOMIC_BLOCK(ATOMIC_RESTORESTATE) { tmpvar = TCNT1; } ... < this is the pause button
[10:12:18] <ambro718> thetruthisoutthe: what happens with the timer in between?
[10:12:27] <thetruthisoutthe> pauses ?
[10:12:42] <ambro718> but does it get buffered, or are the ticks lost?
[10:13:00] <ambro718> lost ticks is not acceptable
[10:13:12] <specing> ambro718: you are overdesigning it
[10:13:18] <vectory_> ticks arent lost, the interupt is disabled momentarily?
[10:13:25] <thetruthisoutthe> ambro718<= discuss that with atmel
[10:13:50] <vectory_> and when the interrupt is turned back on, it fires
[10:17:02] <ambro718> thetruthisoutthe: ATOMIC_BLOCK doesn't stop the timers
[10:17:22] <ambro718> it's just a wrapper for cli/sei
[10:17:32] <thetruthisoutthe> it forbids interrupt to corrupt your 16 bit operation
[10:18:13] <thetruthisoutthe> mangling with your timer value
[10:18:27] <ambro718> thetruthisoutthe: but I need this: ATOMIC_BLOCK(ATOMIC_RESTORESTATE) { captured_offset = offset; tcnt = TCNT1; } return (captured_offset + tcnt);
[10:19:04] <ambro718> thetruthisoutthe: it can happen that in between these two operation the timer overflows, and as a result captured_offset is out of date with respect to the captured tcnt
[10:20:11] <ambro718> ISR(TIMER1_OVF_vect) { offset += UINT32_C(0x10000); }
[10:20:19] <thetruthisoutthe> no, if the interrupt does not touch (captured_offset||tcnt)
[10:21:26] <thetruthisoutthe> how would the interrupt touch your thing inside the atomic block ?
[10:24:48] <ambro718> thetruthisoutthe: suppose this happens: offset=0, TCNT1=0xFFFF ... cli (entering atomic block) ... captured_offset=0 (TCNT1 just overflowed, but interrupt is delayed) ... tcnt=1 (we got it after the overflow) ... sei ... return (0+1)=1
[10:24:54] <ambro718> thetruthisoutthe: we returned a bad time
[10:25:17] <thetruthisoutthe> wrong
[10:25:23] <ambro718> what is wrong?
[10:25:32] <thetruthisoutthe> interrupt is disabled while in atomic block
[10:26:05] <ambro718> thetruthisoutthe: it is. The ISR was delayed while we were in the atomic block. That's the *problem*.
[10:26:48] <thetruthisoutthe> you can not have the precision you want.
[10:26:48] <thetruthisoutthe> get a faster mcu
[10:26:48] <ambro718> this is irrelevant
[10:26:48] <ambro718> the problem will still exist
[10:27:24] <ambro718> it seems you still don't understand what I'm saying. maybe you should read my example above in more detail.. or whatever
[10:27:41] <thetruthisoutthe> i have about 4ns latency reading the TSC value on a 2.2GHz amd64
[10:28:13] <ambro718> how is this relevant to my problem?
[10:29:16] <thetruthisoutthe> just gave a reference value, btw task switching and scheduling delays overheads are in the microsecond range even for the best real-time linux kernel
[10:29:44] <ambro718> the issue here is specifically with using an interrupt to add artificial hight bytes to the timer. It has absolutely nothing to do with specific frequencies or delays.
[10:30:48] <ambro718> thetruthisoutthe: when I said "we returned a bad time" above, we actually returned a time that was off *one whole hardware timer period*
[10:31:47] <thetruthisoutthe> clear flags before starting interrupt
[10:32:03] <ambro718> meh forget about it, you clearly don't know what I'm talking about it
[10:32:13] <thetruthisoutthe> okey
[10:32:20] <ambro718> :)
[10:32:24] <thetruthisoutthe> then i get back to c0ding stupid things
[10:33:41] <theBear> sigh, why do some people think being rude is going to help get their question answered ? it just doesn't work that way, and strangely enough, a lot of people take offence seeing others insulted...
[10:33:51] <Tom_itx> h
[10:33:54] <Tom_itx> w
[10:33:55] <megal0maniac> w
[10:33:55] <Tom_itx> wtf
[10:33:57] <theBear> lol h again
[10:33:58] <megal0maniac> :)
[10:34:43] <Tom_itx> i prefer the reverse polarity resistor personally
[10:34:51] <ambro718> theBear: trying not to waste his time after seeing he doesn't get my problem is *not* rude
[10:34:52] <theBear> we were nice, we told him after a couple minutes :) not our fault he accidentally thought a typo was some secret code
[10:35:07] <theBear> i dunno, looks rude from where i'm sitting
[10:36:31] <megal0maniac> Nwa
[10:36:33] <megal0maniac> Naw
[10:36:38] <theBear> f*&^ the police indeed
[10:37:12] <megal0maniac> Accidental reference :)
[10:37:16] <theBear> :)
[10:37:50] <theBear> saw public enemy last year, not all original guys, but it was kinda cool :)
[10:54:43] <twnqx> ambro718: i am afraid you can't avoid that kind of offsets
[10:55:08] <twnqx> however the interrupt should only be delayed to until the atomic block (it should still be executed)
[10:55:15] <twnqx> not totally skipped
[10:55:53] <twnqx> until after*
[10:58:35] <ambro718> I think the code that I have is pretty optimal though.
http://ideone.com/AIhrkc
[10:59:05] <ambro718> as per vectory_'s suggestion I've stored the offset in a 16-bit and shifted on capture, and now it gets compiled into something smaller
[11:00:01] <twnqx> no idea what that does
[11:00:25] <ambro718> I've done some thinking and I'm sure this code is correct, it won't return a "bad time" if an interrupt happens in between (I've analyzed it, incl. if interrupted in the middle of a m_offset read)
[11:00:26] <twnqx> didn't follow the whole discussion
[11:00:42] <ambro718> twnqx: timer1 overflow interrupt increments m_offset, that is all
[11:01:13] <ambro718> and I need to be able to get a consistent value of (m_offset<<16)+TMR1
[11:01:32] <ambro718> it artificially makes a 32-bit timer
[11:01:36] * twnqx still doesn't quite get the problem there
[11:02:06] <twnqx> dsiable ints, read timer, read upper (preferable into something register uint16_t, enable ints
[11:02:33] <twnqx> that's four memory reads inside a critical section
[11:02:49] <ambro718> twnqx: heh, it's a nasty problem. Suppose this: cli(); read m_offset, read TCNT1; sei();
[11:03:04] <ambro718> what if the timer overflows in the middle of "read m_offset" and "read TCNT1" ?
[11:03:17] <twnqx> hence the other way round
[11:03:47] <twnqx> ok, it could still overflow between cli and read.
[11:03:53] <ambro718> same problem, you get an inconsistent sample
[11:04:03] <ambro718> off by 2^16 or so
[11:04:06] <twnqx> only with an overflow between the two
[11:04:20] <twnqx> (cli and read)
[11:05:16] <ambro718> that would not be an issue, only if it overflows in the middle of TCNT1 reading and m_offset reading, no matter which order you do them
[11:05:17] <twnqx> but yes, there is a chance
[11:05:22] <twnqx> can't
[11:05:29] <ambro718> why not?
[11:05:29] <twnqx> if you have tcnt1
[11:05:35] <twnqx> and interrupts are disabled
[11:05:44] <twnqx> m_offset can't change in between
[11:05:50] <ambro718> but TCNT1 can
[11:05:56] <twnqx> that's why ou read it first
[11:06:14] <vectory_> specing: the m8 datasheet only mentions using a helper byte register for reading 16bit timer registers
[11:06:51] <twnqx> if tcnt1 then changes between the two reads, you still have the old value that matches m_offset
[11:06:56] <twnqx> and you're off by one timer tick
[11:07:28] <ambro718> twnqx: which code are you referring to?
[11:07:55] <twnqx> <ambro718> twnqx: heh, it's a nasty problem. Suppose this: cli(); read m_offset, read TCNT1; sei(); <- with swapped m_offset and tcnt1 reads
[11:08:01] <ambro718> twnqx: oh I see
[11:08:10] <ambro718> that's a nice observation, thanks!
[11:08:18] <twnqx> and yes, there is a chance between cli and tcnt1 read.
[11:08:25] <ambro718> it doesn't matter
[11:08:38] <ambro718> does it?
[11:08:51] <twnqx> yes. you might read 0 without incrementing the offset
[11:09:04] <ambro718> right...
[11:09:35] <ambro718> ok I'll just keep my code that reads offset twice, I'm sure that one's correct, and it doesn't need to disable interrupts
[11:09:50] <twnqx> what does sync_syncronize do?
[11:09:57] <ambro718> memory barrier
[11:11:03] <ambro718> basically just makes sure this code compiles into what you want it to ;)
[11:11:15] <ambro718> I could do some asm if I knew any
[11:11:34] <Tom_itx> learn
[11:11:51] <twnqx> my guess it that it's a nop on avr
[11:12:19] <ambro718> twnqx: it's an order to the compiler no to reorder memory accesses for optimization purposes
[11:12:45] <ambro718> see this,
http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder
[11:14:57] <twnqx> interesting. never observed that in any of the code i read.
[11:15:18] <twnqx> however
[11:15:41] <twnqx> it might be related to a particular crash with cli/sei i observed but never fully debugged
[11:17:25] <twnqx> hm
[11:17:43] <twnqx> call overhead. However, the macro also implies a <i>memory barrier</i>
[11:17:43] <twnqx> which can cause additional loss of optimization.
[11:17:51] <twnqx> # define cli() __asm__ __volatile__ ("cli" ::: "memory")
[11:18:05] <twnqx> so memory barriers to not suffice to disable reordering
[11:18:11] <twnqx> right?
[11:19:48] <ambro718> they disable reordering between reads of *volatile* variables
[11:20:13] <ambro718> if you have other variables that may change from interrupts etc. you need to make them volatile
[11:21:28] <beaky> hello
[11:21:41] <beaky> what software do you guys use to prototype your hardware designs?
[11:24:51] <Tom_itx> i use eagle
[11:24:55] <thetruthisoutthe> for schematic, gschem
[11:25:04] <twnqx> for schematics and pcbs, eagle
[11:25:12] <twnqx> for analog parts of it, ngspice
[11:25:41] <thetruthisoutthe> btw eagle is free now and avail on linux?
[11:25:50] <vectory_> i use ltspice for petty simulation, but i have no clue where to get externa libraries
[11:25:58] <twnqx> it's the same like the past 10 years, thetruthisoutthe
[11:26:12] <thetruthisoutthe> never used it
[11:26:13] <twnqx> it always was available on linux, and there always was a size-restircted free version
[11:26:25] <thetruthisoutthe> okey
[11:26:28] <thetruthisoutthe> so no change
[11:26:38] <twnqx> iirc the limits are two layers and half a euro pcb board (80x100mm²)
[11:27:03] <RikusW> everything works on linux as long as you have virtualbox installed :-P
[11:27:12] <thetruthisoutthe> and you use half size components, and enlarge it using scribus when done ofc
[11:27:23] <twnqx> lol
[11:27:29] <twnqx> scribus expands gerber files?
[11:27:39] <thetruthisoutthe> print is as eps lol.
[11:27:39] <beaky> so eagle lets me run an avr 100% and test out my designs? :D
[11:27:46] <beaky> maybe I should buy it :D
[11:27:47] <twnqx> no
[11:27:50] <beaky> ah :(
[11:27:54] <twnqx> i was afraid that that was your question
[11:28:09] <twnqx> i know noone who dry-tests.
[11:28:19] <beaky> so EAGLE is more for designing a PCB to be sent to some printer?
[11:28:23] <twnqx> yes
[11:28:26] <theBear> or drawing a circuit
[11:28:27] <thetruthisoutthe> beaky<= make a board, solder your microcontroller, program it, then try it out!
[11:28:34] <vectory_> avr studio is the best bet for emulation, but generally debugging is done with jtag and debugwire and uart etc
[11:28:42] <beaky> ah
[11:29:05] <beaky> yeah avr studio is great for making sure my code makes sense before I flash it into my chip
[11:29:47] <twnqx> avr studio would never be able to test my code \o/
[11:29:57] <twnqx> too many external hardware
[11:30:08] <twnqx> too much*
[11:31:12] <beaky> ah
[11:33:31] <ambro718> any ideas about how to manage a software timer queue in avr, to provide multiple "timers" with just one hardware timer?
[11:33:57] * twnqx just uses an array
[11:34:10] <ambro718> I'm specifically interested in the fastest way to keep the smallest timer (the one which needs to happen the soonest)
[11:34:10] <twnqx> and excelusively runs with 1khz timer interrupts
[11:34:25] <twnqx> no timer values
[11:34:43] <ambro718> currently I'm using a sorted linked list and when a new timer is to be inserted I just do a linear search
[11:34:51] <twnqx> same
[11:34:57] <twnqx> no well
[11:35:02] <twnqx> an array
[11:35:10] <ambro718> ah so you memmove it?
[11:35:18] <twnqx> no, i set an initial upper limit
[11:35:21] <twnqx> compile time
[11:35:44] <ambro718> so you do a linear search to find the smallest timer then, as opposed to keeping it sorted?
[11:36:03] <twnqx> i don't run timers, i only have timeout/delay events
[11:36:06] <twnqx> my code sucks
[11:36:14] <ambro718> I'm thinking of trying a heap
[11:36:15] <twnqx> 99% inside interrupt handlers
[11:36:32] <beaky> how do I do input capture in my avr?
[11:36:35] <twnqx> which means that the code has to work without interrupts and completion signals
[11:36:48] <ambro718> I made a very fast event loop, I try to do as much as possibe in the event loop except very time critical events
[11:37:19] <ambro718> most ISRs just post to the event queue
[11:37:21] <twnqx> i would probably go for a limited rtos approach if i were to rewrite this code
[11:37:56] <twnqx> though i'm scared to save 30 registers
[11:38:06] <twnqx> and reload 30 regs
[11:38:07] <twnqx> for the scheduler
[11:38:17] <twnqx> 150-200 cycles is a lot
[11:38:20] <ambro718> I'd like to keep my code portable, so I'm avoiding RTOS stuff for now
[11:38:39] <twnqx> i'd roll my own :P
[12:15:35] <beaky> after I design my circuit on eagle, how do I make it come to life?
[12:16:21] <twnqx> you order the components and PCBs
[12:16:25] <twnqx> solder it all together
[12:16:25] <theBear> erm, you make a circuit board and put parts on it
[12:16:26] <twnqx> and use it.
[12:17:35] <ambro718> twnqx: how about a solution something like this: cli(); cap_tcnt = TCNT1; if (cap_tcnt == 0) { cap_tcnt--; } cap_offset = offset; sei(); return ((cap_offset<<16)+cap_tcnt);
[12:18:08] <twnqx> you still don't know if the max->0 transition happened before the cli or betwee the cli and timer reading
[12:18:09] <ambro718> that assumes that after the sei instructions the next instruction reads the first byte of the TCNT1, which due to buffering samples it in that cpu lock
[12:19:31] <ambro718> twnqx: the assembly would look like this: cli; read first byte of tcnt; read second byte of tcnt; the only problem is if the overflow happens between "cli" and the "read first byte"
[12:19:43] <twnqx> yes.
[12:19:58] <ambro718> if it happens between "read first byte" and "read second byte" it's a non-issue because we already got the old value due to buffering
[12:20:06] <twnqx> though i'm not sure if you can even read a timer atomically with a guarantee of no overflow :P
[12:20:23] <twnqx> like between high byte and low byte, regardless of order.
[12:20:47] <ambro718> twnqx: if the overflow happened in that problematic case (between cli and read first byte), out read value will be zero and the if will catch it
[12:21:06] <twnqx> no it won't
[12:21:10] <ambro718> huh?
[12:21:13] <twnqx> since oyu can't be sure that the 0 wasn't there before the cli.
[12:21:39] <ambro718> so what if it was
[12:21:44] <twnqx> then you decrement
[12:21:48] <ambro718> ah, yes, problem again...
[12:22:21] <ambro718> it would work with no prescaler though :D
[12:22:41] <twnqx> i doubt you ever can be sure
[12:22:59] <twnqx> and now i really wonder if you can read a 16bit timer with a guarantee of it not ticking in betwen
[12:23:02] <twnqx> between
[12:23:55] <ambro718> the only problem with reading a 16bit timer is if an interrupt happens between the read that itself reads TCNT. Something like that, I remember it from reading the docs.
[12:25:07] <ambro718> IIRC, when you read the first byte of TCNT, the MCU will implicitly sample the other byte and it will remain there buffered for you to read... unless an interrupt corrupts it. I'm not sure what first and second are, but the compiler does.
[12:26:04] <twnqx> When the low byte of a 16-bit register is read by the CPU, the high byte of the 16-bit register is copied into the temporary
[12:26:04] <twnqx> register in the same clock cycle as the low byte is read.
[12:26:16] <ambro718> yeah, that's it
[12:26:29] <twnqx> To do a 16-bit write, the high byte must be written before the low byte. For a 16-bit read, the low
[12:26:29] <twnqx> byte must be read before the high byte.
[12:26:35] <twnqx> i wouldn't bet on the compiler here
[12:27:27] <twnqx> If an interrupt
[12:27:27] <twnqx> occurs between the two instructions accessing the 16-bit register, and the interrupt code
[12:27:27] <twnqx> updates the temporary register by accessing the same or any other of the 16-bit timer registers,
[12:27:27] <twnqx> then the result of the access outside the interrupt will be corrupted.
[12:27:37] <twnqx> so only if YOU mess with the registers during the interrupt the state is corrupted :P
[12:27:49] <ambro718> yeah, pretty much what I said :D
[12:29:50] <beaky> my avr only has 3 interrupts, but my application has more than that amount of buttons. How do I manage?
[12:30:07] <twnqx> you just read the buttons periodically
[12:30:13] <beaky> like polling?
[12:30:30] <ambro718> beaky: it doesn't have the Pin Change Interrupts?
[12:30:35] <beaky> what's pin change interrupts?
[12:31:11] <ambro718> my avr has 4 PCIs which happen when any of the 8 pins on a port trigger
[12:31:54] <ambro718> you can just check the pin state in the interrupt if you use more then 1 pin on a port
[12:32:15] <beaky> ah
[12:32:28] <Horologium> beaky, what avr are you using?
[12:32:34] <beaky> I am using the 8-bit ATMega16A
[12:32:56] <Horologium> probably too old to have pin change interrupts then.
[12:33:00] <beaky> so I should just set my interrupt to sense rising edges on the whole bunch of pins, then upon that interrupt I can poll which button was pressed?
[12:33:21] <Horologium> search the datasheet for "pin change"
[12:33:35] <ambro718> I just did, seems it doesn't have them
[12:33:40] <beaky> aww :(
[12:33:42] <Horologium> that's the older generation.
[12:33:56] <Horologium> need the atmega168 for that I think.
[12:34:08] <twnqx> beaky: so poll from your mainloop
[12:34:08] <beaky> I thought the atmega16a was a brand new modern mcu
[12:34:19] <twnqx> but keep the sleep()
[12:34:28] <twnqx> so basically you'll poll once after each timer interrupt
[12:34:28] <beaky> ah
[12:35:38] <beaky> so if I am making a remote-control thingy, I should be using a different avr?
[12:35:43] <thetruthisoutthe> beaky<= next get an atmega48 or atmega168
[12:35:52] <thetruthisoutthe> the pa version is even newer
[12:36:34] <theBear> surely it does, even the oldest avrs have some pins that can trigger ints
[12:36:53] <thetruthisoutthe> if you want much processing power, then xmega
[12:38:18] <Horologium> but nobody really realizes the power of the AVR, even running at 1MHz they rock.
[12:38:38] <thetruthisoutthe> Horologium<= i think i have reached the limit of my atmega168pa at 8MHz :(
[12:38:41] <beaky> wow the xmega seems overkill, probably more fit for a fighter plane than a hobbyist's remote control :D
[12:46:43] <twnqx> serial required software implementation of rts/cts handshake at that bitrates. oh, the fun...
[12:46:56] <twnqx> and i didn't route the pins to interrupt enabled pins. yey.
[12:47:05] <Horologium> fun fun
[12:47:43] <twnqx> so complex interactions of software timers, circular buffers, etc
[12:48:32] <twnqx> and i really need to run my timer at 10khz so be closer to really delaying 1ms between packets, in worst case i end up with 0 after queueing the handler :/
[12:50:16] <twnqx> but heck, i managed to do what i wanted
[12:50:42] <twnqx> (almost, a programming error is still lurking somewhere)
[12:53:30] <twnqx> oh, right. logging to SPI flash is also done :P
[12:53:45] <twnqx> so yeah, you can load an AVR
[12:53:53] <Horologium> oh, definitely.
[12:54:16] <twnqx> though i guess my "50hz rectangular signal generator" is the other extreme
[12:54:22] <Horologium> from the sounds of it, this remote control app is nowhere near loading down an avr, even having to poll a bunch of buttons.
[12:56:21] <thetruthisoutthe> twnqx<= that is in asm i assume
[12:56:29] <twnqx> why
[12:56:43] <twnqx> _delay_ms (10); PORTB ^= 0x01;
[12:56:45] <twnqx> done
[12:57:01] <thetruthisoutthe> i mean the translations
[12:57:41] <thetruthisoutthe> also if you are on 8 bit, and you do array logging there are 16 bit operations
[13:07:36] <twnqx> i know i have room for improvements (a 256byte ringbuffer for serial was too small btw)
[13:07:43] <twnqx> anyway, i'm off for some time
[13:16:10] <tzanger> jesus fuck it's insane how much dirt you take out of a 2x12x1 hole
[13:16:13] <tzanger> I have another 12' to go and I'm at like 7 wheelbarrows-full
[13:16:31] <theBear> hehe yeah, dirt gets fluffier when you dig it up
[13:16:43] <tzanger> fuck that, I hit hard clay 10" down
[13:17:07] <tzanger> digging down to put a drainage ditch in
[13:17:20] <tzanger> well actually I'm digging a foot down to put a few inches of gravel in then putting the dirt back on top
[13:17:45] <tzanger> or rather "top dressing" since it's not as dense. rocks under clay doesn't help much once the clay settles again
[13:17:56] <tzanger> I just can't get over how much dirt there is
[13:18:23] <tzanger> I have 4 or 5 yards of top dressing sitting in the driveway to go over the backyard too when I'm done all this
[13:26:09] <rue_bed> sand?
[13:26:42] <theBear> top dressing is nice soil
[13:26:46] <theBear> sand is sand
[13:37:21] <beaky> avr has been my only introduction to the wonderful world of mcus; what other alternatives to avr are there, and how do they compare to avr?
[13:38:02] <rue_bed> there is 8051 its been around since the beggining of time, its used in industrial stuff
[13:38:07] <rue_bed> everything else sucks
[13:38:12] <beaky> ah
[13:38:18] <rue_bed> (other than 8051 and avr)
[13:38:39] <beaky> how is 8051 pronounced?
[13:38:49] <theBear> lol
[13:38:54] <rue_bed> 80 51
[13:39:03] <theBear> ate oh five wun
[13:39:10] <theBear> you crazy foreigners
[13:39:22] <Horologium> 8051, 68k pic, msp430, renesas, arm
[13:39:23] <beaky> (btw why do mcus and other electronic components have such random naming? no wonder intel won with its simple 'i3, i5, i7' scheme)
[13:39:30] <theBear> but 6800 is sixty eight hundred
[13:39:57] <Horologium> each has it's unique properties and uses.
[13:39:59] <beaky> ah i say it as eighty-fifty-one
[13:40:00] <theBear> i gone off intel completely since that, i liked the old ???86 and pentium names
[13:40:12] <rue_bed> 68k sucks, pic really suck, msp430 are silly, arm is not a microcontroller, its a microprocessor, renesas?
[13:40:50] <Horologium> http://am.renesas.com/
[13:41:35] <rue_bed> I'm not gonna switch, its not worth it, but how many input clocks/instruction?
[13:41:44] <theBear> amd had cool names too
[13:41:53] <Horologium> oh, don't forget cypress.
[13:42:04] <theBear> heh, why not ?
[13:42:05] <beaky> i guess avr's competitive adnavtage over those others are newbie-friendliness?
[13:42:29] <Horologium> beaky, yes.
[13:42:37] <theBear> nah, it's their awesomeness, they were the first micro with sensible logic voltage programming, sensible prices, etc etc
[13:42:43] <rue_bed> avrs are good beause
[13:42:53] <theBear> just beause
[13:43:06] <rue_bed> a) there are open source programmers for them, you can make one yourself for a few bucks
[13:43:30] <rue_bed> b) open source, free C compiler, not having to program in asm is a bonus
[13:43:33] <beaky> and the avr toolchain is free and complete
[13:43:35] <Horologium> or for a few pennies if you have a parallel port.
[13:43:59] <rue_bed> c) support, lots (less now cause of arduino) of people code for avrs
[13:44:23] <beaky> ah i thought avr was just for hobbyists and education
[13:44:29] <theBear> nup
[13:44:33] <Horologium> they are used commercially too.
[13:44:38] <rue_bed> d) performance, its pretty good, pics have higher clock rates but a fraction of the performance
[13:44:39] <Horologium> pic has a larger commercial base yet
[13:44:47] <Horologium> and 8051/8052 has even larger commercial bae.
[13:45:09] <Horologium> cypress chips are everywhere as well but nasty to work with from the hobby perspective.
[13:45:58] <rue_bed> 8051 have , for the most part, less performance than the avrs, less features, but lots of code examples, documentation, books,
[13:46:46] <beaky> because its been around longer?
[13:47:09] <rue_bed> I think 8051 been around since 78 or 80
[13:47:18] <theBear> because technology improves, and avrs were designed in a better age
[13:48:39] <rue_bed> there are a large number of avrs made that cover a wide variety of different built in features
[13:49:08] <rue_bed> some have lots of adc, some have lots of pwm, some have lots of uarts, some have lots of interrupts
[13:49:36] <theBear> most have a few of all those
[13:49:38] <rue_bed> some have usb, some have microprocessor buses
[13:50:00] <rue_bed> some have lcd controllers, some have keybaord controllers
[13:53:02] <rue_bed> beaky, there is one other important differnt thing to look into
[13:53:15] <rue_bed> CPLD (FPGA)
[13:53:31] <beaky> hmm fpga seems very advanced
[13:53:39] <rue_bed> they do what you want really fast
[13:55:01] <rue_bed> its not the same tho
[13:57:58] <beaky> avr is pretty fast too; engineered to run at 32MHz and 1 instruction per Hz, which is ideal for blinking leds :D
[13:59:49] <theBear> err, most of them don't go past 20mhz
[14:00:05] <beaky> 20MHz ought to be enough for everybody
[14:00:27] <beaky> :D
[14:04:56] <rue_house> they upped it from 16?
[14:05:00] <rue_house> coool
[14:05:17] <beaky> yes my professor overclocked one to that high
[14:05:19] <beaky> somehow
[14:05:39] <rue_house> just push it in
[14:06:12] <rue_house> ok this stepper controller code is looking good
[14:07:07] <rue_house> it should go nice with my void SimotaniouslyLinearlyInterpolateMultiAxis(axies_t * this); function
[14:09:08] <tzanger> and I'm done for the afternoon. let the sun go away and I'll finish off
[14:39:15] <vectory_> "they were the first micro with sensible logic voltage programming" what was?
[14:40:34] <theBear> avr afaik... first i ever knew about for sure....
[14:40:59] <theBear> pics needed 12v and transistors and stuff, eeproms are wide and tricky, avr is just a few lines at nice sensible levels
[14:53:42] <RikusW> 12V ISP instead of HVPP would have been nice
[14:54:00] <RikusW> just put 12V on reset instead of 0V when fuses are screwed
[14:54:39] <jacekowski> you have to clock it and do other things to it
[14:56:59] <theBear> only if you screw up, in the meantime i was still able to buy a chip for a few bucks and stick it on a scrap of vero and enter the exciting world of superlow partcount micros :)
[15:10:41] <ambro718> is it better to disable a specific interrupt in critical sections instead of disabling all interrupt, if I know that only that interrupt could interfere?
[15:17:41] <tzanger> ambro718: that would give you better interrupt latency on the interrupts that aren't going to interfere
[15:18:01] <tzanger> ambro718: your critical sections should usually do nothing more than setting flags/variables
[15:18:10] <tzanger> and if you can do that atomically you don't even need to disable interrupts
[15:18:36] <ambro718> many of my critical sections insert or remove from linked lists
[15:19:42] <tzanger> that's fast enough that you should be able to get away with just cli/sti
[15:21:02] <ambro718> anyway I was wondering if there's a lockless algorithms for that kind of stuff
[15:21:35] <ambro718> I remember seeing something in linux kernel... I think it did something, then checked if there was a conflict and did it again, something like that
[15:23:47] <jacekowski> spinlocks
[15:23:52] <tzanger> yes there are, you need to find someone more in line with CS than me
[15:23:57] <tzanger> spinlocks are not lockless
[15:24:19] <ambro718> indeed, that's why they have "lock" in them ;)
[15:24:19] <tzanger> http://lwn.net/Articles/340400/
[15:24:38] <tzanger> of course it requires atoming compare-and-exchange CPU instructions
[15:24:48] <ambro718> avr doesn't have those?
[15:25:02] <tzanger> I don't think so
[15:26:01] <tzanger> I suspect you are performing early optimization, in which case slap yourself with any of Knuth's works and rethink what you're dong
[15:26:01] <tzanger> doing
[15:26:12] <ambro718> probably :D
[15:27:15] <jacekowski> locks are ok
[15:27:20] <jacekowski> deadlocks are not
[15:27:21] <ambro718> on the other hand, Linus says "some people like micro-optimization, and they say, if you like something, you should do it"
[15:28:27] <theBear> well, it's hard to argue with that
[15:28:31] <jacekowski> well, optimising early isn't always a bad thing, but it's more about just writing a code in a way that isn't horrible when it comes to performance
[15:28:56] <theBear> that too, optimisation isn't much use when it makes things worse :)
[15:29:06] <theBear> kinda defeats the whole purpose
[15:29:16] <jacekowski> so it helps if you think about it
[15:29:24] <ambro718> I find that good optimization often looks nice :D
[15:29:42] <theBear> bad things often look nice until you notice why they're bad too :)
[15:29:47] <jacekowski> and sometimes leaving stuff unoptimised in one place allows for much bigger optimisation in other
[15:30:05] <jacekowski> and don't optimise things if it makes them unclear about what they do
[15:30:20] <jacekowski> that's how debian openssl bug happened
[15:30:42] <jacekowski> nobody had any idea what that piece of code is doing and it was looking like nothing important
[15:30:45] <jacekowski> so they've removed it
[15:31:12] <jacekowski> while in fact it was the code that was seeding the prng
[15:31:29] <jacekowski> in some obscure way
[15:36:12] <ambro718> what's some good software for reading datasheets?
[15:36:26] <MrM0bius> adobe acrobat
[15:36:45] <ambro718> I find it annoying how I jump via a link and then have problems getting my way back, for example. Bookmarks in document would be useful to have.
[15:37:19] <ambro718> ah, my reader actually has those, I just noticed :D
[15:39:31] <theBear> lol
[17:13:03] <ambro718> how (in)efficient are functions pointers on AVR?
[17:13:26] <ambro718> how many instructions does it generally take to do a function pointer call?
[17:16:50] <tzanger> you have the compiler output, take a look at the intermediary files, especially the source code
[17:17:31] <specing> ambro718: two ldi and one CALL => 6 cycles
[17:17:57] <ambro718> specing: thanks. That seems fast enough.
[17:18:00] <specing> YMMV though
[17:31:44] <seldon> Probably not ldi, since the pointer is not usually known at compile time. So: 2*ld + call -> 8 cycles (on atmega), if the pointer has to be loaded from memory.
[17:33:10] <stanreg> I'd like my uC to wake-up upon any INT0 logic change. OTOH, I'd also like it to save as much power when sleeping, so turning all pins to input w/ pull-up enabled is suggested. Would that somehow interfere with the INT0 firing condition? Should I not pull-up on INT0?
[17:38:28] <stanreg> Well, let's try this other question, then ... if my uC awakens on an INT0 event, does it execute one more instruction from where it went to sleep before executing the INT ISR?
[17:40:14] <stanreg> Found my answer for the 2nd question.
[17:40:15] <tzanger> stanreg: I just did this on attiny13
[17:40:33] <tzanger> stanreg: INT0 requires ioclk. pin change interrupt does not. To maximize power savings, use EINT
[17:41:28] <stanreg> tzanger: I don't see EINT on tiny48 -- hm.
[17:41:38] <tzanger> you need your i/o pins to be in whatever condition they need to be in to detect the change
[17:41:52] <tzanger> so if you need the avr pullup, you'll need to leave it on of course
[17:42:19] <stanreg> tzanger: matter of fact, I don't see EINT on the tiny13 either -- which pin did you use?
[17:42:36] <tzanger> pin change works on all attiny pins
[17:43:11] <stanreg> Ah, ya mean "PCINT".
[17:43:32] <tzanger> PC
[17:43:33] <tzanger> yeah
[17:43:38] <tzanger> I just looked at my source
[17:43:40] <stanreg> I thought PCINT used more power than INT, hm.
[17:44:05] <tzanger> at least on attiny INT0 needs ioclk to detect pin change, unless it's a level detect.
[17:44:31] <tzanger> attiny specifically says PCINT does not require ioclk
[17:53:57] <stanreg> tzanger: I see. Did you end up turning off ioclk?
[18:09:35] <OndraSter_> tzanger, it does say that, but check the waveform below it
[18:09:41] <OndraSter_> it requires ioclk for PCINT
[18:11:16] <OndraSter_> I tried it in tiny13a simulator -- requires io clk
[18:11:20] <OndraSter_> in deep sleep it did not work
[18:11:26] <OndraSter_> regular INT0 did
[18:11:28] <OndraSter_> (level change)
[18:11:38] <OndraSter_> high-low
[18:12:15] <twnqx> that's what the docs of most avrs say
[18:12:30] <twnqx> external interrupts are the only thing that can wake them from sleep states with io clock off
[18:12:46] <OndraSter_> yes
[18:12:49] <l9> ello twnqx :)
[18:12:53] <OndraSter_> bless Atmel for xmega where any pin can do any interrupt
[18:13:03] <OndraSter_> well, except for one pin per port it can do in deep sleeps
[18:13:09] <OndraSter_> iirc
[18:13:13] <OndraSter_> or is it now that all the pins..
[18:13:23] <twnqx> hey l9
[18:14:16] <twnqx> OndraSter_: i am too lazy to grab my non-soldered attiny13a and plug it into something to try it
[18:14:20] <OndraSter_> :)
[18:14:23] <OndraSter_> I know that feeling
[18:14:28] * twnqx remembers the annoyance the ADC was
[18:15:17] <twnqx> i treid to send my chip to sleep (for SLEEPING) which would trigger the ADC to sample and generate an interrupt which would wake it up...
[18:15:19] <twnqx> rinse, repeat
[18:16:01] <twnqx> so sad you can't tell the ADC to not sample on entering sleep but only on timer
[18:16:31] <thetruthisoutthe> only int0 ant in1 works without clock i believe
[18:16:47] <twnqx> not 0-7?
[18:16:58] <thetruthisoutthe> wake-up sources are stated in the datasheet
[18:17:12] <thetruthisoutthe> well my atmega168 only has 0 and 1
[18:17:39] <thetruthisoutthe> others are pinchange interrupts that require clock
[18:18:13] <thetruthisoutthe> int0 and int1 are asynchronous
[18:19:14] <twnqx> int0-7, twi address match
[18:37:02] <stanreg> So, using ext interrupts is better than PC interrupts, for deepest sleep (max power savings), ay?
[18:37:26] <stanreg> Even in the case where no ext clk is used?
[18:38:52] <twnqx> it all depends on the chip
[18:39:20] <twnqx> at90can says "do not use this without external clocking"
[18:41:02] <stanreg> Sorry. Tiny45.
[19:56:20] <tzanger> OndraSter_: PCINT definitely does not require ioclk
[19:58:40] <tzanger> see section 6.1.2
[19:58:44] <tzanger> and fuck I am backward again
[19:58:51] <tzanger> it's external interrupt that does not require clock
[19:59:53] <Tom_itx> int0 int1
[20:00:00] <tzanger> no I am right
[20:00:03] <tzanger> section 9.2
[20:00:07] <Tom_itx> make up your damn mind!
[20:00:09] <Tom_itx> :)
[20:00:14] <tzanger> Pin change interrupts on PCINT[5:0] are detected asyn- chronously. This implies that these interrupts can be used for waking the part also from sleep modes other than Idle mode.
[20:00:34] <Tom_itx> we call those port interrupts
[20:01:04] <tzanger> PCINT = pin change, that's what I"m using in my crazy little design
[20:01:12] <Tom_itx> yeah same thing
[20:01:18] <tzanger> INT0 can do level-based wakeup
[20:01:20] <Tom_itx> but any port pin will trigger it
[20:01:21] <tzanger> that's where I keep getting confused
[20:01:29] <tzanger> yes, you mask off what you don't want interrupting
[20:02:29] <ambro718> huh, that reminds me, I forgot to do the masking right in my PinWatcher abstraction...
[20:14:53] <ambro718> how can I manipulate with register addresses in C? That is, get the address of a register, and write to a register with a given address.
[20:15:13] <ambro718> it will make my C++ templates easier
[20:15:42] <ambro718> because I can't just pass a register to a C++ template... I need to create class specializations that read and write that register, for example.
[20:16:11] <ambro718> but I *can* pass an integer register address to a template parameter
[20:24:18] <seldon> You could try the _SFR_ADDR macro.
[20:24:48] <seldon> I don't know if that counts as a compile time constant for the purposes of template instantiation, though.
[20:26:09] <ambro718> it does
[20:26:19] <ambro718> I presume the only way to use these is via inline asm?
[20:27:43] <seldon> Well, once you have the address, you can use _SFR_IO8 to get the *(volatile foo) stuff back.
[20:28:05] <seldon> Hold on, _SFR_MEM8.
[20:28:11] <seldon> I think.
[20:29:20] <seldon> I am not entirely convinced that this is a good idea, though.
[20:29:57] <seldon> The compiler may not be able to figure out that you're clobbering the registers it depends on.
[20:30:47] <Horologium> you can declare a variable as register..
[20:31:12] <Horologium> and the compiler will, I think, try to assign a register to it.
[20:33:48] <ambro718> _SFR_IO8(IoAddr) = value; like this?
[20:33:52] <seldon> Well, yes. But you cannot tell it which register to use or to use the same register twice. For that you need inline-asm or tricks like the one ambro718 seems to be implementing, and either of those seems likely to have weird side effects (such as the values of variables changing).
[20:34:36] <ambro718> which "registers it depends on"?
[20:34:49] <ambro718> It's not just supposed to randomly use the I/O registers
[20:35:05] <seldon> Ah, so you're only talking about I/O registers?
[20:35:09] <seldon> Not r0-r31?
[20:35:15] <seldon> I misunderstood.
[20:35:17] <ambro718> if you're talking about CPU registers used in inline asm, yes, I know about hot to use them
[20:35:38] <ambro718> the inline-asm has a clobber list or something
[20:37:13] <ambro718> yeah I wasn't very clear, sorry
[20:39:40] <seldon> Well, what you get is stuff like #define TCNT0L _SFR_IO8(0x28). _SFR_IO_ADDR seems like the one you want to use here to get 0x28, and _SFR_IO8(_SFR_IO_ADDR(TCNT0L)) is essentially back and there again.
[20:40:47] <ambro718> thanks
[20:40:56] <ambro718> what are register addresses by the way? 16-bit?
[20:41:31] <seldon> That depends on the chip.
[20:41:42] <ambro718> but is 16-bit enough or should I use 32-bit?
[20:42:01] <seldon> 16 bit should be enough.
[20:42:22] <seldon> Unless you want this to run on avr32.
[20:42:55] <ambro718> okay will use 32 since it's just a compile time thing :)
[20:44:05] <seldon> On all 8-bit chips I know that have memory operations, registers are mapped below 0x100.
[20:47:13] <seldon> (all 8-bit avr chips)
[20:49:10] <ambro718> what's wrong with this inline asm for setting a bit?
[20:49:12] <ambro718> asm("sbi %0,%1" :: "i" (_SFR_IO_ADDR(PCMSK0)), "i" (0));
[20:49:42] <ambro718> Error: number must be positive and less than 32
[20:50:24] <ambro718> it works for PORTA but not PCMSK0
[20:53:22] <seldon> PCMSK0 is not is not an I/O register
[20:53:35] <ambro718> what is it then?
[20:55:38] <seldon> Well, this is interesting. avr-libc has it as _SFR_IO8(foo) on some and _SFR_MEM8 on other platforms. But it's not I/O anywhere, I don't think, so you'll want to use sbr instead of sbi.
[20:55:58] <ambro718> Some of the status flags are cleared by writing a logical one to them. Note that the CBI and SBI instructions will operate on
[20:56:00] <ambro718> all bits in the I/O register, writing a one back into any flag read as set, thus clearing the flag. The CBI and SBI instructions
[20:56:01] <ambro718> work with registers 0x00 to 0x1F only.
[20:58:12] <seldon> That's a condition you can handle in template magic, at least.
[20:59:15] <ambro718> I could, but I just made separate setBit and softSetBit functions
[20:59:28] <ambro718> at least you know wheter it's atomic or not
[21:00:42] <ambro718> you always know what kind of registers you're dealing with (e.g. one of the PCMSKn, they're all the same with regard to sbi)
[21:03:04] <seldon> sbr and cbr are also atomic, because single instruction.
[21:04:00] <seldon> You could also just write _SFR_FOO(...) |= _BV(bit);
[21:05:25] <tzanger> does avr have atomic swap and test?
[21:09:15] <Xark> tzanger: Wouldn't you only need that with external RAM and multiple CPUs?
[21:09:20] <tzanger> doesn't look like it, avr-libc just disables interrupts
[21:09:35] <tzanger> Xark: no, ISRs can interrupt mid-operation
[21:10:07] <Xark> tzanger: Not mid instruction (but you may need interrupt disable on multi ops).
[21:10:42] <Xark> Actually IIRC, it is in the instruction set, just not implemented on any AVRs I have used...
[21:10:52] <tzanger> Xark: correct
[21:11:05] <tzanger> there are *very* few CPUs which have the ability to interurpt mid-instruction
[21:12:01] <Horologium> you can interrupt any processor mid instruction.
[21:12:04] <Horologium> just cut power.
[21:13:17] <tzanger> lol, sure
[21:13:21] <tzanger> but you can never tell for sure
[21:14:14] <seldon> Suppose I were to build a processor with a storage capacitor attached.
[21:14:19] * Xark notes there is XCH instruction in AVR (that does atomic reg <-> memory swap).
[21:14:42] <tzanger> not quite useful enough... no way to test-and-set atomically with that exchange
[21:15:19] <Xark> tzanger: Plus that instruction isn't present on most common AVR parts (AFAIK).
[21:19:39] <Xark> tzanger: Ahh, here is what I was looking for. There is also LAS (load and set), LAC (load and clear) and LAT (load and toggle). Again, I haven't seen them implement, but I think those are the atomic ops you are looking for (probably unimplemented since not really needed with uni-processor).
[22:25:51] <TechIsCool> So I have a weird question that I have never tried to answer but would like to know is possible. I have a for loop going from 0 to 255 in about 1.5 seconds controlling a pwm brighness curve triggered from an external interrupt. half way though this at about say 128 there is another irq and I want take the second pwm channel from 0 to 255 how can I do this? If this was multi threaded it would...
[22:25:51] <TechIsCool> ...be simple but I am not sure how to do this on a single thread
[22:29:17] <theBear> umm, assuming you doing nothing else, have a variable for each pwm level, throw away the for loop and just reset/start adding to each variable as needed, and setting the pwm to that value each time around
[22:29:29] <theBear> each time around the main loop that is
[22:33:21] <theBear> and if you need/want you can have a little if or two to stop them going up or reset them at 255 or whatever
[22:33:40] <TechIsCool> make sense
[22:34:30] <theBear> you can even use that if (and alternately the interrupt) to set another pair of variables to say, 0, 1 or 2 and ALWAYS add those every loop around, then you get a fixed length main loop/timing and can make the pwm increase at an arbitrary rate
[22:35:36] <TechIsCool> so you could do stuff in between is what you are saying?
[22:37:09] <theBear> yeah sure, just be aware that depending on the stuff you may make the pwm ramping irregular/uneven in timing
[22:37:20] <theBear> tho you probably won't notice a few cycles here and there
[22:37:35] <TechIsCool> right
[22:37:58] <TechIsCool> unless I group them and force whatever else I have to wait until its finished
[22:38:59] <theBear> mmm, i'm not sure what else you need to do or any of that, but i think yer getting the picture
[22:39:21] <TechIsCool> I do
[22:39:34] <TechIsCool> basically
[22:39:45] <theBear> if you REALLY need something to happen on a regular timing you can use a timer to trigger an interrupt regularly too, but you don't wanna get carried away with too many interrupts or they start 'getting in the way'
[22:39:49] <TechIsCool> if (pwm1 == true && TCD0.CCA <= 255)
[22:39:50] <TechIsCool> TCD0 += TCD0;
[22:40:08] <TechIsCool> need cca on the bottom line though
[22:40:54] <theBear> also it's good practice to keep the interrupt routines nice and short, so as not to get in the way of other things (possibly including interrupts)
[22:41:26] <TechIsCool> Yup dump to a temp variable and then do the processing in the loop not in the irq.
[22:42:38] <theBear> that's the spirit
