Back
[00:01:17] <ziph> Why not just send the buffer you use for snprintf off to the UART?
[00:02:01] <Casper> that would need malloc, and that's not to use on micro
[00:02:32] <ziph> Where are you getting that buffer from in your application?
[00:02:54] <Casper> globally declared one
[00:03:17] <ziph> So send a pointer to that buffer to the UART. :)
[00:08:16] <rue_bed> the idea is to program it in the worst way for a microcontroller
[00:08:29] <rue_bed> ways that use resources a microcontroller dosn't evenhave
[00:08:40] <ziph> Hmm? :)
[00:08:58] <rue_bed> now, lets get serious and convert this whole thing to java so he can run it the way he wants on his atmega8
[00:13:37] <Casper> rue_bed: have you seen an uart lib with flow control?
[00:29:15] <inflex> aw hell
[00:29:24] <inflex> itead didn't use the right drill size for my ISP
[00:29:42] <inflex> they went 1 size smaller and now it's impossible for me to put my pin header into the holes
[00:31:19] <Casper> plated holes?
[00:32:30] <Casper> inflex: have you seen any uart libs with flow control support?
[00:33:07] <inflex> Casper: none that I've been exposed to
[00:33:11] <inflex> I'll be writing my own just now too
[00:33:25] <Casper> will you make it public?
[00:33:44] <inflex> Casper: yes, basically just vias under the TQFP in a diagonal 1x6 row and 1.25mm pitch
[00:33:49] <inflex> Casper: it won't have flow control
[00:33:54] <inflex> Casper: it's just going to be a blind-dumper
[00:34:09] <Casper> ok
[00:47:52] <inflex> http://dxp.me/i/SLOGGER1-1.jpg <=- latest contraption, the one that'll do the serial... and the one that I'm peeved has the undersize holes
[00:48:47] <Casper> but... a thru hole component on a smd pad? bad inflex :D
[00:48:58] <inflex> didn't have the right value shunt in 2512, so I had to use a silly normal resistor
[00:49:15] <inflex> at least for testing anyhow
[00:50:00] <Casper> what will you do with the bad boards?
[00:50:05] <Casper> have them redo it?
[00:50:15] <Casper> under waranty that's it
[00:50:17] <inflex> no, not worth it I can still program them, but it's just more fiddly
[00:50:31] <Casper> oh it's just the programmation pads?
[00:50:47] <inflex> yeah
[00:51:07] <Casper> you don't have a nail bed?
[00:51:17] <inflex> no
[00:51:27] <Casper> make one :D
[00:51:30] <inflex> these are 1.25~1.27mm pitch !
[00:51:38] <inflex> the header was the nailbed ;)
[00:52:58] <inflex> Anyhow, hope I can do about 200~400bytes/sec dumping to the EEPROM, I'm sure I should be able to
[00:53:22] <inflex> esp since it's SPI, not I2C
[02:12:52] <inflex> anyhooooo - better go solder an ISP lead onto these stupid too-small header holes
[02:12:56] <inflex> at least I can use IDC calbe
[02:25:49] <inflex> right, another 1-off jig done in my life... *sigh*
[02:33:33] <scuzzy> for, part placement?
[02:34:20] <inflex> nah, cable jig
[02:34:34] <inflex> ... anyone tried using an ADC Vref below 1V on the mega?
[02:34:59] <inflex> the spec says 1V min, but I can't find any reasons/literature as to -why-
[02:37:59] <soul-d> so this is why guy's do robotics
[02:38:00] <soul-d> http://www.youtube.com/watch?v=6L_NsBXN8SQ
[03:21:05] <scuzzy> Is it possible to give an AVR clock like accuracy?
[03:21:39] <jacekowski> if you have external accurate crystal
[03:22:00] <scuzzy> yeah, I know
[03:22:11] <scuzzy> but, most crystals aren't THAT accurate
[03:22:17] <jacekowski> yes they are
[03:22:30] <scuzzy> you're looking at loosing like 10 odd minutes a year
[03:22:38] <Tom_itx> how many ppm do you need to call it accurate?
[03:22:40] <scuzzy> or gaining
[03:22:44] <jacekowski> clocks run of single 32kHz crystal
[03:22:45] <scuzzy> like a watch
[03:22:54] <jacekowski> so get one like that
[03:23:00] <scuzzy> 32khz?
[03:23:01] <jacekowski> because it divides nicely into 1s
[03:23:01] <scuzzy> you recon?
[03:23:11] <jacekowski> yes those are made for just that one purpose
[03:23:17] <devilsadvocate> 32768
[03:23:22] <Tom_itx> and watch the trace capacitance etc very carefully and get very accurate caps for it etc etc etc
[03:23:42] <devilsadvocate> and calibrate it for a month
[03:23:57] <devilsadvocate> and then avoid temperature fluctuations
[03:24:10] <scuzzy> there has to be an easier way
[03:24:11] <scuzzy> lol
[03:24:38] <devilsadvocate> scuzzy: most clocks arent as accurate as that
[03:24:56] <scuzzy> really?
[03:25:06] <devilsadvocate> 10 minutes a year is respectable performance
[03:25:08] <scuzzy> maybe I'll just use the old 16mhz crystal and see how it goes
[03:26:26] <devilsadvocate> you'll be able to keep it on without interruption for a year?
[03:29:39] <scuzzy> that's the idea
[03:30:46] <scuzzy> sleeping most of the time
[03:31:41] <devilsadvocate> if the time is important you may want to consider using an RTC
[03:32:53] <scuzzy> an external IC?
[03:33:04] <scuzzy> they can provide external interrupts hey?
[03:33:41] <devilsadvocate> yes, they can
[03:34:09] <scuzzy> nice
[03:34:20] <scuzzy> can you hook up a 16mhz and a 32khz to any AVR's?
[03:34:29] <scuzzy> ie: one is for time keeping?
[03:34:31] <scuzzy> or, not so much
[03:34:52] <devilsadvocate> dont think so. not any of the small ones, afair
[03:35:09] <devilsadvocate> you can have 32khz + internal RC
[03:36:05] <scuzzy> Hmm ok
[03:36:09] <scuzzy> cool, thanks for the advice
[03:43:28] <scuzzy> has anyone ever built an enclosure for the dragon?
[04:00:08] <inflex> ugh, now time to try talk to my SPI eeprom
[04:02:58] <karlp> it's spi! what could go wrong!
[04:03:18] <karlp> so, I was wondering why the LED was blinking really slowly,
[04:03:45] <karlp> turns out these boards got a 12mhz resonator stuck on them, and the fuses set to use it.
[04:04:01] <karlp> instead of the 8Mhz RC oscillator
[04:04:10] <karlp> and no-one bothered to tell the makefiles about the change
[04:07:17] <karlp> huh, and this one didn't even get the fuses set.
[04:07:19] * karlp shrugs
[04:19:52] <inflex> dooooh... wtf..... I had CS pinned to GND for some dumb reason when there was a perfectly good control pin right there next to the SPI chip *headbangs* damned it, now that's another PCB revision
[04:20:50] <inflex> shitty little mistakes like that cost me too much!
[04:31:37] <ziph> inflex: Get someone to review them?
[04:31:49] <inflex> ziph: not at this level
[04:32:10] <ziph> Hmm?
[04:32:26] <inflex> teeny little board, will take me as long to explain/organise a review
[04:32:39] <inflex> as to just get on with something else and submit a revision
[04:32:58] <inflex> while the cost me, I can't see how to do it any cheaper either
[04:33:20] <ziph> Checking the raw netlist works too.
[04:33:30] <ziph> You would've seen GND ... CS
[04:33:43] <inflex> Not sure I would have picked it up mentally
[04:34:01] <inflex> anyhow, for now I'm lifting the leg and bridging it to the AVR via a 3mm link
[04:34:21] <inflex> and now I'm istting here wondering if I am going to have any luck with this EEPROM SPI code :p
[04:34:26] <inflex> (bit bashed)
[04:36:50] <inflex> just realised this is 64-bit paged memory... so that'll be interesting
[04:38:34] <inflex> hoooooboy... not even sure this is going to work out so well... 256Kbit/32KB isn't really enough to log a lot of data
[04:39:14] <inflex> not sure what I was thinking, was supposed to be 256KB.... ugh, 32KB... shit, time for some crazy compression or something
[04:39:21] <ziph> EEPROM or Flash?
[04:39:24] <inflex> EEPROM
[04:39:39] <ziph> What about FRAM? :)
[04:40:00] <inflex> well, will try get this running... at least I can probably buy 1MBit ones
[04:40:59] <inflex> woop, no, only 512KBit
[04:41:12] <inflex> fugging hell, nothing like having the fun of a project sapped out of you
[04:41:24] <ziph> :)
[04:42:27] <inflex> 24-bits/frame, that only gives me ~10,000 frames, there's ~20fps, that's only 533 seconds
[04:42:44] <inflex> not even 9 minutes :(
[04:43:59] * inflex sobs
[04:44:54] <inflex> I usppose at least with 512Kbit I could get 18 minutes, which is about right for a flight
[04:45:10] <inflex> anyhow, better work out this convoulted timing protocol
[06:20:39] <inflex> aww HELL, what a time to run out of HIN202s
[07:49:37] <impulze> hey there, i'm facing problems when using the 2-wire interface, as long as i put the relevant commands (start, send slave) right next to each other i end up with MT_SLA_ACK in my status register, if i however pause between sending start and sending the slave my status register ends up being zero
[07:49:42] <impulze> any clues what could cause that?
[07:53:27] <ziph> impulze: Pause for how long?
[07:53:59] <impulze> depends, it's triggered via IPC
[07:54:04] <impulze> could be 2-3 secs
[07:54:36] <ziph> What is the slave?
[07:58:12] <impulze> i have two kind of slaves, one pcf8591p and 3 slds157d
[07:58:20] <impulze> http://www.alldatasheet.com/datasheet-pdf/pdf/101395/PHILIPS/PCF8591P.html
[07:58:25] <impulze> http://www.ti.com/lit/ds/slds157d/slds157d.pdf
[07:58:40] <impulze> both show the same behaviour regarding that issue
[07:58:44] <ziph> Hmm, they shouldn't care about the delay.
[07:59:10] <impulze> could the operating system cause some trouble here?
[07:59:10] <ziph> You get a NACK on the address byte?
[07:59:25] <impulze> no, i get nothing
[07:59:30] <impulze> TWSR ends up being zero
[07:59:30] <ziph> What's the operating system?
[07:59:34] <impulze> contiki
[07:59:39] <impulze> current master (git)
[08:04:18] <ziph> Do the other TWI registers make sense at that point? Maybe something else is kicking up and using it.
[08:13:43] <impulze> i have to verify that, i think they did last time i checked
[08:29:29] <impulze> ziph: yes, at least TWCR makes sense at this point
[08:29:47] <impulze> and since this is the first command after the start condition (i.e. sending slave address) i don't expect TWDR to make any sense
[08:32:41] <ziph> impulze: What if you disable interrupts and sit around for 2 seconds between start and the address byte? That would tell you if it was other code running or if it is something timing related with the controller.
[08:33:35] <impulze> when do you suggest disabling and enabling the interrupts again?
[08:34:03] <impulze> disabling after receiving ack from the start command and enabling before setting the data register/control register?
[08:34:44] <ziph> You get an ACK on the start command?
[08:34:54] <ziph> Oh, from the controller?
[08:35:22] <impulze> no ACK as in MT_*_ACK, i just meant ack semantically, not literally :)
[08:35:39] <impulze> as in TWSR & 0xF8 being 8
[08:35:56] <ziph> Ahh, the ack at that stage is to indicate the bus is free.
[08:36:03] <impulze> yeah
[08:36:25] <ziph> Yeah, right after that (so that it is delaying in the same place your existing 2-3 second delay happens).
[08:36:39] <impulze> let's try that :)
[08:37:09] <ziph> You basically want to emulate the existing delay you have but without the OS running any other code in the mean time.
[08:37:39] <impulze> yep
[12:30:22] <impulze> ziph: i was trying to reproduce the exact same step with my debugger, i.e. writing to memory and waiting for register changes, and it turns out even this doesn't work if it's not within the same function so i assume there's a race somewhere
[12:31:09] <impulze> ziph: now i tried to see what kind of interrupts i receive by registering a service routine and i seem to get an interrupt following a status register contents with TW_SR_GCALL_DATA_NACK
[12:31:26] <impulze> i'm trying to find out why/what that is and work my way through from there :)
[13:20:20] <RikusW> !thislog
[13:20:26] <RikusW> !thislog
[13:20:27] <tobbor> This one:
http://rueshouse.dyndns.org:82/~ircjunk/irclogs/html/%23avr-2011-11-21.html
[13:21:26] <Steffanx> CANUCK
[13:21:27] <tobbor> Yankie.
[13:41:18] <specing> tobbor: How much NUCK CAN a CANUCK NUCK if a CANUCK CAN NUCK NUCK?
[13:41:19] <tobbor> YANKIE.
[13:43:15] <RikusW> specing: seems you're enjoying yourself ? ;)
[13:43:52] <RikusW> be carefull tobbor might YANK you out of the channel :-D
[14:08:16] <ama2er> quit
[14:08:24] <Steffanx> bb
[14:23:45] <RikusW> specing: how is your USB projects now ?
[14:23:58] <specing> Which ones?
[14:24:21] <Steffanx> That one
[14:25:32] <RikusW> specing: theres more than one PCB by now ?
[14:26:27] <specing> Nope, still one
[14:26:42] <specing> I have a project now to build a USB battery charger
[14:27:49] <Steffanx> What kind of batteries?
[14:28:37] <specing> Idk
[14:29:10] <specing> I guess NiCD,NiMH and 3.7V Li-ion
[14:29:26] <specing> I'll see which one is the easiest
[14:29:40] <specing> I'll use an atmega to PWM the SMPS
[14:30:38] <Steffanx> NiCD/NiMH is probably easiest and safest :)
[14:31:26] <specing> I heard NiMH are little b****** to charge
[16:55:13] <biker> hi,., im trying to work using uart with an atmega128,., if i set the baudrate to 9600 everything works great,., but if i set it to 115200, it returns me things like: '\xe1' ,., any idea? =/
[16:55:35] <LoRez> what's your clock?
[16:55:56] <biker> LoRez: 16MHz
[16:56:24] <LoRez> crystal, ceramic?
[16:57:08] <biker> LoRez: crystal
[16:57:22] <biker> im using this formula for the setup: BAUD_PRESCALE (((F_CPU / (USART_BAUDRATE * 16UL))) - 1)
[16:57:40] <biker> f_cpu is 16000000UL, and usart_baudrate is 115200
[16:57:52] <LoRez> did you check what that worked out to in the assembly?
[16:58:42] <biker> LoRez: sorry, what do you mean?
[16:59:44] <LoRez> usually the datasheet has the register calculations done for you for common crystal and baud rates. did you make sure yours matched?
[17:01:00] <biker> LoRez: in the datasheet it says this:
[17:01:05] <biker> ooo wait
[17:01:13] <biker> it says:
[17:01:28] <biker> baudrate: 115.2K
[17:01:36] <biker> and it has 3 things:
[17:02:40] <biker> fosc=1.0000 MHz | U2X=0 (what im using) | UBRR = -
[17:03:03] <biker> then: fosc=1.8432 MHz | U2X=0 (what im using) | UBRR = 0
[17:03:30] <biker> and lastly: fosc=2.0000 MHz | U2X=0 (what im using) | UBRR = 0
[17:03:34] <biker> LoRez: ^
[17:06:46] <biker> LoRez: which one of those 3 is the one im using if im using a 16MHz crystal?
[17:07:15] <LoRez> biker: skip ahead a few pages.
[17:07:52] <LoRez> u2x=0 gives you a -3.5% error, where u2X=1 gives you 2.1%
[17:07:53] <biker> LoRez: oops sorry i didnt see that :p
[17:08:04] <LoRez> well then you should keep your tongue in your mouth.
[17:08:11] <biker> haha
[17:08:21] <LoRez> and I should be the one to stick mine out.
[17:08:25] <biker> LoRez: the '-' means that I cant use that?
[17:08:43] <LoRez> yeah, it's not fast enough
[17:08:49] <biker> i mean for the -3.5%
[17:09:11] <LoRez> no, that means your actual baud rate will be -3.5% off
[17:09:37] <LoRez> which may be too much. if you really want to do that baud rate accurately, you should get a 14.7456MHz crystal.
[17:10:04] <LoRez> 16MHz is pretty bad for standard baud rates.
[17:10:52] <LoRez> you could stick with a 76.8k baud. that's the same percentage error as your 9600 and low enough it should work properly.
[17:11:06] <LoRez> anyway, time for me to go for a while.
[17:11:57] <biker> LoRez: okok thanks ! i cant change the crystal because it comes already with a pcb
[17:12:04] <biker> but ill try to use then other baudrates
[17:12:06] <biker> LoRez: thanks!
[17:12:09] <biker> (:
[17:19:11] <vectory> is bestimmt wieder irgend krams, wie immer von dir -_-
[17:19:14] <vectory> oops
[17:19:17] <vectory> wring channel
[17:20:04] <biker> kein problem :P
[19:10:58] <inflex> well hells bells, that was fun *cough*
[19:11:05] <inflex> bloody eeproms on the outside of the chip
[19:11:26] <inflex> now I have to work out some crazy compression scheme to maximise my pitiful 32K or 64K of EEPROM :(
[19:11:33] * inflex wishes they had 1M ones :(
[19:15:42] <Casper> hehe
[19:16:43] <Casper> but if they can make a 3D demo in 64k, that have 12k of text, 7 scene, 15 minutes of high quality audio and a few hundread of textures... you can surelly find a way to compress some :D
[19:20:03] <vectory> Casper: 64k demos use procedural texture generation
[19:20:18] <Casper> I know
[19:20:30] <vectory> thats no compression
[19:20:42] <Casper> they also used some compression for the code
[19:21:07] <vectory> idd, kkrunchy and crinkler
[19:21:12] <vectory> mostly
[19:21:26] <Casper> .the product
[19:21:55] <vectory> 4ks nowadays are lame, imho, only shaderprogramms, tho still over my head
[19:23:04] <vectory> Huffman coding is all i know about compression
[19:23:57] <vectory> inflex: use io extension chips and 16 64k eproms ;)
[19:24:16] <grummund> wut?
[19:24:34] <grummund> 1Mbit serial EEPROM is yesterday's technology
[19:25:28] <Casper> man the amazon kindle fire have an HUGE battery!
[19:26:29] <vectory> mit wine gehts nimmer
[19:26:32] <vectory> oops
[19:26:48] <vectory> sorry, im still new to irssi splitwindow
[19:27:13] <Casper> the battery is the 2/3 of the tablet
[19:32:30] <inflex> well, I only have room for 1 serial eeprom
[19:33:01] * inflex guards the programming with his life... though I'm still confused on their page-writing... will have to re-read that later
[19:34:06] <inflex> am -very- pleased with the serial dumping though, 57600bps without any troubles on a 6MHz xtal, which would normally have a fair amount of error in it
[19:34:14] <inflex> (that's bitbashed!)
[19:38:58] <Tom_itx> nice
[19:41:27] <inflex> to make it work, you have to keep track of how many cycles over/under you are relative to the desired output
[19:42:04] <grummund> i did 115200 on a PIC @ 4MHz once
[21:35:19] <inflex> hah... turns out the REAL problem with my SMPS was the diode
[21:42:24] <inflex> I think the first diode wasn't fast enough
[23:52:00] <soul-d> mmm how bradly manning still apears with news
http://ic.tweakimg.net/ext/i/imagenormal/1321899584.jpeg how he looks now in reallife ->
http://thanksalotobama.com/thanksobblog/wp-content/uploads/2011/03/abu-22.bmp
[23:52:04] <soul-d> go go usa
[23:52:15] <Casper> bmp????
[23:52:18] <Casper> BMP??????
[23:52:26] <soul-d> i din't make it :P
[23:52:33] <Casper> who the hell upload bmp?!?
[23:53:16] <theBear> that's the old schoo' shit
[23:53:42] <soul-d> maybe bradley and encodings gave him an error not allowed :)
[23:53:44] <theBear> ooh look, ffox does bmp this year
[23:53:56] <theBear> that guy looks smashed
[23:54:19] <soul-d> well better not tell on your goverment :)
[23:54:35] <soul-d> cause then you ofcourse have no rights anymore
[23:55:22] <theBear> pfft, our government is way too soft to pull treason charges
[23:56:12] <soul-d> not that americans had any left
[23:57:12] <theBear> pfft, they're only americans, don't worry about them
[23:57:32] <theBear> their sense of self-importance more than makes up for anything bad that might happen to them
[23:57:38] <soul-d> well with the amount of nukes and the FacT they use them
[23:58:39] <soul-d> and imperium on brink of falling apart makes weird moves
