Back
[00:37:27] <sabor> dgriffi: here is my version:
https://paste.apache.org/f4e8
[00:38:08] <sabor> not completely finished, but a design without busy-wait and ready to do some real work...
[00:38:34] <dgriffi> sabor: hmm... I came up with this:
http://pastebin.com/5VZxGm13
[00:39:09] <dgriffi> seems to produce a good sine. Now I'm trying to figure out how to remove the buzzing PWM artifacts
[00:41:02] <dgriffi> what should the corner frequency of the filter be?
[00:41:36] <sabor> depends on the sample rate
[00:41:50] <dgriffi> I'm afraid I don't know it
[00:42:49] <sabor> ofcourse you know it, it's the timer overflow rate
[00:43:06] <sabor> this is F_CPU / prescaler / 256
[00:43:52] <sabor> if the timer is running at full speed its around 62kHz
[00:44:18] <sabor> so everything above 31kHz has to be filtered out
[00:44:48] <sabor> so you would design a low pass filter for maybe 15kHz
[00:45:43] <sabor> but if you use a prescaler != 1, for example 8 then the overflow frequency is around 8kHz, so the filter must be below 4kHz
[00:46:34] <dgriffi> I'm using a prescaler of 1x
[00:47:37] <dgriffi> why won't using a corner freq of 2800 work since I expect the sine wave to be no more than 2700?
[00:55:26] <carabia> Oh, that was funny. I figured fatfs would do lfn allocating by itself but apparently it doesn't. Bedtime now, laters
[00:56:00] <theBear> for a start the corner freq is marked/lives at -3dB on the start of the rolloff, so hmmm, assuming 6dB/oct you would need ummm, i think this works out 2 logs parallel is linmath, so 3dB would be half a octave or 1/4 away from the corner freq, so if 2800 was your (filter) number, err 700 would be half an octave down, so that's ummm, 2100 would be the last/highest freq unaffected level- wise ( and i suspect phase-wise in relation to all the other stuff
[00:56:01] <theBear> lower than itself too, which may be desirable here, from the thru past the 2800 mark the phase will be all over the shop, even worse if you recombining after the filter somehow
[00:56:20] <theBear> wonder what they means by allocating
[00:56:53] <theBear> lfn's are more of a index/lookup table than, well, from memory that's exactly what they are, no more or less, :-)
[00:57:58] <theBear> wouldn't even be surprised if they're completely independant/seperate from the fat standard/spec... no need for them not to be, might even be more "proper" that they aren't
[02:38:30] <mangul> how do i program my atmega8 by myself?not by computer, i dont have it
[02:51:08] <Levitator> You don't have a computer?
[02:54:31] <Levitator> Most bridges I have seen are USB-based, so you could use anything that is a USB host and can compile the AVR toolchain.
[02:54:53] <Levitator> So, probably a Raspberry Pi, which cost about $30. Some smartphones might be able to do it.
[02:56:45] <Levitator> Heh. Or see if you can find a Bluetooth->TTL converter, and then all you need is a phone that will run the toolchain, USB or not.
[03:01:31] <mangul> Levitator, what i can have is an atmega8, many simple electronic tools or objects, a breadboard, my program in binary form
[03:01:52] <Levitator> How did you get your program into binary form without a computer?
[03:23:03] <cousin_luigi> Greetings.
[03:23:32] * cousin_luigi hooked up a ft232rl breakout board and dumped its eeprom, but he can't find any reference on what to change to enable bitbang mode
[03:24:29] <Levitator> https://www.youtube.com/watch?v=xWYwY8GpuO0
[03:25:35] <cousin_luigi> What on Earth is that?
[03:25:39] <Levitator> I didn't know those were even programmable, though I guess it's not surprising.
[03:27:33] <Levitator> Google for Songsmith to discover the chilling truth.
[03:28:12] <cousin_luigi> Man, are you high?
[03:28:28] <Levitator> It only gets better from there:
https://www.youtube.com/watch?v=D8FGvPw6JbI
[03:29:12] <cousin_luigi> carabia: hello
[04:02:56] <dgriffi> sabor: are you around?
[04:03:48] <dgriffi> sabor: I've got a new problem with my beeping code. It won't generate tones above 1032 hertz or so
[04:07:07] <sabor> dgriffi: hmm...
[04:08:22] <dgriffi> here's the latest:
http://pastebin.com/B5AY7GcP
[04:08:30] <Levitator> Weird. Should have about 15500 cycles to use between pulses if you are banging the output.
[04:08:39] <Levitator> Like, in a loop, without interrupts.
[04:09:18] <sabor> dgriffi: it might have something to do with how you calculate the next sample value
[04:09:35] <dgriffi> sabor: I'm sure I'm overflowing something somewhere
[04:10:06] <sabor> dgriffi: are you still using the same sine table?
[04:11:34] <sabor> dgriffi: IIRC this sine table contained values between 0x00 and 0x80, so if you add these values when creating two tones you get sample values between 0x00 and 0x0100 which is again 0x00
[04:12:07] <sabor> but that will probably only give some distortion
[04:13:33] <dgriffi> the sine table is now 0x7E (126) maximum
[04:13:49] <sabor> good :)
[04:14:15] <dgriffi> doing that took care of the buzz I heard earlier, but now that I tried other frequences, I get a low hum above 1032 or so
[04:14:56] <dgriffi> I tried putting the tone_place_x and tone_step_x variables as uint32_t, but that resulted in the first tone played going on forever
[04:19:23] <sabor> i don't see an obvious bug yet
[04:19:38] <sabor> just a few things i would do differently
[04:19:42] <dgriffi> why would using uint32_t cause it to go on and on?
[04:20:12] <sabor> if you use a sine table containing 256 values you save a lot of cpu cycles
[04:26:53] <dgriffi> actually, no
[04:27:05] <sabor> in such cases i create a test routine which calculates a few points and outputs th values over a serial port
[04:29:25] <dgriffi> ah! the exact point it stops playing is 1029. 1028 and below works
[04:30:39] <sabor> yeah, i wanted to make a new guess and calculated that ;)
[04:31:04] <sabor> 255*1028 - 1024*256 = -4
[04:31:28] <dgriffi> setting STEP_SHIFT to 8 resulted in lower actual frequencies played... but still when 1029 is specified, it's quiet
[04:31:30] <sabor> so the next value overflows the calculation
[04:32:45] <sabor> hmm, STEP_SHIFT shouldn't change the frequencies if it's used in all calculations
[04:36:20] <sabor> it seems to overflow a 32bit value
[04:37:29] <dgriffi> what is "millis" in the code you sent me a couple hours ago?
[04:38:37] <sabor> a typo, should be milliseconds
[04:40:56] <sabor> my code has the same calculation with the same bug
[04:41:01] <dgriffi> after I corrected the other typos in your code, I get frequencies too low and the same bug
[04:41:06] <sabor> we should optimize that calculation
[04:41:13] <sabor> hehe
[04:41:32] <sabor> one option is a frequency table listing thos frequencies you need
[04:42:16] <dgriffi> ugh..., I don't want to do that
[04:42:20] <sabor> another option is creating a multiplicator from all those constants
[04:42:36] <sabor> something like that might work:
[04:44:15] <sabor> tone.step = freq * (SINE_SAMPLES * CLK_CYCLES_PER_SAMPLE * 256 / (F_CPU / 256) );
[04:44:31] <sabor> hmm, is this right?
[04:44:36] <dgriffi> hmm.. less hairy than I was imagining
[04:45:18] <dgriffi> you're putting a dot instead of underscore again
[04:45:37] <sabor> ooh, right
[04:46:11] <sabor> tone_step = (freq * (SINE_SAMPLES * CLK_CYCLES_PER_SAMPLE * 256 / (F_CPU / 256) )) / 256;
[04:46:14] <dgriffi> what's CLK_CYCLES_PER_SAMPLE? TICKS_PER_CYCLE?
[04:46:17] <sabor> this maybe
[04:46:29] <sabor> yeah
[04:46:43] <sabor> it's also thet timer max value
[04:47:33] <dgriffi> I'm getting garbage
[04:47:40] <dgriffi> high whirrs
[04:49:31] <sabor> i guess you should try a function which just uses that step as input to get some numbers which work
[04:50:52] <dgriffi> so, just what is overflowing?
[04:51:06] <sabor> then we have some results for this calculation
[04:52:16] <sabor> try just this: void play( ..., uint32_t freq) { ... step = freq; ... }
[04:52:43] <dgriffi> are we looking at your code?
[04:54:32] <sabor> doesn't matter which one, both do more or less the same
[04:55:39] <sabor> in my code you would just change the calculation to: tone_step = freq;
[04:56:53] <dgriffi> okay, just doing step = freq results in tones way too high, but for a value of 1029, it does play
[04:57:26] <sabor> then call it a few times: play( 461, 500 ); play( 922, 500 ); play( 1845, 500 ); play( 3690, 500 ); sleep_ms( 1000 );
[04:58:05] <sabor> i guess i need a speaker to try this too...
[04:58:22] <dgriffi> I've been doing 440,350 700,700 (ie one tone) 700,1029 and 1029,1029
[04:58:58] <dgriffi> with the buggy code, I'd get corrent tone with pair 1 and 2.
[04:59:13] <dgriffi> then for the third I'd hear one tone (700hz) and nothing for the fourth pair
[04:59:45] <sabor> aah, very good
[04:59:52] <dgriffi> so I guess the next big question is "what's the correct value to divide by to get the correct tone?"
[05:00:17] <dgriffi> with simply step = freq, I get tones way high, but they all play.
[05:00:18] <sabor> or how do you convince the compiler to do what you really want
[05:00:24] <dgriffi> right
[05:03:56] <dgriffi> paper and pen time
[05:04:00] * dgriffi scribbles
[05:05:33] * sabor tries the code on linux
[05:06:04] <dgriffi> egad... my calculations are drifting me to floating points
[05:08:46] <dgriffi> got anything?
[05:09:15] <Levitator> My IO abstraction library is more complicated than I thought, but most of the code is for the compiler, not the MCU.
[05:09:58] <dgriffi> sabor: this is confounding... shouldn't all that math that includes dividing by 20,000,000 be done at compile time?
[05:10:18] <dgriffi> maybe I should be explicit about that.
[05:11:59] <sabor> it's a bit difficult to not hit an overflow or a zero somewhere
[05:11:59] <dgriffi> basically, I'm looking at x = (a * b * c) / d
[05:12:09] <sabor> yeah
[05:12:25] <dgriffi> I think the fact that a is in that calculation, that forces it to happen at runtime and thus cause an overflow
[05:12:49] <dgriffi> so, if I extract that a and then I can do the nasty math at compile time
[05:12:55] * dgriffi scribbles more
[05:13:38] <dgriffi> damn... I forgot how to solve for this
[05:16:13] <sabor> i have something you could try:
[05:16:48] <sabor> uint32_t tmp = (SINE_SAMPLES * (TICKS_PER_CYCLE << STEP_SHIFT)) / (F_CPU / 256); tmp *= freq_a; step_a = tmp / 256;
[05:17:44] <sabor> but on linux it just works, gcc must be calculating differently on avr
[05:18:22] <Levitator> Can anyone suggest a Linux-compatible atmega328p simulator?
[05:18:43] <dgriffi> Levitator: I've tried simavr and simulavr and they both suck
[05:19:08] <Levitator> Simulavr shows "atmega8" as an option. Don't know if that encompasses the 328p.
[05:19:27] <Levitator> Well, the current Debian version, specifically.
[05:23:52] <dgriffi> sabor: that works!
[05:24:13] <sabor> magic :)
[05:24:39] <Levitator> Dies with "invalid address". Guessing atmega8 != atmega328p
[05:25:06] <sabor> yeah, there are many differences
[05:25:16] <sabor> i believe atmega8 has only 8k flash
[05:25:58] <Levitator> Sweet. This thing doesn't appear to have been updated since 2012. Well, there's a dead end.
[05:26:09] <sabor> yes, only 8k, atmega8 is more similar to atmega88
[05:27:47] <Levitator> avrsim doesn't appear to list support for the the 328p either.
[05:28:37] <Levitator> I wonder if there is some backward-compatible device I could simulate isntead.
[05:30:35] <dgriffi> sabor: odd... this doesn't work: tone_step_a = (freq_a * MAGIC_MULTIPLIER) / 256;
[05:31:24] <sabor> dgriffi: yes, somehow it overflows there somewhere
[05:31:32] <Levitator> Oh, neat. at90s2313 launched successfully.
[05:31:59] <dgriffi> sabor: this works: uint32_t tmp_a = MAGIC_MULTIPLIER; \n blah blah
[05:32:21] <dgriffi> what should I call this besides MAGIC_MULTIPLIER?
[05:32:29] <sabor> dgriffi: sometimes you have to force it to become happy ;)
[05:33:12] <sabor> isn't it something like samples-per-hz?
[05:33:56] <dgriffi> that works for me
[05:34:00] <dgriffi> SAMPLES_PER_HERTZ
[05:34:38] <sabor> just doesn't explain the /256
[05:34:55] <sabor> SAMPLES_PER_HERTZ_TIMES_256 ;)
[05:35:12] <Levitator> Oops. Just noticed that avr-gdb has an integrated simulator. Should try that first.
[05:35:38] <sabor> Levitator: really? i never heard of that, sounds cool
[05:35:49] <Levitator> Yeah "target sim".
[05:45:36] <dgriffi> well, the tones are done. now to debug the resistor ladder
[05:45:43] <dgriffi> I'm getting a lot of false triggering
[05:50:30] <sabor> maybe you should take the average of a few samples?
[05:53:03] <Levitator> Hey, do the AVRs do anything special to trap null-pointer operations?
[05:53:41] <Levitator> Like, will reading or writing *(void *)0 halt the device, or will it just corrupt something and keep going?
[05:56:59] <Lambda-Aurigae> null pointer is just a C thing.
[05:57:20] <Lambda-Aurigae> all depends on what that null pointer is used to do.
[05:57:34] <Levitator> That's like saying that memory is a C thing.
[05:57:41] <Lambda-Aurigae> no
[05:57:48] <Lambda-Aurigae> what does that null pointer compile down to?
[05:57:49] <Lambda-Aurigae> 0x00?
[05:57:58] <Lambda-Aurigae> then, what is it actually used to do?
[05:58:34] <Levitator> If you take into consideration that all of the avr registers are memory-mapped, then you will notice that it's not an unreasonable question to ask whether a device traps accesses to a specific memory location, in this case 0.
[05:59:11] <Levitator> If they wanted to, they could define an IO register at address zero which belongs to an exception-handling device that calls an ISR.
[06:01:12] <Levitator> Memory-mapping is a powerful feature. Can be a bit dangerous if you don't design your device to be failsafe under all IO conditions, since registers could be overwritten with anything.
[06:06:40] <dgriffi> egad.... the false triggering appears to be because of bad soldering
[06:07:28] <dgriffi> I had a 100K resistor pulling down the pin monitoring the resistor ladder... but apparently I botched the soldering on that connection
[06:07:57] <Lambda-Aurigae> Levitator, again, traps are not a hardware level thing, at least not on avr.
[06:08:38] <Lambda-Aurigae> rom location 0 is the reset vector
[06:08:48] <dgriffi> ohhh... even worse... I put it on the wrong damn pin!
[06:08:50] <Lambda-Aurigae> ram location 0 is actually a used register
[06:11:27] <Lambda-Aurigae> 0x00 in ram is the PINA register.
[06:13:09] <Lambda-Aurigae> remember, this is harvard architecture, so that pointer could be pointing at ram or rom depending on how it is used.
[06:16:18] <sabor> dgriffi: i guess you need a tiny with less pins ;)
[06:16:50] <dgriffi> sabor: the prototype is on perfboard. stuff like that is bound to happen
[06:17:31] <sabor> yeah, hehe]
[06:18:28] <Levitator> They can be a hardware-level thing, which is why asked.
[06:19:40] <Lambda-Aurigae> if your program jumps to 0x0000 then the chip just does a soft reset.
[06:20:13] <Lambda-Aurigae> which you can "trap" if you like in your software by looking at how the program started...whether it was done by a hardware reset, soft reset, watchdog reset, etc.
[06:20:18] <Levitator> Well, at least that traps null function pointers, in some sense.
[06:22:30] <Lambda-Aurigae> ultimately, I recommend reading the datasheet for the chip you are using...cover to cover...at least twice.
[06:22:58] <Lambda-Aurigae> this would answer a good majority of questions people ask in here.
[06:23:16] <Levitator> Another way of saying "Don't ask me shit".
[06:23:21] <Lambda-Aurigae> nope.
[06:23:24] <Lambda-Aurigae> I'm answering.
[06:23:39] <Lambda-Aurigae> I just wish more people would RTFM...it really is a very fine manual.
[06:23:41] <Levitator> I can read just fine. I ask questions in case someone else has some observation I missed.
[06:24:42] <Tom_itx> naw, you're just too lazy to read it
[06:25:07] <Levitator> Fuck you too.
[06:25:38] <Tom_itx> a little touchy this morning are we?
[06:25:48] * Lambda-Aurigae touches Tom_itx
[06:34:23] <theBear> yeah, bu ti ain't feely or grabby, and certainly in no mood for groom,ing, so you probly cool
[06:36:18] <dgriffi> new problem.... _delay_ms() seems to be running at half speed.
[06:38:07] <dgriffi> and I have verified that F_CPU is correct
[06:39:08] <Tom_itx> what about ckdiv8
[06:40:33] <dgriffi> I think I have my fuses set wrong
[06:41:12] <Tom_itx> just don't brick it
[06:42:13] <dgriffi> I have two more in reserve
[06:42:31] <Tom_itx> i'll let them know so they can hide
[06:43:19] <dgriffi> dammit... I think I bricked it
[06:43:35] <Tom_itx> in what way?
[06:43:37] <dgriffi> isn't there some special procedure I can do to get it back?
[06:43:45] <Tom_itx> external clock source
[06:43:49] <dgriffi> doesn't respond to anything I do
[06:43:54] <Tom_itx> 4x spi rate minimum
[06:44:14] <Tom_itx> see if you had my programmer you'd already have a built in clock source.
[06:44:17] <Tom_itx> i thought ahead
[06:44:30] <dgriffi> I tried to flash it with fuses of L=0xFF H=0xDF and it wouldn't take
[06:45:08] <Tom_itx> that sounds backward to me but it's been a while..
[06:45:17] <dgriffi> the fuzes that made it lock were 0x20 0xDF
[06:46:04] <Tom_itx> http://www.engbedded.com/fusecalc/
[06:46:05] <dgriffi> crap... what's a safe fuze setting for an external clock?
[06:46:13] <dgriffi> that's where I was
[06:47:10] <Tom_itx> what chip?
[06:47:15] <dgriffi> attiny85
[06:47:18] <Tom_itx> and why do you want an external clock?
[06:47:26] <dgriffi> err.. crystal
[06:48:30] <Tom_itx> LF:0X66 HF:0XDF looks ok to me
[06:49:05] <dgriffi> it's still not taking. I think this one is toast
[06:49:20] <Tom_itx> LF:0xE6 if you don't want ckdiv8
[06:49:37] <Tom_itx> just make an extenal clock source
[06:49:44] <Tom_itx> and tie it to the xtal pin
[06:49:51] <Tom_itx> you'll have to read which one
[06:51:11] <dgriffi> nah.. I'm just trying to figure out why _delay_ms() is running slow
[06:57:58] <Lambda-Aurigae> dgriffi, did you have a crystal attached to the chip?
[06:58:04] <dgriffi> yes
[06:58:09] <Lambda-Aurigae> and,how were the fuses set?
[06:58:22] <Lambda-Aurigae> and what speed crystal?
[06:58:53] <dgriffi> 0x20 0xDF and a 20mhz crystal
[06:59:28] <Lambda-Aurigae> mega328p?
[06:59:50] <dgriffi> attiny85
[07:01:31] <Lambda-Aurigae> I don't see how that could work with a 20MHz crystal.
[07:01:44] <Lambda-Aurigae> 0x20 for the low fuse sets to external clock, not crystal.
[07:03:19] <Lambda-Aurigae> http://www.engbedded.com/fusecalc/
[07:03:25] <dgriffi> I've been using that.
[07:03:37] <dgriffi> I think I got that setting by fatfingering the entries
[07:03:41] <Lambda-Aurigae> and you have a crystal and not a crystal oscillator?
[07:03:52] <dgriffi> yes. ordinary 2-pin crystal
[07:04:13] <Lambda-Aurigae> it shouldn't run with low fuse at 0x20
[07:04:36] <dgriffi> I see now. my problem now is how to get it back
[07:04:49] <Lambda-Aurigae> you need an external clock source.
[07:05:12] <Lambda-Aurigae> use a 555 or another AVR or an external clock.
[07:05:18] <Lambda-Aurigae> can oscillator
[07:05:19] <dgriffi> ugh.... I don't have the parts to make an arduino-powered debricker
[07:05:33] <Lambda-Aurigae> I didn't say anything about anything ardweeny based.
[07:05:40] <dgriffi> so I'll just put this in a tube, mark it "bricked" and use a fresh one.
[07:05:44] <Lambda-Aurigae> a simple oscillator running 500KHz to 1MHz
[07:06:02] <dgriffi> Lambda-Aurigae: I know. I was looking at debricking options on google
[07:06:16] <Lambda-Aurigae> got an old motherboard with a 16MHz to 20MHz 4 pin oscillator on it?
[07:06:28] <Lambda-Aurigae> hell, 1MHz to 20MHz even.
[07:06:30] <dgriffi> no
[07:06:38] <Lambda-Aurigae> an old tv? an old dead computer?
[07:06:55] <Lambda-Aurigae> a second attiny?
[07:07:04] <dgriffi> I have an attiny in a breadboard
[07:07:07] <Lambda-Aurigae> a dead clock?
[07:07:29] <dgriffi> it uses a 16mhz clock and is known good
[07:07:47] <Lambda-Aurigae> that attiny can easily be used to generate a clock source...just toggle a pin on and off in a continuous loop.
[07:07:48] <dgriffi> I was testing my tone generation stuff on that before I moved it over to my prototype hardware
[07:08:05] <Lambda-Aurigae> that pin output goes to the clock input on the dead chip.
[07:08:28] <Lambda-Aurigae> hook up programmer to dead chip...set programming speed nice and slow...and away you go.
[07:09:23] <Lambda-Aurigae> so long as you didn't set the selfprgen in the extended byte or rstdisbl in the high byte you are good.
[07:10:50] <dgriffi> okay.. which pin on the dead chip do I tickle?
[07:11:04] <Lambda-Aurigae> look at the datasheet.
[07:11:08] <Lambda-Aurigae> it tells you exactly.
[07:11:18] <Lambda-Aurigae> I don't have an attiny85 datasheet on this computer.
[07:11:47] <Lambda-Aurigae> it should be xtal1
[07:11:59] <Lambda-Aurigae> again I must suggest,,,,read the datasheet.
[07:12:43] <Lambda-Aurigae> time for me to head to work...laters.
[07:17:25] <dgriffi> ah... pin1
[07:17:37] <dgriffi> ....aaaand I need a 12V power supply... damn
[07:18:24] <sabor> 12V?
[07:18:45] <pwillard> 12V on reset = high voltage programming mode
[07:20:43] <dgriffi> hmm... this suggests I can do it with an ISP programmer:
http://www.evilmadscientist.com/2007/fixing-a-bad-frequency-fuse-bit-on-an-avr/
[07:21:45] <sabor> ooh, you try HV programming, good luck
[07:26:15] <dgriffi> aaaand that avrdude trick can only be done with an STK500 programmer
[07:30:38] <dgriffi> I'll just set this aside for when I can get an STK500
[07:49:08] <pwillard> there are STK500 compatibles. The WHOLE stk500 is a bit of overkill.
[07:50:17] <dgriffi> LF:0X66 HF:0XDF bricked another one
[07:55:27] <dgriffi> so here I am back at _delay_ms() running about three times as slow as should be running.
[07:56:05] <dgriffi> fuses are L:FF H:DF. I tried with CKDIV8, but I got no audio output.
[08:00:09] <sabor> dgriffi: you could try to use my "tick" method for the delay
[08:00:52] * dgriffi growls
[08:00:58] <dgriffi> why the hell doesn't it just work?
[08:03:32] <carabia> that's kind of a frequent question with myself, too
[08:08:22] <dgriffi> sabor: in your tick method, can millisecond_flag be set anywhere else instead of in play()?
[08:11:13] <sabor> dgriffi: the ISR has a counter which counts one millisecond, then it sets the flag, the sleep_ms functions checks the flag and clears it
[08:11:37] <dgriffi> I want to use sleep_ms outside of the play() function
[08:11:57] <sabor> you can use it wherever you want, except in ISRs
[08:12:01] <dgriffi> okay
[08:12:58] <dgriffi> FINALLY!!!
[08:13:30] <dgriffi> I'll have to add this to my eternal notes... on the attiny, DO NOT TRUST _delay_ms() to be accurate
[08:38:14] <dgriffi> sabor: why is the tick() function necessary for this trick?
[08:38:54] <sabor> dgriffi: it is not necessary, but if you do all delays with this delay_ms you can do periodic things in tick()
[08:39:34] <sabor> in tick() i normally check buttons and do debouncing
[08:40:15] <dgriffi> how would you do that?
[08:40:42] <sabor> do what?
[08:40:52] <sabor> debouncing?
[08:41:04] <dgriffi> I've never done debouncing and button checking in a seperate function like that
[08:43:34] <dgriffi> this is my button checking function.
http://pastebin.com/9gGH1nRZ
[08:44:14] <dgriffi> it's still in a flux of whether or not to make it block and how to detect long presses
[08:46:36] <sabor> dgriffi:
http://repos.borg.ch/projects/avr_leds/trunk/ws2811/avr/big-led-string.c
[08:47:02] <sabor> near the end of that file in read_buttons() i do debouncing and check for long button press
[08:47:50] <sabor> but since it uses 4 digital inputs it is simpler to do than with ADC and multiple voltage levels
[08:49:14] <dgriffi> is my approach sound?
[08:49:51] <sabor> you have 13 buttons with different voltage levels?
[08:49:59] <dgriffi> yes
[08:50:15] <sabor> that's pretty much...
[08:50:39] <dgriffi> and I don't need the program to do anything while waiting for a button to be pressed
[08:52:45] <sabor> you could start an ADC conversionj at the ned of tick() and at the start of tick() you process the result
[08:54:01] <sabor> compare the voltage to get the key number, then count how long you have the same key, when it reaches a threshold you create the key pressed event
[08:54:24] <Lambda-Aurigae> dgriffi, you don't need 12V unless you screwed up the reset pin by programming RSTDISBL fuse.
[08:54:53] <dgriffi> Lambda-Aurigae: I'll clean up that mess later
[08:58:56] <dgriffi> okay. I'll probably revisit that line of thought when I flesh out the rest of my code.
[08:59:06] <dgriffi> thanks
[09:08:23] <bss36504> How's it going my dudes?
[09:09:58] <dgriffi> I think I bolluxed up something I was working on for some hours and I didn't save the working version
[09:10:20] <bss36504> Well that's upsetting
[09:13:08] <carabia> bss36504: I got it working /late/ last night, woo
[09:13:24] <bss36504> ooh excellent! What was it?
[09:13:50] <carabia> well the ST-provided fatfs seemed to be borked, so I pulled the newest one from chan
[09:14:21] <carabia> this seems to work no problem, though, the st-scripts seemed to provide some allocating I had to do manually now
[09:14:35] <sabor> dgriffi: something like this might work:
https://paste.apache.org/xFs0
[09:15:40] <dgriffi> sabor: I fucked up my code... now it's not processing button presses at all
[09:15:42] <carabia> and also an external problem was that st's hal-sdio-driver does this stupid thing that if it identifies the card as hc, it will divide the address provided to it by 512, for byte addressing, heh
[09:16:00] <carabia> whereas it already gets fed lba-addressing
[09:16:01] <sabor> dgriffi: i know that problem ;)
[09:16:17] <sabor> dgriffi: the version control might help you
[09:16:30] <dgriffi> sabor: I know.... I was lazy
[09:18:07] <carabia> but that was fixed with st's implementation. For the new fatfs I just did a quick abstraction for write/read and removed the division.
[09:18:22] <carabia> Well, seems to be working. Now on to bigger and better things.
[09:19:29] <bss36504> carabia: Oh I didnt realize you weren't using the OG-fatfs from chan
[09:19:47] <bss36504> glad you got it working though!
[09:19:50] <carabia> nah I got the OG now.
[09:20:01] <carabia> doesn't have cp1525 but I think I'll just throw it in there.
[09:20:08] <carabia> 1252*
[09:21:17] <bss36504> cool
[09:21:51] <dgriffi> got it back... now to put it in git like I should have
[09:37:45] <dgriffi> sabor: curious... the way I messed up my code was to use your sleep_ms() in getkey(). it doesn't like to work there.
[09:47:31] <sabor> dgriffi: did you switch off the timer?
[09:48:05] <dgriffi> sabor: I don't think I did
[09:48:25] <sabor> hmm, then it should have continued counting...
[09:49:11] <dgriffi> it seems like the debounce waiting period lasts forever
[09:50:15] <dgriffi> ohhh....
[09:50:23] <sabor> you could use the last pin to signal something...
[09:52:09] <dgriffi> the timer is indeed off when reading the keypad
[09:52:22] <dgriffi> there's another timer I can use for this, right?
[09:52:51] <sabor> why is the timer off?
[09:53:14] <dgriffi> that's how I've been turning on and off the tones
[09:53:28] <sabor> ofcourse you could use an other timer to create ticks
[09:53:56] <sabor> there's no need to turn the timer off, if you want to get rid of interrupts yo ucould just disable the overflow interrupt
[09:54:19] <dgriffi> an alternate way to toggle tones?
[09:54:32] <sabor> and set the OCR to 0x7F, then you also don't get an on/off click
[09:56:19] <dgriffi> why 0x7F?
[09:56:55] <sabor> because it's the middle voltage
[09:57:55] <sabor> after decoupling it is the 0V of the sine wave, and when you switch the sine wave off you should set the output to 0V
[09:58:51] <dgriffi> so... OCR0A = 0x7F?
[09:59:35] <sabor> yes
[10:03:07] <dgriffi> then have a global of tones_on. if true then OCR0A = pgm_read_byte(blah)... otherwise OCR0A = 0x7F
[10:03:47] <sabor> yes
[10:06:23] <dgriffi> that did the trick
[10:06:44] <sabor> cool :)
[10:12:40] <dgriffi> sabor: does keeping the timer running all the time consume any more power?
[10:16:05] <sabor> probably no noticable
[10:27:01] <dgriffi> the final product runs on a 9v battery
[10:29:26] <sabor> i guess then you should try everything to save power
[10:30:26] <sabor> dgriffi: is the last pin unused?
[10:31:03] <sabor> you could use its pin change interrupt to wake up the device from a deep sleep
[10:31:32] <dgriffi> PB1 and PB5 are unused when not programming it
[10:32:20] <sabor> then you could use PB1 to wake up the device
[10:33:00] <dgriffi> how?
[10:34:22] <sabor> when nothing happens it can go to sleep mode and before sleeping switch on all power saving features
[10:34:59] <dgriffi> so, how does it get out of sleep?
[10:35:41] <sabor> a think a pin change interrupt on PB1 can wake it up
[10:36:51] <sabor> so if you have some kind of ON button you should connect it there, or do some other trick which toggles PB1 on a button press
[10:37:02] <dgriffi> couldn't I just do that for PB2, which is the pin that monitors the resistor ladder?
[10:37:18] <bss36504> dgriffi: What are you using to convert the 9V down to something usable for the micro? 9V batteries really dont have that many mAH compared to say 3 AAA batteries, so unless you have a very efficient switching regulator, you'll probably lose more power in the quiescent current of your regulator than you'll save in sleep mode
[10:37:19] <dgriffi> the on button just switches power to the device
[10:38:14] <sabor> so you have a power switch?
[10:38:30] <dgriffi> bss the power regulator is an LM78L05
[10:38:37] <dgriffi> sabor: yes
[10:39:04] <sabor> aah, ok, then it's only running when needed so saving power is not that important
[10:39:51] <dgriffi> this device is not intended to be left on for extended periods of time. maybe 10 minutes at a time at the most.
[10:44:41] <bss36504> well, quite honestly you'll only get a few runs before you need a new battery.
[10:45:14] <bss36504> at least use a 7805 switching variant. You can get modules that are the same size but waste less power.
[10:45:42] <bss36504> you're going to be throwing away almost 50% of the power you get from that battery as heat.
[10:46:26] <dgriffi> isn't a 78L05Z a switcher?
[10:48:01] <bss36504> no it's a linear. 7805 is a generic part number meant to indicate a regulator patterned after the 7800 series voltage regulators. The last two digits represent output voltage. Either way, unless you get a "7805 equivalent" switching regulator, as in a module that is pin compatible, it's not going to be a switcher.
[10:49:19] <bss36504> the 78xx regulators have been around for ages. Like 40-50 years.
[10:49:36] <bss36504> some companies make drop in replacement switching versions though
[10:49:59] <bss36504> Like this one:
http://www.mouser.com/ProductDetail/Murata/7805SRH-C/?qs=35WhQNrE6p1ufAToLPR0kA%3D%3D&gclid=CjwKEAjw97K_BRCwmNTK26iM-hMSJABrkNtbFYZDyY3NppdmDwz2Q-gAZtNzezEnKvJxVPoh3VO_MRoCYwXw_wcB
[10:52:15] <dgriffi> ugh.,.. I need it to be closer to to92 sized
[10:52:42] <bss36504> Are you making a custom PCB?
[10:53:05] <dgriffi> yes.. and space is tight
[10:56:28] <bss36504> Well consider this: a 9V battery requires a regulator of some kind. a 9V has an energy per volume 600mAH/21.3cm^3. Three AAA batteries put out 4.5V, require no regulator to be used with your micro and probably most other circuits, and together they have an energy per volume of 3300mAH/11.3cm^3
[10:57:45] <bss36504> So thats 28.4mAH/cm^3 vs 292mAH/cm^3. The three AAA have 10x the energy density of a single 9V
[10:57:53] <bss36504> and just take up less volume in general
[10:59:08] <bss36504> But if you're making a custom PCB, don't shy away from a better power supply scheme if youre absolutely married to the 9V. If your application is low enough current, you could use a charge pump buck regulator that requires a couple external SMD caps. you can get low power cp regulators in packages like DFN
[11:03:16] <dgriffi> another of my restrictions is that it has to be all through-hole
[11:03:30] <bss36504> Why? is it a kit?
[11:03:33] <dgriffi> yes
[11:03:35] <Lambda-Aurigae> 3 AAA batteries will give you more power overall than a single 9V
[11:03:41] <sabor> throughole is so cumbersome to solder...
[11:03:54] <bss36504> sabor not if youre a noob.
[11:03:59] <bss36504> I just led a soldering lab.
[11:04:04] <bss36504> it was...painful
[11:04:10] <sabor> hehe
[11:04:21] <bss36504> all through hole and still people managed to completely fuck it up in ways I never thought possible
[11:04:43] <sabor> lol
[11:04:48] <dgriffi> I guess I can shoehorn in a 3-cell AAA tray into the case
[11:04:48] <bss36504> SMD would have exploded their heads
[11:04:51] <Lambda-Aurigae> I do that with kids every year for the last 10 years.
[11:05:01] <sabor> bss36504: did you make some pics? ;)
[11:05:16] <dgriffi> oooo... I'd love to see pics of that
[11:05:21] <bss36504> unfortunately it wasnt my material, I was just assisting. next time I'll be contributing to the documentation
[11:05:35] <bss36504> oh you mean of the fuck ups? nah didnt get any
[11:05:36] <bss36504> haha
[11:05:47] <Lambda-Aurigae> 3 to 8 kids each summer, learning soldering, electronics, microcontrollers, robotics, and how to read datasheets and tech manuals.
[11:05:51] <bss36504> anyway dgriffi if you go with the 3 AAA you dont even need a regulator
[11:06:00] <bss36504> that's neat Lambda-Aurigae
[11:06:05] <sabor> bss36504: yeah, when my daughter was 4 years old she knew what resistors, capacitors etc are, but with SMD she has no idea animore ;)
[11:06:12] <Lambda-Aurigae> mostly I teach them how to learn.
[11:06:20] <bss36504> Thats the most important thing
[11:06:36] <Lambda-Aurigae> I try to do that here and people get pissed at me for telling them to read the datasheet.
[11:06:47] <bss36504> Lots of students dont want to try and figure stuff out and get upset that I dont just hand out answers
[11:06:51] <bss36504> these are college kids too
[11:07:11] <Lambda-Aurigae> I wouldn't teach college kids..they know it all.
[11:07:30] <bss36504> and yet they also know nothing
[11:07:31] <bss36504> haha
[11:07:39] <Lambda-Aurigae> I teach 10 to 18 year olds. Have gone as low as 8 but that was a special case.
[11:08:06] <bss36504> that's a good age range I'm sure. They all also probably want to be there and are interested in the material.
[11:08:19] <Lambda-Aurigae> and for their first 4 sessions I require a parent to be with them,,no matter the age.
[11:08:40] <bss36504> How many sessions do you do?
[11:08:41] <Lambda-Aurigae> it's a voluntary "club" kinda setup I run out of my workshop.
[11:08:45] <Lambda-Aurigae> as many as they want.
[11:09:03] <Lambda-Aurigae> but usually the whole summer from end of school to beginning of next school year.
[11:09:18] <Lambda-Aurigae> once a weekend to start then more if they want to come play with the toys more often.
[11:10:00] <bss36504> Well that's pretty swell
[11:10:34] <Lambda-Aurigae> I lose 1 in 3 for the rules.
[11:10:56] <Lambda-Aurigae> no cellphones and no social media during meetings.
[11:11:05] <bss36504> I actually have a lab later today. this one is seniors though, and they are all sharp and figure stuff out most of the time. I like working with them much more than the freshman
[11:11:08] <bss36504> That's fair
[11:11:13] <bss36504> no sense in wasting your time
[11:11:50] <Lambda-Aurigae> I have facebook, twitter, and a few others blocked at the firewall in the shop to boot.
[11:12:02] <Lambda-Aurigae> because a lot of what they do is on the computers.
[11:12:21] <Lambda-Aurigae> speaking of which, I'm down to 4. Need to find someone upgrading their laptops soon.
[11:12:45] <bss36504> Oh the humanity, how will they survive a few hours without being connected?
[11:12:46] <Lambda-Aurigae> I get companies who are upgrading their computers to donate them to the cause.
[11:12:54] <bss36504> Oh that's very cool
[11:13:02] <Lambda-Aurigae> usually 2 generations behind
[11:13:23] <Lambda-Aurigae> but I put linux on them along with the 8052, pic, and avr toolchains
[11:13:59] <Lambda-Aurigae> I've also gotten microchip, atmel, and maxim/dallas to donate bits and pieces.
[11:14:54] <Lambda-Aurigae> at the end, the kids get to keep what they build as it is mostly gotten for free..and they keep the computers.
[11:15:05] <dgriffi> cool
[11:15:27] <Lambda-Aurigae> kind of carrying on a bit of a "tradition"
[11:15:40] <dgriffi> "elmering" so to speak
[11:15:43] <Lambda-Aurigae> when I was 14, a xerox tech gave me a truckload of old xerox boards.
[11:16:16] <Lambda-Aurigae> literally, a pickup truck load of boards that were mostly in the 18x18 inch size range and just covered in chips and bits.
[11:16:37] <dgriffi> was there anything useful in that lot?
[11:17:03] <Lambda-Aurigae> head of the GPS/NDS project for Sandia National Labs gave me a signed copy of K&R Teach Yourself C(Still have it)
[11:17:20] <Lambda-Aurigae> that got me started learning C
[11:17:35] <Lambda-Aurigae> Not Teach Yourself C....The C Programming Language
[11:17:37] <Lambda-Aurigae> duh.
[11:17:39] <Lambda-Aurigae> long day.
[11:18:10] <Lambda-Aurigae> I still use that book for teaching C to kids.
[11:18:22] <Lambda-Aurigae> works well for learning C for microcontrollers and linux programming.
[11:18:57] <Lambda-Aurigae> as for anything useful? yeah, lots and lots of 74xx series chips, memory chips, power supply bits-n-pieces.
[11:19:17] <dgriffi> cool.. I'm going to sleep now
[11:19:28] <Lambda-Aurigae> stuff that made up computers and duplication devices from the mid 1980s.
[11:19:40] <Lambda-Aurigae> or, rather, early 1980
[11:23:37] <carabia> You should use that one book that's held in high regard over at ##c
[11:23:43] <carabia> One sec.
[11:24:57] <carabia> https://www.gitbook.com/book/wizardforcel/lcthw-en/details This
[11:28:14] <carabia> Does anyone know off the top of their head what's the performance of bitmap resizing with something like lanczos vs nearest-neighbor?
[11:29:02] <carabia> i know lanczos is bound to be slow... a lot i guess. just thinking a ballpark figure
[11:43:09] <bss36504> I dont know the algorithm for Lanczos
[11:43:23] <bss36504> but nearest neighbor should be O(n)
[11:43:54] <bss36504> Lanczos may well be linear as well, but I imagine the time will be much much longer
[11:55:18] <carabia> exactly, i couldn't find anything with a quick google, gotta delve deeper into it
[12:23:55] <Lambda-Aurigae> carabia, I use what I know. It's the book I learned with and that I've taught with for many years.
[12:26:57] <Lambda-Aurigae> http://freecomputerbooks.com/The-C-Programming-Language.html
[12:29:52] <Lambda-Aurigae> what better book to learn from than one written by the guys who wrote C in the first place, eh?
[12:35:56] <carabia> the book i linked is kind of, really bad, there's a couple of funny reviews of it floating around
[12:36:17] <Tom_itx> Lambda-Aurigae want that in pdf?
[12:36:32] <carabia> pdfs suck. actual copies are better.
[12:36:41] <Tom_itx> i have both
[12:36:58] <Tom_itx> pdf is good for a quick search
[12:37:11] <carabia> k&r is pretty much the baseline standard for learning c from what i gather
[12:37:20] <Tom_itx> tis so
[12:37:33] <carabia> you don't really use k&r too much as a reference tho. Or i don't, at least
[12:37:45] <Tom_itx> no not alot
[12:37:58] <carabia> i've read it through a couple of times many many years ago. skipping the unix bits cause they don't interest me.
[12:38:10] <Tom_itx> i keep it on the shelf though
[12:38:16] <Tom_itx> along with some old asm books
[12:38:57] <Tom_itx> and function calls etc
[12:39:25] <carabia> i wonder if they sell the ref manuals for diff. cortex-m's as hard copies
[12:39:31] <carabia> I could grab a couple of those.
[12:39:43] <Tom_itx> it's doubtful anything is hardcopy anymore
[12:39:56] <carabia> I could just print it but... not at home
[12:40:05] <carabia> perhaps off a shop.
[12:40:12] <Tom_itx> i've got a set of 9-10 books on the motorola 68332
[12:40:26] <Tom_itx> 2 pink books on the 68hc11
[12:40:30] <carabia> yeah but that's from the stone age
[12:40:48] <Tom_itx> cpm is stone age
[12:42:13] <twnqx> cp/m was my first getting to know subdirectories
[12:42:32] <twnqx> which was prettymuch confusing for a 14yrs old that only knew c64/c128 :P
[12:43:36] <carabia> i would just want the ref manuals for crapper-reading and emergency asswipe!
[12:44:12] <carabia> right now i've got some noname analog circuitry design book and i've gone through that too many times. Haven't even had to rip pages.
[12:44:42] <Tom_itx> wish i still had all my logic chip books
[12:45:38] <carabia> oh yes, there's a distinct pleasure-element to it reading about the 7400s while squeezing out a huge turd.
[12:46:14] <carabia> there's a swedish saying that translated goes something along the lines of cake-on-cake
[12:46:20] <carabia> I think that's applicable here
[12:50:15] <bss36504> I can do that with my phone, except instead of 7400 datasheets it's cat pictures on the internet
[12:50:48] <bss36504> is cake-on-cake like racks on racks?
[12:54:16] <carabia> meh, phones. Useless. And can't even use as an emergency wipe in the event of running out
[12:54:29] <bss36504> ooh printer paper sounds sharp
[12:55:17] <carabia> oh, brother, you only use the middle portion
[12:55:24] <carabia> portion, area, ...
[12:55:37] <bss36504> haha I know but it's still bound to be abrasive
[12:56:00] <carabia> mildly, but you're supposed to be a man rather than a mouse
[17:39:11] <Emil> Hey
[17:39:26] <Emil> If I get the contents of a chip (for example from atmega328p)
[17:39:36] <Emil> how can I translate that back into assembly?
[17:39:48] <LeoNerd> With a disassembler
[17:40:14] <Emil> LeoNerd: I tried avr-objdump but can't seem to figure out how to get it to output assembly
[17:40:23] <LeoNerd> I use objdump -S
[17:40:38] <Emil> avr-objdump -S -m atmega328p lap.hex
[17:40:39] <Emil> ?
[17:40:57] <LeoNerd> I don't think you can do it on a .hex file
[17:41:02] <LeoNerd> You'll have to convert it back into an ELF
[17:41:26] <Emil> How can I do that?
[17:41:44] <LeoNerd> Probably some variant of avr-objcopy
[17:47:32] <Casper> Emil: there is a reverse enginnering channel on freenode, maybe ask there?
[17:47:55] <Casper> I think it's ##re
[17:49:02] <Emil> Casper: thanks
[17:50:38] <Lambda-Aurigae> Tom_itx, the K&R book? I have it in pdf.
[17:53:16] <carabia> Has anyone used the jpeg decompressor from elm-chan.org?
[18:01:08] <carabia> well, hmm, basically i need to decompress and scale a jpeg to a certain size, so i guess i'll just set the decompression scaling based on width and height to minimize the buffer required
[18:01:33] <Lambda-Aurigae> I just use png myself when I have to deal with images.
[18:01:47] <carabia> and after that i could do a nearest neighbor or maybe even a bilinear interp resize
[18:02:02] <carabia> well sure, but jpegs are more common and this is not for personal use
[18:02:46] <carabia> i'll have to see how bad the images are after the decompression and scaling. Nearest neighbor might suck a lot
[18:08:26] <carabia> scaaawy overhead
[18:12:17] <Casper> why not use linear scalling?
[18:12:23] <Casper> not much more code I think
[18:12:27] <Emil> Can one make this more efficiently and if so, how?
https://emil.fi/jako/lap.c.txt
[18:12:47] <Emil> more efficient*
[18:13:24] <Emil> "Read pin values into a byte and send byte out of serial"
[18:13:44] <Emil> and by efficiency I mean cycles
[18:14:10] <cehteh> why do you read PINC so often?
[18:14:26] <Emil> cehteh: Because I'm packing multiple measurements into a single byte
[18:14:38] <Emil> I'm only reading two pins
[18:15:42] <cehteh> i think that could be written tighter
[18:16:24] <cehteh> but about some side conditions, you read the lowest 2 bits of PINC, are all other bits in PINC guranted to be 0?
[18:16:34] <Emil> cehteh: yeah
[18:16:43] <Emil> cehteh: in the start I read c=
[18:16:45] <Emil> not c|=
[18:18:17] <Emil> If I had an external delay line connected to PINC I could just read PINC and put it out but alas, a single chip solution it is
[18:18:29] <carabia> Casper: ??
[18:18:33] <carabia> "linear"?
[18:18:45] <Emil> cehteh: but if you have any ideas how to make it more cycle efficient I'm all ears
[18:18:52] <cehteh> moment
[18:19:51] <Casper> carabia: AB -> A . . . . B 0 . . . . 100 0 20 40 60 80 100 ....
[18:20:31] <cehteh> http://paste.debian.net/845882/
[18:20:47] <cehteh> check to what that compiles, might be better or might be not better
[18:21:07] <cehteh> no r
[18:21:15] <carabia> Casper: oh yea, but I think it's pretty poor.
[18:21:17] <Emil> Hmm
[18:21:29] <Emil> I have been avoiding << because it's one cycle per shift
[18:21:30] <Emil> but here
[18:21:37] <Emil> I think it is actually better
[18:21:43] <Emil> and way better actually
[18:21:44] <carabia> Might not matter that much, depends on how close to the target size I can get with the jpeg scaling in the first place
[18:21:51] <carabia> cause the input jpegs are of arbitrary size
[18:22:04] <carabia> and you can only choose from a set of scaling factors
[18:22:35] <cehteh> yes i know the cycle per shift, but loading constants and doing checks and branches most likely wastes more then 2 cycles
[18:22:58] <cehteh> well the bit posiitons this way dont match your code
[18:23:11] <Emil> That's irrelevant
[18:23:14] <Emil> I can decode later
[18:23:23] <cehteh> but maybe you can either fix that, or keep it interleaved and then handle that in your client software
[18:23:25] <Emil> Yeah, this should be much more efficient
[18:23:43] <Emil> yeah this is all pushed through serial to a computer where I can decode
[18:25:10] <cehteh> but how do you syncronize pinc access, this way you do 4 reads, then wait for serial and rinse repeat
[18:25:25] <cehteh> dont you want equal timeframes for each read?
[18:26:14] <Emil> Would, yeah
[18:26:25] <cehteh> (can one read the serial clock register on what bit the serial currently is? have to read datasheet)
[18:26:40] <cehteh> but if yes you can synchonize it evenly with the serial data rate
[18:26:43] <Emil> Nope, at least I have not seen it in datasheets
[18:26:46] <Emil> Hmm
[18:26:53] <Emil> dissassembly shows them at same size :D
[18:27:20] <Emil> They compile to exactly the same code :o
[18:27:25] <cehteh> 328?
[18:27:26] <Casper> << may be 1 cycle per shift, but 0 cycle if you do like constant << 4
[18:27:30] <Casper> time to go home
[18:28:06] <cehteh> yes sometimes one need really to check the asm generated, not always the smallest C code is the fastest
[18:28:08] <Emil> cehteh: They compile to the same code
[18:28:17] <Emil> Yours is way clearer, though
[18:28:21] <cehteh> size or some code?
[18:28:23] <cehteh> same
[18:28:24] <Emil> same
[18:28:38] <cehteh> well i told you that gcc optimization is sometimes quite clever, didnt i?
[18:29:08] <Emil> Yap
[18:29:18] <Emil> But that's good to know
[18:29:56] <cehteh> so gcc outsmarted you :)
[18:30:05] <Emil> Nah
[18:30:18] <Emil> I just did it the best way possible while being way more complex
[18:30:25] <Emil> you achieved the same result in clearer code
[18:30:59] <cehteh> mhm if you cant access the serial clock directly you may need another clock for that
[18:31:16] <cehteh> but then, if you do it clever you dont need to wait for serial because you are in sync
[18:31:34] <Emil> Yeah if I were to do this the proper way I'd program in assembly
[18:32:03] <cehteh> doesnt necessary need asm
[18:32:22] <cehteh> i think the serial baudrate is the limiting factor anyway
[18:32:27] <Emil> ATM I reason that I'm spending more time getting pin values than waiting for serial
[18:32:30] <Emil> Yeah
[18:33:25] <cehteh> so if you sync the loop (aka each read) with serial baudrate, then when a byte is finished, you can send it straight out, no wait for serial
[18:33:51] <cehteh> but you need some wait on another clock
[18:34:39] <cehteh> the trick is to get another clock and serial baudrate into sync, they have the same source clock, but prescaling etc will be pain
[18:36:19] <cehteh> puttin uart in syncronized mode with external clock, loopback one pin to the uart clock input .. how ugly :)
[18:36:27] <cehteh> but might be a low hanging fruit
[18:36:34] <Emil> cehteh: I could use pb0 as clock output >:D
[18:37:13] <cehteh> i am more thinking about software only solution
[18:37:53] <cehteh> setting one counter up to count at the same speed as the uart clock, starting them together
[18:38:11] <Emil> impossible
[18:38:17] <Emil> Well
[18:38:20] <Emil> "impossible"
[18:38:27] <cehteh> almost together would be ok
[18:38:53] <cehteh> not impossible but not trivial eiher
[18:38:58] <Emil> Anycase
[18:39:02] <Emil> I'll go now
[18:39:06] <cehteh> may not work for all boudrates
[18:39:06] <Emil> Thanks for helping me out
[18:39:10] <cehteh> np
[18:39:11] <Emil> Good night : )
[18:39:12] <cehteh> have fun
[20:58:04] <carabia> I have to say, using the "TJpgDec" jpeg-decompressor from elm-chan.org has been one of the least ass-hurting experiences in my recent history.