Back
[17:51:05] <creep> easily
[17:52:10] <creep> tomatto<< charge/discharge a capacitor with the source voltage, measure time and calculate natural logarithm
[17:55:31] <tomatto> creep: do you have some C example code please?
[17:56:04] <creep> atmel.com has i remember
[17:57:48] <tomatto> creep: i found only assembler code :(
[17:57:56] <creep> ;/
[18:01:06] <creep> i believe you should be able to convert that to C
[18:01:46] <creep> how can you program a microcontroller wuthout knowing its instructions?
[18:02:00] <tomatto> creep: in C code
[18:02:31] <creep> but you read datasheet no?
[18:03:36] <tomatto> of course
[18:03:48] <creep> it is full of asm code...
[18:04:26] <creep> btw, C supports inline ASM functions
[18:04:45] <creep> haven't tried this on AVR gcc yet though
[18:04:56] <Tom_itx> it works
[18:05:03] <creep> yea
[18:05:40] <Tom_itx> http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#s5
[18:05:49] <creep> i know that
[18:05:57] <creep> jut was unsure about avr-gcc
[18:06:03] <creep> *just
[18:06:09] <Tom_itx> http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
[18:06:14] <creep> because it is different
[18:07:30] <tomatto> how can i do same thing for two interrupts?
[18:07:31] <tomatto> in C
[18:13:08] <creep> tomatto<< i can use inline asm in normal syntax ?
[18:13:22] <creep> Tom_itx
[18:13:35] <creep> on linux, the default is the crap att
[18:14:02] <creep> it needs to be set intel syntax as a parameter
[18:19:55] <creep> http://www.nongnu.org/avr-libc/user-manual/group__avr__math.html
[18:20:10] <creep> who uses double precision calculations on 8 bit atmel ?:)
[19:23:58] <jadew> hey guys, I have a few questions about bootloaders, never used them but I want to so here are my questions in order:
[19:24:04] <jadew> 1) Is the code in the bootloader section treated differently than normal code?
[19:24:20] <jadew> 2) Is the bootloader code written to the device differently than normal code? (do you have to specify the address or something?)
[19:30:34] <Casper> jadew: I can answer some of those questions
[19:30:45] <jadew> thanks
[19:30:53] <Casper> the boot loader is nothing more than another program
[19:31:12] <Casper> the only difference is where the code start (address)
[19:31:17] <jadew> at the end
[19:31:19] <jadew> right?
[19:31:26] <Casper> near the end yes
[19:32:01] <Casper> you can switch from one to the other, but care must be taken... beware of the interrupts
[19:32:24] <Casper> just do an absolute jump to the proper reset vector
[19:32:37] <jadew> ah, good idea
[19:32:42] <Casper> i.e. 0x0000 for the main code and 0xC000 for example for the bootloader
[19:33:03] <Casper> in code, you can select which vector table will be used for the interrupts: the one at the boot loader or the main code
[19:33:19] <jadew> interresting
[19:33:42] <Casper> and probably the most common one is probably the arduino one
[19:33:51] <Casper> bulky, but work
[19:34:17] <jadew> I'll have to check the protocol used, thanks
[19:34:25] <damjan> Casper: how does the AVR choose where to start, at the bootloader or 0x0000?
[19:34:40] <jadew> damjan, it starts at the bootloader initially
[19:34:44] <jadew> (when reset)
[19:34:55] <damjan> what if you don't have a bootloader jadew
[19:35:05] <jadew> and the bootloader is responsible for passing control to the main code
[19:35:15] <jadew> damjan, if you don't, you don't set the bootloader fuses :)
[19:35:27] <damjan> aha, bootloader fuses, cool
[19:36:02] <jadew> Casper, thanks for answering my questions
[19:36:15] <Casper> damjan: there is some fuses for the start address
[19:36:34] <Casper> and will always start there
[19:37:39] <Casper> so you can tell it to boot to the booloader, then the bootloader check a condition (button pressed within a second, or a certain data on the serial port for example), if that condition exists it continue to the bootloader, else it jump to the main program
[19:38:23] <damjan> Casper: btw, you mentioned there are different interupt vectors?
[19:39:01] <Casper> damjan: yes, but maybe not on all parts
[19:39:50] <damjan> when is the vector switched?
[19:40:51] <jadew> it appears that there's a fuse on atmega8, called bootrst
[19:41:18] <jadew> which moves the reset vector to the boot section - not entirly sure what this means, but I guess it moves the interrupt table there
[19:41:26] <jadew> or uses that one by default
[19:41:42] <jadew> another piece of info: The Interrupt Vectors can be moved to the start of the boot Flash section by setting the Interrupt
[19:41:42] <jadew> Vector Select (IVSEL) bit in the General Interrupt Control Register (GICR).
[19:41:59] <jadew> hmm, maybe bootrst doesn't do that
[19:42:06] <jadew> and maybe you have to do it from the bootloader itself
[19:42:27] <jadew> like "hey, give me the interrupts!"
[19:42:52] <jadew> and when the bootloader is done it probably unsets that bit and gives control to the main code
[19:42:58] <jadew> yeah, makes sense
[19:44:43] <jadew> I think BOOTRST is what enables the bootloader on this particular MCU
[20:03:54] <tomatto> uint32_t is weird with attiny2313
[20:13:25] <tomatto> how can i do 24bit uint?
[20:18:08] <Xark> tomatto: Use asm.
[20:18:21] <tomatto> how?
[20:18:41] <Xark> tomatto: Why do you need 24 bit vs 32?
[20:19:07] <tomatto> Xark: 32bit uint doing bulshit
[20:20:05] <Xark> tomatto: I am skeptical. 32-bit math works fine in my experience on AVR. Do you suspect a compiler bug or something? What is "bullshit"?
[20:22:26] <tomatto> when i do for loop to send serialized data to output, 16bit work fine, and next 8/16bit send zeroes instead of bits what i want
[20:23:48] <Xark> tomatto: OK, maybe you can paste your code somewhere, but your problem is not (directly) because of uint32 (I highly suspect).
[20:24:19] <tomatto> so where do you think?
[20:25:02] <Xark> tomatto: Some bug in your code, sounds like.
[20:26:58] <tomatto> Xark: so what do you think?
http://pastebin.com/0CfhiVPq
[20:27:16] <tomatto> with 16bits it works fine
[20:29:17] <Xark> tomatto: Looks very questionable, but I can't really see what bardata , barport or barcp is for (or where it is defined).
[20:30:06] <Xark> tomatto: So your input is in ledbardata and what are you doing for output? Outputting one bit at a time to a port?
[20:30:22] <tomatto> Xark:
http://pastebin.com/X2hqRc9P
[20:31:04] <tomatto> Xark: yes, outputting one bit at a time to a port from ledbardata variable
[20:32:51] <Xark> tomatto: Not sure why you need barcp, but perhaps something like this :
http://pastebin.com/KQdShv7c
[20:33:12] <tomatto> barcp is clock
[20:34:01] <Xark> tomatto: So you want every other output bit to be a 1?
[20:34:59] <tomatto> Xark: what? and where you have x variable used?
[20:35:27] <Xark> tomatto: I don't need X, I just shift the ledbardata input (so bit 0 is always next to output).
[20:36:04] <tomatto> Xark: why don't use X? i don't want to be ledbardata changed
[20:36:38] <Xark> tomatto: OK, then copy to a temp. Or re-add the test for 1<<x if you like.
[20:36:59] <tomatto> what is bad in my solution?
[20:37:35] <Xark> tomatto: Hard to say since I have only seen a snippet. I don't see what you need bardata or barcp for form the snippet.
[20:38:44] <tomatto> it is entire code, what do you know else to understand it?
[20:40:20] <Xark> No, I don't believe it is entire code. It won't even compile (bardata and barcp aren't defined or initialized - nor barport [but generic port is fine]). :)
[20:41:14] <Xark> tomatto: OK, question for you, why to you check 1<<x of ledbardata, but then or in 1<<bardata (and then don't alter bardata in the loop so ORs same thing every time).
[20:42:05] <Xark> tomatto: I think your code is very broken (and the fact you are accusing uint32_t tends to confirm that). :)
[20:42:55] <tomatto> why 1<<x doesn't work so nicely as your code?
[20:43:14] <Xark> tomatto: It is not about 1<<x...it is about your code not making sense. :)
[20:44:02] <tomatto> i tried add 1<<x to your code, but it is not doing same thing as without 1<<x
[20:44:15] <Xark> tomatto: Here is a version that doesn't alter input if you prefer ->
http://pastebin.com/8Dkj9HmZ
[20:44:45] <Xark> tomatto: Hmm, that isn't what you want...
[20:45:36] <Xark> Perhaps
http://pastebin.com/cAfuVmnx
[20:46:39] <tomatto> this (1<<x) in if(ledbardata & (1<<x)) cause the problem, but i don't see why
[20:47:07] <Xark> Ahh, I know why.
[20:47:42] <Xark> In AVR "int" is 16-bits and literals default to int. So that expression 1<<x fails when x >= 16. You need : (1L<<x)
[20:47:55] <Xark> THAT is why your code worked with 16-bit. :)
[20:48:21] <tomatto> oh :(
[20:48:21] <Xark> Sorry I didn't spot that issue previously (common problem on AVR as nowadays people don't expect 16-bit ints in C).
[20:50:00] <tomatto> so my original code is not too bad or do you still think that no make sense?
[20:50:43] <Xark> tomatto: It made not much sense with bardata and barcp in the loop but not changing. If they are 0, I can see it making sense. :)
[20:51:52] <tomatto> barcp tell that bardata are making sense now and can be read
[21:01:03] <jadew> any idea why the bootloader presented by atmel in AVR109 would fail with verification error?
[21:01:32] <tomatto> Xark: thanks for help
[21:07:05] <Casper> jadew: when you flash with avrdude?
[21:07:14] <jadew> yeah
[21:08:40] <Casper> bad flash (data communication error), hex file too big for the chip
[21:09:37] <jadew> the line looks good (checked it with a scope - also the initial handshake works fine), the hex is small
[21:09:52] <jadew> found something regarding the base address of the bootloader
[21:11:37] <Casper> also, be sure that the chip is erased before
[21:12:04] <jadew> yeah, it looks like it's erased, all the values read back FF
[21:12:52] <jadew> ok, that's weird
[21:13:09] <jadew> apparently I didn't set the base address correctly in the makefile of the bootloader
[21:13:17] <jadew> however that doesn't explain how it worked with out that
[21:13:22] <jadew> (partially worked)
[21:27:14] <jadew> do I have to specify some additional options to avrdude while using the bootloader?
[21:27:22] <jadew> now the program even verifies, but it never gets control
[21:37:00] <jadew> well, it appears the bootloader is faulty
[21:37:15] <jadew> it adds all kind of garbage
[21:37:28] <jadew> either that, or avrdude fails with the addresses
[21:37:34] <jadew> seems to be skipping stuff
[21:42:52] <Casper> could be a miscompiled code too
[21:43:18] <RifRaf> got a nano arduino doing some stuff today
http://www.youtube.com/watch?v=wf4-AMQWl6g
[21:43:52] <jadew> Casper, it seems the bootloader advances the address when it shouldn't
[21:44:10] <Casper> RifRaf: bad demo
[21:44:14] <Casper> make it play music!
[21:44:20] <jadew> basically every 128 bytes, it skipps 128 bytes
[21:44:38] <jadew> so I get real code, 128 bytes of pause, 128 bytes of code, 128 bytes of pause
[21:44:52] <jadew> if I read the flash trough the bootloader, it reports like everything is ok
[21:45:03] <jadew> so it has to be some internal counter that screwes up
[21:45:18] <RifRaf> Casper am just relearning everything again
[21:45:28] <Casper> :D
[21:45:57] <RifRaf> hooking the stuff up is not too hard, the coding is
[21:46:20] <Casper> yeah
[21:46:41] <Casper> but with enought monkey and enought time, you would end up with a working code
[21:48:00] <RifRaf> i am the only monkey
[21:54:22] <jadew> alright, got it working
[21:54:48] <jadew> I was right, avrdude's fault
[21:55:23] <jadew> the bootloader (AVR109) expects the address to be passed as words, avrdude passes it as bytes
[21:55:46] <jadew> commenting out (*address) <<= 1; // Convert address to bytes temporarily. and (*address) >>= 1; // Convert address back to Flash words again.
[21:55:47] <jadew> fixed it
[22:05:16] <Tom_itx> where did you change that?
[22:05:39] <jadew> in the bootloader provided with AVR109 app note
[22:05:54] <Tom_itx> oh
[22:18:20] <jadew> the code is signed by raapeland :P
[23:30:21] <rue_bed> 0xdeadbeef ?