Back
[01:02:45] <inflex> hi Tom_L
[01:10:52] <dgriffi> back after a couple hours. my avr has retained its memory. I guess using 0x00 is verboten.
[02:12:40] <dgriffi> how do I tell gcc that I want to generate an .eep file?
[02:18:26] <Casper> afaik, gcc only produce .bin
[02:18:44] <Casper> you need other tools to create all the other files
[02:19:41] <dgriffi> I just want to somehow get the eeprom programmed
[02:23:09] <Casper> should also be a .hex I think, no?
[02:26:06] <dgriffi> I can't make anything containing eeprom data appear
[02:37:35] <Casper> do you actually tell avrdude to flash the eeprom?
[02:37:59] <dgriffi> brainfart.
[02:38:04] <dgriffi> figured it out
[02:38:17] <dgriffi> my makefile wasn't actually doing that
[02:41:37] * Casper slaps dgriffi with flyback
[02:41:47] * dgriffi whimpers
[02:42:54] <Casper> stop! or I'll lock you in the same room with him! mouahaHAHAHAHAHAHHAHA
[02:46:02] <_ami_> dgriffi: you need to do: avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O ihex blink.elf blink_eeprom.hex
[02:46:33] <dgriffi> _ami_: yeah. I wound up doing that. I'll push something to github in a few minutes.
[02:46:41] <_ami_> that blink_eeprom.hex is the eep file which u need to write to eeprom section via avrdude (-U eepro...)
[02:47:30] <dgriffi> okay, it's pushed (see
https://github.com/DavidGriffith/bluebox-avr)
[02:48:31] <_ami_> dgriffi: what does this command do? -set-section-flags=.eeprom="alloc,load"
[02:48:31] <dgriffi> can I count on a non-initialized eeprom address being 0xFF?
[02:49:07] <dgriffi> I don't know. I just copied it from
http://electronics.stackexchange.com/questions/66145/avr-how-to-program-an-avr-chip-in-linux
[02:49:59] <_ami_> dgriffi:
http://www.atmel.com/webdoc/AVRLibcReferenceManual/group__demo__project_1demo_ihex.html
[02:51:24] <dgriffi> hmm... well, it looks like that stuff was necessary.
[03:01:55] <_ami_> dgriffi: i tested with/without --set-section-flags=.eeprom="alloc,load"
[03:02:21] <_ami_> does not make any difference. may be my testcase does not cover all scenario
[03:08:06] <_ami_> dgriffi: we do need separately write data to eeprom and flash in case of code like below:
[03:08:06] <_ami_> uint8_t EEMEM SomeVariable = 0x01;
[03:08:06] <_ami_> uint8_t EEMEM SomeVariable2 = 0x02;
[03:08:06] <_ami_> unsigned char EEMEM googleme[] = "Hello Ami";
[03:08:30] <_ami_> this will generate two hex files, one for flash and other for eeprom.
[03:11:44] <_ami_> if you forget to write eeprom data to avr, your AVR’s EEPROM won’t have the correct initial values!
[03:14:01] <_ami_> you should check this to ensure that nothing wrong happens if initial values are not loaded correctly. may be you can add some magic value at the first byte to ensure that eeprom data is written?
[03:15:03] <_ami_> uint8_t EEMEM my_magic_eeprom_data = 0x41; - and always check this value before doing some eeprom related stuffs?
[03:27:23] <rue_bed2> /usr/local/bin/avrdude -c stk500v2 -p m8 -P /dev/ttyACM0 -e -B8 -U flash:w:main.hex -U eeprom:w:main_eeprom.hex
[03:27:40] <rue_bed2> #include <avr/eeprom.h>
[03:27:59] <rue_bed2> temp = eeprom_read_byte((uint8_t*)0x00);
[03:28:00] <rue_bed2> PORTA = temp;
[03:28:00] <rue_bed2> eeprom_write_byte ((uint8_t *)0x00, temp+1);
[03:28:00] <rue_bed2>
[03:28:00] <rue_bed2> while(1);
[03:39:50] <dunz0r> Speaking of EEPROMs... is there some "standard" way to check that you aren't writing the same data to the EEPROM several times?
[03:40:10] <dunz0r> To save on writes it would be unnecessary to write unless something has changed.
[03:50:52] <rue_bed2> I think eeprom.h might check
[03:52:14] <dunz0r> Yeah, I checked now. It has update-function. Didn't know that :)
[03:54:56] <dgriffi> ya. eeprom_update_byte() and friends
[08:00:39] <skz81> Sorry I'm a bit scrolled back and did'nt read evrything following this : <anonnumberanon> error: impossible constraint in ‘asm’
[08:02:09] <skz81> maybe the solution has been found in-between, but isn't the problem here that bitmasks[1] is NOT an immediate value ?
[08:03:31] <skz81> in other words : How is supposed the compile to store "adress of symbol 'bitmasks' plus ONE row" in a single word opcode ?
[08:04:28] <twnqx> because the address is still known at compile time
[08:23:39] <skz81> twnqx >> unsure this works though. Futhermore, sound like he was compiling -O0, because I don't know many other case where " PORTC &= bitmasks[1]; [...] works but takes way too many [instructions]"
[08:23:43] <skz81> <anonnumberanon> I'm basically trying to do better than this because this takes a really long time to execute (25 instruction cycles) :
[08:24:33] <skz81> ho cycles, not instructions, made a confusion, but I stand my position
[08:25:37] <skz81> Sound like unoptimized / redundant register saves and so on.
[08:25:57] <Thrashbarg> makes me wonder if PORTC &= *(bitmasks+1); or some hackery would change anything...
[08:26:43] <Thrashbarg> though it should compile down to the same code.. *should*
[08:29:53] <Thrashbarg> reminds me of some ugly stuff I've coded. Something like (unsigned char)*(&i+1) = 0; to clear the upper byte of an integer
[08:31:17] <twnqx> 25 cycles, hm
[08:31:42] <twnqx> it would always be read bitmask to reg; read port to reg; and; write reg to port
[08:32:10] <twnqx> shortcut set/clear bit instructions can only work on consts
[08:35:36] <skz81> <Thrashbarg> makes me wonder if PORTC &= *(bitmasks+1); or some hackery would change anything... >> nope, *(bitmasks+1) and bitmasks[1] are strictly equivalent
[08:36:00] <twnqx> still
[08:36:10] <twnqx> the compiler knows sizeof(bitmasks[0])
[08:36:23] <twnqx> so he knows the address of bitmask[1]
[08:38:11] <skz81> address, yes, value, nope. Even if you declare bitmasks as static const, unsure the compiler will substitute it
[08:38:32] <skz81> you need the value of bitmasks[1] as an immediate value to do the CBI.
[08:38:41] <skz81> not its address
[08:39:38] <twnqx> that's what i wrote, yes
[08:42:51] <skz81> okay, what's your point then ?
[08:43:27] <twnqx> i misread your point
[08:44:01] <twnqx> i thought you meant "can't compute the address if bitmask[1] at compile time"
[08:44:22] <bss36504> Oh god are we still on this?
[08:44:35] <Thrashbarg> lol
[08:44:39] <bss36504> I left 14 hours ago and we were discussing it
[08:44:56] <twnqx> i didn't get to see that discussion :(
[08:45:02] <Thrashbarg> only been discussing it for 45 minutes just now
[08:45:14] <twnqx> grml
[08:45:21] <twnqx> i changed my linux user's groups
[08:45:34] <twnqx> i don't want to log out to get the permissions in a shell
[08:45:36] <twnqx> what to do...
[08:45:41] <bss36504> Thrashbarg is this anonnumberanon's soft PWM nonsense?
[08:45:55] <Thrashbarg> probably
[08:46:05] <bss36504> ffs, its so bad haha
[08:46:08] <Thrashbarg> heh
[08:46:13] <Thrashbarg> twnqx: su username
[08:46:23] <twnqx> i just used sudo -i; login :P
[08:46:28] <Thrashbarg> ok
[08:46:47] <twnqx> but yours works too, and is shorter.
[08:46:51] * twnqx makes a mental note
[08:46:57] <Thrashbarg> yay
[08:47:33] <twnqx> yey
[08:47:47] <twnqx> adb suddenly has the needed permissions to mess with my phone :)
[08:48:03] <Thrashbarg> ah
[08:51:26] <skz81> <bss36504> I left 14 hours ago and we were discussing it >> my bad i'm a off-timed bird, i'm discovering the topic
[08:51:59] <bss36504> haha it's ok
[08:52:07] <bss36504> I was just shocked that it was still going
[08:52:43] <twnqx> it just started again :P
[09:04:43] <carabia> bss36504: I think it was just sk8rboi
[09:04:52] <carabia> or whatever the name is
[09:05:30] <bss36504> carabia: I watched that nixie tube vid. That's amazing
[09:06:57] <skz81> <carabia> bss36504: I think it was just sk8rboi >> I admit. I deserve spanking
[09:14:16] <carabia> yeah. i'm eagerly waiting for some sort of a follow up for it that associates arduinos to it
[09:47:47] <rue_house> WiNdStOrM hAd Me UP AlL NiGhT....
[09:48:17] <rue_house> ItS GoNna Be a ROUgh DaY aT WORk!
[09:48:32] <carabia> do you mean w0rk?
[09:49:37] <rue_house> i JUst HaVE to STay aWAkE
[09:49:45] <carabia> get some c0ff33
[09:50:02] <rue_house> T
[13:48:21] <anonnumberanon> skz81, yes I did not specify an optimization flag. I should try -O2?
[13:48:51] <anonnumberanon> skz81, I meant 25 instructions, x amount of cycles to be determined.
[13:49:09] <carabia> ^ bss36504: alert
[13:49:26] <bss36504> *triggered*
[13:51:32] <anonnumberanon> rue_house, don't tell me you and carbi4 are friends...
[13:51:58] <anonnumberanon> This miscreant! Moule-a-gauffres!
[13:53:06] <carabia> speaking french or proper punctuation doesn't really give you any less of a dumb look
[13:54:06] <anonnumberanon> no carabia you cannot bully me
[13:58:01] <theBear> and noone touches theBear, but he does notice yer kinda being a total dick all the time
[13:59:11] <carabia> theBear: no no, just you and him
[13:59:30] <carabia> and there was a smiley for this... >:)
[13:59:45] <anonnumberanon> theBear, can you claw carabia to death pls(with love)
[14:00:05] <anonnumberanon> lovingly clawed to death, Romeo and Juliet proper
[14:03:04] <carabia> last i heard he was on the prowl for surrogate victims for me
[14:03:25] <carabia> i really appreciate gestures such as those
[14:03:59] * theBear only believes in literal non-fictional violencing, and that raised voices are ya know, waste of breath that could be kicking ass in lots of way
[14:04:00] <theBear> s
[14:06:15] <carabia> is this common among the rednecks?
[14:10:10] <theBear> i'm a neo-luddite, i ain't been capable of rednekkin' even close to the mean or mode this side of the country fer well over a decade now
[14:13:22] <carabia> aren't computers, mcus and so on fighting against your luddite ideology?
[14:13:30] <carabia> or where is it that you draw the line?
[15:54:33] <Lambda_Aurigae> carabia, I'm the redneck here! Raised in backwoods North Carolina. "He needed killin'!" was a valid murder defense round them parts...
[16:45:34] <carabia> Lambda_Aurigae: well theBear follows suit!
[19:10:05] <aandrew> theBear is a high-tech redneck
[19:50:06] <Casper> high-tech? that I ain't sure
[19:52:13] <Lambda_Aurigae> will give you the "high" part.