Back
[04:24:56] <bitd> When I define __DELAY_BACKWARD_COMPATIBLE__ my hex size grows 4KB. Anyone have any idea how to minimize this effect?
[04:28:23] <Xark> bitd: Don't define that? :) Do you need it due to old gcc version?
[04:28:52] <bitd> I need to define dynamic delays.
[04:29:12] <bitd> When I dont define it, _delay_us does not take dynamic delays.
[04:30:39] <bitd> error: __builtin_avr_delay_cycles expects a compile time integer constant
[04:31:12] <Xark> bitd: Well, perhaps hack the header so that routine isn't inlined (or write another delay)?
[04:33:54] <bitd> Xark, you are probably right, need to know what I'm doing. Ugh, just wanted to fix it fast <.<
[04:36:46] <bitd> Meh, I'll just set a timer. Thanks for the idea though Xark
[04:37:28] <Xark> bitd: NP. Good luck. :)
[05:06:18] <Joggl> Xark, why don't you use a function that includes a fixed delay_us for dynamic delay?
[05:06:51] <Xark> Joggl: This was bitd's issue...
[05:07:11] <Joggl> oh, yes, sry ;)
[06:27:47] <Jartza> yay
[06:27:53] <Jartza> started learning avr assembler
[06:28:01] <Jartza> sort of reminds me of c64
[06:28:23] <Jartza> got the led blinking, yay
[06:31:44] <Jartza> although the first code is bit nasty, it omits the reset vector
[08:33:44] <Lambda_Aurigae> Jartza, I have commented many times that avr assembly reminded me of 6502 assembly. glad to see I'm not the only one.
[08:36:04] <LeoNerd> I don't really work at the AVR level... gcc seems good enough at the moment
[08:37:57] <Lambda_Aurigae> for most stuff I do too.
[08:38:11] <Lambda_Aurigae> but I learned AVR assembly before working with C.
[08:38:48] <Lambda_Aurigae> and I still use it for assembly subroutines for time critical stuff like doing vga output and such.
[08:39:14] <LeoNerd> Mmm
[08:40:14] <Lambda_Aurigae> if you wanted to hack v-usb core you will need to know assembly too because the actual usb comms is written in such.
[08:40:29] <Lambda_Aurigae> it just has a C wrapper.
[08:41:16] * LeoNerd nod
[08:41:38] <LeoNerd> I think today I'll either work on putting my STK500 clone onto a real tiny841 that I've now received, or possibly play with a neopixel + '85
[08:41:56] <LeoNerd> since my dirtypcb order -stiiiiiill- hasn't arrived yet
[09:10:54] <Tom_itx> they're on a slow boat from china
[09:11:16] <LeoNerd> Seems likely. Probably slower on account of Christmas too
[09:11:31] <Tom_itx> just don't order during their new year
[09:11:39] <Tom_itx> it will take 2x as long
[09:11:55] <LeoNerd> Ahwell.. it's nothing urgent
[09:12:08] <LeoNerd> A tiny little board to take a SOIC14 ZIF socket and bring it out to a DIP14 pin header
[09:12:20] <LeoNerd> Can't Think Why I'd Need That *cough* ATtiny841
[09:13:26] <Tom_itx> it's in February
[09:13:46] <Tom_L> http://en.wikipedia.org/wiki/Chinese_New_Year
[09:13:49] <LeoNerd> Ahyes
[09:13:58] <LeoNerd> Well hopefully my boards will arrive before then
[09:45:47] <RikusW> LeoNerd: you should try ordering from hackvana next time ;)
[09:46:47] <RikusW> try /join #hackvana you might learn a few things there as well
[10:03:23] <LeoNerd> I usually get boards from oshpark, I just thought I'd try dirty as these are tiny little cheap things
[10:05:09] <LeoNerd> avrdude: AVR Part "ATtiny841" not found.
[10:05:10] <LeoNerd> boooo
[10:20:32] <Lambda_Aurigae> you will have to add it to avrdude.conf
[10:21:55] <LeoNerd> http://www.ve7xen.com/blog/2014/03/07/programming-the-attiny841-with-avrdude/ has a working file
[10:22:19] <Lambda_Aurigae> either way your avrdude.conf has to have the definition for the chip in order for it to work.
[10:44:09] <Jartza> Lambda_Aurigae: yah, I haven't looked avr assembly that much, but now that I started checking it, I instantly got some flashbacks from the 80's :)
[10:44:23] <Lambda_Aurigae> yup.
[10:44:34] <Lambda_Aurigae> although, that could be all the LDS you did back then.
[10:45:08] <Jartza> maybe
[10:45:14] <Jartza> I also did some LCD later
[10:45:18] <Lambda_Aurigae> yes, I'm having startrek movie flashbacks.
[10:45:29] <Jartza> :)
[10:47:15] <Jartza> Program: 16 bytes (0.2% Full)
[10:47:15] <Jartza> (.text + .data + .bootloader)
[10:47:15] <Jartza> Data: 0 bytes (0.0% Full)
[10:47:15] <Jartza> (.data + .bss + .noinit)
[10:47:18] <Jartza> yay
[11:07:07] <Lambda_Aurigae> https://www.youtube.com/watch?v=unhXEQQk8G8 manual pulse width modulation?
[11:12:51] <Jartza> heh
[12:42:06] <LeoNerd> Hrm.. this is awkward. My HVSP burner doesn't want to talk to my new tiny841.
[12:42:26] <LeoNerd> I wonder if it's because the board the 841 is on has a 10k RESET pullup resistor on it.
[12:45:31] <Tom_itx> 10k isn't much
[12:46:05] <LeoNerd> It talks ICSP just fine so I think the chip is generally OK
[12:47:38] <LeoNerd> Does 84 fine
[12:49:48] <LeoNerd> Ah RikusW, just the chap. I can't seem to talk HVSP to my new tiny841
[12:50:39] <LeoNerd> It talks ICSP fine. I have one of these
https://www.tindie.com/products/bot_thoughts/eezeetiny841/ jerryrigged up to my HVSP board. The signature just reads as all zeroes
[12:51:23] <LeoNerd> My only immediate thought is the 10k pullup resistor on the board for reset
[12:53:36] <RikusW> ICSP is for PIC, AVR use ISP
[12:53:54] <LeoNerd> Er.. whatever. Acronyms :P
[12:54:18] <LeoNerd> Pin connections seem fine, because if I put my tiny84 chip in place then that works. just not this 841 board
[12:54:20] <RikusW> 10k might be the problem, does it work with other AVRs with the 10k ?
[12:54:28] <LeoNerd> will check
[12:54:36] <RikusW> and other 841's ?
[12:54:48] <LeoNerd> well, I -do- have one more 841 but no easy way to connect to it
[12:54:54] <LeoNerd> That's why I have this breakout board
[12:55:08] <Lambda_Aurigae> with it pulled to VCC through the 10k resistor you might have a problem because it needs to be isolated up to 12V.
[12:55:46] <RikusW> 10k will take like 1mA or so
[12:56:09] <Lambda_Aurigae> yeah, but it might do strange things to the reset circuit being tied to VCC and 12V
[12:56:33] <RikusW> afaik my design with the 662 and 1k5 in series works even with the 10k pullup
[12:56:55] <LeoNerd> tiny84 still works fine with that 10k
[12:57:00] <Lambda_Aurigae> hmmm.
[12:57:12] <RikusW> try removing it ?
[12:57:24] <LeoNerd> Hrmmm...yeah, easier said than done, that one ;)
[12:57:31] <RikusW> smd ?
[12:57:31] <LeoNerd> It's a 0603 already on the adapter board
[12:57:41] <LeoNerd> It might be easier for me to get my other tiny841 out
[12:57:51] <LeoNerd> I can apply test probes to a SOIC14 right? :)
[12:57:54] <RikusW> 0603 are easy to remove
[12:58:03] <RikusW> you could
[12:58:46] <RikusW> I simply apply enough solder to my iron's tip and let it touch both ends of the 0603, it will then stick to the iron
[12:58:58] <RikusW> use tweezers to remove from iron
[12:59:22] <RikusW> then bridge the pads
[12:59:30] <LeoNerd> Uh, bridging the pads would be worse
[12:59:48] * RikusW didn't think before typing :-P
[13:00:24] <RikusW> was thinking about my series 1k5...
[13:00:59] <RikusW> at least you realized it would be worse ;)
[13:06:19] <LeoNerd> Ohman I wish I had a photo of this. ... ohwait let me get my camera
[13:11:29] <LeoNerd> Ugh.. why don't Atmel put a pin1 dot on these things?
[13:11:58] <LeoNerd> Woo ! :)
[13:12:05] <LeoNerd> It works on the bare chip in my ZIF socket
[13:12:13] <LeoNerd> which is jerryrigged up all to hell on ym board
[13:12:48] <LeoNerd> this surely needs a photo
[13:13:27] <RikusW> so soldered the wrong way on the breakout ?
[13:14:52] <LeoNerd> I don't know yet... most vexing
[13:15:39] * RikusW don't seem to have the 841 datasheets on the 2012 techlib dvd...
[13:15:57] <RikusW> is one edge beveled perhaps ?
[13:16:48] <LeoNerd> Yah.. bevel has it
[13:17:10] <LeoNerd> Soooo... it seems that the tiny84 is happy to do HVSP with or without that 10k resistor, but the moment I try to add it on this jerryrig, it stops working
[13:17:13] <LeoNerd> on the 841 I mean
[13:17:27] <LeoNerd> So I think the presence of it on the breakout board is upsetting it
[13:18:41] <LeoNerd> I don't think they neeeeed it anyway do they? The chip itself has an internal pullup on the RESET line
[13:19:29] <RikusW> did you put a 1k5 in series fro mthe 12V source to the AVR ?
[13:19:35] <LeoNerd> Nop
[13:19:54] <LeoNerd> Oh though I don't have my circuit diagram online easily at themoment to show you
[13:19:55] <RikusW> did you connect it incorrectly ? it might have fried it...
[13:19:57] <LeoNerd> I should do that sometime
[13:20:08] <LeoNerd> Nah, it's all working nicely if I remove the resistor
[13:20:24] <RikusW> 1k5 makes it a lot safer
[13:20:34] <RikusW> and seems to work quite well
[13:20:48] <LeoNerd> But I think there's already a pullup resistor inside the tiny chip anyway, so there's no need for this breakout board to have another one
[13:20:53] <RikusW> higher values lower the voltage too much for reliable programming
[13:21:40] <LeoNerd> I'll consider on that, though I have my HVSP board already made up now, so that'd be another change :)
[13:21:44] <RikusW> you can test for internal pullup, add a pulldown and measure voltage ?
[13:22:58] * LeoNerd AFK to desolder this 10k off the easy841
[13:23:10] <LeoNerd> Actually, maybe after dinner
[13:28:11] <LeoNerd> https://twitter.com/cpan_pevans/status/551816925249294337 photo as promised
[13:34:54] <LeoNerd> Aha! Yes; as I suspected, the chip internal pullup resistor is enabled if the pin is in normal reset mode anyway
[13:35:01] <LeoNerd> So this external pullup on the breakout isn't necessary
[13:35:21] <LeoNerd> (at least according to the PB3 pullup override enable/value listed in the chart in the data sheet)
[13:37:47] <RikusW> sweet success at last :)
[13:38:04] <RikusW> quite a setup you've got there
[13:38:25] <RikusW> try hvpp, more wires, much more wires...
[13:38:29] <LeoNerd> Mmm
[13:38:46] <RikusW> 21/22 or so
[13:38:50] <LeoNerd> Well turns out I have no F-M jumper wires, so I had to wire up a second set of them via this bus pirate probe cable
[13:39:54] <LeoNerd> I should buy one of
http://www.amazon.co.uk/32cm-Female-Jumper-Cable-Connector/dp/B00JR5GMR4/ref=sr_1_14?ie=UTF8&qid=1420399134&sr=8-14&keywords=jumper+wires+male+to+female
[13:56:24] <hetii> Hi :)
[13:56:45] <hetii> Any iidea how to control such ic: web.icasic.com:8000/ziliaoxiazai/yihua/datasheet/Encode_Decoder/dM3D.pdf by some avr?
[14:03:43] <hetii> I also found: web.icasic.com:8000/ziliaoxiazai/yihua/datasheet/Encode_Decoder/dM3D.pdf it seams its transmiter for M3D
[14:09:16] <Lambda_Aurigae> hetii, same as you would with any microcontroller.
[14:10:14] <hetii> sure but its not clear for me the format of data that I should push on it
[14:12:04] <Lambda_Aurigae> well, you need an m3e and m3d as a pair.
[14:12:16] <Lambda_Aurigae> one to send the data the other to receive it.
[14:12:18] <hetii> thats the point. I have just m3d device
[14:12:42] <Lambda_Aurigae> you set your 4 bits of data and 8 bit address then momentary pushbutton for the transmit enable.
[14:13:12] <Lambda_Aurigae> m3e sends data out the DO pin...either over RF or IR or wire...
[14:13:52] <Lambda_Aurigae> i3d takes that data stream in the DIN pin,,if its address matches the data then it puts the 4 bits of data out on the D0-3 pins.
[14:14:08] <hetii> well this device what I have use M3D-L4 and some wireless resicver.
[14:14:52] <Lambda_Aurigae> so you need the wireless transmitter with an m3e device to send the data.
[14:15:23] <Lambda_Aurigae> that datasheet does not give you the packet frame format.
[14:16:10] <Lambda_Aurigae> if you had the pair you could put a logic analyzer on it and catch the data and figure out the frame format.
[14:17:16] <hetii> Lambda_Aurigae: but I don`t have it. Instead my plan was to try use avr with bluetooth transmiter
[14:17:35] <Lambda_Aurigae> do you have a bluetooth receiver also?
[14:18:20] <hetii> well I mean (avr + bluetooth2rs232) and my pc or phone on other side
[14:18:34] <Lambda_Aurigae> then why do you need that m3f unit?
[14:18:57] <Lambda_Aurigae> err...m3d
[14:19:43] <hetii> well the idea was to use just this bluetooth reciver and m3d.
[14:19:58] <hetii> but it make no much sense
[14:20:11] <hetii> also i have limited space in this devices
[14:20:28] <Lambda_Aurigae> it makes perfect sense....but I doubt it will be trivial to connect the two.
[14:20:41] <Lambda_Aurigae> and, again, the datasheet does not say anything about the frame format.
[14:20:49] <Lambda_Aurigae> so without that it's kinda useless.
[14:21:02] <hetii> yep, will be hard
[14:21:27] <LeoNerd> RikusW, et al: I've desoldered that reset pullup resistor off the tiny841 breakout board and now it's talking HVSP juuuuust fine
[14:21:45] <hetii> http://www.mosdesign.com.tw/datasheet/Encode_Decoder/dM3E,.pdf here is some bit wave format on page 3
[14:21:47] <RikusW> good to know
[14:21:54] <RikusW> was it easy to desolder it ?
[14:22:06] <Lambda_Aurigae> that is a timing diagram
[14:22:10] <Lambda_Aurigae> not frame format.
[14:22:14] <LeoNerd> Yah; easy enough. I just didn't want to do that first in case it was unnecessary
[14:22:29] <LeoNerd> But having tested the other chip with this ZIF socket suggested it was necessary, and turns out to have been. So all is fine
[14:22:41] <LeoNerd> And also I'll email the maker of this breakout board to suggest he omit it in future
[14:22:49] <hetii> ok Lambda_Aurigae I will try search more info about thouse ICs
[14:22:58] <hetii> maybe find what is needed to run it.
[14:23:13] <Lambda_Aurigae> what is needed is encoder and decoder pair.
[14:23:21] <Lambda_Aurigae> or to know the frame format..
[14:26:17] <hypermagic> hello my friends
[14:27:19] <hypermagic> bitd, the proper way to delay is using a timer and interrupt
[18:13:31] <Aer93> hey... I'm using the ardupilot mega 2.0. I'm trying to read values from the IMU, MPU6000 with SPI. The thing is that I'm obtaining the values reaaallly slow
[18:13:46] <Aer93> I wonder if I'm configuring wrong the SPI
[18:14:09] <Aer93> I've set the clock with a 16 prescaler, the procesor clock is 16MHz
[18:14:29] <Aer93> so the clock signal for the SPI should be 1MHz... right?
[18:14:47] <Aer93> well Its taking around 20 miliseconds to read 2 bytes, is that normal???
[18:14:54] <Aer93> I stimate it should take 2 ms....
[18:14:58] <Aer93> any idea?
[18:19:14] <Aer93> I have no clue if that's normal, it feels slow for me hehehe
[18:39:29] <doug64k> Aer93: that is 100 bytes per second
[18:39:53] <doug64k> 2 / 0.020
[18:40:23] <Aer93> doug64k: is then correct??
[18:40:35] <Aer93> doug64k: feels really slow
[18:41:07] <doug64k> 1MHz (with zero overhead) should be 125000 bytes per second
[18:41:50] <doug64k> so yeah, 100 is way slow
[18:42:34] <doug64k> I should say, 1 million bits per second = 125000 bytes per second
[18:43:03] <doug64k> there is overhead of course, it isn't a perfect stream of bits
[18:45:31] <Casper> 10/8 encoding
[18:50:54] <doug64k> Aer93: it should be 1000x faster then, 100,000 bytes per second max
[18:51:21] <doug64k> is it a request/response? is there wait time in between?
[18:52:02] <Aer93> doug64k: no wait time
[18:52:29] <doug64k> you are off by one unit. it should be 20 microseconds to get 2 bytes at 1MHz 10 bits per byte
[18:52:29] <Aer93> doug64k: I just do a transfer and wait for the interrupt
[18:52:45] <doug64k> oh?
[18:52:47] <Aer93> doug64k: thats what I spected 2 mili secconds
[18:52:47] <doug64k> how long
[18:53:04] <Aer93> doug64k: therefore I do not get it...
[18:53:38] <doug64k> how do you "wait" for an interrupt. what would be the point of that?
[18:53:42] <doug64k> save power?
[18:53:51] <Aer93> https://github.com/Juanjbb/avionica/tree/fifo
[18:54:02] <Aer93> the spi interface is implemented in
[18:54:05] <Aer93> communications/spi
[18:55:06] <Aer93> I dont see where my time is running out
[18:55:18] <Aer93> maybe the interrupts of the USART communicating with the computer?
[18:55:38] <Aer93> I only do 2 interrupts
[18:55:58] <Aer93> one for the clock, one when the register of the USART is empty so I can send more data
[19:03:37] <doug64k> Aer93: in one case you set one thing, in the other case you set the other. Why don't both cases fully set it up?
[19:04:11] <doug64k> https://github.com/Juanjbb/avionica/blob/fifo/src/code/communication/spi/spi.cpp#L41
[19:04:35] <doug64k> are you making assumptions about initial values?
[19:05:01] <Aer93> what pat
[19:05:10] <Aer93> ah
[19:05:10] <doug64k> either
[19:05:17] <doug64k> one sets one thing, the other sets another thing
[19:05:22] <Aer93> you mean the e1Mhz ?
[19:05:29] <doug64k> 4hmz clears just the bottom 2 bits
[19:05:40] <doug64k> 1mhz just sets bit SPR0
[19:05:42] <Aer93> its in the datasheet
[19:05:47] <doug64k> why don't you fully set it up in both cases
[19:06:00] <doug64k> never assume any state is correct in a microcontroller
[19:06:05] <doug64k> a power glitch can corrupt things
[19:06:26] <Aer93> I dont understand what you suggest me to do
[19:06:32] <doug64k> bulletproof code would periodically reset that to be sure it didnt change from a glitch
[19:06:43] <doug64k> but at least set all the bits when you initialize
[19:06:55] <Aer93> but any way, communications is not being corrupted
[19:07:11] <Aer93> the data I'm obtaining is great, the only problem is that it comes to slow
[19:07:29] <doug64k> and the speed is off by 1000x right
[19:07:50] <doug64k> if I believe you assertion that there is no wait
[19:07:54] <doug64k> your*
[19:09:22] <doug64k> what I was trying to say was, you should be setting all of the bits involved in both cases
[19:09:32] <Aer93> ah ok
[19:09:39] <doug64k> don't assume that some bits are 00
[19:09:42] <doug64k> for example
[19:09:53] <Aer93> ok
[19:09:58] <Aer93> I going to change that
[19:10:19] <Aer93> you are suggesting that maybe a different prescaler is being chose
[19:10:21] <Aer93> right?
[19:10:42] <doug64k> yes
[19:11:58] <Tom_itx> what about ckdiv8 fuse?