Back
[00:01:45] <Casper> avrdude
[00:03:14] <metanosulfonico> yes
[00:04:27] <metanosulfonico> thanks for your help
[03:37:17] <jben> Hi, I have a question about macro extention and token concatenation for the C preprocessor
[03:37:35] <jben> Minimal example:
[03:38:10] <jben> this code works:
https://zero.crans.org/?20061130bbdcb4c2#VAI/rbbzWxB2yfxhtqH7s1qo8aUT8qoT1W3CLlOZhkQ=
[03:38:30] <jben> this code does not work:
https://zero.crans.org/?5a50642d82a66c58#OE3jAditeBF7x1oiuRw9rNvYwgLCrLNmr1rCHQjmQH0=
[03:39:07] <jben> the only diff is in the last #define
[03:40:37] <jben> (I want to do symbol concatenation for a interrupt driven usart, where I only specify the usart name before including my code)
[03:43:10] <cehteh> you need some double expansion for that
[03:43:36] <cehteh> #define CONCAT(a,b) CONCAT2(a,b)
[03:43:47] <cehteh> #define CONCAT2(a,b) a ## b
[03:44:02] <cehteh> else the parameters dont get evaluated
[03:45:10] <jben> cehteh: tricky
[03:45:25] <jben> but it's works, thank you very much!
[03:45:52] <cehteh> cpp can be pita :D
[03:46:42] <jben> cehteh: I am not writting cpp, but C
[03:46:57] <cehteh> cpp -> c pre processor
[03:47:08] <jben> right, I agree
[05:29:02] <julius> the atmega168 doc says that the phase correct pwm frequency is calculated by: freq = F_CPU/(N*510) n being the prescalar. what is this 510?
[05:38:22] <julius> if the 510 is fixed, and there a are only a feq prescalars. does this mean that phase correct pwm can only work with a few frequencys?
[06:01:51] <jben> Again,
[06:02:59] <jben> I have '# define USART_RXC_vect CONCAT(USARTname,_RXC_vect)' in my code, with '#define USARTname USARTC0', I want USART_RXC_vect as USARTC0_RXC_vect
[06:03:07] <jben> is this possible?
[06:03:39] <mohsen_> Is gyroscope used to detect the angle of rotation?
[06:04:16] <mohsen_> or the speed of rotation?
[06:04:21] <mohsen_> I'm confused
[06:06:28] <LeoNerd> jben: Ah.. expanding macros within other macros at the right time and not before, is a little tricky
[06:09:11] <jben> LeoNerd: yes, it seem to be…
[06:09:46] <LeoNerd> I tried to do that once with defining a "port" generically, so I could paste the name of PORTB / DDRB / PINB etc... based on the "B"
[06:12:24] <Jartza> jben: how is CONCAT defined? :)
[06:13:43] <LeoNerd> http://pastie.org/10732616 <== the amount of hackery I had to do
[06:14:36] <Jartza> https://gist.github.com/Jartza/29f70ad559a0f1e7b6ae
[06:14:43] <Jartza> my "avr generic macros" I use all the time
[06:18:51] <Jartza> makes a bit more readable code, IMO
[06:18:52] <Jartza> BITS_SET_EX(ADMUX, MUX1, ADLAR);
[06:19:00] <Jartza> BITS_SET_EX(ADCSRA, ADEN, ADPS1, ADPS2);
[06:19:06] <Jartza> BITS_SET(ADCSRA, ADSC);
[06:19:43] <Jartza> while(ADC_CONVERSION);
[06:19:44] <Jartza> ...
[06:20:08] <LeoNerd> I do that kind of thing with real functions. adc_setup(ADC_REF_INT1V1, ADC_PRESCALE_256);
[06:20:50] <Jartza> #define ADC_CONVERSION BITP(ADCSRA, ADSC)
[06:20:53] <Jartza> that first, of course
[06:21:11] <Jartza> LeoNerd: that's cool too, if you just have enough flash :)
[06:21:31] * LeoNerd hugs LTO
[06:22:00] <Jartza> yea. my Tagsu firmware is 5922 bytes now with LTO :)
[06:22:16] <Jartza> and I have 6kB available for firmware (2kB of flash reserved for user data)
[06:23:11] <Jartza> though I can get it down to 5890 without LTO using the old "include all in single file"-trick
[06:23:15] <LeoNerd> Mm.. I usually work with tiny84(1)s.
[06:23:32] <Jartza> tagsu is tiny85
[06:23:32] <LeoNerd> Recently working on a mega328. luxury... and my next project once this lot is done might involve a mega2560
[06:23:44] <LeoNerd> I honestly don't know what I could fill all that space with
[06:24:05] <Jartza> my current customer project has 2MB of flash
[06:24:12] <Jartza> and we're fighting to fit everything
[06:24:16] <Jartza> :)
[06:24:37] <Jartza> I just don't get why people use atmega2560
[06:25:00] <LeoNerd> IO pins. I need loads
[06:25:27] <LeoNerd> I'm driving a bicolour 8x8 LED matrix, so I need 8 rows and 16 columns. That's 24 pins. Then add to that two 8-bit bidirectional IO ports.. another 16. So 40 pins just on that
[06:25:48] <LeoNerd> Add serial port, and a few miscellaneous buttons and panel indicator LEDs
[06:26:08] <Jartza> and you get this with half of the price:
http://fi.farnell.com/atmel/atxmega256a3bu-au/mcu-8bit-avr-xmega-32mhz-tqfp/dp/2066305
[06:26:16] <LeoNerd> max72xx chips are good for single colour 8x8 matrices but can't cope with synchronised access to two of them
[06:26:52] <LeoNerd> Hrm.. pretty sure the mega2560 was peanuts-cheap
[06:26:58] <Jartza> http://www.atmel.com/devices/ATXMEGA256A3BU.aspx?tab=parameters
[06:27:43] <LeoNerd> Oh. Duh.. I'm misremembering. ATmega128
[06:27:46] <LeoNerd> Well, 128A now
[06:28:52] <Jartza> IMO atmega is obsolete
[06:29:02] <Jartza> if attiny is not enough, then go straight to xmega
[06:29:11] <Jartza> if xmega is not enough, get arm cortex m :)
[06:30:09] <Jartza> xmegas have tons of peripherals with low price
[06:30:38] <Jartza> though many arms are getting so cheap that you can't really compare soon
[06:38:47] <LeoNerd> I don;t need periphs
[06:39:02] <LeoNerd> I need silly number of plain digital GPOIs and a UART
[06:39:21] <LeoNerd> Homestly. a really big attiny2313 would suffice. :)
[06:39:39] <Jartza> what's a silly number
[06:40:44] <Jartza> oh, 24 pins, you said it already
[06:42:51] <Jartza> in your case I would probably go with something like STM32F030R8T6
[06:44:36] <WormFood> fuck! My Internet connection has been shit lately. Trying to work on my calculator, and it's frequently not responding.
[06:49:19] <LeoNerd> I need 40 +,UART + a few extras.. so the 53 on a mega128 is good
[06:49:55] <LeoNerd> Cheaper/smaller/easier than a smaller chip + GPIO expander
[06:51:27] <Jartza> STM32F030R8T6 is about 1.5€ :)
[06:52:07] <LeoNerd> But that's an STM
[06:52:42] <LeoNerd> So then I'd have to factor in new tooling, new software, extra time to learn, the risks of unfamiliar territory,..
[06:53:22] <WormFood> yeah, better to not do anything, and not expand your knowledge :P (I know, you have time constraints, and don't have time to take the risk)
[06:53:48] <Tom_itx> when do you have time to take risk?
[06:54:07] <WormFood> it depends on the time it needs to take. and the potential risks.
[06:54:26] <LeoNerd> WormFood: out of interest; what kind of calculator needs internet access?
[06:54:27] <WormFood> Is failure an annoyance, or a catastrophic event, in your project?
[06:54:39] <WormFood> google "avr baud"
[06:54:48] <LeoNerd> Oh.. that one. Yes, I like that one. Used it quite a lot
[06:54:53] <WormFood> It's a calculator ONLINE :P
[06:54:53] <LeoNerd> You don't have a fuse calculator as well do you?
[06:54:59] <WormFood> hahaha
[06:55:03] <WormFood> everyone asks me about that.
[06:55:37] <LeoNerd> I'm wondering how to get the default values for the fuses. It seems the AVR devices info XML files don't mention them
[06:55:41] <Lambda_Aurigae> so make one!
[06:55:43] <WormFood> no, but I've looked into it. I need to get all the definitions for the fuse bits, for all the different AVRs, and it needs to be automated. I have some in .xml files, but I don't know the source (I got it from someone here)
[06:55:50] <LeoNerd> Lambda_Aurigae: I'm trying to :P
[06:55:54] <Lambda_Aurigae> do
[06:55:56] <Lambda_Aurigae> or do not
[06:55:58] <WormFood> where to get these files from?
[06:55:59] <Lambda_Aurigae> there is no try.
[06:56:16] <WormFood> I install AS the other day, for the express purpose of getting those files, so I can make a fuse calculator.
[06:56:18] <LeoNerd> WormFood: Eh.. So.. They come from Atmel. Officially, they come with a copy of AVR Studio. You can download it at no cost.
[06:56:19] <Lambda_Aurigae> I thought they came from atmel/avr studio.
[06:56:25] <LeoNerd> But it comes as a Windows self-extracting binary.
[06:56:27] <Tom_itx> aren't they in the studio fileset?
[06:56:27] <WormFood> WHERE?
[06:56:33] <WormFood> I can't find them.
[06:56:37] <LeoNerd> So even though it's a standard set of portable files, you need a Windows machine to extract it :(
[06:56:38] <WormFood> I searched, and manually looked.
[06:56:40] <WormFood> nothing.
[06:56:46] <LeoNerd> Hence everyone copies them around here ;)
[06:56:48] <Tom_itx> maybe they don't post them anymore
[06:56:49] <WormFood> BUT WHERE ARE THE FILES?!?
[06:56:49] <Lambda_Aurigae> no clue...won't install on my computer.
[06:57:08] <WormFood> I just installed the newest AS, a few days ago, and these files don't seem to exist in the basic install
[06:57:22] <WormFood> I installed it on a spare machine, since I don't use Windows.
[06:57:22] <Tom_itx> i don't think they put them there anymore
[06:57:36] <WormFood> But, I need these definitions, in an automated way.
[06:57:38] <Tom_itx> i don't have a machine available that has studio atm
[06:57:51] <LeoNerd> Lambda_Aurigae: My plan is a program called 'avrfuse' that you'd run with something like `avrfuse -c m328p EESAVE BODLEVEL=2V4` and it would spit out an exact commandline fragment to pass to avrdude
[06:57:58] <WormFood> Tom_itx, I'm sure this info must be available from somewhere, in a machine readable format (so it can be automated)
[06:58:22] <LeoNerd> But to make that work, I need a fuse definition file that knows the *default* values, so the user only has to specify the changes from default that they want
[06:59:06] <WormFood> google devices.7z and avr
[06:59:11] <WormFood> and you'll get something
[06:59:18] <Tom_itx> http://www.avrfreaks.net/forum/xml-files-studio-7
[06:59:25] <LeoNerd> Yah; but that's just their upstream files, which don't have the fuse default values in
[06:59:26] <LeoNerd> :(
[07:00:08] <Tom_itx> https://metacpan.org/pod/Device::AVR::Info
[07:00:21] <LeoNerd> That's mine :)
[07:00:26] <Tom_itx> haha
[07:00:26] <LeoNerd> That's the thing I wrote, based on those XML files.
[07:00:37] <LeoNerd> In fact, that's the thing I'm going to add avrfuse into :)
[07:01:22] <WormFood> thanks for the link Tom_itx. I'm checking my AS again.
[07:01:24] <LeoNerd> This module loads an parses "part info" XML files as supplied with Atmel's AVR Studio, and provides convenient access to the data stored inside them. <== as it says
[07:06:47] <WormFood> Where do I find the avr_tools_device_file.xsd file?
[07:28:25] <WormFood> as far as a fuse calculator goes, what is wrong with this one?
http://eleccelerator.com/fusecalc/fusecalc.php
[07:29:42] <julius> hi guys
[07:29:50] <WormFood> 你好 julius
[07:30:10] <julius> my client can actually show that...would be nicer if he translated
[07:30:28] <julius> whats that say?
[07:30:40] <WormFood> nihao
[07:31:01] <WormFood> in English, it roughly translates to "Hello".
[07:31:10] <WormFood> It literally translates to "you good"
[07:32:15] <WormFood> I saw a sign at the mall, that had an arrow pointing to "smallpox", so needless to say, the translation tools sometimes produce hilarious results.
[07:33:29] <WormFood> http://wormfood.net/pictures/bad_english/in_case_of_fire_do_what%3f%3f%3f.jpg <-- one of my personal favorites. Feel free to browse the directory for other pictures that I've taken.
[07:34:27] <julius> you good smallpox?
[07:35:05] <julius> oh, hi smallpox
[07:35:11] <WormFood> no
[07:35:18] <WormFood> they had mistranslated something
[07:35:34] <WormFood> they just picked the wrong translation.
[07:37:45] <WormFood> http://wormfood.net/pictures/bad_english/spam2.jpg <-- I need this sign on my email server, right over the bit bucket.
[07:38:59] <WormFood> LeoNerd, what is wrong with this calculator, for fuses?
http://eleccelerator.com/fusecalc/fusecalc.php
[07:39:42] <LeoNerd> It's online
[07:39:45] <LeoNerd> I want a commandline one
[07:39:55] <julius> thats a nice one too
[07:40:00] <WormFood> ooohhh
[07:40:19] <LeoNerd> I want to be able to avrdude -p usbasp -c m328p `avrfuse -c m328p EESAVE CKSEL=EXT_XTAL ....`
[07:40:27] <LeoNerd> and have it calculate the avrdude commandline required to set those fuses
[07:40:46] <julius> you could use python with beautifulsoup to parse the page from wormfood
[07:40:46] <LeoNerd> I can do that right now, but only if the user *fully* specifies every fuse, including all the default values
[07:40:51] <WormFood> why not just hack avrdude to do that fer ya?
[07:40:58] <LeoNerd> Because that isn't avrdude's job
[07:41:20] <WormFood> make it avrdude's job
[07:41:23] <LeoNerd> avrfuse just has to output some string that looks like -U lfuse:w:0x62:m -U hfuse:w:0xD7:m -U efuse:w:0xFF:m or whatever
[07:41:28] <LeoNerd> This is easy to make a separate program for
[07:41:30] <WormFood> fuck that dude, and make him do more work.
[07:42:08] <LeoNerd> But anyway... regardless of *which* tool does this, the fact remains that the information still needs to be obtained by some method
[07:42:13] <LeoNerd> I don't believe we have a method currently do we?
[07:44:16] <jben> Jartza: as cehteh said before
[07:44:21] <WormFood> It appears, that information is tied up in PDF files.
[07:44:32] <WormFood> I think you'd have to do it manually.
[07:44:54] <WormFood> BUT, on the up side, since the same core is used in several different chips, it shouldn't be as much work as it appears on the surface.
[07:45:07] <jben> LeoNerd: this is basicly the same as cehteh said before, but for me the USARTC0 is expanded, because it have a meaning
[07:45:52] <cehteh> i only gave that as generic example
[07:46:59] <jben> cehteh: yes it was working to exand precessor definied variable, but now I want to expand a preprocessor defined varaible to another preprocessor defined variable, but I want only the intermediate level of expansion
[07:47:43] <jben> I have a solution (I think of this when I read LeoNerd code), to do thing like
[07:47:49] <jben> #define USARTname C0
[07:48:31] <cehteh> i am doing that to for UART :D
[07:48:31] <jben> #define USART_RXC_vect CONCAT(USART,CONCAT(USARTname,_vect))
[07:49:03] <jben> and this seem to work
[07:49:11] <cehteh> you can have endless fun with the preprocessor :D
[07:49:30] <cehteh> http://git.pipapo.org/?p=dinoheat;a=blob;f=progmem_string_array.h
[07:49:35] <cehteh> loops ftw
[07:51:13] <jben> cehteh: oh my god
[07:55:07] <Jartza> cehteh: and what on earth does it do? :)
[07:55:37] <cehteh> making declaring a array of progmem strings easy as pie :D
[08:00:28] <cehteh> http://paste.debian.net/402562/
[08:02:59] <cehteh> or simpler #include "progmem_string_array.h"
[08:02:59] <cehteh> PROGMEM_STRING_ARRAY(my_array, L("foo"), L("bar"), L("baz"));
[08:03:44] <Jartza> mmkay
[08:03:46] <Jartza> very cool :)
[08:13:24] <cehteh> lazy programmers let the preprocessor type the program :D
[08:20:30] * LeoNerd reads about *printf_P and ponders using it
[08:20:44] <LeoNerd> It would save RAM I believe... which since I need 1 512byte SD card buffers, might be useful
[08:22:37] <cehteh> as long you have flash, use the _P functions
[08:23:02] <cehteh> there is a bit overhead since things needs to be read from flash
[08:23:27] <LeoNerd> Yeah, but that's just CPU time, and I'm fprintf'ing these things into the UART anyway
[08:23:29] <cehteh> mhm maybe not even that, fetching from flash should be as fast as fetching from ram
[08:23:32] <WormFood> Why don't we see autobaud (autobitrate) detection anymore? I remember back in the bad old days, my computer had a serial port, as the printer port. And companies made serial to parallel converters, that had no switches to set the bit rate, because it could automatically detect it. Why don't I see this anymore?
[08:23:50] <LeoNerd> It runs a character behind, as it blocks writing the *next* character, and the serial line is 19.2kBaud so there's plenty of CPU time spare :)
[08:24:17] <cehteh> or dont use printf at all
[08:24:28] <LeoNerd> It's a debug console on serial port. It's convenient
[08:24:35] <cehteh> formatstrings and parsing them takes time
[08:25:03] <cehteh> just use explicit functions
[08:25:05] <LeoNerd> yeah.. but as I said: debugging, serial port.
[08:25:13] <LeoNerd> I don't care if debug is slow. And serial port is slow *anyway*
[08:25:14] <cehteh> yes still
[08:25:29] <LeoNerd> But I do care about the message strings not eating up lots of RAM I could be using for disk cache
[08:25:59] <cehteh> thats how i do the basework on my io lib output_cstr_P ("The result is: "); output_uint8(i); output_nl();
[08:26:28] <cehteh> later i may add a printf like parser/formatstring facility
[08:26:29] <LeoNerd> Yah; I've done that before on ATtiny projects sometimes
[08:26:31] <cehteh> if ever
[08:26:42] <LeoNerd> But this is a mega328P.. plenty of flash so I'm not worried
[08:26:51] <cehteh> ok then
[08:27:17] <cehteh> well i try to conserve ram as much as possible on the cost of program space
[08:27:40] <cehteh> working on this txqueue things where the functions like above store things in binary
[08:28:00] <cehteh> output_cstr_P ("The result is: "); output_uint8(i); output_nl(); will take 5 bytes ram
[08:29:25] <cehteh> 1 byte CSTR_P tag, 2 byte pointer to "The resuilt....', uint8 tag, i, nl tag .. err 6 bytes :)
[08:29:44] <LeoNerd> Hrm.. Does anyone have a more detailed description of what the "minimal" avr-libc vfprintf function does? The documentation at
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html#gaa3b98c0d17b35642c0f3e4649092b9f1 is relatively sparse on the subject
[08:29:56] <LeoNerd> It says "only the basic conversions"... what are those exactly?
[08:30:16] <cehteh> you can select that at compile or link time with some flags
[08:30:29] <LeoNerd> Yesyes.. I know I can select one
[08:30:30] <cehteh> there are different implemenations which get link depending on what you select
[08:30:38] <LeoNerd> I want to know what things it implements, if I do select it
[08:30:50] <cehteh> use the source luke :D
[08:31:00] <cehteh> (or just test whatever works)
[08:31:20] <cehteh> aka i dont know details either
[08:37:12] <julius> on this page:
http://www.precisionmicrodrives.com/application-notes-technical-guides/application-bulletins/ab-022-pwm-frequency-for-linear-motion-control just above the sentence: Therefore the minimal pulse width should be longer than: they write 56us, and just below that sentence its 5.6us...which is it?
[08:55:58] <LeoNerd> OK... So I have the avr-libc source here. There's two entirely separate vfprintf() functions, ifdef-switched. One for minimal, the other for normal or normal+float
[08:56:08] <aandrew> sounds right
[08:57:20] <LeoNerd> Hmm.. I wonder if it would be possible to statically analyse my .c files and observe that every call to *printf is made with a compiletime-static format string, so the analyser could detech which features I actually use, and include only the smallest implementation that provides them
[08:59:04] <aandrew> minimal is already pretty small isn't it?
[09:12:54] * LeoNerd reads about the SPGM stream flag on FILE* and wishes he hadn't
[09:13:09] <aandrew> spgm?
[09:13:17] <aandrew> I don't want to read it if it makes me unhappy
[09:13:48] <LeoNerd> It's the way the core of libc identifies vfprintf() from vfprintf_P()
[09:14:00] <LeoNerd> The latter temporarily sets the SPGM flag on the FILE* stream you're printing to
[09:27:05] <LeoNerd> Huh... so interesting upshot: using *printf_P() doesn't actually eat basically any more flash, because the generic vfprintf() implements the _P() form with an internal flag
[09:34:08] <LeoNerd> Aha... so.. upshot: the minimal version of *printf() supports all of the non-float formats (csSdiuopxX), only the # flag, no other flags, no padding or width specifiers.
[09:34:25] <LeoNerd> Which is awkward because there's just a couple of places I do %02X
[09:34:42] <lorenzo> yay
[09:34:50] <lorenzo> I've managed to program an at89s52 via sdcc + avrdude + usbasp
[09:35:19] <LeoNerd> Ooh.. sdcc on an AVR?
[09:36:17] <lorenzo> it's an 8051
[09:36:24] <LeoNerd> Ahh
[09:36:31] <lorenzo> but it seems like the avr toolchain can be "hacked" to talk with it
[09:37:28] <LeoNerd> Well, neither avrdude nor the usbasp or similar programmers would care what the meaning of the flash bytes actually is
[09:37:39] <LeoNerd> So if the chip still talks the AVR ISP protocol, why not? :)
[09:38:26] <lorenzo> hehe yeah
[09:38:45] <lorenzo> also I think this is the most useless microcontroller ever
[09:38:56] <lorenzo> http://www.atmel.com/images/doc1919.pdf
[09:39:02] <lorenzo> no peripherials, nothing :D except a uart
[09:39:09] <LeoNerd> Sounds like the tiny2313
[09:39:22] <LeoNerd> Ohwait... the tiny also has a USI
[09:40:17] <LeoNerd> Make a great keyboard matrix scanner. 17 GPIO lines.. two or three for I²C port + optional IRQ line, and dedicate the rest to scanning a keypad matrix
[09:40:30] <lorenzo> yeah, or a display driver
[09:40:38] <lorenzo> serial in, hd44780 out :D
[09:40:38] <LeoNerd> Mm.. that too
[09:40:53] <lorenzo> the $5 development board I've got for this has headers for a hd44780 and a lcd12864
[09:41:10] <LeoNerd> Actually, I'm using one as a bizarre thing... it's an LED matrix scanner. It snoops on the matrix control lines of another matrix driver, and tries to reconstruct what's on the LED display
[09:43:13] <lorenzo> an 8051?
[09:43:34] <LeoNerd> No; a tiny2313
[09:43:44] <lorenzo> ahh
[09:44:37] <Jartza> ahh
[09:44:39] <Jartza> another win for arm
[09:45:01] <Jartza> memory mapped flash and ram, code can be ran from either memory
[09:45:23] <Jartza> no need for those pgm_barf_few_bytes()-functions :)
[09:46:01] <lorenzo> Jartza: I'll soon be using this "feature" for a function generator (storing a looong sine table)
[09:47:01] <LeoNerd> I'm still waiting for a *tiny chip with a tuneable bit direction on the USI module
[09:47:08] <LeoNerd> I don't think it'd take too much effort to add, silicon-wise
[09:47:30] <LeoNerd> It's just otherwise awkward to reverse the bit direction in software
[09:47:48] <Jartza> yea, that's strange stuff in USI
[09:48:32] <LeoNerd> Problem is there's not a single spare bit in the control registers.. so it'd need a second CR to store that bit :/
[09:57:23] <cehteh> i'll give USI serial a try sometime next, reversing a byte isnt that complicated, but lets see how much fun that is with startbits/stopbits and still stay in sync
[09:58:53] <LeoNerd> How would you reverse it?
[09:59:21] <LeoNerd> I can think of either 8 rotate/shift instructions, or some sort of table lookup
[10:02:05] <cehteh> yes
[10:02:21] <LeoNerd> http://www.avrfreaks.net/forum/reverse-bit-order-byte?page=all discusses at length
[10:02:23] <cehteh> prolly a 16byts table and rotate per nibble
[10:02:49] <cehteh> there are some other ways with more or less complexity
[10:03:13] <cehteh> nibble wise sounds like the best compromise to me
[10:03:58] <cehteh> http://graphics.stanford.edu/~seander/bithacks.html << you want that in your bookmarks
[10:06:22] <LeoNerd> Ahyes.. table lookup, SWAP, table lookup
[10:06:41] <cehteh> but as i saied, i think stuffing the start/stopbits will become the harder part, have to read the USI specs, i'd really like to avoid any software busy loop, can one reprogram the USI to send 2 or 3 bits on the fly? .. to be figured out
[10:08:27] <LeoNerd> start/stop bits are easy eonugh on USI
[10:08:44] <LeoNerd> Yes; the USI uses a counter.. it counts down from the programmed value until zero
[10:08:53] <LeoNerd> So you can send 2 or 3 bits by programming the counter
[10:09:02] <LeoNerd> Oh, I misrecall; it counts upwards until overflow.
[10:09:06] <LeoNerd> but anyway- same effect
[10:10:20] <cehteh> ah then it becomes really easy
[10:10:55] <LeoNerd> Yes.. the USI is nice, all apart from its fixed bitwise endian nature. :/
[10:12:10] <cehteh> and the lookup table can be either 15 bytes .. (no need for 0, storing reversed value as 8 bit entity 1=128, 2=64, 3=192..) or only 7bytes, storing nibbles only, but needs an additional shift
[10:13:01] <cehteh> esp with the 16 byte table it should be reasonable efficent
[10:13:07] <cehteh> 15byte
[10:13:33] <LeoNerd> Yah; I think the extra CPU cycles to do a 15 entry table aren't worth it.. one more flash byte is peanuts on that. You'd save more flash space on omitting the code
[10:13:54] <cehteh> yes
[10:14:28] <cehteh> when one has reallyy much flash leftover then of course a 255 byte table will be the fastest
[10:14:41] <LeoNerd> Mm true
[10:14:50] <cehteh> but that costs a lot
[10:15:02] <LeoNerd> Though given the sorts of devices this is most likely to run on (ATtiny chips with a USI), having spare flash seems unlikely :)
[10:15:13] <cehteh> yep
[10:15:26] <cehteh> thats why i was thinking he nibble reverse is the best compromise
[10:16:57] <cehteh> also small queue for the interrupts and push already reversed bytes on that queue, then timing is less critical and the interrupt handlers are very very small
[10:18:17] <cehteh> i have a queue implentation here which has one byte overhead, plus queue size bytes (which doesnt need to be power of 2)
[10:18:57] <cehteh> 3 byte queue + 1 byte usi buffer .. ought to be enouh
[10:22:36] <julius> is it true that timer2 on the atmega8/168 can only do phase corrected pwm with a fixed top value?
[10:22:52] <julius> meaning, that there are only a few possible pwm frequencys?
[10:22:55] <cehteh> i havent read the datasheet
[10:27:04] <cehteh> but i somehow doubt that,
[10:28:09] <cehteh> the diagram on page 129 of the datasheet already shows otherwise
[10:29:37] <cehteh> wow it has a shitload of wgm modes
[10:29:48] <cehteh> which one do you use?
[10:31:04] <cehteh> and why do you need phase correct? its another project not just this water pump?
[10:33:12] <Jartza> LeoNerd: you need bigger AVR ;)
[10:33:26] <Jartza> just wire like PORTA to PORTB, but in reverse :)
[10:33:41] <Jartza> so PB0 <-> PA7, PB1 <-> PA6 etc :)
[10:34:04] <Jartza> then you just write the value to PORTA and read from PINB :)
[10:34:09] <Jartza> fastest byte reverse
[10:34:30] <LeoNerd> Hah :)
[10:34:35] <LeoNerd> Yes.. that's *a* solution
[10:34:59] <Jartza> only wastes 16 pins but whatta heck
[10:37:24] <cehteh> Jartza: woudlnt you use a single tiny6 to do that?
[10:37:58] <cehteh> 3 pins ... in/out/clock
[10:38:49] <cehteh> actually i know from someone in the 80's or 90's connected a PC floppy disk to an atari computer .. but had different endianess
[10:39:11] <cehteh> swapped in hardware by crimping the flat cable swapped
[11:45:42] <julius> cehteh, youre right. it does
[11:45:56] <julius> cehteh, currently i use timer2
[11:46:07] <julius> oh, thats timer1 on 128
[11:46:43] <cehteh> oops yesterday you used the 16 bit timer :D
[11:46:52] <cehteh> make up your mind :D
[11:47:55] <cehteh> looks then like you are right .. but why do you need phase correct pwm?
[11:48:14] <cehteh> for just driving a single pump DC motor its not really important
[11:50:05] <cehteh> still page 160 .. wgm mode 2, 5, 7 ... all use ORCA as TOP
[11:50:25] <cehteh> 5 is phase correct
[11:52:06] <aandrew> hm
[11:52:10] <aandrew> am I missing somehting?
[11:52:23] <aandrew> USART can do either MSB first or LSB first bit order
[11:52:32] <aandrew> looking at chapter 15 of AT2313a
[11:52:45] <cehteh> other tinys have USI .. thats not USART
[11:53:11] <aandrew> ah
[11:53:33] <cehteh> in some ways more verstatile .. its basically just a shift register. counter, interrupt
[11:53:42] <cehteh> but needs more software to handle things
[11:53:44] <aandrew> yes
[11:53:47] <aandrew> I've used USI many times
[11:53:54] <cehteh> and has this stupid direction limitation
[11:53:54] <aandrew> I haven't abused it like Jartza does, but still
[11:57:46] <julius> cehteh, timer1 reads the moist sensor, that works.
[11:57:58] <julius> now im experimenting further with pwm
[11:59:11] <julius> on page 131 in the atmega168 manual it says; pwm_frequency = clock / (2*n*top) so it would be top = clock / (2*n*pwm_frequency) to get the right top value for a given freq?
[12:06:16] <cehteh> hum ... suppose your math works then yes :D
[12:09:04] <cehteh> note that you loose pwm resolution when you reduce the top .. and 256 isnt that much already
[12:10:50] <julius> true, but it will be enough for the motor
[12:11:39] <julius> the questions is what values do actually change the motor, at 100% resolution its every number that fits between 0 and 255. but with less resolution...?
[12:11:42] <cehteh> depends
[12:12:15] <cehteh> for a multicopter you want/have finer control than 256 steps for the motors
[12:12:25] <cehteh> but thats something completely different
[12:12:44] <julius> true
[12:13:39] <cehteh> usually there is some usable range esp for DC motors
[12:14:00] <cehteh> it wont spin well at low duty cycles esp not start up because of friction
[12:15:36] <cehteh> also in the high ranges the differences may not make a big difference, except the last final step where you turn it fully on (100%) may be noticeable
[12:18:32] <julius> i already played around with a smaller 35ma motor, it reacted kinda well to just changing the duty cycle
[12:18:38] <julius> i believe i was running at 4khz
[12:19:09] <julius> i cant find the calculation for phase/freq correct pwm for timer2 :(
[12:19:27] <julius> i mean what frequency i will get with different top values
[12:21:06] <cehteh> iirc its just half the speed of normal mode
[12:21:13] <cehteh> counter goes up and down
[12:21:31] <cehteh> but .. really .. why do you need phase correct pwm?
[12:22:18] <julius> just testing
[12:22:31] <julius> i read that it is recommendate for dc motors
[12:22:38] <julius> recommend
[12:23:10] <cehteh> if you have some bigger motor and a controll loop which regulates the speed and you sense RPM .. then it makes sense
[12:23:39] <cehteh> or when you want to do very fast changes in RPM
[12:26:08] <julius> ah ok
[12:26:28] <julius> so fast pwm will do the trick just fine?
[12:26:41] <cehteh> yes .. but not too fast
[12:26:50] <julius> 1khz-20khz?
[12:27:03] <cehteh> usually you pick a pwm frequency out of the audible range and good
[12:27:20] <cehteh> one can do a lot calculations whats the optimal for a motor
[12:27:33] <cehteh> but thats far beyond what i can do :D
[12:27:57] <julius> so something above 20k?
[12:28:04] <cehteh> 16k
[12:30:25] <julius> lets see if OC2A outputs what i expect....well lets see if the motor turns, no freq counter here
[12:30:49] <cehteh> i'd just pick the pwm frewq by prescaler when driving a motor
[12:30:50] <julius> although one could use another timer to count the pulses and read that via bluetooth
[12:30:59] <cehteh> leave top to MAX
[12:31:57] <cehteh> add some feed forward loop and config vars to get the motor spinning
[12:32:41] <julius> yeah, youre probably right
[12:33:01] <cehteh> like switching the motor on from 0% to 5% would rather put 20% onto it and reduce that to 5% quickly
[12:33:13] <julius> yes i believe we talked about that
[12:33:19] <julius> start fast and then reduce
[12:33:22] <cehteh> when you sense the rpm then you want a PID
[12:33:38] <cehteh> possibly with feed forward too
[12:33:46] <cehteh> yes
[12:34:04] <julius> for now i will just get the pump running for a few seconds, wait 10s, let the moist sensor do a measurement, pump again if needed
[12:34:47] <cehteh> how long are the tubes?
[12:35:01] <cehteh> you have to accout to fill them with water
[12:35:22] <julius> early in the morning i learned that a mosfet can charge its gate without pulldown resistor if nothing is connected to the gate....that was a surprise for my floor
[12:35:32] <cehteh> for my (unfinished) watering system i planned to add a nozzle at the end and dont regulate the pumps
[12:35:52] <cehteh> if there is any air in the tubes it will be pressed out much faster than water flows
[12:36:04] <cehteh> hah
[12:36:05] <julius> yep, already cut the input line...its about 15cm now. still playing around with what the pump can take
[12:36:31] <cehteh> i told you add a pulldown .. but in that case to the driver, because your mosfet should always be connected to the driver
[12:36:42] <julius> oh, forgot that
[12:36:55] <cehteh> more surprisingly is that the charges of the gates can last very long
[12:37:05] <julius> yeah, lets say i added a driver ;)
[12:37:13] <cehteh> depending on the circrruit connected there .. hours to days
[12:37:49] <cehteh> leave the gate floating .. mosfet will do surprising things
[12:40:30] <cehteh> even on high-z configured output pins the charges will last very long, thats why configuring internal pullups for outputs which drive mosfets and possibly some desaster things is a bad idea, always add external pullup or pulldown for those
[12:40:59] <julius> yes yoda
[12:41:04] <julius> much to learn i have
[12:41:34] <cehteh> :D
[12:50:24] <julius> PWM_fequency = clock_speed / (Prescaller_value * 256) <- for fastpwm, with prescalar 1 thats 65khz, with prescalar 8 thats 7khz
[12:50:35] <julius> is 65 to fast?
[12:57:01] <cehteh> possibly
[12:57:04] <cehteh> try it
[12:57:50] <cehteh> its more about losses in the mostfet then
[12:58:27] <cehteh> and of course your driver (or did you connect the mosfet directly to the atmega?)
[12:59:00] <julius> guess
[12:59:07] <cehteh> you can add a small resistor (20-50Ohms or so) to the gate
[12:59:14] <julius> yes
[12:59:14] <twnqx> s/could/should/
[12:59:17] <cehteh> that limits the charge/discharge current to the gate
[12:59:32] <cehteh> makes it slower but will protect the µC output
[13:00:38] <cehteh> when anything starts smoking it was too much :)
[13:00:45] <julius> i bought the mosfet, later on i read that through capacitance it can actually pull in up to 1a - much more than the avr can provide. after that i looked into drivers, but wasnt sure which one to get. docs werent really clear if they work with high pwm frequencys
[13:01:36] <cehteh> with manual switching and slow pwm thats usually not a big problem (with small!!) mosfets
[13:01:42] <julius> i also added a bc547b which worked, but read that it will be to slow for high frequencys
[13:01:53] <cehteh> likely
[13:02:05] <cehteh> well go for 7khz then
[13:02:09] <cehteh> that should work
[13:02:17] <julius> is there a goto driver you just use for <10khz?
[13:03:12] <cehteh> duno i used logic level fets with gate directly at the µC so far
[13:03:59] <cehteh> i have some ULN2003 here .. dunno how fast they are, would have to check the datasheet
[13:04:18] <cehteh> just wanted some generic drivers for small currents
[13:09:24] <cehteh> mhm 1µs turn on/turn off .. possibly too slow, i am to lazy to d the math
[13:13:22] <julius> no problem, will do that in a few days
[13:13:53] <julius> what logic level mosfets do you remember with around 10a of current?
[13:14:16] <cehteh> irlu024n
[13:14:21] <cehteh> reichelt
[13:14:42] <theBear> bless you
[13:14:52] <cehteh> www.reichelt.de/IRLU-024N/3/index.html?&ACTION=3&LA=446&ARTICLE=90365&artnr=IRLU+024N
[13:15:24] * twnqx just got some fancy not-logic-level ones :3
[13:16:52] <cehteh> i once picked them quite randomly (smaller than to220, logic level, okish price) dunno if they are really the most appobiate
[13:16:59] <cehteh> just work for me so far
[13:17:30] <cehteh> other people here are prolly more experienced on picking mosfets for specific applications
[13:17:32] <julius> yeah, looks like a TTL
[13:18:07] <julius> twnqx, and with what do you torture youre mosfests?
[13:18:59] <cehteh> yes some fast driver for mosfets w/o external components would be a good
[13:19:40] <julius> just ported my fastpwm mega8 code from home to my current atmega168 here, the 168 doesnt care...damnit
[13:20:29] <cehteh> :D
[13:21:19] <cehteh> bonus points for a mosfet driver with charge pump for all nfet complementatry switching
[13:24:02] <cehteh> https://upload.wikimedia.org/wikipedia/commons/7/72/Gatetreiber_diskret_highside.PNG
[13:24:29] <julius> i elect the next person to join this channel for the position of official mosfet driver expert
[13:25:44] <theBear> but but, i'm already here, and only an avid amatuer these days, and when i was working my living income involving a lotta power fets i knew a shockingly small amount :)
[13:26:32] <cehteh> imo mostfets are considerably easier then bjt's
[13:26:43] <cehteh> usually they just work
[13:27:20] <cehteh> unless you have some special demands (high pwm rate, high voltage, high efficiency)
[13:27:20] <theBear> for a lotta things, but for example they're very impractical if not impossible to make do linear stuff remotely how you want them too without a bunch of neg feedback to keep them in check, transistor it pretty easy
[13:28:14] <cehteh> and googling helps too
[13:28:48] <cehteh> linear sux anyway .. even audio amp are meanwhile better in class-D :D
[13:31:50] <theBear> pfft, cloth ears... yer average cheap class d chip/amp is fine for low freq liek sub-amps, but you need more than a couple ghz sample/chop rate to even compete with what a cd (44.1k/16 bit (16? yeah surely 16, been a while to remember now)) d-a can output quality/accuracy wise, and i noticed a LOT without even trying/any hints that the fe whundrred khz chips shipping these days in not-cheap instrument amps and things like powered pa speakerboxes, sound
[13:31:50] <theBear> like ass !
[13:32:59] <twnqx> julius: i am fixing some broken down things in my car amp...
[13:33:08] <twnqx> these are for a step-up voltage regulator
[13:33:38] <twnqx> audi: "you need a new amp. 1260€ + taxes please"
[13:33:57] <twnqx> ecu repair service: "unfixable. we can offer you a used amp for 750€ + installation"
[13:34:02] <cehteh> theBear: okok :D .. dont the even use fancy things, tubes, magnetrons etc for such stuff
[13:34:05] <twnqx> http://imgur.com/txYXdOt is my idea of it
[13:34:09] <theBear> ooh, have fun with that... switchey psu power amps like all the big car ones i ever seen/looked closely at, are in my professional opinion one of the trickiest pwoeramp repairs you can do
[13:35:41] <theBear> cehteh, heh, the low and mid end modern-priced (aka cchina forced everyone to be good prices but tight on budgets) audio gear ? yeah of rcourse thhey got multi ghz capable non-solidstate magic bottles and suepr elegant centrifugal resonant
[13:35:43] <cehteh> twnqx: oh now we have your customer, invoice, whatever number... lets see
[13:35:50] <theBear> chambers to fiter it :)
[13:35:51] <twnqx> hf
[13:36:09] <theBear> 1260 ? how the eff big, oh eu brand PLUS high end one
[13:36:13] <twnqx> btw, it's prepay :D
[13:36:21] <twnqx> yeah, bang & olufson amp
[13:36:31] <twnqx> olofson? whatever
[13:36:47] <theBear> twnqx, you know if it comes to it should be trivial to wire up a 3rd party one hidden away, probly cost under 100 bucks these days and be equally good
[13:36:55] <twnqx> not really
[13:37:02] <theBear> yes really
[13:37:04] <twnqx> MOST bus is tricky, can't even get specs for it
[13:37:10] <twnqx> also
[13:37:11] <theBear> oh, so it not just a amp
[13:37:47] <twnqx> yeah... optical in, 10 speakers out
[13:37:54] <theBear> i wasn't suggesting not to fix earlier btw, just that switching psu amps are an arkward issue to approach any way when they semi-working
[13:38:05] <twnqx> but it's the amp board. i can get a used one from ebay and just swap the amplifier / power regulator board
[13:38:11] <theBear> holy crap ! that's a crazy number of speakers, and some fancy tech, for a car :)
[13:38:28] <twnqx> and it was just a gate oxide breakdown
[13:38:34] <twnqx> 12V OUT from the gate of the mosfet...
[13:38:58] <theBear> you sure it the amp ? you got solid rails and stuff ? whether push-pull or switchey, discrete or modules, the amp end should be fairly trivial to fix if you still got solid/not-shutting-down-loop input voltage
[13:39:12] <theBear> or i shoudl say only the amp
[13:39:14] <twnqx> only the supply for the analog amplifiers is gone
[13:39:20] <twnqx> device still talks on the bus etc
[13:39:37] <twnqx> once i have the supply back i will see if the amp chips are gone :P
[13:39:58] <cehteh> theBear:
https://upload.wikimedia.org/wikipedia/commons/thumb/9/97/Spectrum_Analyser_PCB.jpg/1024px-Spectrum_Analyser_PCB.jpg
[13:40:02] <twnqx> i don't even know what voltage it should have, but i could see the voltage coming out from the disabled power supply rail of the switcher :X
[13:40:13] <twnqx> the battery voltage :X
[13:40:19] <cehteh> thats somw awesome pcb .. with a lot fairy dust
[13:40:38] <twnqx> and some parts probably weren't even broken (the small transistor, e.g.)
[13:40:46] <theBear> mmm, supply see, that's where it gets tricky, big ugly power stages hanging off an often oscillating to some degree/rate psu... makes the testing/halfway-repaired zone a challenge technically
[13:40:58] <twnqx> yeah
[13:41:07] <theBear> twnqx, it linear or little tda/something class d modules per output ?
[13:41:16] <theBear> lol "the" small transistor
[13:41:21] <twnqx> 2 stereo class d for the bass
[13:41:26] <twnqx> yeah, the NPN
[13:41:30] <theBear> spose they need a token small one for diversity laws
[13:41:35] <twnqx> errr PNP
[13:41:53] <twnqx> no, that one is supposed to cut the supply to the switching controller
[13:42:15] <twnqx> was pretty surprised to see the voltage still being there after i removed it :X
[13:43:01] <theBear> if it a seperate amp-only board, just resistance-meter can tell you a lot if there big problems, and a v/i curvetracer aka "component tester" in the oldendays, is almost always enough to be 99% sure wjat is going on in a psu-disconnected/standalone pit[it stages
[13:43:17] <twnqx> well
[13:43:25] <twnqx> i cut see 12V out the gate of the mosfet
[13:43:30] <twnqx> after i removed the IC.
[13:43:33] <twnqx> could see*
[13:43:33] <theBear> don't you mean IN the gate ?
[13:43:36] <twnqx> no.
[13:43:42] <theBear> oh, of course, broken
[13:43:47] <twnqx> the mosfet is straight between 12V and GND
[13:43:52] <theBear> sorry, i'm way outta form circuit repair wise
[13:44:00] <twnqx> and there only was a 10k resistor from gate to gnd
[13:44:12] <twnqx> and it had 12V left X:
[13:44:17] <twnqx> so yeah...
[13:44:24] <twnqx> replacing and see what happens
[13:44:38] <twnqx> other end of the mosfet is just a transformer for step-up
[13:44:40] <theBear> and you sure that isn't normal (all in-circuit and pulled down and stuff) just woulda been stuck on ? cos that along shouldn't kill any amp
[13:44:58] <twnqx> yeah, the amp stage didn't receive any power
[13:45:14] <twnqx> the voltage divider of 10k:switcher controller made it just under 9V
[13:45:24] <twnqx> which triggered the undervoltage lockout
[13:45:38] <theBear> a good "trick" for finding/testing leaky/soon-dead/faulty at high power output fet stages, probly any mosfet stages, is measuring across the gate series resistor and looking for ANY noticable voltage
[13:47:03] <theBear> doesn't hurt to watch a scope whileyou do it tho, a lotta designs/setups the fets will go a bit "oscillate SUPERfast"and expode in moemnts
[13:47:04] <cehteh> mhm will memmove(address, address, size) be a no-op or iterate over the whole data?
[13:47:24] <theBear> wll, quietly crack the die inside from gradient/heat related stress
[13:47:48] <theBear> cehteh, got some rough details, like arch and what memmove does ?
[13:48:11] <cehteh> avr-libc .. i just looking at the source
[13:48:29] <cehteh> i mean when dest == source
[13:48:43] <cehteh> it could make a special case for that and just return
[13:48:45] <theBear> and why ? something about audio oh, that makes a lot more sense
[13:49:32] <theBear> and with the level of awesome modern gccs are optimising these days (apparently this new 5.x is another BIGstep uin that area too)
[13:50:16] <cehteh> ok it memmove calls memcpy .. and always iterates
[13:50:48] <twnqx`> i hate myself
[13:50:50] <cehteh> i just add a check, that shall be more sane
[13:50:56] <twnqx`> now i forgot i have 0 battery in this laptop
[13:50:57] <theBear> with all that i would expect optimizing it ou.. can always write up/somehow mark/index a very simple test-program/file and observe the hex/raw-machinecode(asm) output with/without, and/or with various optionms/caches wiggled
[13:50:59] <twnqx`> ...
[13:51:21] <cehteh> it cant be optimized out .. the addresses are of course variable
[13:51:34] <cehteh> and memmove/memcpy are implemented in assembler
[13:52:22] <cehteh> i just happen that there may cases where source == dest, not always, but in some cases, then i dont need to move at all
[13:53:47] <cehteh> ok i leave that for tomorrow .. cu
[13:54:15] <theBear> from what you told me/us so far, and what you wrote for example, the addresses may not be variable, and are always equal anyway
[13:54:18] <theBear> cya :)
[14:07:30] <cehteh> .. eh that was easier than i thought, just a few lines and utf8 support on my line editor is complete :D
[14:07:37] <cehteh> finally off now cu
[14:07:57] <theBear> cool, and aiight
[14:13:52] <julius> twnqx`, yes. the manufactor sticks you up the ass, then tells you what he wants, and if you lucky releases it quickly
[14:15:42] <theBear> twnqx`, hehe, and don't feel bad, i done that several times just today, and not only cos of the amount of laptop(s) i been messing about on/with
[14:19:27] <julius> i wonder how the guys at atmel think
[14:20:27] <julius> lets make a easy to use chip for the customer, lets use OCR2A and maybe TCCR2A and...nonono, that looks to easy
[14:20:30] <julius> lets mix in a B
[14:20:45] <julius> TCCR2B...yes thats it, now it looks complete
[14:21:52] <theBear> heh, it's fun when you "porting" some code to a last/next gen chip, even a very similar/"matching-model" in the other series... finding things like that and just plain whole register names completely changed while the bits/values they represent and/or set ARE identical
[14:22:43] <theBear> lotta search and replacing when i did maybe mega328 -> old series mega8 or mega16 maybe... if i turned around on this spinny chair i could litearlly know by now
[14:42:20] <julius> true
[14:42:41] <julius> the mind has to accept that there is torture involved, not just work
[17:42:41] <LeoNerd> Hrm. Trying to measure my battery voltage by the usual trick of setting ADREF to AVcc and ADMUX to Internal 1.1V bandgap.
[17:43:16] <LeoNerd> (on a mega328P). It seems to work the second and subsequent times I do it, but not the first. Even if I put a big delay in after selecting the channels, taking a couple of readings, discarding them
[17:43:22] <LeoNerd> I'm not quite sure I understand why.
[17:50:18] <julius> it works the second time .....but if you discard readings it does not work?
[17:50:33] <julius> how do you define second time
[17:53:20] <LeoNerd> The second entire time I call the code
[17:54:01] <julius> so throw away the first results up to the point where you call it again
[17:54:11] <LeoNerd> which consists of a MUX setting, one conversion that I throw away, then two more conversions that I add together to form an 11bit value
[17:54:25] <julius> and post the question on avrfreaks or stackexchange
[19:26:31] <jacekowski> LeoNerd: sounds like something isn't set in correct order maybe
[19:29:19] <LeoNerd> It's not that it doesn't work at all, it's just I get an unreliable reading
[19:33:23] <Casper> LeoNerd: the datasheet usually say to discard the first conversion
[19:34:03] <LeoNerd> Yes, first conversion. I was doing that. Didn't help.
[19:34:09] <LeoNerd> This way I'm discarding about the first four.
[19:35:20] <Casper> probably code bug somewhere
[19:35:34] <Casper> hmmm
[19:35:46] <Casper> do you have a capacitor on the AREF ?
[19:52:01] <LeoNerd> Yes
[19:52:12] <LeoNerd> (now... didn't earlier <.< )
