Back
[02:58:28] <LeoNerd> Someone remind me... What is the required fuse setting to make a bootloader actually work?
[02:58:32] <LeoNerd> I thought it was BOOTRST=0
[02:58:38] <LeoNerd> but that doesn't appear to be having an effect
[03:06:13] <LeoNerd> Ohright, but I have to get the boot size correct too?
[03:07:35] <ThatDamnRanga> indeed
[03:12:46] <LeoNerd> OK, I have BOOTRST=0 and BOOTSZ correct, and still it doesn't. It jumps directly into my application immediately
[03:32:56] <LeoNerd> Ah, RikusWork hi. :) I wonder if you'll think of anything... Trying to make a bootloader work on a 328PB. I've set BOOTRST=0 and BOOTSZ to the size of the loader. I've burned the loader. But still the chip boots directly into my application, skipping the loader entirely
[03:33:16] <RikusWork> Hi LeoNerd
[03:34:29] <RikusWork> fill the entire boot area with hlt ?
[03:34:57] <RikusWork> then see if it still happens
[03:35:41] <LeoNerd> Um.. notsure how to do that
[03:38:23] <RikusWork> get the opcode for hlt and fill a hexfile with it..
[03:38:44] <RikusWork> use asm. .db
[03:45:27] <LeoNerd> Ooooh oopsie
[03:45:49] <LeoNerd> I bet I did something silly like not doing fullchip erase first. If I do the make install type step with optiboot's makefile, it works
[05:51:08] <theBear> from memory the bootrst bit just changes the behaviour/which code to start at pending things like cold "boot" vs reset or long-reset or something like that, but you should be able to get the bootloader to run one way or another with it either value
[05:55:09] <LeoNerd> Yah. I'm not quite sure what I was doing wrong.
[05:55:28] <LeoNerd> "make atmega328pb_isp" in optiboot installed it fine. I think possibly the fact it does a fullchip erase first might be related
[06:07:24] <theBear> mmm, on ??prom style flash devices not erasing does all kinds of odd things cos of the way the cells will only program "more" or stay as they are, and obviously that ain't gonna cover all possible programs
[06:46:20] <megal0maniac> RikusWork: Hey!
[06:46:31] <RikusWork> hi megal0maniac
[06:47:03] <RikusWork> I met scuzzy the other day on Table Mountain
[07:35:12] <Qwertie> Hi
[07:42:36] <carabia> hi
[07:51:21] <Qwertie> Im looking to get into micro controller programming. I have an ATmega328P with an ardunio board right now. From what I have seen I need a programming tool to write stuff to the chip and I can use the AVR GNU tools with the programmer tool?
[07:51:44] <NicoHood> has anyone subscribed to the avr-libc mailing list? i've reported a bug there, but i am not sure if my mail arrived
[07:57:53] <carabia> Qwertie: ??
[07:58:02] <carabia> are you a communist?
[07:58:07] <Qwertie> ?
[07:58:39] <carabia> if not, use atmel studio, which compiles with avr-gcc
[07:58:55] <carabia> it's like quasi-communist but better than nothing
[07:59:36] <Qwertie> How would I use that on linux?
[08:00:28] <carabia> oh, another commie. Well, you use avr-gcc to compile, avrdude to upload
[08:00:31] <LeoNerd> I usually do AVR stuff with plain avr-gcc + makefile + avrdude to upload
[08:00:37] <LeoNerd> Works fine for me
[08:01:25] <NicoHood> I use dmbs as makefile environment
[08:03:45] <Qwertie> I can use this to program it?
http://www.ebay.com/itm/AVR-JTAG-USB-Download-emulator-Debugger-AVR-JTAG-ICE-Programmer-Atmega-/331668037700?hash=item4d38f4a044:g:53gAAOSwFnFWCl4E
[08:04:11] <carabia> usbasp 8)
[08:04:26] <carabia> communism intensifies, or something
[08:04:39] <Qwertie> So just this then?
http://www.ebay.com/itm/USBasp-USBISP-3-3V-5V-AVR-Programmer-USB-ATMEGA8-ATMEGA128-New-/130682846209?hash=item1e6d4dfc01:g:Y00AAMXQTT9RyEjT
[08:04:42] <LeoNerd> The usbasp kinda works but it's really chepa and nasty...
[08:04:44] <LeoNerd> *cheap
[08:04:52] <LeoNerd> I'd suggest get yourself a Pololu v2. They're nice
[08:04:58] <LeoNerd> I have the v1, which is almostbutnotquite as nice
[08:05:05] <carabia> you *could* get the usbasp, and when it ships you can come back here crying why avrdude fails with some mysterious error code
[08:06:01] <LeoNerd> The main problem with the usbasp is that it talks fake USB, via vusb on a not-really-USB-capable AVR chip
[08:06:19] <LeoNerd> Sometimes it works, sometimes it doesn't. Mine seems stable on my laptop but point-blank refuses to work via a USB hug
[08:06:22] <LeoNerd> hub
[08:06:23] <Qwertie> the pololu seems nice, still pretty cheap
[08:06:33] <LeoNerd> Whereas the real USB chip in the pololu is just fine everywhere
[08:06:35] <carabia> Qwertie: didn't you say you had an arduino board?
[08:06:39] <Qwertie> Yeah
[08:06:49] <carabia> the chip didn't come with a bootloader flashed?
[08:06:54] <Qwertie> Its a board pretty much the same as the uno
[08:07:17] <Qwertie> carabia: It does but I was told if I mess something up and write over the bootloader then I need to reflash i
[08:07:18] <Qwertie> t
[08:07:29] <carabia> well yeah
[08:07:53] <carabia> but i mean you can get started right away
[08:08:16] <Qwertie> So as long as I dont write over the bootloader I can still use the rest of the tools like avrdude?
[08:10:46] <carabia> yes
[08:12:22] <carabia> now shoo and go make some blinky leds and stare in awe
[08:25:06] <carabia> i always thought arduinos used some ftdi chip but at least this uno one seems to have atmega there
[08:25:58] <rue_house> the chineese ones use a variety of chips
[08:26:16] <rue_house> which isn't a problem under linux, but trying to keep up with drivers for windows...
[08:26:46] <_ami_> rue_house: my uno clone has ch340g as usb talking chip
[08:26:50] <carabia> commies... pffff
[08:27:28] <rue_house> that seems to be the more popular one latley, I think due to its size
[08:57:57] <twnqx> pl2303 are also common i think
[09:10:02] <LeoNerd> There's a variety of common non-FTDI USB-UART bridges
[09:10:12] <LeoNerd> I've really gone off the PL2303s lately because they don't do BREAK conditions
[09:10:23] <LeoNerd> Real FTDIs support them just fine.
[09:10:30] <LeoNerd> I forget what other chips do and don't.
[13:16:42] <anonnumberanon> Hi can you explain me what I'm doing wrong in this test case?
https://ideone.com/bpBhPH
[13:17:34] <bss36504> Looks pretty clear to me, youre trying to include io/avr.h but that file cant be found by the compile
[13:17:36] <bss36504> r
[13:17:53] <bss36504> So either you dont have that file at all, or it's not in your compiler's search path
[13:18:22] <bss36504> Obviously ideone doesn't have it, so of course that compilation will fail
[13:18:40] <anonnumberanon> No read the code. Why my second call to the macro does not work?
[13:18:52] <bss36504> Ohh
[13:18:54] <bss36504> hold on
[13:19:22] <anonnumberanon> I'm not sure what "type" the stuff you put into the macro needs to be.
[13:20:32] <bss36504> What error do you get when you try to compile that?
[13:20:41] <bss36504> you say "it doesnt work", but how?
[13:22:02] <anonnumberanon> error: impossible constraint in ‘asm’
[13:23:22] <bss36504> I think you want just a single colon, not a double colon
[13:23:47] <anonnumberanon> I'm basically trying to do better than this because this takes a really long time to execute (25 instruction cycles) :
[13:23:48] <bss36504> using the double colon means your "I" (_SFR_IO_ADDR(port)), "I" (pin) section is in the "clobbered registers" field of the asm instruction
[13:23:48] <anonnumberanon> PORTC &= pul_stream[i].bitmask;
[13:24:10] <anonnumberanon> or PORTC &= bitmasks[1];
[13:24:22] <anonnumberanon> ^^ that works but takes way too many instructions.
[13:24:23] <bss36504> Right ,i know what you want to do
[13:24:25] <bss36504> asm(code : output operand list : input operand list [: clobber list]);
[13:24:37] <bss36504> ^ that is from here:
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
[13:25:37] <bss36504> I think the "I" (_SFR_IO_ADDR(port)) part should be in the output operand list, but I might be wrong.
[13:38:23] <anonnumberanon> But thanks for the link. I don't understand how to use SFR IO ADDR I will read the doc and understand it. Even though I believe this will not be my solution (there is no solution). But I'd like to understand at least how it works.
[13:46:16] <bss36504> No what youre doing seems entirely plausible I think.
[13:51:04] <anonnumberanon> I have 16 pins and they get sorted in a different sequence every time so I have to access an array of them(or their address) to be able to know which one to turn off.
[13:51:21] <anonnumberanon> I think there is no way around putting the bitmasks in an array.
[13:52:09] <bss36504> Why not just make your sort work on bits in an int instead of an array?
[13:52:59] <anonnumberanon> Uhm can you go into more details? Not sure I follow you.
[13:53:54] <bss36504> Well I guess I understand it that you read some values in as bits, put them into an array, then sort the array? So why not just store those values in a 16 bit integer and use bitwise operations to sort
[13:54:11] <bss36504> I dont fully understand what youre even trying to do though
[13:59:06] <anonnumberanon> So I sort an array of pins according to the times they should be turned off. Like I use a struct that has a bitmask for the pin and it has a time at which to turn off that pin (making PWMs).The times thus are used to sort, and the pins themselves can fire/turn off according to their position in the array of structs.
[13:59:57] <anonnumberanon> Since I delay before this happens and I know it takes 25 instructions to access the bitmask to use at that piont, I can remove 25 instructions time from each delay before turning off the pin.
[14:00:20] <anonnumberanon> I'll look for a table that tells me how many instruction cycles each instruction lasts.
[14:00:50] <bss36504> What if you just maintained the output state in an int and wrote to the whole PORT register every time you need to update, whether it's one pin or all the pins.
[14:00:54] <bss36504> That takes one instruction
[14:01:06] <bss36504> And you dont need any cbi sbi nonsense
[14:01:13] <anonnumberanon> Probably here
http://www.atmel.com/Images/Atmel-0856-AVR-Instruction-Set-Manual.pdf
[14:02:02] <bss36504> I guess I dont understand the need for an array. You're trying to do a soft-PWM implementation, ok.
[14:02:14] <bss36504> So you must have some sort of a tick timer
[14:02:23] <theBear> sounds like a fine abuse of interrupts and a good bunch of the never-do-this-in-an-int-handler list is ticked off... just do the old and/or style shuffle in c-land and it should compile down to just an extra lie or o
[14:02:40] <anonnumberanon> Yes I want to do that and I have seen in my asm output .s file that that method takes just one cycle, which is great, but that doesn't give me the capability of knowing exactly which bitmask to use against the port.
[14:02:40] <bss36504> that tick timer is presumably in hardware, presumably triggering an ISR
[14:02:53] <theBear> oh wait, soft pwm ? hmmm, maybe i retract half of that interrupt comment, depending if you doing anything else much
[14:03:28] <anonnumberanon> bss36504, for the tick timer I use NOPs.
[14:03:41] <theBear> for multi channel pwm/servo-chopping stuff i like the counter counting and spending yer "main" loop spare time just comparing channel/output set-values to the timer at that moment
[14:03:42] <anonnumberanon> 16 nops for one microsecond
[14:04:07] <bss36504> But you wouldnt be setting the PORT using a bitmask, youd be setting a placeholder uint8 in the "dead time", using conventional bit shifts and then writing that whole value to the PORT every time
[14:04:23] <bss36504> insert comma after "shifts"
[14:04:36] <anonnumberanon> so if i need to delay by 1 microsecond, i call a functin that does NOP 16 times, also since there is overhead to calling that function, it may be less than 16 NOPs. It may be even something like 5 or 10 NOPs.
[14:04:44] <bss36504> Dont do that
[14:04:45] <bss36504> lol
[14:04:48] <bss36504> just use a timer
[14:04:48] <anonnumberanon> lol
[14:04:52] <bss36504> and an ISR
[14:05:15] <bss36504> the ISR call will have a repeatable amount of instructions, you can tailor your performance from that
[14:05:17] <anonnumberanon> timer is out of the question because I already use it and then turn it off while this here stuff I'm talking about is executing.
[14:05:23] <anonnumberanon> It's a huge hack my friend.
[14:05:36] <bss36504> Well why cant you use the timer then?
[14:05:40] <bss36504> I guess I dont understand
[14:05:47] <bss36504> just leave it running, have a global tick
[14:06:00] <bss36504> the global tick can indicate to your main loop that you need to service the PWMs
[14:06:38] <bss36504> honestly though, if youre trying to make cycle accurate PWMs on 16 pins with an AVR, IN SOFTWARE, then you should just be using an external PWM chip to do the actual toggling for you
[14:07:28] <anonnumberanon> But that would be too easy :)
[14:07:33] <bss36504> Oh ffs.
[14:07:40] <anonnumberanon> I am trying to become a master of time.
[14:07:59] <bss36504> You should preface that you're doing it to do it then
[14:08:06] <anonnumberanon> Lol.
[14:08:32] <bss36504> I end up in the rabbit hole that is these questions all the time because people put unnecessary restrictions on themselves.
[14:09:17] <bss36504> Also, I just noticed youre using nops for a tick timer. what the actual hell dude
[14:09:35] <bss36504> and then youre concerned about cycle accuracy in setting the ports!?
[14:09:36] <anonnumberanon> But think of the beauty of the result if this actually works (assuming I use the advanced timing hack). That means one puny avr running 16 PWMs. Absolutely no other hardware required. And every time I do an entire PWM, I am left with a very lengthy 18 milliseconds to do other things!
[14:09:42] <bss36504> Youre making me crazy, anonnumberanon
[14:10:15] <bss36504> Yeah, you know what "other hardware" you could use? the fucking on-board timer module!
[14:10:24] * bss36504 rages :P
[14:10:30] <anonnumberanon> huehue
[14:11:00] <anonnumberanon> At least I learned how to use any timers and any ISR combinations through this project :)
[14:11:15] <anonnumberanon> I do have tried using just timers.
[14:11:47] <bss36504> well thats good.
[14:12:06] <bss36504> I mean, if youre gonna shoot out your kneecaps, you cant expect to run full speed.
[14:12:36] <anonnumberanon> I don't remember the details but I think I was getting a bit of jitter. With this method here, you would look on the oscilloscope at the wave and see absolutely no jitter. Or maybe just a few hundred nanoseconds of jitter :O.
[14:14:20] <anonnumberanon> But anyway if this works after some hand-tuning, it will be beautiful and I'm very excited.
[14:15:27] <bss36504> I wish you luck on your journey to be a timelord
[14:16:42] <anonnumberanon> Now that I've brought it up though...
[14:17:29] <anonnumberanon> My NOP idea to delay may be hard to achieve for less than one microseconds.
[14:17:58] <anonnumberanon> because of while(i), i++;
[14:18:17] * anonnumberanon goes insane already
[14:31:53] <anonnumberanon> It would be nice to have a program that takes for input a file containing "ldi r24,lo8; ldi r25,0" and outputting the number of cycles all the instructions take.
[14:33:21] <anonnumberanon> All it would need is a list of instructions and their times. Then parse the input (easy). I wonder if there is such a database, other than just looking at the instruction set documentation.
[14:39:25] <bss36504> You could make an excel spreadsheet. Just copy the column of instructions from the datasheet, the number of clocks column, make a simple lookup in excel
[14:39:26] <cehteh> code such a tool
[14:50:46] <carabia> what the fuck?
[14:51:09] <carabia> anonnumberanon: are you a complete tool?
[14:51:59] <carabia> not a rhetorical question, though given your nickname one might be led to such a conclusion
[14:57:02] <carabia> also bss36504 finally there's a good piece on hackaday. the guy making the nixie tubes. i really enjoyed the clip, recommended!
[14:58:23] <bss36504> carabia, coming in hot!
[14:58:49] <carabia> as you should!
[14:58:51] <bss36504> I'll check it out later. Time to perform a knowledge transfer to college kids.
[14:59:13] <carabia> lobotomy is a better option
[15:02:21] <carabia> and also yeah, the whole clip is over half an hour. He has parts premade, like the cathodes etc. But he does pretty cool stuff like forming the glass tube itself etc. He sells them at $145 a pop. Quite expensive but they're such a niche.
[15:03:03] <anonnumberanon> Ah indeed there is a table at "Instruction Set Summary" in the datasheet.
[15:03:50] <anonnumberanon> carabia, why you want to use me for a project? And also I am not complete I am a prototype tool.
[15:04:22] <carabia> A failed one at that I can tell, judging by your software pwm
[15:05:40] <carabia> there has to be other kinds of people than the extreme ends of duct taping arduinos and the ones doing useless "academic research". Isn't there like a middle ground anymore?
[15:10:16] <anonnumberanon> And another vociferous teenager makes the list.
[15:21:39] <carabia> i kinda giggled at that
[15:21:46] <carabia> tee-hee
[15:22:36] <carabia> then again it's a good thing, not getting any younger anyway i 'spose
[15:37:59] <carabia> i heard kids these days are struggling with issues such as their age
[15:38:07] <carabia> is that so, anonnumberanon?
[15:44:53] <anonnumberanon> carabia, You should ask your grandson that question.
[15:45:54] <carabia> you can't keep moving the goalposts, what's it gonna be?
[15:46:43] <anonnumberanon> no carabia you cannot bully me
[15:48:02] <carabia> i wasn't trying, and aren't i supposed to be on said list already?
[15:48:20] <carabia> or is that the "definite cool guys to have a beer with"-list?
[15:49:11] <anonnumberanon> Oh that? That was just my kill-list.
[15:50:57] <WormFood> Come on, fight nicely children.
[15:53:14] <carabia> hello WormFood how's it in commie china?
[15:53:32] <WormFood> Have any of you guys tried connecting a RA8875 driver, for an LCD display, to an AVR?
[15:53:51] <WormFood> carabia, come join the communist party. It's a blast.
[15:54:30] <carabia> WormFood: no.
[15:54:43] <WormFood> It's better than democracy
[15:55:01] <WormFood> But, don't worry, your democracy will soon vote itself into communism.
[15:55:29] <carabia> WormFood: no, i'm long gone before that
[15:55:38] <carabia> anyway WormFood that looks like a funky driver
[15:57:10] <carabia> you could seemingly do a single buffer rgb565 or a double buffer 8 bit colors. Hmm.
[15:57:30] <WormFood> ugh
[15:57:46] <WormFood> shitty Chinese internet. You guys should be glad your internet isn't made here in China :P
[15:58:15] <carabia> communist quality control!
[15:58:30] <WormFood> I was thinking about trying to search out one of those drivers, for an LCD I have. OR, I could get a dedicated one for my RPi
[15:59:51] <carabia> with a quick glance that chip looks pretty a-okay
[16:00:29] <carabia> if you could do like a full 16 bit bus i/f on the rpi for fast 565
[16:00:42] <carabia> though, i guess not needed as the rpi clocks quite damn high.
[16:00:48] <WormFood> I think it uses spi on that.
[16:00:56] <WormFood> I have the 3 model
[16:01:01] <carabia> the ds seemed to specify 8/16b
[16:01:01] <WormFood> so, yeah, it's pretty nice.
[16:01:22] <carabia> 8080/6800 with 8/16 Data Bus Width (off the ds)
[16:01:26] * anonnumberanon is building a combat robot for that very purpose
[16:01:37] <carabia> and i2c/spi, usually selected with some pins.
[16:04:14] <carabia> though WormFood for an rpi, i don't know if there's any advantages to have a controller with an internal framebuffer
[16:04:28] <WormFood> There is a big advantage to it.
[16:04:36] <WormFood> The timing on these displays is VERY tight.
[16:04:50] <WormFood> Also, that controller does font generation, and primitive graphics support too.
[16:05:01] <carabia> well, surely, but it's still an rpi.
[16:05:30] <WormFood> it would be very tricky to do. No point in reinventing the wheel.
[16:06:03] <carabia> well, not _that_ tricky? but reinventing the wheel, a bit.
[16:06:23] <carabia> then again, talking about reinventing the wheel, you could just use the hdmi which interfaces to the gpu...
[16:06:30] <carabia> and get a display
[16:06:39] <WormFood> That isn't the point.
[16:06:55] <carabia> well, if you're looking for an easy solution, it could be
[16:07:05] <WormFood> ugh
[16:07:09] <carabia> ugh
[16:07:17] <WormFood> I didn't say I was looking for an "easy solution"
[16:07:28] <WormFood> I want to know more
[16:07:49] <WormFood> It's not about putting a display on something...it's about making the display I have useful for *something*
[16:08:47] <carabia> right
[16:22:12] <megal0maniac> Where's beaky at?
[20:16:27] <scoy> anyone want to talk about ISRs and doing a lot of string comparison in them? i've always read that you should do as little as possible inside an ISR.
[20:18:03] <scoy> but i'm trying to detect the end of a variable length string sent via an USART ISR.
[20:37:42] <dgriffi> why would the eeprom in an attiny85 seemingly erase itself?
[20:41:51] <Casper> scoy: you can not have more than 1 interrupt of each type at once
[20:42:02] <Casper> that's why
[20:42:08] <Casper> there is no queue
[20:43:00] <Casper> the way the interrupt work is: it set a flag (really a bit in one of the register), the avr check if any of the interrupt bit is set, if so it execute them in the order of the vector table
[20:43:06] <Casper> which is predefined
[20:43:48] <Casper> so if "interrupt 1" fire too often, the rest may not even get executed, even worse, if there is a second interrupt of the same while still in that interrupt, then you lose it
[20:46:20] <scoy> Casper, hmm ok. I'm OK with other interrupts not firing. But if another character comes down the pipeline, would it cancel the execution of the current USART ISR?
[21:08:36] <Casper> no
[21:08:42] <Casper> it will be ignored
[21:10:34] <scoy> Casper: so i can spend a day in the ISR processing strings and any characters send during that time will be ignored. once i leave the ISR the next available character will be captured, right?
[21:12:24] <Casper> yes
[21:12:39] <scoy> Casper, got it. much appreciated!
[21:13:10] <Casper> some code are actually all run in interrupt
[21:13:26] <Casper> I started to make one, 95% of the code is in interrupt
[21:13:55] <scoy> interesting
[21:14:28] <scoy> i'll have to test this one out and figure out if it's too much and start loosing characters. thanks again!
[21:47:59] <anonnumberanon> For some reason my ISR is not firing..
[21:53:30] <rebecca> anyone here played with any of the tiny operating systems for avr hardware?
[21:57:47] <eszett> hi! I'm trying to dump the flash memory of my atmega32u4 with "dfu-programmer.exe atmega32u4 dump" and it tells me "memore read error, use debug for info"
[21:58:03] <eszett> what could be the problem?
[21:58:22] <Tom_L> you blew it's brains out and it lost it's memory ?
[21:58:51] <Tom_L> can you slow it down?
[21:58:55] <rebecca> i'm working on a portable retro computer and have experience with avr hardware.. would like to run a simple os that takes care of filesystem, task switching and provides a shell with some programming/scripting capability.. but i don't want to write my own OS.
[21:59:00] <Tom_L> i haven't used dfu that much
[21:59:48] <eszett> I dont even know how to enter the debug mode ;-(
[22:00:59] <Tom_L> rebecca google elm chan
[22:02:00] <Tom_shop> http://elm-chan.org/fsw/ff/00index_e.html
[22:04:53] <rebecca> have looked at things like contiki os, nuttx, freeRTOS but none of them seem well suited or well supported on AVR hardware
[22:04:59] <rebecca> Tom_L: ok
[22:05:07] <Tom_L> eszett i'm not sure dfu has a debugger
[22:06:31] <eszett> tom ye it has the option --debug but im not very versed in how to use it to tell me the truth about the error
[22:08:09] <Tom_shop> http://htmlpreview.github.io/?http://github.com/dfu-programmer/dfu-programmer/blob/master/docs/dfu-programmer.html
[22:08:15] <Tom_L> eszett,
[22:08:30] <rebecca> Tom_shop: doesn't appear to have a scripting/programmable interface
[22:08:39] <eszett> ye that is the official doc, but i miss some examples there.
[22:10:30] <Tom_shop> The at90usb series chips do not make available any read/write protect flags so the dump or flash command may fail with a less than helpful error message.
[22:10:48] <Tom_L> eszett i think your chip may fall into that category
[22:10:52] <eszett> ah I see
[22:11:02] <eszett> But its a atmega32u4
[22:11:09] <Tom_L> the U2 is the same as that chip
[22:11:13] <eszett> got it
[22:11:21] <Tom_L> u4 has adc and a few other additives
[22:11:30] <eszett> so i cant dump the flash
[22:11:42] <Tom_L> try flip under windows
[22:11:47] <Tom_L> i've done it
[22:11:47] <eszett> ah flip yes
[22:11:53] <eszett> i know it well
[22:12:09] <eszett> just deinstalled because it needs java, and java is meh. but ok, i reinstall it
[22:13:36] <eszett> Tom: thanks for support i have to leave to bed now
[22:13:47] <Tom_L> yeah it's about that time
[22:13:56] <eszett> right, cu late
[22:14:36] <dgriffi> is there anything special about eeprom location 0x00? I'm using an ATtiny85
[22:15:00] <Tom_L> is that a valid eeprom address?
[22:15:05] <dgriffi> the value I store in there keeps changing without me doing anything
[22:15:10] <Tom_L> that may be the start of code space
[22:15:32] <Tom_L> check the memory map in the pdf
[22:16:32] <dgriffi> according to
http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html, that is the start of eeprom
[22:19:06] <Tom_L> it needs ~4.5ms between writes
[22:19:14] <Tom_L> P.157 PDF
[22:21:33] <dgriffi> this is happening when I'm doing only one write
[22:21:49] <rue_house> of more than 8 bits?
[22:22:06] <dgriffi> nope. just 8 bits using eeprom_update_byte()
[22:22:12] <rue_house> hmm
[22:22:14] <Tom_L> 0x0000 0x0FFF is flash
[22:22:16] <Tom_L> area
[22:22:22] <rue_house> I'v only done eeprom once
[22:22:26] <rue_house> on a mega32
[22:22:43] <dgriffi> okay, I put 10ms around both writes
[22:23:11] <dgriffi> now disconnecting power. let's see how long this lasts
[22:23:35] <dgriffi> plugged back in... eeprom settings are back to blank
[22:23:38] <Tom_L> read starting around P155 on serial programming EEPROM
[22:24:52] <Tom_L> http://tom-itx.no-ip.biz:81/~webpage/abcminiuser/articles/avr_eeprom_index.php
[22:24:54] <Tom_L> also that
[22:26:13] <Tom_L> i've only done it maybe once or twice...
[22:27:53] <dgriffi> Tom_L: there's nothing new there that seems to address my problem.
[22:28:15] <Tom_L> can't help much more...
[22:32:25] <Tom_L> dgriffi, can you write other locations ok?
[22:32:59] <dgriffi> Tom_L: I'm tinkering with that now. According to this:
http://www.avrfreaks.net/forum/setting-eeprom-address it's not recommended to use address 0 for some unexplained reason
[22:33:30] <Tom_L> they don't do some silly thing like starting the eeprom addressing at 0x01 do they?
[22:35:33] <dgriffi> I don't know. the symptoms I'm observing are that I can save a byte at 0x00, turn the power off, and it might stick there for 10 seconds to a minute
[22:35:51] <dgriffi> after that, it goes to something random
[22:35:57] <sabor> dgriffi: progtamming can also erase the eeprom
[22:36:12] <dgriffi> sabor: I figured that out right at the beginning
[22:36:18] <Tom_L> heh
[22:36:37] <sabor> the bigger avrs have a "don't erase eeprom on chip erase" fuse or something like that
[22:36:44] <sabor> aah, ok :)
[22:37:35] <sabor> how do you check the value? using the programmer?
[22:38:44] <dgriffi> at the beginning of my code after the timer is started, I do an eeprom_read_byte() and check to see if it's lower than 0x00 or higher than 0x04. I have five startup modes.
[22:39:09] <dgriffi> if it's outside of these bounds, 880hz is played three times.
[22:39:25] <Tom_L> is it too hard just to move it all up one byte?
[22:40:06] <dgriffi> Tom_L: no problem at all. But I'd like to know that I'm doing this because 0x00 is forbidden rather than grasping at straws
[22:40:09] <Tom_L> it sounds like a known issue
[22:42:46] <dgriffi> hmm... I'll set it aside for a few minutes and see if it takes if write to 0x01 and 0x02
[22:44:59] <Tom_L> i found on the atmega32U2 if i wrote a test program to blink all the pins to test continuity on my board that it would reset every time when it got to portc
[22:45:16] <Tom_L> they exposed the reset pin on that port :D
[22:45:19] <dgriffi> oh dear....
[22:47:51] <dgriffi> I think 0x00 is indeed forbidden. five minutes and my chip has retained its settings
[22:48:27] <sabor> shouldn't be, on the *8 avrs i always start at eeprom address 0...
[22:48:43] <sabor> but who knows on this one...
[22:49:10] <dgriffi> I'll go do something for a couple hours and check again.
[22:49:15] <dgriffi> so long. thanks all
[23:33:33] <scoy> \quit