Back
[03:15:31] <braincracker> hello
[04:39:43] <sjokkis> hey assembler guys, in this code here (
http://www.freertos.org/implementation/a00017.html) it first loads the pointer to the task control block (pxCurrentTCB and pxCurrentTCB+1 into the X-register, and then as far as I can tell (without really knowing asm) it loads the X-register into the Y-register, before finally loading it into the stack pointer register
[04:39:55] <sjokkis> Why is it necessary to involve the Y-register here?
[04:42:08] <sjokkis> Why couldn't __SP_L__ be loaded with r26 and __SP_H__ with r27 right after the line marked (2)?
[04:45:25] <sjokkis> Oh wait both LDS and LD add the data pointed to by the second argument, and since pxCurrentTCB points to a struct it's a ** and now I get it
[04:45:42] <sjokkis> Thanks for the rubber ducking guys
[08:05:32] <kdehl> How the heck can I get 6.25 ± 0.25 Volt to program an EPROM?
[08:05:52] <kdehl> There are 6 V regulators... but then I only get 6 volt. Which might not be enough.
[08:06:17] <kdehl> Can I just measure the inner resistance of the EPROM and run it all on 12 volts? Seems scary...
[08:07:51] <kdehl> Hm. I could use an adjustable regulator...
[09:20:18] <Casper> kdehl: the internal "resistance" vary, you can't use a resistor
[09:20:27] <Casper> but an lm317 would do the job
[09:24:10] <kdehl> Casper: Looks good.
[12:26:19] <N1njaneer> So quiet!
[12:32:41] <tzanger> ssh you'll disturb the sleep()ing AVRs
[12:42:07] <N1njaneer> Mmm, don't want to Interrupt their sleep() :D
[12:43:17] <Tom_itx> can you interrupt during sleep(); ?
[12:43:37] <N1njaneer> Externally :)
[12:43:48] <tzanger> depends on how soundly they sleep and/or the type of interrupt
[13:11:45] <kastein> so, funny question. Using the AT90CAN128 and the ASF code for the UART. I've compared the documentation, the ASF code output, my math, and WormFood's bit rate calculator and everything agrees that for a sys clock of 12MHz and a desired baud rate of 38400, I should use a UBRR value of 0x26 if X2U is 1. Yet... when I burn the code to the chip, I get 25600 baud, which is exactly 1/1.5 (AKA 8/12) of 38400.
[13:12:02] <kastein> I've #defined FOSC to 12000
[13:12:25] <kastein> if I #define FOSC to 8000, suddenly everything works, and I get a perfect 38400 baud rate... while using a 12MHz external crystal oscillator.
[13:12:32] <kastein> what in hell am I missing here?
[13:13:13] <kastein> I have the main prescaler (the one configured by CLKPR) reset to 1:1
[13:14:02] <kastein> I mean, I can just run with this and hack around it, clearly, but I want to know WHY this is happening, because it's almost certainly going to foul up my CAN baud rate as well
[13:14:31] <kastein> I've verified with my scope that the external oscillator is running at 11.999997MHz. Which is close enough for me.
[13:20:54] <N1njaneer> That's very odd.
[13:24:02] <kastein> right?
[13:24:12] <kastein> I'm rather perplexed
[13:24:29] <kastein> is there a prescaler between the system clock and I/O clock that I'm not aware of, or something?
[13:37:40] <WormFood> kastein, have you looked at the assembly code, to make sure it's actually being programmed as expected?
[13:41:12] <tzanger> there is an ioclk divider, check the documentation
[13:41:35] <kastein> huh, I searched for all instances of "clkio" and found nothing, will check again, thanks
[13:42:07] <kastein> WormFood: I haven't - but I did set it up to spit the value out via serial after reading it back from UBRR0L/H and verified it was what I was expecting
[13:42:56] <tzanger> kastein: CLKPR and also CLKDIV8 fuse.
[13:43:12] <tzanger> CLKDIV8 "preprograms" CLKPR
[13:43:46] <kastein> I have CLKPR set to 1:1 as the very first thing my main function does
[13:44:39] <WormFood> can you replicate the problem, without all of your code?
[13:45:04] <WormFood> in other words, can you share with us, a program, that exhibits your problem?
[13:45:27] <kastein> sure
[13:45:42] <WormFood> pastebin it, or something
[13:45:49] <kastein> what's odd is that it's off by a factor of 1.5, which really confuses me
[13:45:56] <WormFood> I've looked over the baud rate table, and I don't see anything obvious
[13:46:01] <WormFood> that is odd
[13:48:52] <tzanger> are you driving the crystal strangely and got it in some overtone mode? I'm kind of grasping
[13:48:52] <kastein> yeah
[13:49:04] <kastein> and like I said, I ran the numbers myself and I agree with yours
[13:49:10] <kastein> so does the atmel software framework
[13:49:19] <kastein> so does the datasheet
[13:49:32] <kastein> tzanger: I'm using an external crystal oscillator just to make sure
[13:49:34] <WormFood> my calculator uses the same formula they use ;) So it should match perfectly
[13:49:38] <kastein> at 12MHz
[13:49:42] <kastein> haha yeah, so did I
[13:50:12] <kastein> http://pastebin.com/PbxaKxE3 is my main function
[13:50:25] <kastein> all the functions I haven't commented out are from ASF libraries
[13:52:19] <WormFood> how are you measuring the baud rate?
[13:52:33] <kastein> http://pastebin.com/ZM5rVCMt is relevant sections of config.h
[13:52:36] <WormFood> I mean, how do you determine it's 25600?
[13:52:41] <kastein> I used a logic analyzer I have
[13:52:50] <Raazeer> hi people
[13:52:54] <WormFood> and what method did you use, to arrive at 25600 baud?
[13:53:03] <WormFood> 你好 Raazeer
[13:53:06] <kastein> it told me, it's got autobaud... I also checked myself
[13:53:11] <WormFood> ok
[13:53:18] <kastein> it said 25641, then I hung my scope on TXD and determined that each bit is ~39-40uS long
[13:53:19] <Raazeer> Worm 你好.
[13:53:54] <WormFood> 25641....I see
[13:54:19] <Raazeer> WormFood, 你好吗?
[13:54:21] <kastein> bit time of 39uS works out to 25600 baud, so I said close enough and ran with it
[13:54:33] <WormFood> Raazeer, 我很好，你呢？
[13:54:58] <Raazeer> 也很好谢谢
[13:55:15] <Raazeer> interesting thing, to adress somebody in chinese on IRC.
[13:55:34] <WormFood> I'm in China
[13:55:38] <WormFood> :D
[13:55:48] <Raazeer> WormFood, also you're a show-off ;)
[13:55:57] <WormFood> now 25641 is an interesting baud rate
[13:56:20] <WormFood> at 12Mhz clock, that would give a 0.9% error rate
[13:56:45] <WormFood> since whatever you read, is driven by the clock, whatever baud rate you received, should have a 0% error rate
[13:58:15] <kastein> yeah
[13:59:01] <Raazeer> WormFood, what's the idea setting 25641baud as a transmission rate?
[13:59:05] <WormFood> http://www.wormfood.net/avrbaudcalc.php?postbitrate=25641&postclock=12&bit_rate_table=1&u2xmode=1&hidetables=1 <-- this shows all the possible bit rates, for a 12 Mhz crystal...unfortunately, it does not show U2X=1 values
[13:59:18] <WormFood> Raazeer, because i'm showing off :P
[13:59:20] <kastein> I think the 41 part is slightly random, probably caused by temperature variations during startup and the fact taht this tiny cheap usb logic analyzer likely aliases a bit when sampling
[13:59:25] <WormFood> it's the speed that kastein is getting
[13:59:37] <WormFood> I was checking it to see if it seemed like a reasonable speed, for a 12 Mhz xtal
[13:59:54] <kastein> it's close enough to 25600 that my assumption is "something" is causing a 1.5x reduction in baud rate from my expectation
[14:00:01] <kastein> just not sure what yet
[14:00:14] <WormFood> kastein, and you've tried other values, to see if they're also being reduced by the same amount?
[14:00:20] <kastein> yes
[14:00:48] <kastein> if I #define FOSC to be 8000, and run with a 12MHz crystal oscillator still, I get damn near 38400 baud actual measured line rate
[14:00:52] <WormFood> I recommend you don't figure based on "close enough"...you appear to have sensitive enough equipment, to get accurate values
[14:00:55] <kastein> that's what puzzles me
[14:01:21] <kastein> (and the UBRR0H/L values line up with what one would expect to produce 38400 baud... with an 8MHz crystal...)
[14:01:24] <WormFood> and when you're multiplying and dividing things, sometimes that extra 41 makes a difference
[14:01:28] <kastein> true
[14:01:37] <tzanger> async interfaces are awesome for this... too much variance in either direction and they fall apart
[14:01:58] <kastein> 25641 times 1.5 gives 38461.5, let me burn that code and see what the LA says
[14:02:00] <tzanger> some hardware has fractional uart dividers for this reason
[14:02:05] <kastein> yeah
[14:02:17] <kastein> and 16x or 64x oversampling on reception
[14:02:28] <WormFood> and the reason I asked you for the smallest program that exhibits this problem, is sometimes your code causes problems, and you don't notice it, until you try to do only that one thing
[14:02:34] <tzanger> yep. designing your own uart is one of those basic fpga projects
[14:02:35] <kastein> to help with decoding data from crummy rc or ceramic oscillators
[14:02:38] <WormFood> it's getting up on 4am here, and I need to go to bed soon
[14:02:38] <kastein> WormFood: fully understood
[14:03:20] <kastein> like I said I can *make* it produce what I need, I just have to lie to it that I'm using an 8MHz crystal or hack on the library. so either way I'll get this working, I'm just puzzling over it and wondering if there is some config reg I'm missing or something basically
[14:03:38] <WormFood> you're doing it wrong(tm)
[14:03:41] <kastein> and it's probably going to screw up CAN data rates, but now that I know to expect it, I can fudge the numbers till they work too
[14:03:48] <kastein> yes, but... how :(
[14:03:49] <kastein> lol
[14:03:53] <WormFood> beats me
[14:04:06] <kastein> me also, which is bothering me
[14:04:06] <WormFood> I'd need to break out the datasheet on that avr and take a peek at it
[14:04:37] <WormFood> I really think, that when you have it stripped down to the absolute barest code, to do what you need done, that the problem will go away
[14:04:53] <N2TOH> you could try tweeking the clock rate for what ever baud rate your aiming for
[14:05:06] <WormFood> try to only set the uart properly, and send the same character over the uart
[14:05:18] <kastein> that is pretty much the bare minimum, lemme comment out a few more functions though
[14:05:31] <WormFood> N2TOH, that makes no sense.....you didn't read all the background, it appears
[14:05:53] <kastein> N2TOH: I could, but my point is trying to understand why this is happening, rather than just hacking around it (which I have already done to verify what the problem was)
[14:06:00] <tzanger> have you measured the crystal that is driving the system?
[14:06:03] <kastein> yes
[14:06:05] <WormFood> he has tzanger
[14:06:07] <kastein> 11.999997MHz
[14:06:07] <tzanger> and it's not 8MHz
[14:06:09] <tzanger> hm
[14:06:09] <kastein> close enough for me ;)
[14:06:14] <kastein> that was my second thought
[14:06:27] <tzanger> that's odd. I have a AT90CAN128 design at 12Mhz, let me see what my BRG values are
[14:06:28] <WormFood> it's a conspiracy!
[14:06:41] <kastein> I figured it might have been some goofy third overtone I was getting or something
[14:06:43] <WormFood> have you tried a different chip?
[14:07:06] <kastein> not yet, it's a QFP and I hate desoldering those non destructively
[14:07:21] <kastein> and don't have enough spares on hand to just rip it off with wild abandon
[14:07:33] <N2TOH> what type of power supply is powering the system? have you ruled out noise on the power rail?
[14:07:44] <WormFood> you know, when you put your probe in the circuit, it does change the circuit's value...are you sure it isn't really running at 8Mhz, and when you apply your probe, it loads it enough to run properly?
[14:08:05] <kastein> it's an external oscillator rather than a crystal, so I really hope not
[14:08:14] <WormFood> oh yeah, you said that before
[14:08:23] <WormFood> have you tried swapping out the xtal or mcu?
[14:08:55] <tzanger> #define UART_BAUD_SELECT_DOUBLE_SPEED(baudRate,xtalCpu) ( ((((xtalCpu) + 4UL * (baudRate)) / (8UL * (baudRate)) -1UL)) | 0x8000)
[14:09:07] <kastein> N2TOH: it's a micrel mic5239-5.0 linear w/ appropriately specced filter caps on input and output, checked my rail and it's reasonably clean
[14:09:22] <tzanger> sorry, I'm at 16MHz, not 12
[14:10:28] <kastein> WormFood: I haven't tried a new oscillator since it's a 4 lead LCCC, I did put a new MCU on yesterday morning because I let the smoke out of the old one shorting some pins on PORTF with an oscilloscope probe and they started acting funky. old MCU had the same behavior
[14:10:37] <kastein> which is why I'm all out of spares now
[14:10:54] <WormFood> oooohhhh....I hate it when that happens
[14:11:00] <WormFood> short out the pins with the probe
[14:11:06] <kastein> yeah
[14:11:22] <WormFood> sorry I can't help more
[14:11:24] <kastein> accidentally fed 12v unfused from before the polyfuse+regulator straight into portf pin 6
[14:11:26] <kastein> no worries
[14:11:41] <WormFood> good luck with it kastein. I gotta hit the sack. Good to see you again tzanger. See ya'll l8r 晚安
[14:13:15] <kastein> thanks
[14:14:36] <tzanger> later
[14:41:54] <DanFred> are the internal clocks imprecise?
[14:42:24] <DanFred> +-1% or worse?
[14:43:21] <Casper> +/-10+%
[14:43:49] <Casper> hence why it's unsuitable for uart
[14:58:11] <N2TOH> http://www.controlchips.com/cybp51ds.htm
[14:58:28] <N2TOH> in reference to the ISA thread the other day
[14:59:13] <braincracker> kastein happens with arduino only
[15:00:16] <braincracker> DanFred they are usable, +-5% usually
[15:00:38] <braincracker> if you want a clock, hook up a 32768Hz xtal
[15:03:51] <spec_> Casper: Unusable for higher baud rates. The slower you go, the lower the error rate.
[15:21:45] <kastein> braincracker: it's not an arduino, it's an AT90CAN128 on a 4 layer PCB I designed... I'm better at PCBs and mixed signal logic than clock source configuration or reading documentation, clearly
[15:22:33] <kastein> well. it's currently an AT90CAN32, but they have the same footprint and everything else except device IDs and memory sizes
[15:33:09] <DanFred> braincracker, I'm just doing pwm SMPS. +-5% is a little high but I suppose I can live with it
[15:34:24] <braincracker> that is fine, while control loop is online ;)
[15:34:44] <braincracker> but a glitch will kill things
[15:52:03] <DanFred> braincracker, glitch?
[15:52:25] <braincracker> yes
[15:52:39] <braincracker> interrupt does not trigger for x time :)
[15:52:53] <braincracker> or skips
[15:53:07] <DanFred> I don't rely on code for every cycle
[15:53:19] <braincracker> well, you do pwm
[15:53:37] <braincracker> control loop failure may cause meltdown.
[15:53:40] <DanFred> I'll probably switch at 50 or 100kHz so I don't dare rely on the chip always getting ready in time
[15:54:07] <DanFred> I'm well aware that there is no room for error at 400V into small inductances at 100kHz :)
[15:54:22] <DanFred> things go quickly
[15:54:55] <DanFred> I simple intend to let the built in PWM run and 'ocassionally' adjust the pwm up or down as needed by a non real time loop
[15:55:29] <DanFred> occasionally*
[15:55:40] <DanFred> that word looks odd :)
[16:08:17] <kdehl> Anyone of you retro guys have the IBM XT Expansion Unit?
[16:10:54] <Casper> spec_: not with internal RC... well, not with uncalibrated one
[16:11:04] <Casper> 10% off is still 10% off at any speed..
[16:11:16] <Casper> but when you add the jitters... yeah better with low speed
[16:11:34] <Casper> but once calibrated, I did 115200 on internal RC reliably
[16:13:14] <N1njaneer> Casper: What about over a wide temperature range?
[16:30:31] <Casper> N1njaneer: no idea, but worked at room temperature :D
[16:30:56] <Casper> I'm happy, I fixed another painfull computer
[16:31:11] <Casper> simple issue: corrupted user account
[16:31:33] <Casper> simple solution: system restore... in theory... there was something that made all restore fail
[16:31:37] <Casper> that something was...
[16:31:46] <Casper> norton antivirus + avast
[18:47:25] * inflex is finding he hates most of the commercial AV's now
[18:47:41] <inflex> I just stick with Microsoft security essentials - at least it doesn't seem to cluster-fsck the whole system when things go wrog
[18:47:42] <inflex> wron
[18:47:45] <inflex> wrong... damn
[19:52:05] <N2TOH> http://www.futurlec.com/Protoboards.shtml#ISABUSBRD.shtml
[19:52:15] <N2TOH> WEE I found a ISA protoboard
[19:52:51] <jerkey> about 20 years too late. I made an ISA card once, back in the day, before i knew anything about long ribbon cables and 0.1uF capacitors
[19:53:12] <N2TOH> they have a PCI version too
[19:53:24] <Tom_itx> iirc i made an eagle footprint for pci
[19:53:28] <jerkey> i was just going to say that. but is PCI even reasonably easy to prototype?
[19:53:56] <N2TOH> it's only 33MHz a fair sight easier then some of the stuff today
[19:55:15] <braincracker> hey
[19:58:27] <Epsilon-Auriga_> careful buying from futurlec
[19:58:35] <braincracker> okey
[19:58:39] <Epsilon-Auriga_> they have good prices but shipping can get you
[19:58:42] <hackvana> You'll get it in time for Christmas
[19:58:44] <braincracker> canceling my $2.5M order right now
[19:58:46] <hackvana> Christmas 2014
[19:58:50] <Epsilon-Auriga_> and they sometimes take 3 to 6 weeks to ship.
[19:59:07] <N2TOH> I'm not in any rush
[19:59:09] <Epsilon-Auriga_> shortest time I ever got from them was 2.5 weeks.
[19:59:21] <Epsilon-Auriga_> longest was 6 weeks,,,on a few hundred resistors.
[19:59:42] <Epsilon-Auriga_> they apparently shipped it via passenger pigeon...
[19:59:47] <N2TOH> :)
[20:01:09] <Epsilon-Auriga_> http://www.circuitspecialists.com/at-bus-prorotyping-boards
[20:02:37] <Epsilon-Auriga_> http://www.circuitspecialists.com/xt--bus-prototyping-boards
[20:02:40] <N2TOH> LOL the VME proto cards are lower cost
[20:03:22] <Epsilon-Auriga_> stdbus looks like commodore vic-20 expansion card.
[20:03:31] <N2TOH> I was looking at the AT bus stuff as it would make interfacing with old video card and other PC perhiperals a breez
[20:03:59] <N2TOH> LOL VIC-20 FPU cart
[20:07:26] <N2TOH> the multi bus is that not the same as the S100 bus?
[20:08:31] <Epsilon-Auriga_> circuitspecialists is also a good place to get solderless breadboards cheap...and they are decent grade too.