Back
[07:21:11] <anton02> please answer my question here
http://electronics.stackexchange.com/questions/230353/voltage-amplifier-stage-for-audio
[07:26:59] <LeoNerd> Without reading the question: TL071
[07:27:42] <LeoNerd> Oh.. odd question. Why are you building that at the transistor level?
[07:32:42] <anton02> LeoNerd, im an audiophile
[07:33:26] <anton02> lol jk
[07:38:21] <twnqx> yuck, analog electronics
[07:38:36] <twnqx> just get some 16bit PWM and a capacitor
[07:44:59] <LeoNerd> Hehe
[07:51:41] <LeoNerd> In any case.. that looks to be a rather more deep analog design question than I suspect #avr could help you with
[07:59:53] <Emil> twnqx: "PWM", pls
[07:59:59] <Emil> just use a resistor network
[08:00:11] <Emil> and a voltage buffer amplifier
[08:00:26] <twnqx> emil: not enough powwah
[08:01:59] <LeoNerd> Mm.. resistor network can be a sensible DAC, yes
[08:02:15] <LeoNerd> My siggen has a 12-bit R/2R ladder
[08:02:40] <Emil> twnqx: there is if you buffer it ; )
[08:03:29] <twnqx> back to analog domains, i see
[08:03:46] <twnqx> on.off. there's nothing more to it with pwm (or class-d amps)
[08:04:33] <Emil> twnqx: and a fuckton of fitlering
[08:04:38] <Emil> filtering*
[08:05:09] <twnqx> nah
[08:05:24] <twnqx> all you need is a cap
[08:05:53] <Emil> Not if you want to do it well
[08:34:43] <daey> is there no interest in creating a working "double" in avrgcc?
[08:35:24] <LeoNerd> Not from me. I can't imagine what I'd be doing on an AVR chip that needs any sort of floating point, let alone 64 bits of the stuff
[08:37:38] <Emil> LeoNerd: that's a very silly way to look at things
[08:39:04] <LeoNerd> I prefer to work on things that I might actually use
[08:39:13] <LeoNerd> That takes up all my time so I don't have any spare for things I wouldn't use
[08:39:15] <Emil> LeoNerd: it's not away from you
[08:43:50] <daey> LeoNerd: its frequently requested in relation with gps coordinates
[08:44:22] <LeoNerd> Presumably by people who don't know about scaled integer arithmetic
[08:46:15] <daey> no by lazy people who like to write double instead of writing another float themself :p
[08:46:30] <Emil> daey: the thing is
[08:46:41] <Emil> daey: only stupid people use float or doubles on an avr
[08:46:56] <daey> nah
[08:47:15] <Emil> I am all okay with giving people the tools to hurt themselves, though, and I actually advocate to have everything available
[08:47:15] <daey> sometimes it makes sense. but i try to avoid it if reasonably possible
[08:47:18] <LeoNerd> The trouble with floats is that they're terrible
[08:47:28] <Emil> LeoNerd: only if you don't have FPU
[08:47:33] <LeoNerd> floats are useful for when you don't know what range of value you're going to be working in... it could be tiny or huuuuuge
[08:47:48] <LeoNerd> But e.g. in the realm of GPS, you know exactly the range. LAT will be -180 to 180, LONG will be 0 to 360
[08:47:57] <LeoNerd> Ergo, you can use scaled integers much nicer
[08:48:10] <Emil> indeed
[08:48:17] <daey> isnt scaled integer what float is all about?
[08:48:20] <LeoNerd> IT's like a floating point except all 64(?) bits can be dedicated to the significand of the value; rather than wasting 11 on the exponent
[08:48:24] <daey> a number + exponent?
[08:48:25] <LeoNerd> So it's actually /better/ precision
[08:48:30] <daey> mantisse*
[08:48:38] <Emil> daey: no
[08:48:46] <Emil> daey: they are linear precision
[08:48:47] <LeoNerd> Yes - the word "float" in "floating point" means that the precision scaling isnt' fixed... it's allowed to move
[08:48:53] <Emil> yeah
[08:48:56] <LeoNerd> That movement has to be stored somewhere. That's the exponent field
[08:49:22] <LeoNerd> If you know exactly what range of values you want, and what precision (it's GPS, you know you can't get better than, say, 10cm precision), then you want to be using a fixed exponent
[08:49:40] <Emil> It's a fuckton faster
[08:49:41] <LeoNerd> Fixed exponent means you're not wasting precious RAM to store it, and precious CPU cycles to manipulate it
[08:49:46] <daey> so how would you do that scaled integer thingy? allocate 3bytes? and then simply interprete them as one variable?
[08:50:01] <LeoNerd> So... Correct: only idiots use floats for GPS. Anyone sensible uses fixedpoint
[08:50:16] <LeoNerd> Especially on a low-resource machine like an AVR
[08:50:29] <daey> i was thinking of using a struct + 3 ints
[08:50:36] <daey> but that might turn ugly down the road
[08:51:06] <Emil> daey: in your algorithms you simply decide what a value represents. Instead of having 1,001 you have 1001
[08:51:23] <Emil> you scale them
[08:52:51] <cehteh> floats wtf ... who started with that crap :D
[08:52:53] <Emil> so if your precision is, for example, 1mV
[08:53:05] <cehteh> telling all the kids that if you want digits you must use floats
[08:53:07] <Emil> you should keep all your measurements in mVs
[08:53:10] * cehteh suspects arduino
[08:53:21] <Emil> and then when you present that to the user you do the appropriate conversion
[08:53:26] <Emil> but only then
[08:53:31] <cehteh> µV when you need more precision
[08:53:48] <LeoNerd> You don't even need to convert
[08:53:53] <Emil> LeoNerd: I know
[08:53:56] <daey> Emil: i get that. my question was more into the direction of, what if you want 24bit precision? how do you wrap that up nicely?
[08:54:04] <LeoNerd> Print the value div 1000, print a ".", print the value mod 1000 with leading zero padding
[08:54:11] <LeoNerd> Never have to think about nonintegers
[08:54:12] <Emil> LeoNerd: I know
[08:54:21] <LeoNerd> Yah I'm mostly stating out loud for the record :)
[08:54:26] <rue_2bed> typedef struct int24_t {
[08:54:43] <daey> LeoNerd: and you do all that in a uint16_t mymeasurement;?
[08:54:45] * cehteh thinks about adding a feature to his io lib to place a . at a certain digit while printing integers
[08:54:45] <Emil> It's really sad that we don't have a ready to go fixed point library widely available and advocated
[08:54:53] <Emil> I think there is one in the avr/libc code, though
[08:54:56] <LeoNerd> rue_2bed: I /believe/ verylatest gcc for avr actually has a (u)int24_t type
[08:55:00] <cehteh> and maybe truncating trailing zeros then
[08:55:01] <LeoNerd> Or maybe that's still a patch
[08:55:21] <rue_2bed> in the last 2 years, 4 people here have written their own fixed point libraries
[08:55:27] <rue_2bed> you will make 5
[08:55:28] <cehteh> yes i've seen a int24 too
[08:55:59] <cehteh> but hey fixed point is simple, i would wish there was a lib for rationals
[08:56:28] <rue_2bed> thats not what bothers me
[08:56:29] <cehteh> maybe i do one someday
[08:56:49] <rue_2bed> the amazing repetition of work by society
[08:56:52] <Emil> I mean, if only we could get an easy to use fixed point library :(
[08:57:50] <daey> ok so i simply malloc(3); then write my own bit interpretation for that?
[08:57:58] <cehteh> malloc?
[08:58:12] * cehteh never uses malloc on avrs :D
[08:58:18] <daey> why not?
[08:58:31] <cehteh> 1: robustness ..
[08:58:38] <cehteh> 2: low memory
[08:58:44] <daey> what do you use?
[08:58:45] <Emil> no need
[08:58:54] <cehteh> stack or globals
[08:59:06] <LeoNerd> Wow.. malloc /and/ floats on an AVR?
[08:59:10] <Emil> LeoNerd: shhh
[08:59:15] <Emil> no tears, just sleep now
[08:59:15] <LeoNerd> What will we be adding next, pthread_t? ;)
[08:59:30] <Emil> LeoNerd: heo now! There are solutions to that :D
[08:59:30] <daey> i try to avoid globals :/
[08:59:36] <daey> maybe i shouldnt?
[08:59:36] <cehteh> LeoNerd: which leads to malloc + floats + pointers
[08:59:37] <Emil> daey: nono, globals are fucking awesome
[08:59:41] <Emil> daey: on an avr
[08:59:47] <daey> i see
[08:59:58] <daey> they feel like gotos
[08:59:59] <Emil> and actually in x86, too
[09:00:02] <cehteh> daey: on a PC you should try to avoid globals, on a µC they make some sense
[09:00:10] <Emil> nothing wrong with gotos and globals
[09:00:17] <cehteh> but you should still try to use them sparingly
[09:00:20] <Emil> the reason globals are not cool is porting is hard
[09:00:31] <Emil> and gotos usually lead to badly thought out code
[09:00:34] <daey> whats so good about globals?
[09:00:46] <Emil> daey: think about the instructions
[09:00:49] <cehteh> they are there :)
[09:00:56] <Emil> every cycle count
[09:00:57] <Emil> s
[09:01:03] <daey> i see
[09:01:10] <cehteh> no need for allocation/freeing/memory manage overhead/processing/pointers ...
[09:01:22] <Emil> I think I should actually learn C gotos
[09:01:31] <Emil> used them on .bats when I was 11 :D
[09:02:18] <cehteh> btw yesterday i had some crazy idea about redneck paging .. union { } subsystem data for subsystems which are not used at the same time
[09:02:19] <daey> so every local variable declaration is like a malloc itself which is free'd at the end of the scope it was declared in?
[09:02:46] <cehteh> then one can switch subsystems have globals sharing memory
[09:02:54] <cehteh> daey: yes
[09:03:13] <daey> i see
[09:03:18] <cehteh> be careful with deeper recursion .. then it eats your stack in nomore
[09:03:30] <cehteh> *but* still you should prefer that if possible
[09:03:40] <cehteh> deeper recursions are a nogo on µC anyway
[09:04:20] <cehteh> you should pay uttermost attentions to conserve ram
[09:05:17] <daey> how do you track ram usage?
[09:06:05] <LeoNerd> The compiler does that for me
[09:06:54] <Emil> daey: if you have jtag or debugwire or something like that
[09:06:58] <Emil> you can also use the avrsim
[09:08:16] <daey> i imagine a simulator to be a pita if you deal with external hardware that interacts with the chip
[09:09:13] <cehteh> just try to make your program somewhat static, where data is global and recursion (and thus local variables) are bounded to well known depths
[09:09:55] <cehteh> then you can check stack usage when debugging, or even deduce that by beans counting
[09:11:19] <cehteh> if everything is static and correct then your program will never run out of memory
[09:12:38] * cehteh sometimes wishes that gcc could dump how much memory each function needs on the stack, maybe even analyze that statically
[09:13:43] <cehteh> (maybe it can .. it has soo much options)
[09:20:09] <inflex> evening cehteh
[09:20:21] <cehteh> hi
[09:20:51] <cehteh> -fstack-usage
[09:21:19] <Emil> does anyone have the paste about arduino digitalwrite vs port manipulation
[09:21:25] <cehteh> error: stack usage computation not supported for this target
[09:21:28] <cehteh> ohnoes
[09:21:43] <cehteh> paste?
[09:23:06] <Emil> cehteh: pastebin paste
[09:23:08] <Emil> or some other paste
[09:23:19] <Emil> it was about the assembly required
[09:25:43] <cehteh> cant remember
[09:26:07] <cehteh> but i am absolutely sure that digitalWrite() is stupid :D
[09:28:26] <Emil> Indeed
[09:28:46] <Emil> You are in #arduino, too
[09:28:50] <Emil> how long are your logs?
[09:29:14] <cehteh> since always :D
[09:29:18] <Emil> niceee
[09:29:41] <cehteh> now whats it worth to you? :D
[09:29:56] <Emil> can you provide the last week of #arduino? Or grep me saying something with the keywords "I'll just leave this here" "pastebin" "fastdigitalwrite"
[09:30:04] <Emil> cehteh: demonstrating to someone why arduino is cancer
[09:30:25] <cehteh> that doesnt need digitalWrite() :o)
[09:30:28] <Emil> Someone on the internet is wrong worth
[09:30:34] <Emil> so not much but would be cool
[09:30:57] <cehteh> ihave to log into my server and search the logs
[09:31:07] <Emil> probably "paste" ".com" and "Emil"
[09:31:28] <cehteh> hah ..at least i found the correct server :D
[09:31:54] <Emil> cehteh: too many server is such a first world problem :D I know what you mean
[09:32:03] <cehteh> ls .znc/users/ct_freenode/moddata/log/
[09:32:03] <cehteh> Display all 16755 possibilities? (y or n)
[09:32:07] <cehteh> too many logs too
[09:32:39] <Emil> ":D"
[09:32:50] <cehteh> $ ls \#arduino_201
[09:32:50] <cehteh> Display all 648 possibilities? (y or n)
[09:33:19] <Emil> grep -i "Emil" "\#arduino" | grep -i "paste"
[09:33:32] <Emil> or
[09:33:41] <Emil> grep -ir "Emil" | grep -i "paste"
[09:35:57] <cehteh> This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff.
[09:36:00] <cehteh> .. oh noes
[09:36:13] <Emil> :DDD
[09:36:17] <cehteh> ./users/ct_freenode/moddata/log/default_#arduino_20160422.log:[19:22:40] <Emil>
http://pastebin.com/kBY3ynDt
[09:36:17] <cehteh> ./users/ct_freenode/moddata/log/default_#arduino_20160425.log:[13:50:36] <Emil> Does anyone have the arduino vs port manipulation paste somewhere?
[09:36:23] <cehteh> that was it?
[09:36:44] <Emil> someone didn't like it showing how shitty the function was
[09:36:46] <Emil> probably yeah
[09:36:48] <cehteh> http://pastebin.com/dSRSxgax
[09:37:05] <Emil> Hey that's it!
[09:37:09] <cehteh> lucky you ..
[09:37:59] <cehteh> boah .. i expect it to be bad .. but not *that* bad
[09:38:20] <cehteh> i am more complaining about the semantics .. because you cant set multple pins atomically
[09:38:50] <Emil> cehteh: glad I could shock you ; )
[09:39:13] <cehteh> well arduino doesnt shock me anymore
[09:41:31] <Emil> cehteh: what do you mean can't set multiple atomically?
[09:42:28] <cehteh> PORTx |= 1<<pin1 | 1<<pin2 ....
[09:42:42] <Emil> cehteh: eeeh
[09:43:02] <Emil> why not just PORTx=0bnnnnnnnn
[09:43:14] <cehteh> doesnt matter for this example
[09:43:19] <Emil> it is atomic
[09:43:22] <cehteh> yes
[09:43:29] <cehteh> digitalWrite isnt
[09:43:36] <Emil> and?
[09:43:41] <Emil> ah
[09:43:45] <cehteh> that can cause problems
[09:43:59] <Emil> you are complaining that digitalWrite isn't atomic
[10:30:32] <dsal> Emil: pretty the complaint is changing two pins requires two calls to that function and probably a large amount of time. The atomicity of the change probably matters for some use cases, but the huge delay surely affects more.
[10:30:36] * dsal sigh
[10:30:37] <dsal> "pretty sure"
[10:31:02] <Emil> dsal: yeah I know
[10:31:21] <Emil> I thought he was complaining that PORTx=... isn't atomic
[10:31:27] <dsal> oh
[10:31:57] <dsal> When you said "you are complaining that digitalWrite isn't atomic" I took it to mean that the function itself isn't atomic, which might also be a valid, but different, complaint.
[10:32:11] <LeoNerd> You can do direct PORTx maniulations in arduino code, however
[10:32:18] <LeoNerd> It's still just C++ over the usual avr-gcc
[10:32:37] <LeoNerd> All the regular registers are available as normal
[10:33:59] <cehteh> LeoNerd: yes, but you never know what arduino does in the back reconfiguring things it may expect otherwise could be a bit awkward
[10:34:38] <LeoNerd> Mm.. true
[10:34:42] <cehteh> see digitalWrite source .. which also checks if there is PWM on the pin and disables it
[10:34:53] <cehteh> and other stuff
[10:35:11] <LeoNerd> I only mention it because I have a board that's /almost/ entirely plain C code using the registers, except that I wanted a USB-CDC driver and the easiest one at short notice was to use arduino's one
[10:35:24] <LeoNerd> So I have an arduino program that uses almost none of their C++ code
[10:35:45] <cehteh> yes. may work, often does
[10:36:19] <cehteh> i possibly take some arduino drivers into mµOS as well someday
[10:36:44] <cehteh> as long there is no C++ and the code is ok
[10:37:56] <LeoNerd> Ohwait not CDC, HID
[10:38:06] <LeoNerd> USB HID is nicer as it's basically entirely MCU-driven interrupting into the host
[10:38:22] <LeoNerd> I have a box that just pretends to be a keyboard and throws keypresses occasionally
[11:10:32] <dsal> How can I store a port and pin? I'm building a thing that needs some configurable IOs. I'd like to just have an array of things I can turn up and donw.
[11:10:44] <LeoNerd> ah that's a fun question
[11:10:56] <LeoNerd> For all my derision of Arduino that is one thing I do feel is nicer about it
[11:11:09] <LeoNerd> A pin number is just a number, so you can pass it around parametrically
[11:11:38] <LeoNerd> In plain C, something you might find easy enough is to pass around a { volatile uint8_t *port, uint8_t mask } pair
[11:12:12] <LeoNerd> Or if memory is a little tight, consider a struct { enum { PORT_A, PORT_B, PORT_C, PORT_D, ... } port : 5; unsigned int bit : 3 }
[11:12:39] <LeoNerd> But then then implementation for setting / clearing / reading that pin is more complex
[11:13:57] <dsal> Oh neat. Thanks. Both of those look good.
[11:14:38] <LeoNerd> There's a fairly regular register structure though, on most AVRs at least, all of PORTA, PORTB, ... are densely packed and contiguous at the start of register space.
[11:16:16] <LeoNerd> Recently I found I wanted an enumerated abstraction of timer PWM ports.. so I had to abstract out the port/pin number as well as the timer unit and compare unit of it
[11:16:19] <dsal> I guess it's just the type of a register that's confusing to me.
[11:16:29] <LeoNerd> All registers are uint8_t
[11:16:52] <LeoNerd> Except some of the pseudo-faked-up 16bit pairs e.g. the ADC result
[11:16:55] <LeoNerd> or 16bit timers
[11:17:09] <dsal> But I can't just have the right value of a uint8_t var and |= into it and have outputs happen.
[11:18:35] <LeoNerd> Sure
[11:18:42] <LeoNerd> Hence the port pointer
[11:19:04] <LeoNerd> e.g. in my first example; *port |= mask; will set a bit in the port
[11:19:24] <dsal> Yeah. Gonna give that a shot.
[11:19:46] <LeoNerd> To construct one you could eg. { .port = &PORTB, .mask = _BV(PB2) } to refer to the PB2 pin
[11:19:56] <dsal> I'm trying to see if I can manage multiple pwm outputs with a timer. (not using hardware pwm since it doesn't do what I want, AFAIK, and there aren't enough of them).
[11:20:06] <LeoNerd> Ahyes.. I've done softPWM before
[11:20:19] <LeoNerd> Ihave a nice little 6-LED softPWM driver with charlieplexing on 3 IO pins
[11:21:07] <dsal> I wrote an RC radio thing that outputs a digital protocol, but then I started making cheap planes that would benefit from dumb pwm. Seems like a fun challenge.
[11:22:24] <dsal> Each channel takes 1-2ms to output, I need a bit of downtime, and I get updates every 9ms. I could do up to 8 channels. Just need to calculate when to fire timers.
[11:22:36] <dsal> It's going to be weird when they're close together, though.
[11:22:53] <cehteh> for blinking leds i have some test code here for a io-sequencer ... will integrate that later
[11:23:03] <LeoNerd> If you have lots of RAM spare, you could prerender a set of all 8ms of bytes to output into a long buffer
[11:23:11] <cehteh> one can load blink patterns for each output there
[11:23:14] <LeoNerd> Then just output a byte then a short delay in a loop
[11:23:35] <LeoNerd> E.g. for 8bit PWM resolution you'd need an array of 256 bytes
[11:23:58] <dsal> OK. I think you guys and your expertise seem to know an approach that sounds better than mine.
[11:24:23] <cehteh> you can safe some space when you do the logarithmic correction first and have only 32 brightness levels
[11:24:32] <cehteh> (or 16 .. 4 bit)
[11:25:08] <cehteh> when dimming PWM in 8 bit most of the 256 levels are useless anyway
[11:25:13] <LeoNerd> Yah; my idea is less suitable for 16bit PWM ;) You don't get AVR chips with 64Ki of RAM
[11:25:17] <LeoNerd> Yea
[11:25:52] <dsal> I'm not doing lights. I need to get an output that's as close to 1µS as I reasonably can in the 1000µS - 2000µS range.
[11:26:30] <cehteh> servo driver :D
[11:26:33] <dsal> Is there something magical that can do that?
[11:26:40] <LeoNerd> You could get -exactly- 1µs if you wanted... 16MHz crystal gives you 16 instructions
[11:26:43] <cehteh> pwm can do that
[11:26:53] <cehteh> only one channel?
[11:26:57] <cehteh> 16 bit pwm
[11:26:59] <dsal> On like, 4-8
[11:27:06] <cehteh> then it gets more complicated
[11:27:18] <cehteh> who was the one who wanted to build a robot?
[11:27:30] <cehteh> i sketched some days ago how to do that for a lot servos
[11:27:32] <dsal> I mean, I'd take one... but that's not what I'm doing now.
[11:27:33] <LeoNerd> Waaait a moment. With only 8 channels, there's only 8 values you need to remember.
[11:27:39] <cehteh> but its not that simple
[11:27:46] <dsal> I think I can do it with the one timer.
[11:27:51] <LeoNerd> You can solve this in 8 * {8 + resolution} bits of memory
[11:28:10] <cehteh> problem is rather the jitter timer wont be enough if anytihng else produces interrupts
[11:28:28] <cehteh> LeoNerd: you know how servos signals work?
[11:28:38] <LeoNerd> Create 8 structs { uint8_t value; uint{PWMsize}_t time }; and sort them by time. The first value will be 0xff, and each value thereafter will lose one or more bits
[11:28:41] <LeoNerd> So the final value is 0
[11:28:57] <cehteh> yes
[11:29:02] <LeoNerd> Now; reset the timer to zero, let it run.. if the count matches the next 'time', output the new value then advance.
[11:29:19] <cehteh> something like that
[11:29:19] <LeoNerd> 16 instructions ought to be enough to implement that if you're careful, and you can run 8 channels at 1µsec resolution
[11:29:39] <LeoNerd> Well, provided your 8 channels are all 8 bits of a single 8bit IO port
[11:29:42] <cehteh> and you have 20ms time for the next frame
[11:30:16] <cehteh> downside is that you need to disable interupts while you drive your servo loop for approx 1ms
[11:30:22] <LeoNerd> But yaknow, if I wanted an 8 channel PWM controller for servos I'd use a TLC5940
[11:30:35] <LeoNerd> :)
[11:30:48] <LeoNerd> (which is 16channel 12bit)
[11:30:57] <cehteh> or slap a tiny with a 16bit counter to every 2 servos
[11:31:10] <cehteh> connect that via spi/twi done
[11:31:44] <LeoNerd> Mm.. Speaking of which:should I feel bad that my next ATtiny84 project will be basically a specialised I²C-attached GPIO expander?
[11:32:03] <cehteh> why? :D
[11:32:07] <LeoNerd> It has some input pins for buttons and output pins for PWM'ed LEDs, on I²C+INT.
[11:32:17] <LeoNerd> It's *almost* like just using one of those PCF chips, except with PWM
[11:32:34] <cehteh> i once reimplemented a ne555 on a tiny13
[11:32:36] <LeoNerd> I can find plenty of bus-attached PWM drivers, or plenty of bus-attached plain GPIOs with interrupt, but none with both.
[11:33:06] <LeoNerd> I mean, it's not inherently bad... the 'tiny chip costs /about/ the same as any of those generic expanders anyway.. so I don't feel too bad
[11:33:19] <LeoNerd> It just costs me time to write the code
[11:35:39] <cehteh> mhm .. uart, queue .. errors .. i flag errors, but i wonder if it makes sense to mark at which byte in the rx queue the error happend
[11:35:50] <cehteh> .. possibly wasted effort
[11:35:53] <dsal> LeoNerd: You basically described what I was planning to do.
[11:36:09] <LeoNerd> dsal: Though I only have two PWM channels
[11:36:16] <LeoNerd> You have 8 :) I was just going to use the hardware module for it
[11:36:42] <dsal> Will pwm do what I want?
[11:37:13] <LeoNerd> If you want 8 channels, you'll have to find a chip that has 8 of them. I don't think there's many
[11:37:36] <dsal> Oh. Yeah. I don't mind getting pretty close if I can do it with a timer hack.
[11:37:52] <dsal> I'm trying to make a really dumb rx for really cheap rc planes.
[11:38:18] <cehteh> what do you use as radio receiver?
[11:39:08] <cehteh> and what price do you target?
[11:39:24] <dsal> I have this working:
http://www.aliexpress.com/item/CC2500-SPI-2-4GHz-Wireless-Transceiver-Module/32610339676.html
[11:39:34] <cehteh> methinks simple frsky receivers are less than $20
[11:39:50] <cehteh> they have a stm32
[11:39:53] <LeoNerd> Ohoh! I found one.. MAX7313. 16 IO pins, each pin can be a PWM output or an interupt-capable input
[11:40:26] <LeoNerd> Only 4bit PWM but that's fine for my LEDs
[11:40:36] <dsal> cehteh: Sure. I've got a friend who makes a pretty great one. I also found those Airwolf things (but those are done so very poorly).
[11:40:43] <LeoNerd> Perfect for a remote control
[11:41:19] <cehteh> dunno much about that cheap stuff
[11:41:35] <LeoNerd> Ugh.. except: only available in a tiny QFN24 package and 3.6V absolute max. I wanted DIP and 5V
[11:41:39] <cehteh> i rather dont want my copters to fall out of the sky
[11:43:36] <dsal> Heh. I'm not flying with anything I've made yet. My code's pretty solid so far. And one of the planes I flew this weekend was $2 or so in material for the bulk of the body, an old motor from a quad, an old ESC from a failed quad experiment, two super cheap servos, a couple bent pieces of metal, and some glue.
[11:43:44] <dsal> The d4r in it cost more than the rest of it.
[11:45:52] <cehteh> yeah ok
[11:46:28] <cehteh> things here are a bit more expensive :D but still i only crash what i've build
[11:46:44] <dsal> Sure, I've built a ton of quads. :)
[11:48:58] <cehteh> https://pbs.twimg.com/media/Cgqsc3rWgAAgQhV.jpg:large when finished maybe 550-580g .. @ 7000g thrust :)
[11:53:06] <dsal> Heh. That's kind of absurd.
[11:54:08] <cehteh> nah fun
[11:54:29] <dsal> Do you plan to FPV that?
[11:54:35] <cehteh> yes
[11:54:43] <dsal> I basically can't LoS quads.
[11:54:55] <cehteh> ah i do a lot LoS
[11:55:02] <dsal> I can stand around and do some basic tricks and stuff, but more just kind of "walking" than flying.
[11:55:28] <cehteh> i have to learn backward flying :D
[11:56:02] <dsal> When my quads go nose in, they turn on me and attack.
[11:56:11] <cehteh> i mean in the same way than forward .. with acrobatic manevers
[11:56:28] <cehteh> lol
[11:56:38] <cehteh> go learn that .. its important for survival
[11:56:52] <dsal> I've pretty much only done planes LoS the last few weekends. I might accidentally have learned something from that.
[11:57:03] <cehteh> my big quad minces cows .. you really want to be in control at any position
[11:57:58] <dsal> I've got a 550 tri with 9" props. I've autotuned that in my basement. heh. My biggest quad is 6045s. I've got > 140A through it a few times. But I'm super comfortable FPV.
[11:57:59] <cehteh> flying forwad is somewhat simpler yes
[11:58:04] <cehteh> also with a quad
[11:58:19] <dsal> I run dumb high rates, though. They can change their minds at any moment.
[11:58:39] <cehteh> my big one is 2.5kg 12" props .. goes 90km/h
[12:00:17] <cehteh> gtg now cu tomorrow
[12:01:14] <dsal> ttyl
[13:03:57] <Evidlo> Can I program an AVR through ISP but leave the power pin disconnected?
[13:04:13] <Evidlo> The AVR is powered through a separate 3.3V supply.
[13:09:28] <dsal> Yeah, I do that on 3v3 stuff sometimes.
[13:10:19] <Evidlo> dsal: even though the ISP programmer is 5V?
[13:11:13] <dsal> Hmm. Mine has a jumper to disable its input power for that reason. I don't actually know what it does.
[13:13:30] <Evidlo> dsal: Yeah the datasheet says the max input voltage to IO pins is VCC + 0.5
[13:13:43] <Evidlo> so I think 5 - 3.3 = 1.7V is a bit much
[13:16:45] * Xark 's cheap programmer has a 5v/3.3v switch (and the fancy one senses power - but doesn't provide it from VCC connection).
[13:17:43] <Xark> If you can fiddle with it to power programmer with 3.3v it probably will work. :)
[13:18:37] <Xark> Or perhaps temporarily power circuit at 5v (if it can take it)?
[13:20:34] <GeneralStupid> Hi, i have a strange behaviour in atmel ASF with usb cdc. I thought i have to implement RTS/CTS Flow control by myself. Is there any REAL documentation for that?
[14:00:47] <GeneralStupid> is there a flow control or something? i guess atmel already implemented something (because the signal is not available)
[14:06:23] <twnqx> i implemented it myself as the once i had didn't have it
[14:07:30] <GeneralStupid> twnqx: i want to implement DTR/DSR by myself and i recognized that the ASF set CTS to high…
[14:07:48] <twnqx> what's ASF?
[14:08:16] <GeneralStupid> so i configured QSerialPort (the PC side) to hardware flow control. But it does not work as it should, so i think Atmel uses some mixture of DTR/DSR, RTS/CTS
[14:08:24] <GeneralStupid> twnqx: Atmel Software Framework
[14:08:51] <twnqx> ok...
[14:09:01] <twnqx> no idea about that
[14:09:15] <GeneralStupid> how did you implement that?
[14:09:22] <twnqx> only rts/cts
[14:09:27] <GeneralStupid> ok...
[14:09:33] <GeneralStupid> thats what i tried, too
[14:09:39] <twnqx> i was overflowing my usb2serial converter
[14:09:52] <twnqx> so i had to fix that
[14:29:34] <phinxy> Whats up with the unpopulated SMD pads on the back of the AVR Dragon?
[14:46:04] <hetii> Hi
[14:48:07] <hetii> I port avr stk500 programmer from
http://tuxgraphics.org/electronics/200705/article07052.shtml to esp8266 to have wifi programmer
[14:48:27] <hetii> I can reprogram fuses etc.. and all that works fine
[14:48:41] <hetii> but I cannot get why avrdude resd just FF
[14:48:52] <hetii> after writting flash
[14:59:21] <Emil> What could be the problem
[14:59:31] <Emil> I compiled all the software from scratch
[14:59:38] <Emil> and there is no atmega328pb
[14:59:53] <Emil> 168pb, 48pb, 88pb
[14:59:57] <Emil> but no 328pb
[15:00:00] <Emil> in avrdude
[15:08:27] <LeoNerd> Often it doesn't know about very new chips, indeed
[15:08:32] <LeoNerd> You can usually take an existing config entry and clone it
[15:08:36] <LeoNerd> I had to teach it about the tiny841
[15:08:56] <LeoNerd> Make yourself a $HOME/.avrduderc, clone the 'part' chunk from an existing file and edit until correct
[15:09:29] <liwakura> maybe copy the avrdude config from arduino
[15:09:31] <Emil> But it's strange
[15:09:36] <liwakura> it has a shitton of chips
[15:09:39] <Emil> it's the latest avrdude version
[15:09:58] <Emil> from 16.2.2016
[15:10:11] <Emil> v 6.3
[15:16:08] <Emil> LeoNerd: where's that part chunk by default?
[15:23:28] <LeoNerd> ?
[15:23:31] <LeoNerd> Oh.. Mm.. noidea
[15:23:40] <LeoNerd> I'd start looking in /usr/share
[15:23:55] <LeoNerd> I'd also consider dpkg -L avrdude or strace the running binary
[15:25:49] <Emil> it was in /usr/local/etc/avrdude.conf
[15:26:46] <Emil> also on /etc/
[15:28:23] <Emil> Can't program efuse to ff
[15:29:00] <Emil> But I'm not sure if it affects any of the values
[16:10:24] <Emil> Avr-gcc doesn't regognice my atmega328pb installation
[16:12:44] <dsal> What's this pb stuff? I'd heard of that at some point.
[16:13:48] <antto> maybe that chip is too new?
[16:15:20] <Emil> the shit is that I compiled from source
[16:16:01] <antto> does the "source" include support for that chip?
[16:16:50] <Emil> Should
[16:16:57] <Emil> But alas, avrdude doesn't either
[16:17:00] <Emil> which is fucking silyl
[16:17:23] <antto> why is it silly about avrdude?
[16:17:32] <Emil> antto: because I built it from source too
[16:17:39] <Emil> they are all from 2016
[16:17:44] <Emil> oldest from February
[16:17:57] <antto> you know avrdude is a tool made by a few volunteers
[16:18:01] <Emil> binutils-avr, gcc-avr, avr-libc and avrdude
[16:19:40] <LeoNerd> People.. opinions: I²C (actual I²C, not my silly one), over unshielded signal cable. How far practically can I go? Could I do a couple of meters at least? It's only a GPIO expander with buttons/LEDs, so I'm happy to run at a really low bitrate...
[16:20:02] <Emil> LeoNerd: slow bitrate?
[16:20:15] <Emil> with *
[16:20:17] <Emil> easily
[16:22:03] <LeoNerd> I think I just found the I²C equivalent of using a 74'595 on an SPIport to hang some LEDs on
[16:22:26] <LeoNerd> PCF8574. It doesn't really have a data format or registers. You just write a byte to it and it outputs those values.
[16:23:04] <LeoNerd> But... any value you output as a high bit only weakly sources current with a pullup resistor. So you can use buttons to ground on it. If you do that, you can read the pins back in. and it has an interrupt
[16:23:12] <LeoNerd> It's prettymuch perfect for LED/button remotes
[16:24:17] <liwakura> okay
[16:24:19] <liwakura> close call
[16:24:30] <liwakura> my bootloader is 510 bytes big
[16:24:39] <liwakura> just a word left
[16:24:48] <LeoNerd> There must be some feature you can implemnt in that spare space
[16:24:54] <antto> nop nop
[16:25:01] <liwakura> antto: onto it
[16:25:51] <antto> that's all i know about ASM.. just nop nop nop nop ;]
[16:26:16] * liwakura slaps antto
[16:26:23] <antto> ouch
[16:26:23] <liwakura> how long is a "nop" in AVR?
[16:26:34] <liwakura> no double nop
[16:26:35] <antto> one blink of an eye
[16:26:38] <liwakura> its just nop
[16:27:18] <antto> or 1/FCPU
[16:28:10] <liwakura> okay
[16:28:15] <liwakura> now the other question
[16:28:26] <liwakura> how the fuck do i burn it onto the chip so it will run
[16:28:37] <antto> you need a programmer
[16:28:45] <liwakura> a second
[16:28:53] <liwakura> got one usb asp
[16:28:58] <antto> and you need to set the fuses properly
[16:29:08] <liwakura> nah
[16:29:14] <antto> so that it starts in the boot section first
[16:29:19] <liwakura> imma just copy the ones from optiboot
[16:30:07] <antto> be careful what you copy, more specifically, careful what fuse values you program onto your chip, even if they come from <something else> that "works"
[16:30:23] <liwakura> i just modified optiboot
[16:30:36] <liwakura> ws2812 led at PB5...
[16:30:45] <antto> better throw the fuse values into "avr fusecalc" (search it on the net) and check out what they mean for your specific chip
[16:30:57] <liwakura> link?
[16:31:44] <antto> http://eleccelerator.com/fusecalc/
[16:34:23] <liwakura> hm
[16:34:27] <antto> if the chip is programmed via ICSP, and you disable the SPI, you will not be able to re-enable it back (without some more serious programming method, which is complicated)
[16:34:29] <LeoNerd> Hahaha
[16:34:34] <LeoNerd> fusecalc is good but it's ooooold
[16:34:38] <LeoNerd> it does'nt know any of the newer chips
[16:34:58] <antto> LeoNerd do ya know anything bett0r?
[16:35:06] <LeoNerd> Not online, no
[16:35:07] <antto> besides "RTFM"
[16:35:22] <LeoNerd> I have my -own- calculator as a commandline script
[16:35:33] <liwakura> shit
[16:35:36] <LeoNerd> But you have to then type in the names of aaalll the fuses, because the XML files don't give defaults :(
[16:35:40] <antto> well, it knows even a few xmegas
[16:35:58] <liwakura> the fusecal says 3E00 start address is for 512 words
[16:36:14] <liwakura> but my stuff is starting at 3E00 and only has 512 bytes
[16:36:38] <liwakura> and goes to FLASHEND
[16:37:32] <antto> which chip is that?
[16:37:40] <liwakura> atmega328p
[16:38:10] <liwakura> hm. fusecalc says the same like datasheet
[16:38:23] <liwakura> but its clearly wrong
[16:38:30] <liwakura> 0x200 is never 512 words
[16:39:16] <liwakura> i dont like this.
[16:39:17] <antto> how much flash does it have?
[16:39:24] <antto> 16kB?
[16:39:48] <liwakura> my version actually has 32 kb, so its actually 0x7e00 - 0x7fff
[16:39:49] <liwakura> but same problem
[16:43:00] <liwakura> hm
[16:43:03] <liwakura> i think i got it
[16:43:08] <liwakura> it uses word addresses
[16:43:34] <antto> yeah
[16:44:02] <antto> smallest boot size for atmega328P seems to be 512 bytes, max is 4kB
[16:44:52] <antto> well, looks like the fusecalc is correct
[16:45:03] <liwakura> the optiboot defaults go into the 1024 bytes mode
[16:45:09] <antto> 256 words, offset=3E00
[16:45:22] <liwakura> im gonna use that mode
[16:55:25] <liwakura> do i need to crossover miso and mosi?
[16:58:43] <liwakura> ahaha
[16:58:47] <liwakura> half blind
[16:59:27] <liwakura> soldering an ws2812 to the SCK pin was the most stupidest idea i ever had
[17:00:44] <GeneralStupid> mache mir halt mehr gedanken über die tests
[17:01:03] <liwakura> starting avrdude reliably causes the ws2812 to go #FFFFFF
[17:01:13] <dsal> haha
[17:01:28] <dsal> You could cut its power.
[17:01:44] <liwakura> its guerilla-soldered onto the board...
[17:03:02] <liwakura> still having an black spot on my retina
[17:07:17] <liwakura> GeneralStupid: wrong channel?
[17:09:33] <liwakura> at least i know now that i connected SCK correctly
[17:11:24] <liwakura> ah. i do not need to crossover MISO and MOSI
[17:11:42] <liwakura> i guess the crossover is already done on the usbasp side
[17:14:31] <GeneralStupid> liwakura: i was switching my screens to fast ;)
[17:14:40] <liwakura> i guessed
[17:27:43] <liwakura> aaaaah
[17:27:52] <liwakura> the bootloader talks to me
[18:11:23] <Flecks> so guys, for fading leds, any good formula/function to make it linear for eye? or lookuptables is the way?
[18:13:46] <Lambda_Aurigae> one would think it would depend on the LED, the voltage you run it at, the current limiting resistor used, etc.
[18:14:25] <Flecks> not so mutch, it all boils down to human eye as I have found out :D
[18:14:39] <Flecks> like this article:
https://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/
[18:14:44] <Lambda_Aurigae> liwakura, miso to miso, mosi to mosi...always.
[18:15:04] <liwakura> figured out
[18:15:21] <Lambda_Aurigae> master out slave in...so on the master side it is output on the slave side it is input.
[18:15:32] <liwakura> oh
[18:15:32] <Lambda_Aurigae> same for miso, only backwards in reverse.
[18:15:34] <liwakura> nice to know
[18:15:39] <Lambda_Aurigae> master in slave out
[18:15:46] <liwakura> its sorta different for tx and rx i know
[18:15:49] <Lambda_Aurigae> yup.
[18:16:03] <Lambda_Aurigae> tx is always transmit..rx is always receive..so you cross them
[18:16:23] <Lambda_Aurigae> no master/slave definition in a UART/USART really.
[18:17:00] <Lambda_Aurigae> Flecks, I still think different LEDs brighten differently under the same voltage/pwm
[18:17:18] <Lambda_Aurigae> and an LED will vary differently under different voltage levels given the same PWM
[18:18:03] <Lambda_Aurigae> but, yes, one should take into account the perception of the human eye as well.
[18:18:23] <Lambda_Aurigae> different PWM frequencies can also affect the eye's perception I bet.
[18:20:38] <liwakura> if its over 50 Hz or so, then not
[18:21:15] <liwakura> except when the pwm is close to 0%, then people might notice that it flickers
[18:21:41] <Flecks> I use 1KHz
[18:21:59] <Flecks> and it works just like that for white leds, red leds and green leds :D
[18:22:07] <Flecks> all different size/current rating
[18:24:11] <dsal> How does one program an attiny4?
[18:24:30] <Lambda_Aurigae> dsal, with a tpi programmer one would think.
[18:24:44] <dsal> What's that? I've only done the icsp thing.
[18:25:12] <Lambda_Aurigae> it's in the datasheet...also Tom_itx was selling a programmer that did ISP, and TPI
[18:25:26] <Lambda_Aurigae> ICSP is for PIC
[18:25:29] <Lambda_Aurigae> ISP is for AVR
[18:26:01] <dsal> TIL
[18:26:14] <dsal> I've always thought that six pin thing was called ICSP.
[18:26:33] <Lambda_Aurigae> again, ICSP is PIC...ISP is AVR
[18:26:55] <Lambda_Aurigae> it's a patent thing.
[18:27:22] <dsal> Sure, I read that. I just didn't know that was a different thing.
[18:27:27] <dsal> Is it the same protocol?
[18:27:31] <Lambda_Aurigae> no.
[18:27:41] <Lambda_Aurigae> totally different.
[18:27:43] <dsal> I know nothing of PIC
[18:27:57] <Lambda_Aurigae> attiny 4/5/9/10 use TIP,,,Tiny Programming Interface.
[18:28:07] <Lambda_Aurigae> which is rather different from ISP for the larger chips.
[18:28:18] <Lambda_Aurigae> page 159 of the datasheet for the attiny4.
[18:28:27] <Lambda_Aurigae> section 17.6 External Programming
[18:28:51] <Lambda_Aurigae> all of section 17 talks about programming the chip.
[18:29:05] <Lambda_Aurigae> I understand the USBASP type programmers can be hacked to do TPI.
[18:29:40] <inflex> I do TPI over a USBTiny
[18:29:58] <dsal> Yeah, it looks like I've got enough stuff around the house to try it.
[18:30:00] <inflex> it's a simple hack, just a 1K resistor from MOSI -> MISO, then use MISO as TPIDATA.
[18:30:12] <inflex> You'll need to patch avrdude though
[18:30:20] <inflex> ( I have 6.3 prepatched here already if you're not sure )
[18:31:30] <dsal> I don't have one. Just decided I need one now.
[18:33:08] <inflex> np, I don't know if the patch works on usbasp, but certainly usbtiny it does :)
[18:33:41] <dsal> I use usbtiny most of the time.
[18:33:56] <dsal> I've not actually tried usbasp. Some boat has a 10 -> 6 pin adaptor so I can give it a try.
[18:34:02] <dsal> I found some things about doing it with arduino.
[18:34:09] <dsal> How to physically do it is going to be the next thing.
[18:38:04] <inflex> I ended up making a daughterboard
[18:38:56] <dsal> I'm look at the sot-23 things. Ideally, I'd have something I could ZIF into or something for the programming.
[18:39:13] <dsal> But even then, I'm screwed after initial programming.
[18:39:59] <inflex> You can buy ZIF SOT23 sockets for about $30~$40 already built up
[18:40:23] <inflex> If you're going to use them in pinthrough boards then you sort of defeat the purpose of them though (using a T10)
[18:40:25] <dsal> Woah. I thought I made that up.
[18:41:29] <inflex> http://ctpc.biz/tpid.png <=- daughter board I'll use on my tinyISP
[18:42:10] <inflex> actually already designed another one with built in high-voltage programming option, and a calibrate facility
[18:43:05] <inflex> ( the reason for the 3x2 header on mine is because I still have some of Tom's HVP adapters which use that configuration, so I can plug them in and go off to my existing SOT23-6 programming boards
[18:43:13] <dsal> Where do you get these zif things? I found pictures, but not products.
[18:43:30] <inflex> I just place the T10 on those SOT23-6 pads, press down, and press enter to program :)
[18:43:50] <dsal> Heh. Yeah. That could work.
[18:44:01] <inflex> http://www.ebay.com.au/itm/SOT6-TO-DIP6-B-SOT-6-IC-Test-Socket-Programming-Adapter-for-SOT6-SOT23-Package-/251019097845?hash=item3a71e776f5:m:moFiePysl7ubsG7QjhIkPHA
[18:44:26] <inflex> http://www.ebay.com.au/itm/Free-Shipping-SOT23-6L-IC-Test-Socket-Programmer-Adapter-Burn-in-Socket-/172018057467?hash=item280d1340fb:g:rIgAAOSwNphWYEmn
[18:44:46] <inflex> bare tester,
http://www.ebay.com.au/itm/499-P44-20-REV-A-SOT6-SOT-23-Wells-IC-Test-Burn-in-Socket-Adapter-0-95mm-Pitch-/251080289625?hash=item3a758d2d59:m:mwpGWu3_VWKYTj5avK4JKBg
[18:46:01] <dsal> Neat, thanks.
[18:46:23] <inflex> Anyhow, I do find normal HASL finish tarnishes up quickly, so if you go the way of a daughterboard, perhaps consider getting a gold finish
[18:46:28] <dsal> First one I found was $274.
[18:46:58] <inflex> heh, can make you choke a bit :)
[19:34:31] <dsal> If I want something like a watchdog timer, does it make sense to set TIMER0 = 0 to accomplish it?
[19:34:41] <dsal> Someone was advising against playing with timer values, but they seem so playful.
[19:35:43] <Lambda_Aurigae> dsal, need more info.
[19:35:54] <Lambda_Aurigae> your avr chip has a watchdog timer onboard.
[19:35:57] <Lambda_Aurigae> most likely.
[19:36:00] <dsal> Yeah, but I need ~2.5ms
[19:36:11] <dsal> So I want a timer that fires at about 2.5ms, but I reset it to 0 regularly.
[19:45:44] <Lambda_Aurigae> the minimum time on the avr(atmega1284p) is 7.8125ms
[19:46:20] <Casper> can be faster than that
[19:46:26] <Lambda_Aurigae> oh?
[19:46:34] <Lambda_Aurigae> I thought it ran on the 128KHz oscillator
[19:46:55] <Casper> he talk about using the timers...
[19:47:01] <Lambda_Aurigae> yeah.
[19:47:08] <Casper> timer run off the main clock
[19:47:13] <Lambda_Aurigae> I'm just rambling.
[19:47:27] <Lambda_Aurigae> oh...prescaler can make it run faster.
[19:47:46] <Lambda_Aurigae> so can div by 2 or 4
[19:47:56] <Casper> div/1
[19:47:57] <inflex> lo Casper
[19:48:08] <Casper> o/ inflex
[19:48:21] <Lambda_Aurigae> Casper, looking at this datasheet...says 16ms to 8s...
[19:48:45] <Lambda_Aurigae> so my math is off.
[19:50:09] <Casper> that is still for the WDT
[19:50:21] <Lambda_Aurigae> I know.
[19:50:29] <Lambda_Aurigae> again, I'm just rambling.
[19:55:00] <inflex> Damnit, want a new reflow oven... don't have $250 for it :(
[19:55:36] <inflex> ...and *still* can't find my powered vacuum pickup tool... might have thrown it out :(
[19:57:20] <Casper> :(
[19:57:23] <Casper> make a new one?
[19:57:59] <Lambda_Aurigae> get a toaster oven used for 10 dollars
[19:58:07] <Lambda_Aurigae> build a controller from scrap bits for free.
[19:59:44] <inflex> Casper, well, I've still got the chassis/oven of the old original one I used to use
[20:00:00] <inflex> Casper, just don't know what I've done with the controller and I'm in no mood to rebuild one
[20:01:15] <inflex> The other thing is, it's too big, too power hungry and doesn't have sufficient power ( in spite of its hunger ) to really work the best, esp with lead-free
[20:01:35] <Lambda_Aurigae> so, get a full oven!
[20:01:37] <inflex> I think I'd be better off getting a $20 skillet
[20:01:39] <inflex> :p
[20:01:42] <Lambda_Aurigae> that works too.
[20:01:57] <Lambda_Aurigae> I was thinking an induction cooker and cast iron skillet.
[20:01:59] <inflex> Lambda_Aurigae, I'll get a proper oven soon as I get enough $, shouldn't take too long
[20:02:18] <inflex> Lambda_Aurigae, ja, that would work, or just an offcut from a local steel supply store
[20:03:13] <Lambda_Aurigae> K type thermocouple for a temp sensor, some other bits-n-pieces, some coding, and voila.
[20:04:36] <inflex> Lambda_Aurigae, already done it all before (I prefer PT1000 sensors, easier to interface with, less noise )
[20:07:14] <inflex> Lambda_Aurigae,
http://ctpc.biz/oven.jpg <=- from 2008 :)
[20:07:49] <inflex> No surprise I'm after a new one, it's getting a tad old ;)
[20:07:53] <Lambda_Aurigae> I built one for the local hackerspace.
[20:08:20] <Lambda_Aurigae> I also had to explain to them why I had to use a toaster oven and not a microwave oven they had handy.
[20:08:28] <inflex> can't believe it's been 8 years... :\ explains why my multimeter is also a bit out of calibration
[20:09:17] <Lambda_Aurigae> they think arduino is the height of technology
[20:09:54] <Lambda_Aurigae> when I brought up using different microcontrollers for different projects and purposes they pretty much ignored me and everybody went out and bought a bunch of arduinos.
[20:32:29] <inflex> I do often wonder if Arduino (language) has done more harm than good... tough to decide
[20:33:02] <Lambda_Aurigae> the language is just C/C++
[20:33:03] <inflex> I think it's great we have so many more ppl involved in the field, that's mostly a good thing
[20:33:19] <Lambda_Aurigae> but the libs have caused a lot of dumbing down of users.
[20:33:27] <inflex> I know... but it obscures a lot of what should be known
[20:33:42] <inflex> I just write in plain C and what ever the avr-gcc lib normally provides
[20:34:10] <Lambda_Aurigae> yup.
[20:34:12] <Lambda_Aurigae> same here.
[20:34:20] <Lambda_Aurigae> and bits of assembly here and there.
[20:35:16] <inflex> on a slightly different platform, working on the RPi the other week, using GPIO, person couldn't get a fan-tach reading right via Python, was a horrid stack of code. Wrote it in about 10 lines of C and turned out about 6K binary
[20:35:54] <inflex> I don't deny python and such are very good languages to build a lot of things in... but handling stuff like that really is more the realm of C/ASM
[20:36:30] <Lambda_Aurigae> python is not meant for real world/realtime interfaces.
[20:36:38] <inflex> talking i2c on Pi was even easier again in C than Python, no libraries required either (assuming you're using the kernel interface to /dev/i2c)
[20:36:42] <inflex> exactly
[20:37:59] <Lambda_Aurigae> I've never actually written anything in python
[20:38:05] <Lambda_Aurigae> but have had to hack it some.
[20:38:57] <Casper> I think the arduino actually did more good than harm, it revived the DIY stuff, which was almost dead
[20:40:19] <inflex> Casper, I agree with you there, and now with the Pi, I think we've got a resurgence finally
[20:40:33] <inflex> I think back in the late 90s the big problem was the formidable cost vs return
[20:40:43] <inflex> not to mention the poor distribution
[20:40:53] <Casper> currently, china destroyed most
[20:41:27] <inflex> I'm also glad we now have the likes of Digi, E14, Mouser and RS... online and fast to deliver
[20:41:57] <inflex> Back "then" you were lucky to have 0.01% of available parts and you wondered where the hell to get many things as the local RadioShack/Tandy/Jaycar/DSE had pretty much stuff all
[20:42:48] <inflex> On the other side of things, the advent of lithium batteries has also helped a lot, along with brushless motors ... yep, it's been an impressive 15~16 years
[20:42:51] <Casper> Like, right now, I'm working on the electrical of an old golf cart... The lights is an isssue: 36V battery, 12V lights. Unmatched. Can't series/parallel them to get to 36V, too much current for a linear reg, and 36->12V regulators >15A are hard to get by... Yet, china have them, with unknown quality... Might go china
[20:43:25] <Casper> or do the math and add some resistors to balance...
[20:43:39] <inflex> Change to LED lights?
[20:43:53] <Casper> too $$
[20:43:58] <Casper> not mine, uncle's one
[20:44:06] <inflex> fair enough
[20:44:25] <inflex> and yes, 15A buck converting... rough going
[20:44:57] <Casper> 2.71A for the headlights (each), 2.1A for the tail light
[20:46:15] <Casper> ow well, bath time, bbl
[20:46:30] <inflex> mm... can you do gold-contact finish after a PCB is manufactured?
[20:46:56] <Lambda_Aurigae> gold plating is doable.
[20:47:01] <Casper> why not? if you can apply current to the contact, then you can
[20:47:46] <inflex> not sure I can get an AU finish on these PCBs via itead or seeed (can with GoldPhoenix though, but I don't want 100 boards)
[22:14:56] <dsal> Hmm... So, TCNT0 = 0 doesn't appear to be resetting my timer.
[22:15:02] * dsal sigh
[22:15:03] <dsal> dumbass
[23:23:30] <dsal> How do I do PORTB |= _BV(n) in asm? (I've got n in a register)
[23:23:36] <dsal> I'm doing like, a loop with lsl right now.
[23:23:37] <dsal> feels wrong
[23:25:09] <Casper> don't know the syntax, but look for sbi
[23:26:23] <dsal> sbi requires a literal. that's what I tried first.
[23:26:32] <dsal> My n is variable.
[23:31:22] <Casper> I see... considering that the avr have no "shift by x bit".. I'm guessing that a loop or a "switch" like would be required.... but I don't do asm, so can'T say what is the best way...
[23:34:36] <dsal> Yeah. I did the loop. It seems OK.
[23:50:46] <inflex> What about using a LUT
[23:51:55] <inflex> I suppose it depends on what you've got more of, flash, or time
[23:53:04] <dsal> I'm going for speed to some degree. I could "unroll" it kind of.
https://usercontent.irccloud-cdn.com/file/CUL66u8B/latency.png
[23:53:31] <dsal> Each channel is a little slower to react. attiny85's only giving me 4 channels, so my worst is behind by 4.3µs
[23:54:08] <dsal> Big picture: Reading PPM and outputting PWM:
https://usercontent.irccloud-cdn.com/file/UhG6ug9M/pwmppm
