Back
[00:15:39] <rue_house> your factory need some slave labour yet?
[01:58:37] <microchip_sac> hello, can someone help me here?
[01:58:53] <microchip_sac> im trying to accomplish serial comm. between two avrs
[01:59:02] <microchip_sac> using the usart
[01:59:50] <microchip_sac> but its not working (the sender is supposedly sending, but the receiver is not receiving)
[02:00:39] <microchip_sac> both avrs are clocked at 1 MHz, and the data transfer is at 2400 bps
[02:06:48] <jacekowski> well, get a scope out and make sure that data is sent
[02:07:20] <jacekowski> and if it is, make sure that receiving end is configured correctly
[02:07:47] <microchip_sac> the prob is i dont have a scope (else i could have figured it out ages ago!)
[02:09:51] <microchip_sac> could i do it by sending the serial output to the input capture unit?
[02:10:04] <microchip_sac> if there is a signal, i could work out the problem?
[02:43:47] <microchip_sac> is the internal rc osc. good enough for usart?
[02:52:05] <hackvana> Out of the box? No, it drifts with temperature even if you calibrate it. However...
[02:52:59] <hackvana> In theory you could watch the pin state changes from the data the other side was sending you, and derive a factor describing how far out the the timing was, and use this to correct the RC oscillator on the fly.
[02:53:26] <hackvana> This trick is used with V-USB to calibrate the RC oscillator to give accurate USB packets.
[02:53:41] <Valen> could use internal temp sensor to help too one presumes
[02:53:49] <Valen> do they write to oscal hackvana?
[02:55:53] <hackvana> Yes, on the fly
[02:57:25] <Valen> is oscal in ram or only in flash?
[03:00:37] <RikusW> io IO
[03:00:40] <RikusW> in IO
[03:00:45] <microchip_sac> so should i use an external cystal?
[03:00:48] <RikusW> its a register
[03:01:01] <RikusW> for a start Rc is good
[03:01:14] <microchip_sac> but its not working, apparently
[03:02:19] <microchip_sac> do you want to see the code?
[03:02:27] <Valen> use an xtal if you can
[03:02:35] <Valen> then you know thats not the problem
[03:03:17] <microchip_sac> so the int. rc is not good at all for usart?
[03:03:27] <Valen> it can be
[03:03:40] <Valen> but if you have an xtal and room for one is it worth the hassle?
[03:04:32] <microchip_sac> i could try, but i cant help feeling it will make things more complicated...
[03:05:29] <microchip_sac> do you want to look over the code?
[03:05:37] <microchip_sac> or is that not the problem?
[03:08:17] <Valen> I don't know enough about avr uart to hep
[03:08:18] <Valen> help
[03:10:46] <microchip_sac> anyway, ill try clocking them externally
[03:10:59] <microchip_sac> and see whether it solves the prob
[03:11:03] <microchip_sac> thanks!
[04:35:55] <RikusW> microchip_sac: just don't set the external clock fuse...
[04:36:00] <RikusW> use external crystal
[04:55:24] <RikusW> jadew:
http://pastebin.com/v9UjjeRa
[04:55:33] <RikusW> solved the comport issue
[04:55:48] <RikusW> and got a race condition in my other code :-P
[06:19:35] <jadew> RikusW, why don't you dedicate a thread to it?
[06:21:11] <jadew> then you can do something like while (running) { ReadFile(); if (no timeout and no errors) { forward the data to another handler; } }
[06:21:17] <jadew> then the thread can block all it wants
[06:24:40] <RikusW> thats another option
[06:25:48] <RikusW> though had some bad experience with CommGetModemStatus in a thread in a console application, it blocks...
[06:26:12] <RikusW> until the primary thread calls CommGetModemStatus or GetMessage....
[06:26:30] <RikusW> seems threads and console apps don't mix too well
[06:26:38] <jadew> that's weird
[06:27:00] <jadew> no, they mix just fine, there might be an issue with that function
[06:27:06] <jadew> maybe it needs a message loop or soemthing
[06:27:20] <RikusW> think so
[06:27:28] <jadew> I can't find it in msdn
[06:27:52] <RikusW> its for getting DCD RI etc
[06:28:07] <jadew> are you sure that's how its called?
[06:28:14] <jadew> google doesn't know about it either
[06:29:01] <RikusW> CommGetModemStatus
[06:29:07] <RikusW> looking at its docs right now
[06:29:13] <jadew> link?
[06:29:16] <RikusW> vc++5
[06:29:51] <jadew> I think it's a custom function
[06:29:57] <jadew> there's no record of it in MSDN
[06:30:29] <RikusW> well its part of old VS97
[06:30:45] <jadew> still, should be there, I think
[06:31:08] <jadew> not to mention that ms isn't in the habbit of removing functions from the SDK
[06:31:25] <jadew> what library is it part of?
[06:31:28] <jadew> does it say that?
[06:31:50] <RikusW> GetCommModemStatus
[06:32:04] <RikusW> typo ...
[06:32:12] <jadew> ah ha
[06:32:25] <RikusW> copynpaste don't work from my VM :-P
[06:32:42] <RikusW> running XP in virtualbox
[06:32:47] <jadew> ah
[06:32:59] <jadew> it doesn't mention anything about a message loop
[06:33:31] <RikusW> looks weird when I alt-tab to pidgin in Linux
[06:33:47] <RikusW> even more so is seamless mode
[06:36:04] <RikusW> jadew: ever loaded a dll into another app ?
[06:36:35] <jadew> RikusW, yeah
[06:36:38] <RikusW> I did some handcoded asm doing loadlibrary in another exe
[06:36:42] <jadew> it's used to replace some functions
[06:36:50] <RikusW> then you can code the hack in C :)
[06:36:54] <RikusW> yep
[06:36:59] <RikusW> mess with IATs
[06:37:16] <RikusW> I've got a custom intercept function for that
[06:37:51] <RikusW> CreateRemoteThread is another interesting function
[06:38:08] <RikusW> and the timer message passing a function pointer... very dangerous
[06:38:41] <RikusW> WM_TIMER
[06:40:25] <jadew> I think I only used WM_TIMER like... twice
[06:40:52] <jadew> but it's not as dangerous as it may seem
[06:40:56] <RikusW> well sending it to another app with a function pointer can be -fun-
[06:41:36] <RikusW> especially if you loaded a dll using hooks
[06:42:11] <jadew> I don't think you can do it otherwise
[06:42:23] <jadew> because I don't think you can call upon a function from another process
[06:43:15] <RikusW> but you can send a message to -any- window
[06:43:38] <jadew> yeah
[06:44:04] <RikusW> you can even change another window's region iirc
[06:44:40] <RikusW> eg put a nice big hole in them
[06:44:54] <jadew> you can do anything to it that the originating process can do with it
[06:46:04] <RikusW> and those remain after the offending app closes...
[06:46:24] <jadew> yeah... but I see this more as a feature than an issue
[06:46:33] <jadew> because this means you can alter an app and add functionality
[06:46:38] <RikusW> can be used for mischief :-P
[06:46:53] <jadew> of course, but it's mostly used to add functionality :)
[06:47:04] * jadew worked on something that did just that with IE
[06:47:12] <jadew> it was for a toolbar
[06:48:58] <jadew> it was a BHO that mostly used the SDK, but some stuff couldn't be done by SDK alone
[06:49:10] <jadew> and you had to hook into IE's windows
[06:49:23] <RikusW> custom hacking :)
[06:49:32] * RikusW did some of that too
[06:49:40] <jadew> I think I actually had to replace the WndProc in order to process some of my messages
[06:50:51] <RikusW> at that point it becomes too easy to break stuff ;)
[06:51:07] <jadew> nah, if you pay attention and you handle everything properly, it's fine
[06:51:16] <jadew> most stuff is well documented anyway
[06:52:00] <jadew> IMO this is what makes windows so fast
[06:52:32] <RikusW> well I've had hooks + spy++ + debugger crash windows totally
[06:52:57] <jadew> ah, obviously
[06:53:05] <jadew> depends on the hooks tho
[06:53:33] <jadew> like... if you have a _LL hook that starts blocking, that could become a problem
[06:54:26] <jadew> like say... preventing any keyboard && mouse messages from getting trough
[06:54:33] <jadew> that's basically a frozen system :)
[06:55:03] <RikusW> do -> for(DWORD *p = 0xC0001000; ; *p++ = 0); on win9x
[06:55:16] <RikusW> it will cause instant reboot
[06:55:33] <RikusW> overwriting the kernel cause a triple fault afaik
[06:55:48] <jadew> that's where the kernel is at?
[06:55:53] <RikusW> yep
[06:56:09] <RikusW> starting at 0xC0000000 won't work, that page is protected
[06:56:40] <jadew> well, protected mode was still in its infancy back then
[06:56:42] <RikusW> I even done an app for listing vxds and then got the idea to overwrite everything
[06:57:01] <RikusW> yep, don't work on XP
[06:57:46] <rue_bed> see if you can make a virus that fixes the 95 clock rollover bug
[06:58:13] <RikusW> already got on, calls XP install disk :-P
[06:58:16] <RikusW> *called
[06:58:50] * jadew starts working, he's on a tight deadline
[06:59:40] * RikusW should do that too
[07:04:25] <OndraSter__> I should start learning
[07:04:26] <OndraSter__> I am writing two tests on thursday
[07:04:26] <OndraSter__> I know nothing :D
[07:04:27] <OndraSter__> yet I am here, trying to port minecraft mod to newer version
[07:07:46] * RikusW hands OndraSter__ the minecraft exam papers :-P
[07:14:49] <tzanger> interesting
[07:15:18] <tzanger> CLKDIV8 blown or unblown sets the system clock prescaler to 8 on tiny13a. I manually set the prescaler to 1:1 and get the expected clock rate
[07:16:18] <twnqx> no license delivery yet :/
[07:16:23] <twnqx> cadsoft is slow.
[07:17:58] <RikusW> tzanger: use the CLKPR register
[07:18:19] <twnqx> tzanger: you just have the wrong fuse ::P
[07:20:35] <tzanger> RikusW: that's what I said. :-)
[07:20:35] <RikusW> tzanger: t13a got CKDIV8 in lfuse 0x10
[07:20:40] <tzanger> twnqx: I don't think so, I'm using the AVR fuse calculator
[07:20:46] <tzanger> the values make sense
[07:20:59] <tzanger> twnqx: you bought it through james? did he give you any deal?
[07:21:14] <twnqx> no, but that wasn't what i was after in the first place
[07:21:28] <twnqx> 384$ is still far better
[07:21:41] <tzanger> true
[07:22:01] <tzanger> now I'm trying to figure out the leakage path that is causing my tiny13a to turn on this damned triac
[07:22:34] <tzanger> the pin is an input and with or without a pullup, I'm seeing about 1.5mA draw at the zero cross which is plenty to fire this triac
[07:23:05] <twnqx> Oo
[07:23:13] <twnqx> some alternate function active?
[07:23:25] <tzanger> no
[07:23:30] <twnqx> or an A/D pin?
[07:23:34] <tzanger> this is a very small program, I think 380 bytes flashed
[07:23:43] <tzanger> might be ADC but it's not in use
[07:23:50] <tzanger> I'm pushing the boundaries here. :-)
[07:24:29] * twnqx tries to remember the I/O pin schematic for ADC pins
[07:24:39] <tzanger> the chip enables the pin change interrupt then sleeps until it sees the gate of the triac go low. it then decides whether it wants to fire the triac or not, sets a timer for 100us and sleeps
[07:24:56] <tzanger> t0 wakes up in 100us, I decide whether I'm driving the LEDs or not, set t0 for 5ms and sleep again
[07:25:07] <tzanger> 5ms later I turn off the LEDs and set the timer for 100us again
[07:25:16] <tzanger> then it enables the pin change interrupt again and sleeps
[07:25:54] <tzanger> well it sleeps when waiting for pin change because pin change is async and I can stop the clock. the toher sleeps (with t0) are idle not sleep since I need the i/o clock
[07:26:26] <tzanger> all this sleeping nonsense and short firings of the triac are because my supply is *very* weak (capacitive supply)
[07:27:04] <tzanger> I was using the reset pin for zero crossings (with reset disabled) but I think I can get away with just watching the triac gate lead
[07:27:34] <tzanger> nope this isn't an ADC issue; RB0 has no ADC function
[07:27:42] <tzanger> nevermind I can't read
[07:28:14] <tzanger> it's also AN0 so it might just be sitting there too... good catch twnqx
[07:28:46] <twnqx> good louck figuring out if i was rightr
[07:30:00] <twnqx> and my last electronics order from this morning isn't shipped yet either :(
[07:30:12] <twnqx> and thursday is bank holiday, so o delivery... yey
[07:31:05] <tzanger> er no
[07:31:13] <tzanger> it's not ADC, it's AIN0 - the analog comparator
[07:34:24] * Tom_itx wonders if the last few bytes of flash on a chip are actually good.
[07:34:32] <Tom_itx> who uses them anyway?
[07:36:06] <tzanger> hm, I wonder if it'd be better if I didn't use the digital input for this and used the comparator instead
[07:36:14] <tzanger> I can't interrupt myself out of sleep though
[07:36:59] <Tom_itx> you sleep typing?
[07:37:15] <tzanger> nope
[07:38:03] <Tom_itx> myself must be the chip then
[07:38:35] <tzanger> bah still hitting 2.5mA peaks
[07:38:35] <RikusW> Tom_itx: the bootloader uses it
[07:38:37] <tzanger> fuck!
[07:38:54] <RikusW> and below the bootloader my modules use it too
[07:39:27] <Tom_itx> just couldn't tell who was sleepy there
[07:41:08] <rue_bed> tzanger, do you have pins set to have a pullup and their output is low?
[07:41:18] <tzanger> I'm making this AVR sleep as much as possible due to the extraordinarily weak supply
[07:41:20] <rue_bed> tzanger, how much current is the led taking
[07:41:32] <tzanger> rue_bed: the LED is not connected to the triac gate
[07:41:48] <rue_bed> how much current does it take to fire the gate?
[07:41:50] <tzanger> my supply is referenced off the "line" side of the supply, ground is 5V below that
[07:42:29] <tzanger> rue_bed: very little, 1mA typical
[07:42:38] <rue_bed> usually a cap in the order of .22uf is used, whats yours?
[07:43:16] <rue_bed> you should be able to pull more than 50mA if your arrangement is right
[07:43:18] <tzanger> actually I'm firing in quadrant 2, so 2mA not 1mA
[07:47:01] <rue_bed> lots of circuits have line pulled supplies that operate relays
[07:50:37] <rue_bed> google is failing a search on it
[07:50:50] <rue_bed> I should have schematics somewhere
[07:59:51] <tzanger> rue_bed: I'm bickering about the AVR pulling anything at all, but it's pulling 2.5mA peak
[07:59:58] <tzanger> which is plenty to drive that triac gate
[08:00:04] <tzanger> rue_bed: tiny13a
[08:00:20] <tzanger> rue_bed: I'll post my schematic momentarily
[08:00:47] <tzanger> the supply's fine, the circuit's fine, I've got a suspicion that it is the negative pin protection diode on the avr pin doing it
[08:00:58] <tzanger> in that case I'll just add a transistor as an interposing switch
[08:05:08] <tzanger> moving the comparator input off the pin and disabling the comparator cuts the leakage current in half
[08:05:12] <tzanger> it's still too much though
[08:12:37] <tzanger> ok this is ridiculous
[08:12:44] <tzanger> my gate resistor is now 10k and it's still triggering
[08:14:55] <RikusW> protection diodes maybe ?
[08:15:02] <tzanger> yep that was my guess
[08:15:21] <tzanger> I would have expected 10k to limit the current more
[08:15:27] <tzanger> I'll have to add an interposing transistor
[09:22:12] <theBear> 10k isn't much compared to the gate of the fet
[10:22:39] <tzanger> EYE AM TEH WEINER!
[10:22:41] <tzanger> PH33R
[10:23:10] <tzanger> Circuit is working. Software is working. I fucking rock. That is all.
[10:23:25] <jadew> yey for blinky led!
[10:24:25] <tzanger> blinky led? fuck that! relay working, circuit consuming minimal power, crazy reprogramming of the timer
[10:25:00] <jadew> so you're controlling the led with a relay? activated using a timer? :P
[10:25:21] <jadew> kidding, what did you make?
[10:27:54] <microchip_sac> what is the best clock source for usart comm.?
[10:28:16] <LoRez> crystal
[10:31:39] <jadew> anything that doesn't drift too much
[10:32:08] <jadew> and the higher the baudrate the less drift you will need
[10:32:11] <microchip_sac> is internal rc good enough?
[10:32:14] <jadew> no
[10:32:21] <microchip_sac> i dont need too much accuracy
[10:32:25] <jadew> you'll have to calibrate it for it to work
[10:32:44] <jadew> well, with out calibration, you won't get anything out of it
[10:32:51] <microchip_sac> its just a simple 'button-press-signal-transfer' device
[10:35:18] <microchip_sac> like, where a button pressed on one end will do something on the other end
[10:35:52] <jadew> why don't you give it a try?
[10:36:13] <jadew> depending on the baudrate you chose, it might work
[10:48:00] <tzanger> jadew: heh
[10:48:24] <tzanger> jadew: it's a pump "exerciser" -- basically these pumps need to be run at least once every 24h or they lose prime
[10:48:43] <tzanger> so this thing watches the pump inputs and if they haven't been run in 24h, it forces a run for 30s
[10:49:08] <tzanger> the issues are that it has to be dirt cheap and run off 24VAC
[10:49:33] <tzanger> so tiny13a is small and cheap, but not enough inputs to do it straightforwardly
[10:50:34] <tzanger> needs to be cheap so a capacitive power supply is used. problem with that is I can't use DC relays because they consume too much power
[10:50:41] <tzanger> so I use 24VAC relays and a triac
[10:51:01] <tzanger> but block firing a triac is expensive power wise as well, so that's where the timer trickery comes in
[10:51:36] <tzanger> I shut off the LEDs and triacs, set up a pin change interrupt for the zero crossing of the 24VAC and go to sleep
[10:51:45] <jigoe> If I am using an external interrupt on INT0, am I right in thinking it sets up the Data direction register for the port as an input already?
[10:52:03] <tzanger> when I wake up I know I've had a zero crossing. If I'm supposed to run a pump, I drive the triac and set the timer for 100us
[10:52:31] <tzanger> in 100us I stop driving the triacs (they'll stay on until the next zero crossing) and decide if I should do anythign with the LEDs
[10:52:41] <tzanger> I run the LEDs and set a timer for 5ms and go back to sleep
[10:53:14] <tzanger> 5ms later I shut off the LEDs (one of the LED outputs is also my zero cross detect input) and set the timer for another 100us to let the pin level stabilize back to whatever the AC line is doing, and sleep
[10:53:28] <tzanger> wake 100us later, re-enable pin change interrupts and sleep again
[10:53:48] <tzanger> zero cross interrupt counts crossings and gives me a 100ms tick that I use to tell wall time
[10:54:39] <tzanger> I was having a bitch of a time because I had MT1/MT2 on the triacs reversed and that was causing issues with both firing and zero cross detect, once I actually sat down with pencil and paper and drew out what I actually had on the board it became clear
[10:55:08] <tzanger> then I realized that the 128kHz clock is significantly off (and wobbles because my power supply wobbles like crazy), so I ahd to shorten my timer times so I wasn't taking too long
[10:55:49] <LoRez> tzanger: why doesn't it matter if it's "expensive" power wise if you have AC power to run it from?
[10:58:03] <LoRez> also, you just need the ZC interrupts to tell you wall time. it crosses at 120Hz.
[10:58:15] <LoRez> (assuming 60Hz)
[11:32:39] <tzanger> LoRez: if I want to put a real power supply on it means a rectifier, regulator and associated circuitry. size and cost.
[11:32:50] <tzanger> LoRez: that is exactly what I'm using them for
[11:33:25] <tzanger> I detect ZC to know when to start firing the triacs, and I also count ZC interrupts to get a 100ms tick which I use to create wall time
[13:02:45] <abcminiuser> https://www.youtube.com/watch?v=5p1fmLu3XoA
[13:07:48] <Malinuss> hahahaha
[13:08:07] <Malinuss> oh wow
[13:08:09] <RikusW> abcminiuser: advertising for the competition now ? ;)
[13:08:28] <abcminiuser> RikusW, actually I think that's more of an ad for us...
[13:08:37] <abcminiuser> I was proposing we do a parody in the office today
[13:08:43] <abcminiuser> AVRMAN Rap
[13:09:03] <Malinuss> wow I want to see that
[13:09:39] <RikusW> is atmel behing infineon ?
[13:09:39] <RikusW> behind
[13:10:09] <abcminiuser> "AVRMan, be a 8-bit winner - stay away from the competition, don't be a 32-bit sinner"
[13:10:13] <abcminiuser> "Peace."
[13:10:34] <RikusW> lol
[13:10:45] <RikusW> 8bit is nice and simple :)
[13:10:59] * abcminiuser is working on 32-bit ARMs now anyway :(
[13:11:22] <RikusW> probably atsam ?
[13:12:35] <RikusW> porting lufa to it ?
[13:13:01] <abcminiuser> Hell no
[13:13:11] <abcminiuser> I've got enough troubles with AVR8 and XMEGA as it is
[13:23:09] <twnqx> grumble
[13:23:23] <twnqx> another two vendors which are not available at mouser
[13:46:55] <skroon> hi all
[14:13:03] <OndraSter__> twnqx, which ones?
[14:13:03] <OndraSter__> abcminiuser, haha, which troubles?
[14:13:03] <OndraSter__> need help? :P
[14:13:26] <twnqx> OndraSter__: melexis and allegro microsystems
[14:14:25] <abcminiuser> Porting demos in a way that doesn't make them hideous :(
[14:14:33] <abcminiuser> See: current XMEGA demo branch in LUFA
[14:24:58] <skroon> to use UART in async mode, do I need to set the UMSEL to 0 in the UCSRC register?
[14:27:23] <skroon> i'm trying to read it in the datasheet, but I didn't find it really clear yet
[14:29:24] <abcminiuser> Which device?
[14:30:03] <skroon> 328p
[14:30:32] <abcminiuser> *Please wait while we service your request*
[14:31:25] <skroon> hehehe :_)
[14:31:28] <abcminiuser> Both UMSELx bits should be cleared
[14:31:42] <RikusW> how to store 4Gb in a cap
https://www.youtube.com/watch?v=U1oDYSsUet8 :-D
[14:32:22] <skroon> abcminiuser: where do you read this in the datasheet? i'm reading: Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet
[14:32:23] <abcminiuser> UCSR0C = (1 << UCSZ01) | (1 << UCSZ00); // 8-bit, no parity, 1 stop bit async operation
[14:32:39] <abcminiuser> Table 20-7.
[14:32:40] <abcminiuser> UMSELn Bits Settings
[14:35:12] <skroon> abcminiuser: damn, I wasn't that far yet, I was reading page 173 about the UMSEL bit and they talked about 1 being for sync
[14:35:28] <skroon> abcminiuser: I guess I shoudl probably read the whole section first, before trying stuff out :-)
[14:35:33] <abcminiuser> I always skip to the register defs :P
[14:35:52] <skroon> right :-) hehe
[14:36:03] <skroon> your probably more advanced then me, and don't need that first part
[14:36:51] <OndraSter__> RikusW, haha nice trolling
[14:36:59] <RikusW> heh
[14:37:51] <OndraSter__> abcminiuser, haha so do I
[14:37:51] <OndraSter__> except for USB module
[14:37:51] <OndraSter__> that one I read through maybe 10 times
[14:37:52] <sabesto> skroon: all you need to do is to enable TX/RX and set baudrate to get it working with most used settings (8-N-1)
[14:38:00] <skroon> is it convenction to turn off a bit by doing: UCSRC = ~(1 << USMEL) why not just do: UCSRC = (0 << UMSEL) ?
[14:38:15] <skroon> sabesto: cool thanks for that tip
[14:39:10] <sabesto> UCSR0A &= ~(1<<USMEL) to clear a bit, UCSR0A |= (1<<USMEL) to set one
[14:41:20] <ambro718> is is possible to set a timer interrupt manually?
[14:41:50] <sabesto> ambro718: to trigger it manually?
[14:41:52] <ambro718> that is, as opposed to manipulating OCRnA to have the timer trigger the interrupt
[14:41:54] <ambro718> yes
[14:42:11] <sabesto> set the flag high
[14:42:37] <sabesto> dont remember if it has flags though
[14:46:02] <ambro718> nope, writing 1 to OCF0A actually clears the flag
[14:46:39] <sabesto> are you simulating this?
[14:47:22] <ambro718> what do you mean?
[14:48:05] <sabesto> if you are debugging/simulating interrupts will not work as intended
[14:48:16] <sabesto> unless you change some settings
[14:48:57] <ambro718> In my code the interrupt handler sets OCRnA to tell when the interrupt should handle next. The problem is when the time is too small (less than TCNT), the interrupt will not happen on time, and the timer will overflow.
[14:50:08] <ambro718> I was thinking of something like this: OCR0A = next_time; if (TCNT > next_time) { force_interrupt; }
[14:50:17] <ambro718> but I don't know how to force the interrupt
[14:51:06] <sabesto> just set OCR0A to TCNT+1 or something
[14:51:27] <ambro718> this doesn't guarantee anything
[14:52:07] <ambro718> compiler could add as many instructions as it wishes between reading TCNT and setting OCR0A
[14:53:14] <sabesto> it should que an interrupt regardless
[14:53:34] <sabesto> you setting the interrupt flag inside the same interrupt?
[14:53:36] <skroon> sabesto: i'm trying to really understand it perfect, but whenever I do: 1 << 4 the output would be 1000 , and 1 << 5 10000 right ?
[14:53:55] <skroon> 0b1000 and 0b10000 I mean
[14:54:07] <ambro718> sabesto: I'm setting OCR0A inside the interrupt, I don't set interrupt flags there
[14:54:12] <sabesto> add one more 0 to both
[14:54:30] <skroon> sabesto: ahhh, right because it's putting it on the index 0 already
[14:54:51] <skroon> sabesto: 1 << 0 == 0b1
[14:54:59] <sabesto> (1<<X) is just a representation of a number written in a more readable form
[14:55:18] <skroon> sabesto: right
[14:55:37] <sabesto> more readable if the decimal value isnt interesting, but the position of the bits
[14:55:44] <skroon> sabesto: i'm wondering though why not use (0<<0) to turn off a bit, because 0<<0 would be 0b0 right ?
[14:56:46] <sabesto> (1<<2)= 0b100, ~(1<<2) = 0b011
[14:56:46] <skroon> sabesto: i'm probably saying something really stupid :-)
[14:56:48] <twnqx> because it's the same as just not writing anything
[14:57:04] <sabesto> xxxx & 1011 = x0xx
[14:57:40] <sabesto> xxxx & 0000 = 0000, you cleared all the bits
[14:57:55] <sabesto> xxxx | 0000 = xxxx, you did nothing
[14:58:21] <skroon> sabesto: right, that made it much clearer to me, thanks
[14:59:01] <sabesto> and ofc, x |= y is the same as x = x | y
[15:01:36] <skroon> sabesto: cool I now really understand it :-) less stress now hehehe
[15:01:41] <twnqx> (except for what gcc makes of it. but i am disgressing)
[15:02:16] <skroon> twnqx: what do you mean ? :-)
[15:02:36] <skroon> twnqx: you mean gcc's imblementation could store the bits differently?
[15:02:42] <sabesto> skroon: pen and paper, write down the math every time in the beginning
[15:03:13] <twnqx> skroon: ignore this. the result is the same.
[15:03:26] <skroon> sabesto: that's what I was doing indeed! :-)
[15:03:33] <skroon> twnqx: ok :-) I was just curious
[15:04:49] <twnqx> ask again once you grasped the idea and can explain it when shaken awake in the middle of the night :P
[15:05:12] <skroon> twnqx: hahaha, that's indeed a good measure
[15:26:58] <skroon> I'm still a bit wondering, with async UART, ... it means both mcu's don't have a clock signal to sync up with right?
[15:27:20] <skroon> so their both using their own internal clocks and some agreed upon speed to start communicating
[15:29:44] <skroon> i'm confused because, even though they would listen at the same intervals, it could still be the case that they aren't fully synced right?
[15:30:39] <Casper> the issue is: clock sleed mismatch
[15:31:13] <MannImMond> well, they sync one time per byte
[15:31:23] <Casper> the avr in standard mode use 16 samples per bits
[15:31:31] <Casper> so it can be quite off and still be fine
[15:31:34] <Casper> however
[15:31:46] <skroon> Casper: sleed, was typo for "speed", or that's really called "sleed" ?
[15:31:50] <Casper> if the speed is so mismatched that you end up half a bit off.... it won't work
[15:31:55] <Casper> speed...
[15:32:01] <Casper> I hate this keyboard
[15:32:05] <Casper> and I'm vncing
[15:32:07] <skroon> k, thought it was perhaps some technical term of it
[15:32:14] <skroon> Casper: no problem, just double checking :)
[15:32:27] <Casper> if both side use a crystal, no issue
[15:32:33] <OndraSter__> sure
[15:32:34] <OndraSter__> that is why there is the magic column "error"
[15:32:36] <OndraSter__> (plus add crystal error)
[15:32:41] <OndraSter__> oscillator error
[15:32:44] <Casper> if one or both side use the internal rc oscillator... then it can be an issue
[15:33:19] <OndraSter__> they both "start" with the start bit
[15:33:19] <OndraSter__> and then they sample at given baud rate
[15:33:19] <OndraSter__> slower baud rate = very much less prone to oscillator errors
[15:33:23] <skroon> Casper: why would using the internal rc oscillator be a problem?
[15:33:40] <Casper> the internal RC oscillator is junk
[15:33:47] <MannImMond> because the same setting of the UBBR register will result in a different actual frequency
[15:33:51] <Casper> it can be off by 10-20%
[15:33:56] <skroon> Casper: so always use external oscillators with AVR's?
[15:34:07] <Casper> so a 10MHz setting could be anywhere between 8 and 12MHz
[15:34:10] <MannImMond> if you can afford it and need it for the application
[15:34:36] <skroon> wow, never knew... why is the internal osc there anywas? because you can use it, when exact timing isn't an issue perhaps?
[15:35:55] <MannImMond> well you can calibrate it.... the 10% are over temperature i.e. from -40 to +125°C
[15:36:04] <skroon> Casper: so this "16 samples per bits" what exactly does that mean? the UART hardware it self, takes 16 samples of the same bit, and check if it varies and choose the average value or something?
[15:36:32] <skroon> MannImMond: ah yeah ofcourse indeed... so when would you go with the internal osc at all?
[15:36:35] <Casper> to keep it simple, the majority win
[15:37:00] <Casper> when you set the divider, it's actually set 16 times faster
[15:37:19] <skroon> Casper: right, that was going to be my next question ;-)
[15:37:30] <Casper> then samples the 16 bits, check how many 1 and 0, the majoruty win. this make this bit
[15:37:35] <skroon> Casper: now I understand the datasheet, why I need to device by 16 * the baud rate :-)
[15:37:51] <Casper> the x2 mode reduce it to 8 samples per bits
[15:38:03] <Casper> so
[15:38:15] <skroon> right, basically saying... we pray to be on the same clock sync :)
[15:38:16] <Casper> the speed do not need to be a perfect match
[15:38:16] <skroon> right?
[15:38:42] <Casper> with the internal RC, yes... however there is some means to reduce the error
[15:38:46] <Casper> to calibrate it
[15:39:00] <skroon> is this also how it works with RF (433mhz) then as well? because you don't know the *exact* timing of the other transmitter, you take multiple samples?
[15:39:04] <Casper> but a calibration is more issues, and can calibrate itself wrong of course
[15:39:27] <MannImMond> well you can tune it to <5MHz :D
[15:39:40] <MannImMond> though that is not really stable anymore
[15:40:03] <Casper> with wireless it's even worse... you have to deal with speed mismatch, transmission error, droped signal, interference...
[15:41:08] <skroon> Casper: I can imagine indeed :-) i'm really intrestted in RF, but though about some of these issues already, so I thought about learning UART first, and see how it works, hopefully RF get's more easier to understand aftherwards
[15:43:17] <Casper> for serial communication, a crystal is storngly recommended... like the weird frequency... 14.7456MHz or 18.432MHz
[15:43:35] <Casper> it look weird and stupid to use those frequency
[15:43:42] <Casper> but those are the perfect match
[15:43:50] <Casper> http://www.wormfood.net/avrbaudcalc.php
[15:48:35] <skroon> Casper: so basically USART with a clock line is generally simpler/more-stable ?
[15:49:11] <Casper> more stable
[15:49:15] <Casper> however
[15:49:22] <Casper> with crystal, there is no real difference
[15:49:45] <skroon> because that margin for error is so low, you mean right?
[15:49:56] <skroon> or change of error I should say
[15:50:51] <jacekowski> serial is bit more complicated
[15:50:54] <Casper> on async, it's clocked on the start bit
[15:51:01] <jacekowski> a lot of serial busses rely on clock recovery from the data
[15:51:08] <Casper> so the offset reset at each byte
[15:51:13] <jacekowski> like async serial
[15:51:30] <Casper> as long as you don't excede about 2% speed mismatch then zero error will occur
[15:51:38] <jacekowski> SATA uses clock recovery as well
[15:52:12] <jacekowski> that's why there are encodings limiting run lenghts
[15:52:29] <skroon> it's funny how even such things, I used to take for granted, so much complexity in there :)
[15:52:35] <jacekowski> so there will be transition often enough to keep the PLL locked
[15:52:40] <skroon> really interestting stuff
[15:52:47] <skroon> jacekowski: PLL?
[15:53:11] <jacekowski> phase locked loop
[15:53:53] <jacekowski> basically an oscillator that uses a reference signal to generate a frequency
[15:54:07] <jacekowski> but it drifts
[15:54:40] <jacekowski> used to create higher frequencies or just for clock recovery
[15:55:05] <jacekowski> http://en.wikipedia.org/wiki/Phase-locked_loop
[15:57:25] <jacekowski> your phone and computer has at least few
[15:57:46] <jacekowski> if you ever heard about the multiplier for cpu clock frequency
[15:58:04] <skroon> what do you mean? multiplier ?
[15:58:07] <jacekowski> the PLL is the thing that does the multiplying
[15:58:10] <skroon> man I have a lot to learn :)
[15:58:11] <jacekowski> clock multiplier
[15:58:14] <skroon> ahhh right
[15:58:22] <jacekowski> http://en.wikipedia.org/wiki/CPU_multiplier
[15:58:39] <skroon> hehe I was just at that wikipedia page as well :-)
[15:58:58] <skroon> i'm excited about learning about all those things
[15:59:39] <jacekowski> so if you have multiplier 10, base clock will be 10x slower and PLL will be corrected every 10 cycles which is often enough to keep the clock stable
[16:00:13] <jacekowski> or like with serial comms and clock recovery, PLL will run at the same frequency as the bus
[16:00:46] <skroon> base clock being the speed of the cpu then as advertised?
[16:00:51] <skroon> or the other way around :-)
[16:00:59] <twnqx> skroon: the excitement will change to despair....
[16:01:11] <skroon> the advertise the PLL but in reality speed is slower
[16:01:14] <twnqx> also, AVR 8bits don't have multiplier, afaik
[16:01:19] <skroon> twnqx: haha, I have been there as well, ups and downs :)
[16:01:24] <jacekowski> base speed being the FSB speed or something
[16:01:24] <twnqx> PLLs also stabilize clocks, not only multiply
[16:01:32] <MannImMond> twnqx yeah they do
[16:02:12] <MannImMond> e.g. the Mega64M1 got a pll
[16:02:31] <twnqx> so i can clock it to 10x external? :>
[16:02:35] <twnqx> 160mhz avr, go!
[16:02:39] <MannImMond> ....
[16:02:49] <jacekowski> skroon: PLL is used to generate internal cpu clock from slower frequency supplied from motherboard and used for the FSB/hypertransport/other_bus
[16:02:52] <twnqx> sorry.
[16:03:27] <twnqx> i am reading data sheets, availability lists and price lists for too long now.
[16:03:32] <OndraSter__> DFLLs stabilize
[16:03:39] <skroon> jacekowski: cool, i'm gonna take my time and read those wikipedia pages again, thanks for those links
[16:03:47] <skroon> jacekowski: and ofcourse the explinations
[16:04:06] <OndraSter__> PLLs multiply
[16:04:06] <OndraSter__> well
[16:04:06] <OndraSter__> PLLs can lock too
[16:04:06] <OndraSter__> and stbailize
[16:04:06] <OndraSter__> stabilize
[16:04:06] <OndraSter__> damnit, what did I just write
[16:04:07] <OndraSter__> PLLs can stabilize too
[16:04:07] <OndraSter__> check out xmega
[16:06:30] <skroon> on a atmega328p i'm trying to set the UBBR register, but I can't find in which header file it's defined
[16:12:51] <ambro718> there is no UBRR, just UBRR0
[16:13:04] <skroon> ambro718: oops,thanks
[16:47:54] <Essobi> what's up...
[16:48:16] <Essobi> Got me a atmega128RFA1 to play with. :D
[16:48:30] <Essobi> anyone horked around with one yet?
[16:55:46] <RikusW> no
[17:10:42] <Essobi> RikusW: Looks pretty cool.. has a zigbee radio on it
[17:10:59] <RikusW> I've seen tha ds of the rfa chip though
[17:11:03] <RikusW> but not read it
[17:11:22] <RikusW> still busy on the sim900 project
[17:47:11] <tzanger> Essobi: nice. how much?
[17:47:53] <Essobi> tzanger: oh it was the badge from THOTCON
[17:48:11] <tzanger> ah
[17:48:51] <tzanger> never been to a con, not in the 20ish years I've been into the scene and old enough to be able to enter. :-)
[17:57:35] <Essobi> heh
[22:17:36] <jadew> got a new site for sharing code and I just shared my 1-wire library, if anyone is interested:
http://eenoob.com/home/post?id=2
[22:19:48] <Tom_itx> you know about rue's site?
[22:19:55] <Tom_itx> you can put it there as well
[22:20:11] <jadew> I don't know it, what's the link?
[22:20:33] <Tom_itx> i'm not sure
[22:20:35] <Tom_itx> :)
[22:20:39] <jadew> :)
[22:20:56] <Tom_itx> rue_house?
[22:21:20] <jadew> well, if he find the code worthy of his site, he's welcome to put it there
[22:21:37] <Tom_itx> yeah i don't know how many even know about it
[22:21:50] <Tom_itx> i thought it was in the topic once but i don't see it
[22:23:15] <Tom_itx> can anyone post code or do you have to upload it?
[22:23:28] <jadew> I think I ended up on his site a while ago too
[22:23:41] <Tom_itx> not his regular site
[22:24:12] <Tom_itx> http://ruemohr.org/
[22:24:15] <Tom_itx> there
[22:24:47] <jadew> that's nice
[22:25:07] <Tom_itx> somebody should spruce it up a bit
[22:25:08] <jadew> but I don't see how I can make a submission :)
[22:25:16] <Tom_itx> i think he has to upload it
[22:25:19] <Tom_itx> i'm not sure
[22:26:25] <jadew> well, I guess if he'll like it, he'll put a link in there
[22:26:52] <Tom_itx> is it slave too?
[22:27:02] <ptrkOP> Do you guys have any suggestions for github links with good AVR code to learn from.
[22:27:06] <Tom_itx> err that's not i2c
[22:27:10] <ptrkOP> As far as best practices and stuff
[22:27:21] <jadew> Tom_itx, I have slave code too
[22:27:26] <jadew> I'll probably post it tomorrow
[22:27:35] <jadew> I have it both in C and asm
[22:27:52] <jadew> however the ASM version is meant to work by itself on an attiny13
[22:28:06] <jadew> it has a pretty specific behaviour
[22:28:18] <jadew> well.. the C version too, but that's easier to change
[22:50:24] <rue_shop2> hey
[22:50:36] <rue_shop2> I can put something under the lib section if you like
[22:50:42] <rue_shop2> want the content or a link?
[22:52:00] <Tom_itx> jadew ^^
[22:52:19] <jadew> hey rue
[22:52:21] <jadew> http://eenoob.com/home/post?id=2