Back
[02:36:56] * abcminiuser pokes
[09:22:28] <Getty> i have read out an eeprom with the :i option so that i can read it, but now i realize that i actually would like to write it to the device
[09:22:34] <Getty> is there a way to convert this?
[09:24:48] <cehteh> avrdude?
[09:24:54] <Getty> yes
[09:25:09] <cehteh> should be able to flash :i (hex)
[09:25:13] <cehteh> as is
[09:25:53] <cehteh> actually thats the way i flash here ...
[09:26:11] <Getty> oh i wasnt reading the error proper, thanks ;)
[09:26:15] <Getty> it seems he doesnt like paths
[09:26:37] <cehteh> otherwise avr-objcopy can convert between some formats
[09:26:46] <Getty> ah good to know, thanks
[09:26:56] <Getty> AH!!! the error is reproduceable... thats revealing...
[09:27:03] <Getty> now just finding out what it is
[09:27:14] <Getty> totally awkward, first analyse already showed one value on the eeprom which i never ever set
[09:28:41] <cehteh> last byte?
[09:28:45] <cehteh> bytes
[09:28:53] <cehteh> or first byte?
[09:31:49] <Getty> 2nd byte
[09:32:45] <Getty> can i set ONE BYTE of the eeprom?
[09:33:53] <cehteh> what µC?
[09:34:03] <Getty> hu?
[09:34:11] <Getty> oh ;)
[09:34:14] <Getty> atmega64
[09:34:37] <cehteh> check eeprom pagesize on the datasheet
[09:34:40] <cehteh> dunno
[09:34:48] <cehteh> some can programmed bytewise
[09:35:00] <Getty> oh wait
[09:35:02] <Getty> we are stupid
[09:35:10] <Getty> i can just change that one byte in the textfile
[09:35:42] <Getty> ok that byte was not the fault
[09:35:48] <cehteh> and with some glitches at programming you can accidentally programm the first few bytes .. there is an application note for that
[09:36:18] <cehteh> and for the last bytes iirc avrdude once implemented a counter there counting how often the device got flashed
[09:36:28] <cehteh> (but that might be obsolete)
[09:37:33] <cehteh> btw .. for debugging its a good idea to make a busy lool _delay(something) before programming the eeprom, then you have a chance not to wear cells out on a programming error wich writes them in a tight loop
[09:37:39] <cehteh> once finished remove that delay
[09:38:24] <Getty> aehm
[09:39:00] <Getty> is ther ea checksum at the end of the line?
[09:39:25] <cehteh> could be
[09:40:11] <cehteh> https://en.wikipedia.org/wiki/Intel_HEX
[09:45:50] <Getty> <facepalm>
[10:01:03] <Getty> damn it
[10:01:15] <Getty> somehow the read command doesnt want to generate a hex
[10:01:30] <Getty> it always says the target file doenst exist, he reads the eeprom and then errors out tha tthe file is missing
[10:01:43] <Getty> yeah the file is missing cause you should write it there ;) its your fault, damn avrdude!
[10:02:17] <Getty> i mean binary not hex i need it raw
[10:04:18] <Getty> ah :r
[10:15:38] <cehteh> makefile?
[10:17:22] <Getty> what you mean?
[10:17:35] <Getty> my makefile doesnt have magical the commands i need ;) i have to add them ;)
[10:17:46] <cehteh> just do :D
[10:18:13] <Getty> no no you cant use no format on read
[10:18:15] <Getty> thats the problem
[10:18:24] <Getty> no idea why, avrdude just ticks out if you dont give format
[10:18:30] <Getty> when i gave :r or :h it works just fine
[10:18:38] <Getty> but without format on :r: he wants to tick out
[10:19:00] <cehteh> eh?
[10:19:24] <Getty> wtf, now it works?!
[10:19:32] <Getty> i scrolled back to the broken command and now it just works
[10:19:57] <Getty> wait wait..... ok, i see cause the file is there
[10:20:09] <cehteh> 61 read_program:
[10:20:09] <cehteh> 62 $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_DEFAULT_SCK) -U flash:r:$(TARGET).hex:i -U eeprom:r:$(TARGET).eep:i
[10:20:09] <Getty> but ... wtf, so when i dont give a format the file must exist, but when i give a format it doesnt need to exist?
[10:20:14] <cehteh> .. from my Makefile
[10:20:17] <Getty> yeah :i
[10:20:19] <Getty> you gave a format
[10:20:27] <Getty> remove the :i and remove $(TARGET).eep
[10:20:31] <Getty> and see what happens
[10:20:46] <cehteh> why do you want to remove the format?
[10:21:05] <Getty> i thought that means raw, thats why i tried it, and as the documentation on avrdude pages are not saying much about it at all
[10:21:12] <Getty> on the 3rd page i saw the :r then which means raw
[10:21:12] <cehteh> :r means raw :D
[10:21:14] <Getty> yeah
[10:21:16] <Getty> NOW i know
[10:21:25] <cehteh> r .. like ... RTFM! :D
[11:56:16] <Lambda_Aurigae> Getty, you were seeing data in the eeprom you never set? Isn't the rc oscillator calibration byte stored in the eeprom from the factory?
[11:56:22] <Lambda_Aurigae> or is that stored somewhere else?
[11:57:11] <Getty> mh? would be awkward if they misuse the 2nd byte of the eeprom ;)
[12:00:31] <Lambda_Aurigae> as I recall, it's the first two bytes...would have to look it up..just a minute.
[12:01:20] <cehteh> thats stored somewhere else
[12:02:00] <cehteh> at least for the avr's i know
[12:02:09] <cehteh> never worked with the mega64
[12:02:29] <Lambda_Aurigae> hmmm...guess I'm wrong.
[12:02:43] <Lambda_Aurigae> it's in the high byte of the signature address space.
[12:03:08] <Lambda_Aurigae> must have been thinking of another chip.
[12:03:29] <Lambda_Aurigae> I know avrdude can be told to write a number to the eeprom...to tell how many times you have flashed the chip.
[12:04:02] <cehteh> improper initialization of the eeprom control registers or wrong voltage/clock can corrupt eeprom writes, esp the first few bytes
[12:04:21] <Lambda_Aurigae> that too.
[12:04:37] <cehteh> my current avrdude seems to be abadoned that feature, either way that was at the end of the eeprom
[12:04:53] <cehteh> was a misfeature anyway
[12:07:52] <cehteh> either way its not a good idea to store data always at the same place, esp when you want to store it frequently, when there is enough space available make some canarys around your data, add an checksum and have some strategy to write it at different places
[12:08:14] <cehteh> and verify your writes
[12:08:46] <EvanR> canaries?
[12:08:51] <EvanR> how does that work
[12:09:33] <cehteh> just some known value you can search for
[12:09:34] <Lambda_Aurigae> bits that you check for functionality.
[12:09:53] <Lambda_Aurigae> put * around your date or something.
[12:10:10] <cehteh> header+data+checksum alone is ok too
[12:10:30] <cehteh> maybe generation counter . .whatever suits the task
[12:10:50] <Lambda_Aurigae> as for the writing to eeprom in one location...on a microcontroller it shouldn't be an issue.
[12:11:08] <cehteh> depends on how often you plan to do that
[12:11:10] <Lambda_Aurigae> the eeprom is good for 100k writes and the flash for 10k writes.
[12:11:29] <Lambda_Aurigae> so, writing a spot in eeprom with the number of times the chip was flashed should be just fine.
[12:11:30] <cehteh> if its few times only config data its no problem
[12:11:46] <cehteh> yeah
[12:13:06] <cehteh> if you want to safe some other data on more frequent intervals you may think about endurance
[12:13:28] <cehteh> like max/min value and lifetime clock for a sensor or whatever
[12:13:29] <EvanR> use FRAM!
[12:16:09] <Lambda_Aurigae> cycle through memory locations too.
[12:16:19] <Lambda_Aurigae> EvanR, bah...core memory ftw!
[12:16:43] <EvanR> embedded core memory
[12:16:59] <cehteh> :)
[12:18:12] <Lambda_Aurigae> http://hackaday.com/2015/08/31/core-memory-for-the-hard-core/
[12:18:14] <Lambda_Aurigae> there ya go.
[12:18:49] <Lambda_Aurigae> 64 BITS of core memory!
[12:19:12] <cehteh> just struct mydata { unsigned generation_counter; my data ....; checksum thereof; }[as big as space is available] ..... increment generation counter on each write and write at index [generation_counter % as big as space is avalable]
[12:19:41] <cehteh> ... and when reading iterate over the array and pick the one with the biggiest generation counter AND checksum intact
[12:20:24] <EvanR> i wonder what the access time for that core memory module is
[12:20:49] <cehteh> not that shabby ,.. few khz :D
[12:20:50] <Lambda_Aurigae> or just get maxim-ic.com to send you a handfull of DS1230Y-100 modules.
[12:21:30] <Lambda_Aurigae> 10 year offline battery that doesn't get activated until the first poweron....32k*8bit nvsram module.
[12:21:46] <cehteh> or that
[12:22:14] * Lambda_Aurigae has some.
[12:22:35] <cehteh> but if you have eeprom and you can project the intended lifetime and wear .. why not use it when it is withhin desired range (+ a lot of safety marigin)
[12:23:28] <EvanR> FRAM
[12:23:56] <Lambda_Aurigae> dang..they still make the 128k*8bit ds1245 in dip package!
[12:24:01] <Lambda_Aurigae> have some of those too.
[12:25:03] <Lambda_Aurigae> wicked awesome fun with those and 8052 chips....bank switching and all...execute from external ram plus have banks of external data
[12:27:34] <Lambda_Aurigae> microchip makes a nice little nvsram too...spi interfaced 8pin 128k*8bit...add your own external battery and it autoswitches to battery when main power is lost.
[12:27:45] <Lambda_Aurigae> no need to abuse the poor eeprom.
[12:39:05] <Jartza> Lambda_Aurigae: ouch... I'm over-engineering the vga
[12:39:08] <Jartza> halp :)
[12:39:17] <Lambda_Aurigae> uhuo!
[12:39:18] <Lambda_Aurigae> hehe
[12:39:29] <Jartza> I implememented row-based scrolling
[12:39:31] <Lambda_Aurigae> I have about 15 mintues left of lunch.
[12:39:46] <Jartza> so you can use my "self-implemented" ansi-escape to scroll one row left
[12:39:50] <Getty> is this all about my one bit? ;-)
[12:39:54] <Jartza> <ESC>[##[
[12:40:00] <Jartza> where ## is row number (0-13)
[12:40:04] <Jartza> https://www.dropbox.com/s/tofm47x1quh0lf5/20151110_003.mp4
[12:40:06] <Jartza> :)
[12:40:07] <Lambda_Aurigae> Getty, no...it's all about me being bored at lunch..
[12:40:10] <Jartza> someone should make me stop :D
[12:40:53] <Lambda_Aurigae> I should look at the microchip serial sram and attiny85 and see how many of the required pins line up if you stack them
[12:41:35] <Lambda_Aurigae> Jartza, kewl.
[12:41:50] <Lambda_Aurigae> you got vertical scroll working, yes?
[12:43:06] <Jartza> Lambda_Aurigae: sure
[12:43:17] <Lambda_Aurigae> thought so but haven't played with that part yet.
[12:43:55] <Getty> i get crazy
[12:44:08] <Getty> before i actually take care of the bug i added a failsafe start to reset configuration instead of starting it up
[12:44:10] <Getty> to avoid the asme problem
[12:44:24] <Getty> now i tested it with the original eeprom that broke, and....... it just works
[12:44:27] * Getty gets headache
[12:44:37] <Jartza> Lambda_Aurigae:
https://drive.google.com/file/d/0B2dTzW9TMeBxTlRzTVUwUDl4alU/view
[12:45:07] <Lambda_Aurigae> kewl.
[12:45:49] <Lambda_Aurigae> ski game time!
[12:46:10] <Jartza> hehe
[12:46:18] <Jartza> though it only scrolls up
[12:46:31] <Jartza> and horizontal scroll is only one row and only to left
[12:46:31] <Lambda_Aurigae> that's perfect.
[12:46:44] <Jartza> if scrolling all 14 rows, it gets pretty slow
[12:46:47] <Lambda_Aurigae> skier goes downscreen...trees and such go up.
[12:47:20] <Lambda_Aurigae> skier gets moved side to side so as not to impact the trees and flags.
[12:47:31] <Jartza> or well, the scrolling isn't that slow, but if you want to scroll full screen left and update texts, there's a lot of ansi escapes involved
[12:47:48] <Lambda_Aurigae> it's one of those simple/complex games that we all wrote on the vic-20 and apple-2 as early exercises.
[12:47:51] <Jartza> scroll one row, move cursor to the end of that row, insert character, scroll one row, move cursor....
[12:48:08] <Lambda_Aurigae> don't need horizontal scrolling for the skiing game.
[12:48:12] <Jartza> https://github.com/Jartza/attiny85-vga/blob/master/vga.asm
[12:48:36] <Jartza> 740: forward is the left scroll :D
[12:48:41] <Jartza> I needed to split that into two parts
[12:49:03] <Jartza> as there's not enough time in single hsync to move whole row :D
[12:49:16] <Lambda_Aurigae> yeah.
[12:49:17] <Jartza> sorry, 712: forward
[12:51:22] <Jartza> what I would want to do is also full-screen scroll to left, but it might just be too much :(
[12:52:45] <Lambda_Aurigae> then we could make defender!
[12:52:50] <Jartza> the scroll should finish before next character arrives from uart
[12:53:21] <Jartza> hmm... that's about 16 characters per screen refresh (9600 equals about 960cps, divided by 60Hz)
[12:53:48] <Jartza> that's about 25 scanlines to scroll full screen
[12:53:51] <Lambda_Aurigae> too bad you don't have more ram for offscreen buffer.
[12:54:10] <Jartza> it's because I'm stubborn :D
[12:54:27] <Jartza> and wanted to push attiny85 to some limits
[12:54:38] <Jartza> scrolling single row takes 2 scanlines
[12:54:57] <Jartza> scrolling 14 rows takes 28 scanlines then
[12:54:59] <Jartza> ohh
[12:55:23] <Jartza> it actually might be doable!
[12:55:33] <Lambda_Aurigae> combining thingies?
[12:55:40] <Jartza> interleaving
[12:55:44] <Jartza> like that row-scroll
[12:55:58] <Jartza> just do part of stuff and continue with that horizontal line
[12:56:13] <Jartza> and on next horizontal line, continue whatever there was going on :D
[12:56:21] <Lambda_Aurigae> that could work.
[12:56:30] <Jartza> well it's how I already need to do stuff
[12:56:36] <Jartza> even the screen clearing needs to be interleaved
[12:56:38] <Lambda_Aurigae> ok...coffee break's over..back on your heads.
[13:01:55] <Jartza> hmm
[13:02:53] <Jartza> also "cursor up" and "cursor down" could make things a bit faster
[13:03:21] <Jartza> <ESC>[A instead of <ESC>[31;9H saves many bytes
[13:03:32] <Jartza> because most of the slowness comes from the fact that the uart is 9600bps
[13:03:40] <Jartza> 19200bps didn't work. stupid Nyquist.
[13:20:16] <zer0ptr> does anyone know where to find the ".inc" file which contains the top of stack address for the atmega328p?
[13:21:45] <zer0ptr> for the atmega328, i can see it is m328def.inc from this source code file
http://web.alfredstate.edu/weimandn/programming/lcd/ATmega328/LCD_code_asm_4d.html
[13:21:59] <zer0ptr> i don't have that on my system though
[13:30:06] <sim642> I have some code I'm compiling which spews loads of incompatible implicit declaration warnings about sprintf. It somehow uses sprintf without including it. Adding #include <stdio.h> to get rid of the warnings shouldn't affect any behavior of the code, right?
[13:31:05] <cehteh> normally not
[13:32:11] <sim642> ok good, then I can keep the irrelevant warnings to minimum
[13:32:26] <cehteh> heh
[13:32:29] <sim642> I was just wondering because I find it weird that sprintf can be used without including stdio or anything
[13:32:42] * cehteh always aims for -Walls -Wextra -Werror
[13:38:05] <zer0ptr> i can't seem to find this file. is there an alternative way, i could initialize the stack pointer?
[13:39:47] <sim642> cehteh, without -Werror here, I can't be bothered to fix warnings in others' crappy code
[13:43:15] <Jartza> zer0ptr: you need that asm inc file?
[13:43:21] <Jartza> should come with atmel studio
[13:43:41] <zer0ptr> Jartza: im using avr-as
[13:44:53] <Jartza> then you need to copy it somewhere, maybe even modify it
[13:45:12] <zer0ptr> well from the C compiler generated code. i have found out the stack pointer high order and low order byte addresses
[13:45:15] <Jartza> I'm using avra, as it seems to be very compatible with atmel studio
[13:45:29] <Jartza> https://github.com/DarkSector/AVR/blob/master/asm/include/m328def.inc
[13:45:34] <Jartza> google is your friend :)
[13:46:09] <Jartza> https://code.google.com/p/ardupilotdev/source/browse/trunk/QuadControllerV4_5JLN/m328Pdef.inc?spec=svn23&r=18
[13:46:14] <Jartza> that's for 328p
[13:46:33] <Jartza> avra eats those as-is, don't know about avr-as
[13:47:15] <EvanR> avra?
[13:47:31] <Jartza> http://avra.sourceforge.net/
[13:47:53] <Jartza> yea. it's old, but works
[13:48:21] <zer0ptr> Jartza: thank you :)
[13:48:30] <EvanR> is it only for 32 bit
[13:49:11] <Jartza> no, it's for 8 bit
[13:50:13] <Jartza> for example my vga code I made with avra
[13:50:28] <Jartza> and the code compiles as-is with atmel studio too
[13:50:35] <Jartza> (but I'm mostly using mac)
[13:50:55] <zer0ptr> yeah that file does not work, the assembler complains missing commas
[13:51:01] <zer0ptr> *about
[13:51:08] <EvanR> atmel studio doesnt work on mac?
[13:51:42] <Jartza> windows only
[13:52:13] <Jartza> zer0ptr: yeah, it's because that file is made for atmel studio assembler too
[13:52:30] <Jartza> it works with avra, but not with avr-as as-is, you need to modify it to support gnu assembler syntax
[14:12:41] <Getty> great
[14:12:42] <Getty> 1 char
[14:12:47] <Getty> uint_8 => int_8
[14:13:01] <Getty> will cost now..... mmmhhhh 350-400 EUR? ;)
[14:13:13] <Getty> excluding the work of reprogramming
[14:13:25] <sim642> Getty, what did you manage to do? :P
[14:13:27] <Getty> <facepalm> electronics suxx, web development was so much easier
[14:13:39] <Getty> nah, the usual shit, we made a device and have a bug even tho its already sold
[14:13:46] <Getty> we actually had 2 bugs this is already the 2nd rerun
[14:13:52] <Getty> but one was literally planned in
[14:14:09] <Getty> so the customer who hit the bug must now get replaced
[14:14:17] <Getty> and every replace cost our distributor 7 EUR
[14:30:30] <Lambda_Aurigae> sounds like someone needs to do some unit testing before shipping a product.
[14:30:33] <Lambda_Aurigae> much like xerox.
[14:31:11] <Getty> well i did a lot of testing
[14:31:37] <Getty> but the first bug was so subtile that i didnt noticed, and the second bug was related to the daytime when the device gets started
[14:32:05] <Getty> (as in, the bug exist only if you switch the device on before sunriser)
[14:32:11] <Getty> sunrise
[14:32:31] <Lambda_Aurigae> guess you didn't make it idiot-resistant.
[14:32:40] <Lambda_Aurigae> unit testing for the win.
[14:32:54] <Getty> unit testing means that i have a test to find this kind of failure
[14:33:00] <Lambda_Aurigae> used to do that for software that got hard coded onto devices that couldn't be recalled....satelites.
[14:33:21] <Getty> yeah sure, i was just a bit more in pressure and i have no peer review of my code
[14:33:25] <Lambda_Aurigae> test every possible thing that could be done to it whether it was meant to be done or not.
[14:33:28] <Getty> so i try my best to test out anything
[14:33:29] <Getty> yes
[14:33:33] <Getty> and i just didnt tested THIS ONE THING
[14:33:37] <Lambda_Aurigae> yup
[14:33:38] <Lambda_Aurigae> hehe
[14:33:50] <Lambda_Aurigae> do we need to get out the noodle whip?
[14:33:54] <Getty> nah
[14:33:56] <Getty> shit happens
[14:34:10] <Lambda_Aurigae> fifty lashes with a wet noodle!
[14:34:32] <Lambda_Aurigae> yeah...like the two gps satellites that were launched with a manual reset circuit breaker on the main power feed.
[14:34:56] <Lambda_Aurigae> because that's what they had on the ground based testbed and nobody thought to change them.
[14:35:10] <Lambda_Aurigae> they tested one and it failed and never came live again.
[14:35:33] <Getty> yeah
[14:35:47] <Getty> booking.com story is also fascinating, software story, but as brilliant
[14:35:53] <Lambda_Aurigae> they were within 24 hours of testing the power supply to overload when we found the part number on the schematic and someone noticed that it was NOT a self-resetting fuse but a manual reset breaker.
[14:36:07] <Getty> they invested a huge amount of money to switch their website, made the biggest testsuites in history, and planned everything out so good
[14:36:24] <Getty> there was 99.9999999999999999% of all things covered
[14:36:59] <Lambda_Aurigae> didn't figure on 13 year old girls?
[14:37:18] <Getty> but........... no one........... ever........ tested........... how the site reacts if a user comes in with a session of the old system ......................
[14:37:30] <Lambda_Aurigae> oops.
[14:37:56] <Getty> its brilliant if you hear the story of the people involved, they actually can list you so many things they tested that it gets hilarious every minute more
[14:38:13] <Getty> since then they dont do tests anymore, or lets say: not unit tests ;)
[14:38:18] <Getty> they do the dollar-test
[14:38:44] <Strangework> Pardon, the dollar test?
[14:38:44] <Getty> code is always put on a part of the cluster, the amount of money it brings in is messured against the money it SHOULD bring in
[14:38:52] <Getty> and if its more as before, then the code gets in
[14:39:06] <Getty> no joke, and i cant deny that this is a brilliant form of testing ;)
[14:39:29] <Getty> this does detect outage pretty effective, its impossible to bring in faulty code
[14:39:50] <Getty> (or faulty enough that its relevant ;)
[14:40:19] <Strangework> Hold on, you said these guys no longer conduct unit tests/
[14:40:20] <Strangework> ?
[14:40:39] <Strangework> Knowing the usefulness of a component is separate from knowing if a component works
[14:40:56] <Getty> if they didnt changed recently, they dont do a specific testing on the code directly, even tho, many of their code is opensource and so covered with those test suites
[14:41:00] <Getty> yeah
[14:41:07] <Getty> but after the "disaster" it went a bit into mentality
[14:42:10] <Getty> i bet they have some basic tests to assure they dont deliver white pages from start on ;)
[14:42:15] <Getty> but the only relevant thing is the money-test
[16:09:44] <day> im trying to get the atmega internal ADC bandgab reference 1.1V working. The 5V external ref pin works flawlessly
[16:09:57] <day> bandgap*
[16:10:14] <day> is there something tricky that i need to take care of? :/
[16:16:53] <LeoNerd> It's a fairly high-impedence source. The first reading after you switch to it isn't reliable
[16:16:59] <LeoNerd> Personally, I throw away the next two
[17:18:37] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxX01pTTFlNDU0SFE/view
[17:49:03] <day> LeoNerd: yeah i know. the strange thing is just, when i use the 1.1V ref. the ADC outputs 1023, even though the ADC pin is connected to GND
[17:51:11] <RikusW> is the mux setup correct ?
[17:51:52] <day> RikusW: well with the 5V ref. it works just fine
[17:51:58] <day> so i would assume they are
[17:52:55] <day> do i have to connect anything externally for the 1.1V ref to make it work?
[17:53:23] <RikusW> which avr is that ?
[17:53:31] <RikusW> (mega/tine ?)
[17:55:20] <day> atmega328p
[17:55:56] <day> the datasheet says something about a capacitor at Aref etc. But this is only to make it nicer
[17:57:03] <sabesto> you should be able to measure the reference voltage at aref pin
[17:57:39] <day> right
[17:57:45] <sabesto> i am however not sure if the act of measuring it will change the value
[17:57:55] <day> it is a good idea
[17:58:09] <day> i think i will measure 0V
[17:59:39] <day> i noticed another strange thing btw. for some reason the ADC seems to get stuck at 255 for a while, until the value raises far enough. its like theres a big gap between the lower register and the higher :?
http://i.imgur.com/H2gAEQS.png
[18:02:30] <sabesto> how are you reading out the values?
[18:03:04] <RikusW> I'll put a 100nF cap on Aref and use an inductor (10uH) from vcc to avcc, and add 100nF to avcc too.
[18:03:06] <sabesto> it does look like 1.1V will be electrically connected to aref pin if 1.1v is selected
[18:03:24] <day> im reading the ADC register within an interrupt
[18:03:37] <day> sabesto: yes that is definitely the case
[18:03:53] <sabesto> like "value=ADC", or are you reading ADCH and ADCL?
[18:04:00] <day> sabesto: first
[18:04:20] <RikusW> iirc L needs to be read before H
[18:04:20] <sabesto> ok, because if you fuck up the latter (the order) it will lock up
[18:04:21] <day> according to the datasheet that is ok
[18:04:48] <day> RikusW: the compiler takes care of it
[18:04:56] <sabesto> if you use ADC "register" the compiler will handle ADCH/L
[18:07:49] <sabesto> it might be because of noise, and you should at least put a cap on aref and avcc, and if you got it, an inductor aswell
[18:11:24] <day> sabesto: i give it a try tomorrow, but i doubt its a noise issue. i would at least see a few non 1023s
[20:13:43] <zer0ptr> how is it possible that a nested loop (outer loop: 0 -> 255, inner loop: 0 -> 255: nop on each iteration) to cause no visible delay?
[20:21:35] <Tom_itx> optimized out?
[20:23:02] <zer0ptr> Tom_itx: well im using the assembler directly
[20:23:17] <zer0ptr> so i dont think there are any optimizations
[20:24:34] <Tom_itx> oh
