Back
[06:46:54] <buserror> hmm can I program the flahs AND eeprom from a single .hex file with avrdude ? it complains about invalid address if I use just flash:w:h.hex, the hex file has both sections, the eeprom being at address 810000
[07:02:10] <Tom_itx> i think they need to be separate
[08:03:50] <braincracker> buserror <= you program them using 2 files.
[08:04:04] <braincracker> since they are different things
[08:07:58] <buserror> bit lame :/
[08:08:11] <braincracker> i see
[08:08:19] <braincracker> learn how things work then
[08:09:07] <buserror> heh
[08:09:23] <braincracker> there is also a bootloader
[08:09:37] <braincracker> and fuses
[08:09:44] <braincracker> all different things
[08:10:03] <buserror> I have no problem loading a composite .hex in simavr. the "address" offset is pretty clear to parse
[08:12:21] <braincracker> hm...
[08:12:34] <braincracker> well one could create a container for the files
[08:12:58] <buserror> gcc flattens the various avr address spaces into a big one. flash is at 0, eeprom at 810000...
[08:13:01] <braincracker> but then all tools you want to use must know the format
[08:15:53] <buserror> well it's a bit silly to have to split files when theres one container that works. objdump has no problem creatign the hex, and the hex format itself allows disjoint spaces too (thus the start offset)
[08:16:11] <buserror> anyway, I removed the .eeprom section in my thing
[08:17:24] <braincracker> where?
[08:17:27] <braincracker> i never seen one.
[08:19:52] <buserror> there, parser for disjoint hex:
https://github.com/buserror-uk/simavr/blob/master/simavr/sim/sim_hex.c
[09:11:27] <Atlantic777> Hi there! Can anyone tell me few words about atmega 8? A friend of mine built some dev board but I have to buy him a chip, he said me that he needs atmega 8 in DIP 28 package. It would be nice to have at least serial communication, few ADCs, SPI and maybe USB support. It would be great to have some libs for glcd, motor drivers and such libs...
[09:11:32] <Atlantic777> Can you suggest me anything?
[09:11:53] <Atlantic777> I have just few minutes... it's urgent. :/
[09:12:39] <specing> you'll have to go XMEGA for USB and multiple ADCs
[09:13:07] <specing> actually not USB, but surely for multiple ADCs
[09:13:27] <specing> if he wants an atmega8 then buy an atmega8, doh
[09:14:33] <antto> if main() is doing an empty loop: while (work == 1) {} .. will an interrupt "interrupt" it?
[09:16:15] <specing> antto: interrupts never interrupt anything, you should have known that by now
[09:16:39] <Atlantic777> specing: so I can't buy wrong atmega8? :D
[09:17:14] <antto> specing what do they do then?
[09:17:52] <Atlantic777> This is the first time I'm doing something with avr chip, and I didn't have time to do some reading. Sorry fur dumb question.
[09:17:56] <specing> Atlantic777: if you buy it from China, sure
[09:18:31] <Atlantic777> no, I'm going few blocks away but I'm not sure if guys at the store will know what I'm asking for :)
[09:19:05] <specing> erm...
[09:19:11] <specing> Do YOU know what you are asking for?
[09:20:12] <Atlantic777> I am told to ask for "atmega 8 DIP 28" but I'm not sure if I can go wrong, if there are some versions of it.
[09:20:25] <Atlantic777> And no, I don't know actually what I should buy.
[09:21:08] <Atlantic777> Sorry, have to go. Wish me luck, I'm about to abandon microchip. :)
[09:21:18] <specing> download the datasheet and see what versions are availalbe?
[09:26:46] <Casper> Atlantic777: you do not want the atmega8L (low voltage), but the atmega8-PU and -PN (P=plastic DIP, U=-40-85C, N = -40-105C)
[09:27:20] <Casper> the 8L is a 8MHz version, while the standard is 16MHz
[09:27:39] <Casper> the 2 good ones, the difference is the upper temperature limit
[09:28:07] <Casper> but I think you can also get the 48/88/168/328
[09:28:22] <Casper> I think, but not sure, that they are pin compatible
[09:37:17] <cart_man> RikusW: Hi Riuks
[09:37:21] <cart_man> ups Rikus`
[09:47:06] <RikusW> hi cart_man
[09:56:09] <antto> hm.. i see the stk500v2 uses boot_page_fill() to write one word at a time, and when it finishes, calls boot_page_write()
[09:56:21] <antto> this is weird
[09:57:34] <antto> where does boot_page_fill() write to?!
[10:12:38] <RikusW> it doesn't write
[10:13:02] <RikusW> the data goes into some buffer on the AVR and page_write writes it
[10:15:53] <antto> ooh, that's so great
[10:15:59] <antto> ;]
[10:16:16] <antto> i thought i would have to make my own buffer
[10:20:05] <antto> well, is boot_page_erase() required then?
[10:20:44] <antto> or does that erase this same buffer, and not the actual page in flash?
[10:21:06] <Casper> afaik, you have to erase the page first
[10:21:24] <antto> but both those functions want the address as an argument
[22:40:04] <braincracker> c <Casper> but I think you can also get the 48/88/168/328 < they are exactly the same with different size memory, and different device id
[22:52:37] <vectory> huh, the xmega a1 has two pairs of registers for results?
[22:52:38] <vectory> #define ADCA_CH3RES _SFR_MEM16(0x0216)
[22:52:50] <vectory> and also #define ADCA_CH3_RES _SFR_MEM16(0x023C)
[22:53:04] <vectory> are they redundant?
[23:01:25] <braincracker> well it has 2 adcs.
[23:02:54] <braincracker> so 1 differential reading at a time, or 2 single ended
[23:03:40] <vectory> it can only sample one reading per channel at a time
[23:04:38] <vectory> each adc has 4 channels, but still, each channel has two pairs of res regs
[23:04:52] * braincracker points to datasheet
[23:05:09] <vectory> nope, not helpfull :<
[23:05:10] <braincracker> it has double input mux, and 2 adcs
[23:05:54] <braincracker> well at least the devices i visited
[23:05:55] <braincracker> .
[23:06:57] <braincracker> there are many xmegas haven't read all datasheets
[23:08:31] <vectory> ah well, maybe i should read the ds more carefully
[23:09:15] <vectory> which of the two pairs do i want, when not double input muxing?
[23:21:54] <vectory> theres so many appnotes concerned with adc :X
[23:30:38] <vectory> 16 bit register access in gcc isnt atomic by default, i guess
[23:31:08] <vectory> damn, writing exam and starting to learn 5 hours before sucks every time
[23:31:37] <Casper> nope, it is not
[23:31:46] <Casper> which is sad
[23:32:10] <theBear> well it's not atomic in avr by nature, gcc can't really change that
[23:33:06] <vectory> well it can with atomic.h :)
[23:33:39] <vectory> ive decided that the second result register pair is redundant
[23:33:41] <theBear> but, it can't change the nature of the avr itself, even in asm they aren't atomic
[23:35:17] <vectory> the read is, luckily
[23:35:46] <Casper> well, there is some registers that is.... well, atleast 1... or so it seemed to be in the datasheet
[23:36:40] <vectory> in xmega it apears to be the case for any 16 bit register. but the ds is, well ... you know
[23:37:39] <vectory> whatever constitutes a 16 bit register. like, perhaps any succession of two possibly unrelated 8 bits
[23:41:05] <braincracker> vectory <= on a 8 bit architecture, 16 bit access is 2 operations.
[23:41:27] <braincracker> but for example reading 16 bit timer value will be atomic on an atmega
[23:41:49] <braincracker> if the 2 reads come one-after one
[23:41:58] <braincracker> ( no interrupt in between)