#avr | Logs for 2016-02-15

Back
[00:12:18] <Deskwizard> yeah I've had the same problem initially
[00:13:13] <Deskwizard> Alex1992: http://fourwalledcubicle.com/AVRArticles.php
[00:13:28] <Deskwizard> started from scratch reading those, it helped in my case
[00:13:46] <Deskwizard> Dean's way of explaining it gets through to me
[00:13:52] <Deskwizard> which is quite an accomplishement really lol
[00:17:49] <Alex1992> thanks deskwizard, i'll look through this stuff. I think I need to install MinGW to fix that error, according to the internet
[00:18:05] <Alex1992> but installing and using MinGW isn't too easy either :/
[00:18:58] <Deskwizard> Alex1992: I honestly don't know :| good luck though!
[00:21:05] <mohsen_> What do the values of x y z in the serial output mean?https://learn.adafruit.com/adafruit-hmc5883l-breakout-triple-axis-magnetometer-compass-sensor/wiring-and-test
[00:21:18] <cehteh> morning
[00:21:24] <WormFood> They're X, Y, and X axises
[00:21:41] <WormFood> the 3 different directions you can go in free space
[00:22:57] <cehteh> http://www.vitatec.com/images/page-content/erdmagnetfeld-neu-600.jpg?sfvrsn=2
[00:23:11] <cehteh> should explain why you want 3 axis magnetimeters
[00:24:40] <mohsen_> I know a magnetometer is for finding the direction of X,Y,Z but a direction is just a direction not a number?
[00:25:00] <cehteh> angle?
[00:25:05] <mohsen_> X,Y and in the link I sent have numeric values
[00:25:05] <WormFood> Directions are quantifiable
[00:26:17] <WormFood> get the datasheet for that sensor, and see
[00:26:43] <cehteh> from a peek on the link pasted, the sensor gives measurements in microTesla
[00:26:54] <cehteh> per axis
[00:27:53] <mohsen_> You mean the direction is calculated from the values of x,y,z?
[00:27:54] <cehteh> µT
[00:28:04] <cehteh> yes
[00:28:26] <mohsen_> The direction that the sensor is heading?
[00:28:35] <mohsen_> I mean getting moved?
[00:28:47] <cehteh> not moved, rotated
[00:29:21] <Deskwizard> 'morning cehteh
[00:29:24] <cehteh> the sensor has (see datasheet) 3 axis usually on aligned to the chip
[00:30:31] <cehteh> btw you may like quaternions ,, even when you dont understand them (i dont either :D)
[00:30:58] <cehteh> but they are a nice representation of directions in space
[00:31:12] <mohsen_> You mean another variable in addition to xyz?
[00:31:32] <cehteh> convert it
[00:32:03] <mohsen_> To what?
[00:33:05] <cehteh> https://en.wikipedia.org/wiki/Quaternion
[00:33:24] <cehteh> looks complicated, but actually its simpler as it looks
[00:35:12] <cehteh> moreover when you calculate this x,y,z measurements to newtonian angles (angle in each plane) you run into a lot corner cases with huge or very small numbers which becomes inprecise or even not calculateable (tan(0))
[00:35:22] <Deskwizard> :| so, with those 4 dimentions, can we finally time travel?
[00:35:28] <cehteh> quaternions a free of those
[00:35:29] <Deskwizard> or teleport at least? please? lol
[00:35:39] <Deskwizard> (sorry, I stfu now)
[00:35:55] <cehteh> i dont understand that math either, but its much simpler to use than it looks like
[00:37:53] <mohsen_> I see
[05:22:24] <WormFood> http://wormfood.net/avrbaudcalc-testing.php <-- I'm done with the calculator part, unless someone notices a bug. I'm gonna clean it up a little bit, and put up as the main calculator page.
[05:23:48] <cehteh> arent the colors off? the green shades?
[05:24:05] <cehteh> 25.00 81 0x051 24.98 -0.1% 163 0x0A3 24.98 -0.1%
[05:24:09] <WormFood> I changed them. Did you like it the other way better?
[05:24:17] <cehteh> the legend is wrong
[05:24:30] <WormFood> Yes. That is one of the parts I need to clean up.
[05:24:46] <WormFood> The colors will change, depending on the number of data bits+parity
[05:25:57] <cehteh> you may include slower baudrates 25 30 50 150, not that they are pretty useful but they give a hint into what ballpark range you are
[05:26:14] <WormFood> Also, I need to fix one of the tables, but I doubt most people will ever use it.
[05:26:26] <cehteh> and wasnt nasa's deep space probes at some incredibly low baudrates?
[05:26:31] <WormFood> I thought about putting 110 on the table.
[05:26:45] <WormFood> The low baud rates help with the distance.
[05:26:47] <cehteh> somewherei in the 10's ..
[05:26:56] <WormFood> at high speed, a burst of static could destroy several bits
[05:27:03] <cehteh> yes
[05:27:13] <WormFood> and without a 2-way hand shake, the transmitter can't tell it needs to resend.
[05:27:32] <cehteh> when a handshake takes a day things get complicated :D
[05:27:44] <WormFood> You know why I thought about putting 110 bit rate on the table? Do you know what uses that speed?
[05:27:55] <cehteh> how far out are the voyagers? 15 hours?
[05:28:06] <WormFood> dunno
[05:28:16] <WormFood> far enough to make communications interesting.
[05:28:31] <cehteh> or rather incredibly complicated
[05:28:51] <cehteh> well for debugging i used 50 baud here
[05:29:40] <cehteh> clock at highest divider on the nano gives 60somewhat kHz ... 50 baud works then .. and you can see the bits going over the line
[05:29:42] <WormFood> that's a painfully slow speed
[05:30:15] <cehteh> sometimes slowmo is what you want .. checking the rendering on the terminal emulator (lineedit)
[05:30:17] <WormFood> I remember back in the 300 bps modem days, how slow it was. I could almost type that fast.
[05:31:26] <WormFood> anyways, I'm done with the hard work on my calculator now. Just cleaning up a few things.
[05:31:43] <cehteh> next pwm calculator :D
[05:33:31] <Haohmaru> and a "when will i be rich" predictor pls
[05:34:16] <cehteh> thats simple
[05:34:25] <cehteh> printf("NEVER\n");
[05:34:28] <Haohmaru> shadap! >:(
[05:40:42] <WormFood> Alright, I fixed the legend. Does it make sense?
[05:42:13] <Deskwizard> lol
[05:45:29] <cehteh> yep better
[05:49:22] <cehteh> looking at all the tables only confirms me that 9600 baud is what one wants to use in general
[05:49:37] <cehteh> least problems and fast enough for most things
[05:49:50] <WormFood> Of course, it depends on what you're doing.
[05:50:39] <twnqx> i'd say 1 or 2 mbaud is what one wants to use...
[05:50:52] <twnqx> usually a perfect match
[05:51:10] <cehteh> huh
[05:51:36] <twnqx> well, at least linux users have no issues with that
[05:51:47] <twnqx> windows... well, i don't care about windows
[05:51:56] <cehteh> i'd also consider that handling the input needs processing time, too fast baudrates may drop data or stall anything else
[05:52:07] <WormFood> My fastest serial port, only does 230k baud
[05:52:27] <WormFood> well, I don't know what my usb-serial adapter can do.
[05:52:30] <twnqx> WormFood: are you sure? ever ftdi does mbit/s
[05:52:33] <cehteh> its often not sane to go as fast as possible
[05:52:35] <WormFood> that probably goes much higher
[05:52:51] <Deskwizard> im with cehteh on that one.
[05:52:54] <WormFood> normal max speed for a serial port, is 115.2k
[05:53:07] <Deskwizard> because you can != you should
[05:53:10] <twnqx> cehteh: for sending data to the µC... maybe, yeah
[05:53:20] <twnqx> for the other direction.. no prob at all
[05:53:27] <WormFood> Newer ports go faster, but 115.2k is the fastest lowest common denominator
[05:54:04] <cehteh> twnqx: problem is that serial has the same speeds in both directions
[05:54:12] <cehteh> i'd like if TX would be faster :/
[05:54:34] <twnqx> actually, 2mbit/s is not trivial, even on a fast desktop :P
[05:54:47] <twnqx> i actually lost data when i read byte by byte :P
[05:54:56] <WormFood> how can the tx be faster, if the receiver is not faster as well?
[05:54:59] <cehteh> 9600 rx, 115200 tx would be nice
[05:55:08] <twnqx> linux kernel syscall overhead was to high
[05:55:12] <WormFood> then the other end, would be opposite
[05:55:17] <Deskwizard> cehteh: sounds like traffic in MTL. lol
[05:55:28] <cehteh> :D
[05:55:28] <WormFood> in some instances, it'd be good
[05:56:05] <cehteh> someone, i think LeoNerd suggested me to make TX a bit faster, i implemnted that here
[05:56:23] <LeoNerd> Hmm?
[05:56:32] <cehteh> some TXBOOST config var, calculating the baudrate 0.3% faster or so
[05:56:40] <Deskwizard> cehteh: RX on uart0, tx on uart1 ?
[05:56:41] <Deskwizard> :P
[05:56:41] <LeoNerd> I don't recall that
[05:56:46] <cehteh> LeoNerd: wasnt you?
[05:56:51] <cehteh> then someone else
[05:57:04] <Deskwizard> or rx in soft/semi
[05:57:05] <Deskwizard> idk
[05:57:13] <cehteh> nah too much trouble
[05:57:19] <Deskwizard> mkay
[05:57:24] <WormFood> Two women are hiking in the woods, and they come to a river that is too wide to cross, so they start walking along the river, until they come to a bridge. 1/2 way across the bridge, one of the women stops, and says "I always wanted to see what it feels like, to be 'one of the guys', and pee off a bridge". Her friend looks around, and says "well, I don't see anyone, so now is your chance"...
[05:57:36] <Deskwizard> but yeah I agree it would be nice, bitch to set in hyperterminal though :P
[05:57:59] <Deskwizard> WormFood: lol
[05:58:13] <WormFood> so, she pulls her pants down, and backs up to the side of the bridge, and let it fly. She looks over her shoulder, and screams "oh my god! I just peeded in a canoe!", and her friend said "relax, it's just your reflection in the water"
[05:58:26] <Deskwizard> LMFAO
[05:58:39] <cehteh> m(
[05:58:44] <Deskwizard> i have to remember that one
[05:59:11] <WormFood> How do you make a turtle fast?
[05:59:16] <WormFood> Don't feed it.
[06:00:01] <cehteh> https://www.youtube.com/watch?v=hyUmGHdK9e8
[06:00:12] <twnqx> but back to the serial speeds... i don't think that mbit/s speeds will stall your code for too long, as it means that data comes down in bursts. of course, your application has to have at least a ring buffer then, and be able to survive the bursts - and you'll probably want an assembly written irw handler
[06:00:13] <twnqx> irq*
[06:01:17] <theBear> even ancient avrs got something over 10bytes of serial-assistey buffer if my memory ain't gone defective suddenly, that buys a lotta microseconds at most serial rates
[06:01:49] <nikomo> if I have a function for sampling the ADC, where I sample the ADC, wait for conversion, and return result, I can't do anything whilst waiting on the conversion. lame. oh well.
[06:02:19] <twnqx> yeah
[06:02:34] <twnqx> all this "waiting for stuff" in a µC is pretty annoying
[06:03:01] <cehteh> is it?
[06:03:13] <twnqx> i kinda want to rewrite a large mess i made where 99% of the code is actually running in interrupt handlers to be event based, and everything can run asynchronous (including the periodic ADC polling)
[06:03:14] <nikomo> they're my cycles, and I want them now
[06:03:17] <WormFood> theBear, my memory is also the same. It's a minimum of 1 byte, but I want to say it's a few bytes.
[06:03:30] <cehteh> ah busy wait you mean
[06:03:52] <twnqx> yes, busy wait, other forms don't really matter :P
[06:04:05] <cehteh> thats why i am working on my scheduler
[06:04:10] <cehteh> never ever busywait :D
[06:04:11] <theBear> heh
[06:04:29] <twnqx> i don't like multithreading/tasking in avr
[06:04:46] <twnqx> too many registers to save, to expensive task switching
[06:04:48] <twnqx> too*
[06:04:54] <cehteh> well scheduler runs, working on TX queue still, serial queue which stores data in binary
[06:05:12] <cehteh> not multitasking ,, just queue functioncalls
[06:05:25] <theBear> evne if you gotta throw together a little (as they should always be,) interrupt routine to catch serial interrupts and throw the data somewhere until you wanna deal with a reasonable ram vs time kinda chunk of it, that won't cut into overall processing time much
[06:05:25] <cehteh> each has to complete before the next is scheduled
[06:05:29] <twnqx> wouldn't you still have to save regs?
[06:05:35] <cehteh> only one stack, no context switching
[06:05:39] <cehteh> no
[06:05:49] <theBear> and of course not, "multitasking" on a micro is as wrong as everything ms made this century or so <grin>
[06:06:25] <twnqx> i mean, a scheduler is only a few hundred bytes in code
[06:06:28] <cehteh> well there is a option to call the scheduler recursively which will need stackspace ..
[06:06:49] <cehteh> something one should avoid, i didnt even tested/used that yet
[06:06:55] <twnqx> but i really don't like the cost of task switching compared to cpu clock speed
[06:07:11] <cehteh> exactly
[06:07:18] <cehteh> i dont like that either
[06:08:26] <theBear> interrupts aren't switching, they're "free"
[06:08:42] <nikomo> how are they "free"?
[06:08:43] <twnqx> you still have to save regs
[06:08:43] <theBear> but that's also why the interrupt code itself should always be short and sweet
[06:08:59] <twnqx> i have deep nested function calls in my interrupt handlers
[06:09:05] <twnqx> and the timer interrupt even registers callbacks :P
[06:09:12] <theBear> oh, you talking assembly land, well, yeah, but ya know, small price to pay if it gains you a few bytes of serial buffery
[06:09:16] <theBear> buffoonery ?
[06:10:37] <WormFood> theBear, it's 2 bytes of buffering
[06:10:42] <twnqx> oh, serial buffer... boring
[06:10:59] <twnqx> no, i run deeply nested stuff in irq handlers
[06:11:12] <twnqx> receive a can packet, and fully process it, queue up responses, etc
[06:11:18] <twnqx> including higher level protocols
[06:11:28] <twnqx> horrible, horrible design, but seems to work.
[06:11:41] <WormFood> "The Data OverRun (DORn) Flag indicates data loss due to a receiver buffer full condition. A Data OverRun occurs when the receive buffer is full (two characters), it is a new character waiting in the Receive Shift Register, and a new start bit is detected."
[06:12:30] <Jartza> avr ISR has latency anyway
[06:12:39] <Jartza> it's not immediate
[06:12:50] <theBear> nested irqs ? not sure i like the sound of that <grin> short sweet irq handlers is just one of "the rules" that yer never break if yer even close to enough experience to know they exist :)
[06:13:00] <Jartza> and then you need to push the registers anyway
[06:13:18] <theBear> pfft, until i got a thousands or smaller hand on my wristwatch i say it's pretty damned immediate <grin>
[06:13:46] <Jartza> when ISR happens, the instruction currently in pipeline is being executed first anyway
[06:13:51] <Jartza> that'll be 1-3 clock cycles
[06:13:58] <Jartza> then the PC is pushed to stack, 2 more cycles
[06:14:07] <Jartza> and jump to vector, 3 cycles
[06:14:14] <Jartza> and usually the vector is another jump, 3 cycles :)
[06:14:46] <Jartza> so you might've missed 11 cycles already when you're in the beginning of ISR
[06:14:51] <cehteh> thats why you better use hardware where available, capture unit, uart etc
[06:14:54] <Jartza> and _then_ you start pushing the registers to stack
[06:15:48] <Jartza> but still I've done task switching multitasking with separate stacks for tasks, with attiny85 :()
[06:15:54] <Jartza> :) even
[06:16:11] <cehteh> it works .. but makes no much sense for real stuff
[06:16:16] <Jartza> it all depends how quick switches you need to make
[06:16:32] <cehteh> and how much ram you need
[06:16:55] <Jartza> well, that's really up to your choise of avr
[06:17:09] <Jartza> task switching is the same and doesn't really depend on that .)
[06:18:01] <Jartza> but I mean, how much you "lose" in task switching depends how responsive your stuff needs to be
[06:18:14] <Jartza> if you can live with task switching 100 times a second, versus 1000 times
[06:19:04] <Jartza> for example, chip runs @8Mhz and you switch 100 times a sec. the switching is not very high percentage of the clocks you have
[06:19:31] <Jartza> each task runs almost 80000 clock cycles before switching and the switching takes in a ballpark of 50 cycles
[06:20:03] <Jartza> but if you need to switch 1000 times, then it's 50/8000
[06:20:34] <Jartza> first case is 5000 "lost" clock cycles per second, last one is 50000 lost cycles :)
[06:21:05] <cehteh> ram is the limiting factor
[06:21:22] <Jartza> it limits the number of tasks
[06:21:27] <WormFood> if you need to switch 1000 times per second, then you can probably do it another way.
[06:21:47] <cehteh> and it is a bit hard to predict how much stack space is needed when you have some deeper nested calls in different threads
[06:21:50] <Jartza> if you need more ram, get bigger avr :)
[06:22:12] <cehteh> aiming for worst case would be a big waste
[06:22:52] <Jartza> I tend to try limiting stack use always anyway
[06:23:00] * cehteh thinks his scheduling function calls, not threads is a good approach
[06:23:01] <Jartza> on other architectures too
[06:23:18] <Jartza> just saying, it can be done and it's not even that hard
[06:23:41] <cehteh> if you keep functions small enough and dont do lengthy loops or deep recursion its pretty clear whats going on
[06:23:45] <Jartza> I'm not saying it's the best way to do it :)
[06:24:05] <theBear> i learned the asm in a dark and ancient time long long ago when diy hw programming involved several BIG dip chips just to do half of what a tiny little avr does in one package now, thus limited stack approaches come naturally to me
[06:24:31] <WormFood> theBear, you sound like an old man.
[06:24:33] <Jartza> who needs stack anyway ;)
[06:24:34] <theBear> i also think compiling c remotely efficiently for such a small cpu/system is amazing and tend to be lazier than i probly should :)
[06:24:49] <theBear> WormFood, heh nah, just jaded and trying to keep on the happy side of bitter <grin>
[06:24:50] <Jartza> like this: https://github.com/Jartza/octapentaveega
[06:24:52] <Jartza> no stack, no cry
[06:24:59] <Jartza> all of the ram used for screen buffer
[06:25:05] <WormFood> C for AVR is awesome. I'm really impressed with how efficient it is.
[06:25:09] <Jartza> let registers be your variables ;)
[06:26:06] <theBear> WormFood, indeed, it's not rocket science when you compare your pre compiled to the final output asm, but still far from trivial to write a compiler and optimizey stuff to achieve the same
[06:26:31] <theBear> and there's no denying gcc has really kicked some ass AND taken several names sine the late 2.x times up to present
[06:27:47] <Jartza> optimization-wise some commercial compilers still kick it's ass though
[06:28:03] <Jartza> I don't know what's the situation with AVR but at least on ARM-side
[06:43:23] <WormFood> I've helped to contribute to gcc-avr. I submitted the ibutton CRC code.
[06:43:36] <WormFood> Because I needed it, and they didn't have it.
[06:54:47] <nikomo> crc16.h has crc8 functions.
[06:55:02] <nikomo> ... I'm going to assume the file name is because of some horrible past decision and now they regret it
[06:56:58] <Lambda_Aurigae> http://www.gpf-comics.com/archive/2016/02/15
[06:57:10] <Lambda_Aurigae> standard programmer mentality/functionality
[06:58:39] <Jartza> nikomo: yeah, should've used TEMPLATES!!! :D
[06:58:46] <Jartza> crcnn.h
[07:02:36] <twnqx> i have a memory tester written in 100% C that only uses registers
[07:02:52] <twnqx> just make sure you don't use more vars than you have regs :P
[07:03:13] <twnqx> and inline EVERYTHING so you don't use stack by accident
[07:22:37] <Jartza> in gcc you can even reserve registers for variables
[07:47:16] <LeoNerd> https://twitter.com/cpan_pevans/status/699220177297268737 my latest board.. an *almost* complete success... <.< >.>
[07:48:01] <LeoNerd> (mega328P, PCF8563 RTC, PL2303SA USB-UART bridge)
[07:58:18] <Jartza> LeoNerd: happens :)
[07:58:34] <Jartza> last fumble I made with board was with oscillator
[07:58:52] <Jartza> why, oh why, oscillator datasheets show the pinout from _bottom_
[08:02:32] <cehteh> lol
[08:02:54] <cehteh> because cheap chinese copies?
[08:05:03] <Jartza> nop
[08:05:40] <Jartza> even quality ones, like abracon
[08:05:41] <Jartza> https://i.imgur.com/LmDS5eJ.png
[08:06:16] <Jartza> I remember even briefly thinking "oh, they have the pins clockwise, not counterclockwise like ICs"
[08:06:22] <Jartza> and then just made the footprint :D
[08:06:47] <Jartza> luckily that was through-hole component
[08:06:51] <Jartza> so I just placed it underside my board
[08:06:55] <Jartza> but still it was stupid :D
[08:07:50] <Jartza> oh well. back to debugging. laters!
[08:10:30] <LeoNerd> Hah... Yes; a throughhole SD card holder would have helped me too
[10:35:24] <julius> hi
[10:35:42] <julius> what kind of ampere would you expect from a 12v windshield washer motor?
[10:36:58] <LeoNerd> 1A would be 12W. Is 12W a lot of movement power?
[10:37:18] <Emil> julius: did you try to google that? ; )
[10:37:23] <julius> have to check it at home, was just interrested
[10:37:29] <julius> oh. i missed that
[10:37:51] <julius> Emil, i googled the part number i got...but that thing only got information for what car it fits
[10:40:03] <Emil> julius: julius probably a maximum of 2 amps
[10:40:25] <Emil> or something along thosel ines
[10:40:52] <Emil> Meaning just put in a mosfet and everything is fine ; )
[10:42:31] <cehteh> dont forget the flyback diode :D
[10:42:59] <Emil> an excellent point
[10:43:21] <julius> https://www.mikrocontroller.net/articles/Datei:Motor_PWM1_real.gif this circuit is for up to 10a
[10:43:35] <Emil> which is more than enough
[10:43:41] <julius> yes
[10:44:00] <cehteh> julius: there are simpler logic level mosfets
[10:44:05] <julius> the thing is that i want to control it with pwm, i only want to water a plant with it. so it needs to run very slowly
[10:44:05] <Emil> most of the left part is there to drive the saturation level higher
[10:44:13] <julius> cehteh, such as?
[10:44:25] <cehteh> ah halt moment needs driver o guess for 12V
[10:44:26] <Emil> julius: he means that you don't really need the left part at all
[10:45:03] <Emil> if you choose appropriately for the mosfet that you'll control
[10:45:37] <Emil> it all depends on the the GS-voltage of the mosfet and what saturation level will you reach with that
[10:45:56] <Emil> s/will you/you will/
[10:46:37] <Jartza> julius: my astra seems to have 4A motor
[10:46:45] <Jartza> or well, it says "max 4A"
[10:46:50] <julius> will the startup power of the motor still be 5a if its controled with pwm and on for like 10% of the time, or will that reduce the ampere?
[10:47:13] <julius> Jartza, yes, that seems to be common. found that number in two different places
[10:47:14] <Jartza> but as motors go... the more you put load on them, the more amperage they eat
[10:47:15] <Emil> julius: amperes are not a unit of power ; )
[10:47:26] <Emil> anycase
[10:47:28] <cehteh> startup current may be way higher
[10:48:23] <cehteh> julius: IRLU024N
[10:48:34] <cehteh> used them working :D
[10:49:30] <Emil> julius: the inrush current will usually be higher than during normal operation but it might not matter. If you are concerned about it just include a smooth start circuit
[10:49:31] <julius> that thing got enough power. combined with a flyback diode thats all i need?
[10:50:40] <cehteh> IRLU024N available from reichelt, up to 17A, logic level compatible
[10:50:52] <Emil> julius: plenty
[10:51:22] <cehteh> 4A should work w/o cooling
[10:51:27] <Emil> julius: you don't need a logic level mosfet if you simply buffer it
[10:51:37] * flyback sinks his teeth deep into julius's leg meat
[10:51:59] <Emil> unless, of course, the GS-voltage is too high to even turn the mosfet on at your logic levels
[10:53:15] <cehteh> or just use some generic driver
[10:53:20] <julius> flyback, oh im sorry
[10:53:27] <julius> didnt know youre here
[10:53:33] <cehteh> uln2003? .. bit too big but cheap and will do
[10:53:50] <julius> even from my "local" store, its 44cents
[10:54:07] <Emil> cehteh: the amps on that one appear too small
[10:54:10] <julius> cehteh, yes reichelt is what i use if it has to go quick
[10:54:19] <cehteh> Emil: which one?
[10:54:33] <Emil> uln2003
[10:54:39] <cehteh> as driver for the mosfet
[10:54:41] <flyback> eheheh :P
[10:54:54] <Emil> cehteh: aaaah
[10:54:54] <cehteh> for that its actually way too big
[10:55:01] <cehteh> but easily available and cheap
[10:55:35] <Emil> cehteh: you can usually just use another mosfet ; )
[10:55:45] <cehteh> yes
[10:56:33] <julius> so that thing eats 5v for as a control current, with a protection for the motor circuit like this: Schottky diode, TO-220AC, 45 V, 10 A im good to go?
[10:57:12] <cehteh> TO-220AC?
[10:57:22] <cehteh> is that the diode?
[10:57:25] <julius> from the other circuit i posted, yes
[10:58:08] <cehteh> what?
[10:58:45] <cehteh> just some simple diode will do
[10:59:20] <julius> are they quick enough?
[10:59:51] <cehteh> simple schottky then
[11:00:24] <cehteh> no need for 10A
[11:00:59] <cehteh> 1A type should work
[11:01:11] <Emil> yeah pretty much any diode will do
[11:01:45] <cehteh> 1n4148 might be a bit small :D
[11:02:09] <Emil> cehteh: I don't think so, actually
[11:02:22] <cehteh> 'might' .. could be working already
[11:02:25] <Emil> it's mostly to protect from the high voltage spike
[11:02:28] <cehteh> yeah
[11:02:37] <Emil> not from a lot of current, really
[11:02:58] <cehteh> well if someone turns the motor manually it may induce some current
[11:03:12] <Emil> true
[11:03:20] <cehteh> 1n4148 is really punny .. a little biggier one may not harm
[11:03:22] <Emil> but it's not likely they'll be generating much current
[11:03:28] <Emil> cehteh: but I do agree with that
[11:03:29] <cehteh> but no need for a 10A t220 tyle
[11:03:33] <Emil> yeah
[11:03:55] <Emil> but if one wants to overengineer then why not :D the cost difference is almost neglible
[11:04:09] <cehteh> lol
[11:04:55] <Emil> negligble*
[11:05:07] <Emil> negligible*
[11:05:15] <cehteh> i know what you mean :D
[11:05:25] <Emil> cehteh: yeah but I have to, for my own sake :D
[11:05:39] <Emil> I alwasy get that word wrong
[11:05:43] <cehteh> so .. whats the bug in my integer to string function .. grr
[11:06:07] <Emil> post code
[11:06:09] <julius> bigger is better ;)
[11:06:09] <cehteh> up to 0xfffffff it works
[11:06:15] <Emil> welllllll
[11:06:18] <Emil> could it be overflow :D
[11:06:25] <cehteh> should not
[11:06:35] <cehteh> but you dont want to see my code :D
[11:06:35] <julius> show the code
[11:07:16] <cehteh> http://paste.debian.net/389276/
[11:07:22] <Emil> cehteh: please, if it works up to that number then it is hunder precent sure overflow
[11:07:47] <cehteh> no its not .. its more the queue handling :)
[11:08:28] <cehteh> the challenge here is a int to string which is interruptible (when the queue is full)
[11:08:34] <cehteh> and can be resumed later
[11:11:46] <cehteh> lets test the uint16 variant :)
[11:11:52] <Emil> hmm
[11:12:14] <cehteh> the problem is likely in the caller
[11:12:27] <cehteh> but overall that code is a bit to complex for pasting here
[11:12:36] <Emil> why not just push it out at 115200?
[11:12:44] <Emil> it takes very little time
[11:12:48] <cehteh> eh?
[11:12:52] <julius> use a paste site like codepad.org
[11:13:00] <Emil> why do you need it to be interruptable?
[11:13:02] <julius> oh youz did
[11:13:15] <cehteh> because i dont have infinite ram?
[11:13:51] <cehteh> interuptable is the wrong word, its not interrupted
[11:14:11] <cehteh> but when suspended, state is preserved and can be called again to append the remaining digits
[11:16:51] <Emil> but
[11:16:59] <Emil> it takes less ram to just push it out :D
[11:17:03] <Emil> than to keep it
[11:17:12] <cehteh> no
[11:17:49] <Emil> yes.
[11:18:02] <cehteh> i have 2 queues .. one small queue (as small as 2 bytes only) for the TX interrupt handler which pushes out bytes
[11:18:26] <cehteh> and one biggier 'txqueue' which stores things in tagged binary representation
[11:19:15] <cehteh> output_uint32('0') will put a literal '0' byte on that queue for example
[11:19:30] <cehteh> instead 4 bytes
[11:19:52] <cehteh> also this queue can handle pointers to progmem strings and other tagged data
[11:19:57] <Emil> To push out a 64 bit number through 115200 serial takes like less than a millisecond
[11:20:04] <cehteh> and?
[11:20:12] <cehteh> a millisecond is a lot time
[11:20:19] <cehteh> and i am using 9600 here
[11:20:24] <Emil> use 115200
[11:20:25] <Emil> then
[11:20:27] <cehteh> still this doesnt matter
[11:20:52] <cehteh> the idea is to have this space efficient queue which will handle all kinds of data
[11:21:05] <cehteh> without blocking on io
[11:22:03] <Emil> but using the hardware rx and tx won't block anything
[11:22:38] <cehteh> mainly this is about conserving space
[11:22:56] <twnqx> in my code i just block if queueing is not possible
[11:23:07] <cehteh> 32 bit number in binary are 32 digits .. 32 bytes
[11:23:12] <Emil> you just need a single array of 8 chars
[11:23:20] <Emil> what
[11:23:23] <Emil> mate
[11:23:23] <Emil> pls
[11:23:24] <twnqx> what
[11:23:26] <cehteh> 0100100010...
[11:23:35] <twnqx> you print it.. in binary?
[11:23:40] <twnqx> why not hex?
[11:23:43] <cehteh> did you see that i support all kinds of bases
[11:23:58] <cehteh> just example
[11:24:16] <twnqx> ah, another generic code because "it might be useful some day"
[11:24:17] <Emil> what
[11:24:30] <twnqx> just stick to base 10 and 16, nothing else is ever really used
[11:24:38] <cehteh> well i could add decimal and hex only .. that are the most useful things
[11:24:45] <Emil> so you are printing chars that are either '0' or '1'
[11:24:47] <cehteh> but handling the base as parameter is simple
[11:25:15] <twnqx> i admittedly just use sprintf
[11:25:28] <Emil> then just bloody hell include another global char which is a counter
[11:25:29] <twnqx> because, you know, they have better optimized base 10 code than i could write
[11:25:48] <Emil> and on every call where you push another '0' or '1' out increment thbat
[11:25:50] <cehteh> some higher bases (base36) is sometimes useful for encoding binary data in ascii
[11:25:51] <Emil> ease as hell
[11:26:24] <cehteh> anyway .. thats not m bug :) .. so i go on
[11:26:51] <Emil> cehteh: do you really understand what you are doing
[11:27:46] <cehteh> yes
[11:27:48] <Emil> even if you wanted to print in multiple bases you are doing super inefficient code if you say that you need 32 chars to print a 32 bit number
[11:28:26] <Emil> you only need to store your shit in the native presentation, increment a counter and then print however you like, whichever base that is
[11:28:57] <Emil> so 32 bits takes exactly 4 chars
[11:29:21] <cehteh> thats what i am doing here
[11:29:39] <Emil> apparetly not
[11:29:41] <cehteh> storing 4 chars at most and be restartable
[11:30:02] <cehteh> pushing the digit which is due on the output queue
[11:30:35] <Emil> did you know that 0xfffffff is wider than 4 chars
[11:30:43] <Emil> oh sorry
[11:30:44] <Emil> it's not
[11:30:46] <Emil> my bad
[11:30:47] <cehteh> :D
[11:32:30] <NicoHood> !seen westf
[11:32:43] <NicoHood> dont we have bots in here?
[11:32:53] <NicoHood> does anyone know how to contact him?
[11:33:16] <NicoHood> well the question is: can fuse bits prevent something like this: http://oneweekwonder.blogspot.de/2014/07/bootjacker-amazing-avr-bootloader-hack.html
[11:33:45] <NicoHood> also he wrote something here i dont understand and would like to: http://hackaday.com/2014/07/05/overwriting-a-protected-avr-bootloader/#comment-2586139
[11:33:54] <LeoNerd> Only if you disallow SPM everywhere
[11:34:00] <LeoNerd> I'm not sure if that's an option is it?
[11:34:14] <LeoNerd> Actually it might be.. so not fuse bits as such, but lock bits
[11:34:25] <cehteh> different chips have different protection fuses
[11:34:29] * theBear disallows it, so it was spoken, so it shall be written, and so it SHALL be law !
[11:34:49] <cehteh> and if that article claims they found a bug in that .. maybe its possible
[11:34:57] <Emil> how I wish avrs were von neumann <3
[11:35:04] <Emil> but alas that is not the case
[11:35:14] <theBear> it's true, tho the large majority of avr8's even from the old series thru the current and fancy usb specific ones share many common traits, albeit often in different location/bits
[11:35:41] <theBear> and word on the street is i'm some bot gone wrong in the head, but i feel like a real boy
[11:37:49] <Emil> NicoHood: probably not preventable
[11:38:25] <Emil> NicoHood: but I don't understand why you are concerned with trying to prevent it?
[11:38:32] <Emil> you can simply prevent reprogramming
[11:40:28] <theBear> you can "lock" the (default area set aside for) bootloader zone on all the bootloader-suggested/"specced as capable" avrs i ever looked at a datasheet for, but ya know, like most lock and anti-readback bits, it's got lots of pros as well as one or two cons
[11:42:01] <Emil> anycase, the hack presented requires reprogramming the avr in the first place
[11:42:14] <Emil> so I don't super really understand why would you like to prevent it
[11:42:28] <Emil> I'd rather have it be possible at all times
[11:43:48] <LeoNerd> Yah; it's an interesting result in achieving something the original intent of which was to prevent, but it's hard to see how that can turn into a security/etc... issue
[11:44:07] <Emil> I'd rather have avr be capable of doing anything with its internals and have all error checking and so on when compiling
[11:44:51] <Emil> I mean, you can prevent reprogramming which will erase the content of the chip if set so it's just a blank avr
[11:45:33] <theBear> it's kinda the opposite of a problem, for a start program being able to write bootloader zoneis the only way to update a bootloader without a "special"/other programmer being needed, and once you can install new code (regardless of via a bootloader or any other programmer,) it's not exactly a security risk being able to write over the bootloader... you already able to run any code you want anyway
[11:45:50] <Emil> yeah
[11:45:57] <Emil> this exactly
[11:45:59] <theBear> micro/embedded land doesn't have the same issues with things like keyloggers catching important info that desktop/pc kinda systems do
[11:48:00] <Emil> If your physical security is compromised there's nothing you can really do. The attacker could even just switch the chip
[11:48:01] <NicoHood> well in this case its an important security risk
[11:48:12] <NicoHood> so people dont take over your device and flash a different firmware
[11:48:13] <Emil> then you are doing serurity wronmg
[11:48:37] <NicoHood> its a very small chance, but if we can avoid that, it would be great
[11:48:47] <Emil> NicoHood: give background information
[11:48:49] <Emil> what kind of device
[11:48:51] <Emil> what kind of userbase
[11:48:59] <theBear> the old switcho chango, the peruvian one-two they call it in some countries, mary jane and her little lamb...
[11:49:13] <NicoHood> on a device that keeps passwords
[11:49:16] * theBear tries to keep a straight face while saying these things as if they were fact
[11:49:34] <LeoNerd> If you have physical access to the device, you can replace the firmware.
[11:49:35] <NicoHood> a modified firmware could add a backdoor that saves the keys in plain text and someone can recover them.
[11:49:36] <LeoNerd> Full stop
[11:49:38] <LeoNerd> Nothing can stop that
[11:49:42] <theBear> my mindtank is only userbased by my body region afaict, if that answers your question :)
[11:49:47] <Emil> NicoHood: like I said
[11:49:51] <NicoHood> i have though about all that
[11:49:54] <theBear> and afaik it has only a front door and some bogey and sound holes:)
[11:49:54] <LeoNerd> Maybe you left ISP turned on? OK that's easy, I can attach a burner and write that
[11:50:00] <Emil> if your physical security is compromised then you are fucked
[11:50:04] <LeoNerd> Maybe you turned of ISP? No problem, I'll get my HVSP burner out instead
[11:50:09] <Emil> do you go around giving your keys to someone else?
[11:50:10] <LeoNerd> Maybe you.. er.. I dunno.. you can't disable that.
[11:50:29] <LeoNerd> If I *really* wanted, I could desolder the MCU and put my own one in place with my own custom-burned firmware that I created at home
[11:50:34] <NicoHood> if you have phyiscal access you need to break the device. it will be not useable. and even if possible, the bootloader contains a unique password to unlock. a faked bootloader will let you in alwyas or never with that password
[11:50:59] <Emil> NicoHood: then simply don't expose the programming pins
[11:51:14] <Emil> LeoNerd: yeah, I mentioned that above
[11:51:18] <NicoHood> you could open the avr for 500$ and replace it though. but well the device will be broken anyways. in this case you should be wondering why one would do that
[11:51:40] <NicoHood> yes we dont expose the programming pins
[11:51:47] <Emil> NicoHood: so what's the bloody issue then?
[11:51:52] <NicoHood> but we still need a bootloader that can upload new firmware
[11:52:05] <NicoHood> and if new firmware can update the bootloader we have a problem
[11:52:18] <NicoHood> because the bootloader should ensure the firmwares checksum is correct
[11:52:33] <NicoHood> the bootloader is also a recovey mode for checking the integrity of the firmware
[11:52:55] <NicoHood> at any time. if the bootloader is untrusted (aka modifyable) its not considered that the firmware is valid
[11:53:06] <Emil> NicoHood: then simply enable the fuses that disable reprogramming
[11:53:36] <Emil> your chip will be wiped clean if someone tries to reprogram them.
[11:53:43] <NicoHood> but the bootloader itself is the higest risk, not the ISP
[11:53:48] <Emil> .................
[11:53:49] <Emil> mate
[11:53:50] <Emil> pls
[11:53:57] <theBear> heck, for $500 i'd do a lot more than convincingly slice up an avr and wire something else in the hole before i carefully put the lid back on top
[11:54:32] <theBear> when yer a crippley pensioner with all the time that ever was to fill up (to avoid the stir crazies,) it's kinda horrible what you would consider doing for that kinda cheese
[11:54:34] <NicoHood> yeah. as i said, an hardware opening hack is not what i am focusing, but its still covered
[11:54:36] <LeoNerd> I'm struggling to work out what the problem is here
[11:54:41] <LeoNerd> Explain the hypothetical attack
[11:54:54] <Emil> NicoHood: if you don't understand that with an ISP you can rewrite everything your product is not something anyone should trust
[11:54:54] <LeoNerd> What does your hypothetical attacker have access to, and what is his end-goal?
[11:54:58] <NicoHood> i want to know if lock bits can preserv attacks from the firmware to modify the bootloader
[11:55:28] <Emil> NicoHood: and sorry but I hope you fail in your endeavour if you have not the slighest clue about this
[11:55:51] <Emil> A security product should not come from people who don't understand simple ideas
[11:56:07] <LeoNerd> If the chip itself allows SPM (which is required if you want the bootloader to work), and the bootloader actually contains an SPM instruction (see above); then no - any running AVR code can find that SPM instruction and execute it.
[11:56:44] <Emil> NicoHood: if you expose reprogramming pins then you are at the mercy of the user. This is why every keycard in existence should only be tied to a single user
[11:56:55] <LeoNerd> But why is this an issue?
[11:57:04] <NicoHood> can the avr code also acess that instruction if the lock bits are set? because this one sais its not possible: https://ucexperiment.wordpress.com/2014/12/19/reading-an-avr-bootloader-from-the-application-section/
[11:57:08] <LeoNerd> How has your attacker installed bad application code into it?
[11:57:24] <LeoNerd> This is the part I don't understand
[11:57:32] <cehteh> the best is that the bootloader must not allow flashing arbitary firmware ..
[11:57:33] <Emil> NicoHood: please such fucking understand that with an ISP you can reprogram the whole fucking thing
[11:57:54] <NicoHood> emil i know. but the bootloader contains a secret password the isp cannot read
[11:58:06] <Emil> NicoHood: and?
[11:58:10] <NicoHood> and if you burn a new firmware all passwords will be valid (in a faked bootloader) or none
[11:58:17] <NicoHood> so you can check if the bootloader is the same
[11:58:26] <cehteh> how?
[11:58:33] <LeoNerd> NicoHood: Can you answer my question please? To attack this, the attacker would have to install their own custom-made dodgy firmware. Why are you not preventing *that* from happening?
[11:58:37] <cehteh> your checks might be tampered
[11:58:39] <NicoHood> because your password will not work or all password will work
[11:59:20] <cehteh> what you can do is only allowing uploading encrypted firmware
[11:59:24] <LeoNerd> NicoHood: If you're allowing the attacker the ability to install their own dodgy firmware, then that firmware can just execute LPM directly to read out the entire contents of the memory, and thus recover that secret password. They'd not even have a need to run SPM to overwrite the firmware.
[11:59:27] <LeoNerd> Bootloader
[11:59:28] <NicoHood> leonerd: we are doing this also. but if the bootloader itself is not secure, we cannot go on. there are also options to secure the firmware flashing of course (with the password i mentioned)
[11:59:32] <LeoNerd> GAHHHHh
[11:59:33] <cehteh> bootloader has the key to decrypt it
[11:59:36] <LeoNerd> PLease stop and start again
[12:00:02] <NicoHood> cant you prevent the firmware from reading the bootloader section?
[12:00:17] <Emil> NicoHood: like I simply said: enable the "disable reprogramming"-fuse and everything is secure
[12:00:17] <NicoHood> would the closed source bootloader from teensy 2.0 not then have been leaked?
[12:00:18] <LeoNerd> NicoHood: The SPM hack described above is ONLY a problem if for some stupid stupid reason, you allow the attacker to upload whatever firmware they choose. So don't do that.
[12:00:30] <NicoHood> emil: that is what i was asking for
[12:00:34] <LeoNerd> NicoHood: If you properly sign and verify the *firmware* image as well as the bootloader, then all is fine
[12:00:42] <Emil> NicoHood: and it was said for ten fucking times already
[12:00:52] <LeoNerd> Emil: please stop
[12:01:13] <theBear> not recently firmware updated thunderbolt macs are all a bit vulnerable to running "card firmware" snippets verbatim on baremetal just moments after booting with a say, thunderbolt->ethernet cable, or similar... you can have the internal firmware both patched with your dodgy code AND even make it incapable of future updates via any non-physical/solder-based method if ya want, in a few seconds while it posting ready togo bong and start the about-to-boot
[12:01:14] <theBear> display
[12:01:30] <avr_0x01> Maybe someone is online now to help me with my kk2.1.5 board with this error?: verification error, first mismatch at byte 0x0000 0xff != 0x0c
[12:02:06] <NicoHood> leonerd: we prevent attackers from uploading bad firmware. i am just finding out what happens if that is already the case. because the bootloader should veryfy the firmware integrity. and if the bootloader is fakes, the firmware cannot be veryfied anymore. the bootloader could say "that firmware is trsuted"
[12:02:18] <LeoNerd> If there's *already* bad firmware in there then you're already too late
[12:02:19] <LeoNerd> you've lost
[12:02:42] <NicoHood> but emil said the lock bits prevent the firmware from accessing the bootloader code
[12:02:46] <LeoNerd> Forget overwriting the bootloader.. Your "crown jewels" is that password, yes? The attacker's bad firmware can just *READ THAT OUT* directly
[12:02:54] <Emil> NicoHood: like I said, enable "disable reprogramming" which will wipe the chip clean which in turn means that your attacker cannot access any secret keys
[12:03:49] <NicoHood> leonerd: but cant lock fuse bit prevent that? this also shows that it could be right, that lock bits can prevent it: https://ucexperiment.wordpress.com/2014/12/19/reading-an-avr-bootloader-from-the-application-section/
[12:03:50] <LeoNerd> NicoHood: OK... but then if you've disabled LPM'ing that password, how does the good firmware get to use it?
[12:03:53] <Emil> LeoNerd: the idea is that the bootloaded check for a known key given first and only then allows reprogramming
[12:04:06] <Emil> bootloader checks*
[12:04:26] <NicoHood> yep. the key is entered before reprogramming
[12:04:42] <LeoNerd> That doesn't sound very secure... Maybe your attacker can interrupt the reprogramming stream, to first send that good key, and then substitute their own firmware?
[12:04:50] <Emil> LeoNerd: of course
[12:04:54] <Emil> that's not the issue here
[12:04:55] <LeoNerd> Wait hang on.. this key is *just* for reprogramming?
[12:05:09] <Emil> LeoNerd: they still need to access that key
[12:05:16] <NicoHood> yes. only for reprogramming
[12:05:25] <LeoNerd> And why can't they just start a genuine reflash operation?
[12:05:40] <LeoNerd> I presume you're still allowing reprogramming *generally* because you want to allow in-the-field upgrades?
[12:05:49] <Emil> LeoNerd: because if they lose the preprogrammed key in the bootloader they cannot produce valid hashes
[12:05:54] <Emil> or that's what I presume
[12:06:05] <LeoNerd> I'm struggling to understand this security model now
[12:06:34] <NicoHood> should i maybepublish my paper about that so far?
[12:06:45] <LeoNerd> NicoHood: Can you please explain clearly, who your hypothetical attacker is, and what they are trying to achieve, that you are trying to prevent?
[12:06:50] <Emil> NicoHood: LeoNerd: but if your security product relies on the fact that you shouldn't be able to reprogram the bootloader then you are fucked from square 1
[12:07:09] <NicoHood> okay
[12:07:14] <Emil> NicoHood: if the attacker doesn't need the secret key to do attacks then you are fucked already
[12:07:28] <Emil> Because it is simply not possible to disable reprogramming the avr completely
[12:07:58] <LeoNerd> Er.. sure it is. :) You can turn off SPM in addition to using the LOCK bits, and then the *only* thing that can be done is a whole-chip erase using HVSP
[12:08:01] <LeoNerd> (or HVPP)
[12:08:10] <twnqx> desoldering is easy enough
[12:08:13] <Emil> which is the same as reprogramming
[12:08:25] <LeoNerd> Right; but that still doesn't leak information that used to be contained inside the chip
[12:08:28] <Emil> I KNOW
[12:09:00] <theBear> mmm, most commercial product installed avrs i stumbled on over the years (not just ambitious home-diy dudes, but real commercial 1000's all over the world kinda stuff,) haseverything locked up tight as can be, never read/verify access, seldom a bootloader, even isp-header or solder-to-program style is allowed by fusing... always seemed a bit overkill to me, who gonna wanna steal your stepper code or smoke/coffee machine heating-cycle and light-flashing
[12:09:00] <theBear> code on your several hundred or even 10s-of-thousand dollar fancy disco light product ? it's far from the straw that broke the camels back if someone wants to copy/clone/steal your business
[12:09:18] <LeoNerd> Yah... exactly that
[12:09:36] <Emil> LeoNerd: 2016-02-15 19:42:17 < Emil> NicoHood: if the attacker doesn't need the secret key to do attacks then you are fucked already
[12:09:40] * LeoNerd waits to see what NicoHood has to say...
[12:10:06] <NicoHood> The bootloader is meant to upload new firmware to the device (for authorized people) and also for veryfying them at any time. the firmware should be always trusted. even if someone can modify the firmware you can use the bootloader to get the checksum of the firmware. if its not what you expect, then the firmware is faked. to ensure the veryfication works correct, the bootloader needs to be secure. if the firmware can change the
[12:10:13] <Emil> But if they do need a secret key to do attacks then their scheme will work just by enabling the "disable reprogramming"-fuse
[12:10:33] <LeoNerd> NicoHood: But who is the *attacker*?
[12:10:43] <Emil> NicoHood: Not. Possible.
[12:10:56] <LeoNerd> You are trying to prevent someone from doing something here. Please explain *WHO* the person is, and *WHAT* you are trying to stop them doing
[12:11:20] <Emil> NicoHood: you can reflash the bootloader
[12:11:29] <Emil> but you can't then extract any information within the bootloader
[12:11:59] <theBear> if you just flashed it why you care about extracting what you flashed ? you already "posess" it
[12:12:23] <Emil> theBear: because I hope they are doing hashes or other cryptography
[12:12:36] <twnqx> bascially, that's why reasonable bootloaders use asymmetric encryption
[12:12:37] <Emil> that rely on the bootloader's secret key
[12:12:48] <NicoHood> the bootloader contains a secret key which cannot be read (if the lock fuses thing works). then a new flashed bootloader will not work the same way.
[12:12:53] <twnqx> extracted the bootloader? still doesn't give you the secret key, just the public one :P
[12:13:06] <LeoNerd> NicoHood: You are repeatedly failing to answer my question. If you don't answer my question then I cannot help you. So please help me to help you.
[12:13:19] <NicoHood> that was for emil
[12:13:27] <LeoNerd> NicoHood: Again: Please explain *WHO* the person is, and *WHAT* you are trying to stop them doing
[12:13:46] <Emil> twnqx: but in that case you could simply rewrite the bootloader
[12:13:52] <Emil> ->into the trash the device goes
[12:14:07] <Emil> because then physical security is broken
[12:14:12] <twnqx> the difference is: overwriting the bootloader requires physical access
[12:14:32] <twnqx> while "hey, here's some (malicious) new software" works great against your regular users.
[12:14:39] <NicoHood> the attacker could be someone getting access to the device (that holds your passwords), modfy it, add a backdoor and give it back to you. you type passwords, his backdor writes them in eeprom and he steals them later. like an evil colleague or so
[12:14:50] <LeoNerd> Right. Thank you
[12:14:53] <LeoNerd> So... that is *always* possible
[12:14:59] <twnqx> then don't bother with your bootloader indeed
[12:15:04] <twnqx> physical acces => goodbye
[12:15:04] <LeoNerd> If you give me physical access to your device, I can *ALWAYS* modify it
[12:15:17] <NicoHood> no
[12:15:26] <LeoNerd> If it comes down to it, Ican build myself a *brand new device* that looks like yours, and substitute it
[12:15:30] <Emil> yeah
[12:15:33] <LeoNerd> Anything else is just saving me time or money, on doing that
[12:15:36] <NicoHood> if that is true, why isnt the teensy 2.0 bootloader source code not leaked?
[12:15:42] <twnqx> what
[12:15:44] <Emil> NicoHood: what
[12:15:46] <LeoNerd> Because nobody considers it worth their time
[12:15:56] <twnqx> because it's like 20k to open up a chip and read the flash
[12:15:59] <NicoHood> leonerd, even if you do that, you dont have the secret key inside the device
[12:16:00] <twnqx> 20k€
[12:16:02] <LeoNerd> I *could* do that easily, if I had a scanning-tunneling microscope and ....
[12:16:10] <twnqx> bah
[12:16:11] <LeoNerd> I just don't have one, nor do I have enough interest in doing so
[12:16:31] <twnqx> you just "solder" wires to the right parts of the flash
[12:16:33] <Emil> NicoHood: oh yeah, you can't prevent physical inspection of the bits in any way
[12:16:40] <LeoNerd> Every possible security mechanism ever invented, or that ever will be invented, is simply a time/money/energy barrier; that is all
[12:16:57] <twnqx> NicoHood: step a: do not, ever, use a shared secret approach. use a private/public key approach.
[12:17:14] <LeoNerd> If I wanted to keylog your computer I could likely find dozens of ways to do it. But I wouldn't bother doing that if I didn't think it worth my time or money
[12:17:18] <Emil> twnqx: disagree
[12:17:27] <Emil> symmetric crypto is much, much faster
[12:17:33] <twnqx> yes, and far less ecue.
[12:17:34] <NicoHood> and smaller
[12:17:35] <julius> to run my 12v water pump, would you use 12v as supply voltage and "get that down" to 5v for the avr. or use 5v and make 12v out of it for the pump?
[12:17:36] <twnqx> secure.
[12:17:39] <NicoHood> hey guys
[12:17:48] <twnqx> julius: 12 -> 5
[12:17:51] <NicoHood> ive though about that. focus on the usecase. here it is just not used
[12:17:55] <NicoHood> useful
[12:18:02] <LeoNerd> julius: A water pump likely wants significant power; best to start with 12V and regulate that down to the small power that the MCU wants at 5V.
[12:18:13] <LeoNerd> Or two separate supplies with a common ground
[12:18:14] <twnqx> NicoHood: anyway, the whole point is "rising the cost", in time and money, beyong the point that makes it attractive for an attacker
[12:18:16] <twnqx> nothing else
[12:18:21] <theBear> and a bunch of bricklayers acid and all the time and patience in the world ? yeah you probly could do it, but would it really be satisfying by the time you finished ?
[12:18:30] <NicoHood> if the lock bits work, you have no chance to get that key unless you open the device. if you open the device, then its already too late. thats out of scope
[12:18:44] <LeoNerd> GAHHHH
[12:18:51] <Emil> NicoHood: then what is the problem?
[12:18:53] <LeoNerd> NicoHood: This is the partI am not explaining. Please talk me through it
[12:19:03] <LeoNerd> NicoHood: You are getting so hung up on these lock bits.
[12:19:15] <LeoNerd> Can please EVERYONE stop so we can get to the bottom of this, as this is getting tedious now
[12:19:20] * limpkin needs backlog on that channel
[12:19:31] <NicoHood> but ive thought about this.
[12:19:50] <Emil> Enable the "disable repgoramming" and then the only way to read the bootloader is by physical inspection which costs a fuckton
[12:19:55] <LeoNerd> NicoHood: You are correct in observing that the lock bits cannot prevent a dodgy untrusted attacker-given firmware that is now running on the device, from using SPM to replace the bootloader itself.. We accept that.
[12:19:55] <theBear> i think most of us started at the bottom of it, someone just seems kinda stuck on a few points or concepts and keeps going in circles
[12:20:20] <LeoNerd> NicoHood: But how did you get INTO that situation? Why have you ALLOWED the attacker to put that dodgy piece of firmware on the device in the first place? You haven't explained that part
[12:20:34] <Emil> LeoNerd: it's irrelevant
[12:20:41] <julius> LeoNerd, ok thanks
[12:20:52] <LeoNerd> If you're *already* in that situation then sure; you are already fucked. That dodgy firmware can leak keystrokes, etc... anyway. all without touching the bootloader or SPM
[12:21:01] <Emil> yap
[12:21:09] <NicoHood> exactly. its like a worse case scenario. there ARE things to prevent flashing firmware. this scenario is about the case where the one HAS access to that
[12:21:12] <LeoNerd> If you trust the bootloader *and* the firmware it is loading, then you remain secure.
[12:21:19] <Emil> NicoHood: not possible
[12:21:25] <theBear> you can lockbit isp style programming out, and i suspect at least a lot of chips you can 100% lockout even "parallel style" fix-your-big-mistake-when-yer-still-green programmers if you want, but that also means even the tiniest error or effup in what you program into the thing can potentially make it an instant and unredeemable brick
[12:21:27] <LeoNerd> And if you already have access to the hardware, then all bets are off. Already.
[12:21:30] <LeoNerd> So stop focusing on that
[12:21:33] <LeoNerd> It's not useful
[12:21:47] <Emil> Yeah, if your attacker can run arbitrary application code then you have lost already
[12:21:53] <theBear> and if you can't access the hw, it's beyond trivial to make the bootloader equally "unaccessible"
[12:22:01] <LeoNerd> theBear: I don't believe any AVR chips can lock out HVxP
[12:22:10] <julius> a 78xxsr 12->5 is like 12€ from my local supplier (no china), isnt there something cheaper?
[12:22:26] <twnqx> O_O
[12:22:29] <LeoNerd> julius: That sounds wrong.. you should be able ot obtain a 7805 for... pence. 20p? Maybe a bit more
[12:22:31] <Emil> theBear: you cannot prevent high-voltage preprogramming and even the lockbits simply issue an erase command
[12:22:41] <twnqx> julius: an 78l05 should be just a few cents
[12:22:50] <cehteh> you can *always* at least chip erase and install any firmware when you have access to the hardware
[12:22:51] <twnqx> a full 220VAC -> 5V block is like 2-3$
[12:22:54] <NicoHood> leonerd: high voltage programming would not help you. you dont have the fucking key.
[12:22:58] <Emil> cehteh: yap
[12:22:59] <LeoNerd> NicoHood: WHAT KEY??
[12:23:06] <LeoNerd> Damnit we're back in circles again
[12:23:07] <cehteh> no bootloader no nothing prevents that on avr
[12:23:08] <twnqx> NicoHood: you do not need ANY key for HVPP
[12:23:11] <Emil> NicoHood: ............
[12:23:19] <twnqx> HVPP is pure hardware, no bootloader or anything
[12:23:20] <Emil> NicoHood: like I fucking said for the 20th time.
[12:23:27] <theBear> Emil, you sure on ALL chips ? even the tinies where you might flip all the pins to alternate functions cos you only got maybe 4 or 6 not including power ?
[12:23:33] <LeoNerd> NicoHood: If I have physical access to the hardware, I can write WHATEVER bootloader AND firmware Ilike and there is nothing you can do to stop me
[12:23:37] <julius> ah ok, right. they are cheap
[12:23:42] <julius> some weird product i found there
[12:23:50] <Emil> theBear: even then if I recall correctly
[12:23:51] <LeoNerd> NicoHood: I will say this again: if I have physical access to the hardware then game is over.
[12:23:54] <LeoNerd> You have lost.
[12:24:08] <cehteh> NicoHood: whats the exact scenario you want to secure?
[12:24:08] <Emil> indeed
[12:24:09] <twnqx> julius: probably a very high current version
[12:24:10] <theBear> either way, if you can wire that up, you can throw away someone elses chip and board and everything and put yer own in there, or put the whole lot in a truck and brick the gas pedal so it does a thelma+louise off the nearest cliff, the world is your oyster
[12:24:26] <NicoHood> twnqx: but you need the key in the new burned bootloader. otherwise the user (who will get back the device and runs the faked bootloader) will notice
[12:24:40] <LeoNerd> "the key in the new burned bootloader"?
[12:24:41] <LeoNerd> What key?
[12:24:45] <theBear> and while they ain't remotely common, you sure ain't gonna include anything remotely like a parallel/hvpp header on something you this paranoid about
[12:24:53] <cehteh> there are certainly some mircocontrollers around with PROM memory or fuses which prevent reflashing
[12:24:57] <cehteh> but avr dont do so
[12:25:16] <LeoNerd> cehteh: Eh... prevening rewriting of the chip just slows people down when they can desolder/replace that chip with their own
[12:25:17] <Emil> NicoHood: no. you donät
[12:25:21] <twnqx> NicoHood: some symmetric encryption key do decrypt the firmware? yeah, that would surely get you a bit further
[12:25:30] <cehteh> LeoNerd: yes
[12:25:39] <twnqx> unless the cipher is weak, like xor :P
[12:25:40] <LeoNerd> NicoHood: I feel there's still extra details you're not telling us here, because you keep mentioning this key... What is this key?
[12:25:46] <theBear> there's this thing called cryptography that maths dudes invented, it can be used to make rather tricky to guess or workout how to generate magic-codes, these can in turn be used in various technical and computing scenarios, for example to make telling a bootloader to do anything bootloader beyond tricky
[12:25:56] <cehteh> with some beefier chips you could make some authentication and handshake while running
[12:26:11] <cehteh> might be a little much for avr's (but people used that too)
[12:26:11] * twnqx remembers 2048bit RSA on a 386
[12:26:13] <LeoNerd> NicoHood: Surely.... Surely this key is being used for *more* than simply permitting the bootloader to replace the firmware? Because; as we said, that key does not help you if the attacker can just burn a new firmware+bootloader.
[12:26:27] <theBear> heh, that's why they call him "mr beefy", them beefy chips he always uses
[12:26:33] <twnqx> let's just say, it wasn't good for verifying license keys in my bbs software. it would take far too long to validate the key :P
[12:26:38] <LeoNerd> NicoHood: So I suspect either you misunderstand that, or you've not yet explained to us any *other* tasks this key performs, such as communicating with 3rd party systems.. servers, network infrastructure, etc....
[12:26:47] <NicoHood> just listen
[12:27:02] <twnqx> LeoNerd: since he mentioned symmetric cipher earlier, i suppose the firmware is encrypted with said key.
[12:27:14] <limpkin> LeoNerd: challenge is implementing a secure way of doing firmware authentication and update on a MCU without asymetrical crypto
[12:27:16] <theBear> that's the thing about programming, you can program a cpu/micro to do anything you can imagine if yer halfway decent at it, so ya know, surely a key can protect any aspect(s) you want if you choose for it to
[12:27:17] <cehteh> the avr's can keep things secret .. but you cant prevent chip-erase and reprograming them
[12:27:25] <Emil> twnqx: or simply you need to provide a key before the bootloader will start to reprogram
[12:28:00] <twnqx> cehteh: avrs are relatively bad at keeping things secret, since they do not self-destruct upon opening .P
[12:28:12] <LeoNerd> limpkin: You can do preshared-secret verification of checksums.
[12:28:13] <Emil> but NicoHood doesn't want to accept an answer
[12:28:24] <LeoNerd> limpkin: But I fail to follow /why/ at this point
[12:28:26] * cehteh thought about a open source friendly secure bootloader .. you first send the program what is already flashed (proof of ownership) .. and then the new program
[12:28:33] <NicoHood> they key is only used to access the firmware burning feature. the key is hidden in the bootloader section. if you have physical access to the device and burn a new bootloader, you still dont know which key to burn. then bootloader will then flash any firmware or no firmware. because you dont know which key to accept. so you know it was faked
[12:28:38] <limpkin> LeoNerd: secure firmware update of the mooltipass
[12:28:42] <cehteh> but thats not very useful except some show off 'because we can'
[12:28:45] <theBear> and if it a double-mathed up key, which is to say you need to workout a far from trivial formula to give the right response to a random prompt from the bootloader side to even make it raise an eyebrow, that makes bruteforce somewhere from very impractical to potentially indefinately ineffective if some randomness is involved in what the bootloader prompts you with
[12:28:54] <LeoNerd> NicoHood: Can you explain "so you know it was faked" please? I'm not following this part
[12:28:58] <theBear> crypto-mathery is kinda cool like that
[12:29:07] <Emil> NicoHood: then you are fucked
[12:29:19] <LeoNerd> NicoHood: You're still not really making any sense. You're trying to prevent someone from applying something to the device...
[12:29:19] <Emil> NicoHood: then your security product should fail
[12:29:24] <twnqx> NicoHood: that is probably the most pointless version i have seen
[12:29:38] <theBear> and that's just a simple concept/example, the guys that invent new everyday/worldwide-usage systems are way beyond that kinda level and have been for many years
[12:29:38] <NicoHood> let me explain and all calm down
[12:29:45] <twnqx> how would your enduser notice it would accept any firmware?
[12:30:00] <Emil> twnqx: actually
[12:30:03] <cehteh> NicoHood: again: avrs can keep secrets .. but nothing prevents one from erasing them and put *anything* new on it
[12:30:03] <Emil> that's simple
[12:30:05] <LeoNerd> NicoHood: Are you trying to prevent the *device owner* from performing certain tasks, DRM-style? Or are you trying to prevent *other people* who happen to have incidental physical access to the device, from doing things its legitimate owner doesn't permit?
[12:30:06] <Emil> it would accept any key
[12:30:17] <theBear> try to explain with some fact or little quirk that we are all missing this time <grin> cos otherwise we just go roundabout again :)
[12:30:32] <theBear> that's not really a lock then <grin>
[12:30:42] <theBear> imagine if yer front door accepted any key <grin>
[12:30:52] <Emil> theBear: no the point is that the user can test multiple keys
[12:30:53] <limpkin> LeoNerd: we want to give the ability to the user to flash approved fw udpates on an unsecured computer
[12:30:55] <Emil> and if all work
[12:31:00] <theBear> not like stupid criminals will just assume it's a normal one-key lock and never try it:)
[12:31:03] <LeoNerd> NicoHood: You haven't explained the WHO part of the attacker scenario. Feel free to treat me as the attacker if you like - what are you trying to stop *ME* doing? And who am I in relation to your device?
[12:31:04] <NicoHood> you need the key to burn a new firmware. only if you enter the key, you can burn the firmware. they key is in bootloader. if you burn a new bootloader, you need to know the key. if you enter a different key, the user will not be able to flash the firmware. so he notices the bootloader is not original. or you modify the bootloader that it can burn firmwares with any key to unlock. the user can also notice that
[12:31:05] <cehteh> NicoHood: you could store some key on the avr and provide a user a interface to authenticate the device, if done right the key wont leak
[12:31:05] * twnqx wonders if NicoHood works with DPG authorized einwegpfandautomaten vendors :D
[12:31:07] <Emil> then the device is not secure
[12:31:24] <NicoHood> leonerd i already wrote that. you will get a paste in a sec
[12:31:32] <NicoHood> The attacker could be someone getting access to the device (that holds your passwords), modify it, add a backdoor and give it back to you. You then use the firmware to save your passwords, his backdoor writes them in EEPROM and downloads them later again. An evil colleague could be that guy. Or someone who gets the device when you are away/while shipping it to you.
[12:31:38] <NicoHood> in a more cleaned version =)
[12:31:40] <LeoNerd> Right - because until we know that, we can't really make progress here.
[12:31:47] <Emil> NicoHood: if thatäs what you are doing then you don't know a bit about security
[12:32:01] <theBear> Emil, but if trying every possible key from a-z 0-9 style is applied to a changing prompt/challenge code, potentially random-number assisted to generate before prompting, bruteforce will likely never get the right key at the right time
[12:32:01] <LeoNerd> Righty... I see..
[12:32:07] <LeoNerd> In that case, this is a doomed product
[12:32:16] <LeoNerd> The attacker can *always* do something in that device
[12:32:24] <Emil> theBear: that's the bloody point
[12:32:26] <theBear> that's the trick with crypto algorithms/ideas, it's a kinda double-bluff deal
[12:32:27] <twnqx> well
[12:32:35] <LeoNerd> E.g. if it's your device, you can lend it to me and I can apply all kinds of trickery and give it back to you, and you ought not trust it
[12:32:58] <cehteh> NicoHood: the only security is the other way around .. the device has authenticate itself to the outer world
[12:33:07] <theBear> stupid itchy trigger finger, really gotta change that mouse button, not like i ever actually remember it asuming i did wanna leave a channel, which also never seems to happen
[12:33:10] <twnqx> LeoNerd: you can add physical security measures, like encasing it all in epoxy, and you would indeed have to clone the device for the owner not to notice
[12:33:24] <LeoNerd> For example: I could have myself a custom STM32 core made, in a tiiiiny tiny raw-silicon wafer package, decap your AVR ATmega chip in your box, solder my core into that, recap the chip, and you probably won't notice. But now I have my piggyback CPU on there.
[12:33:33] <limpkin> mechanical integrity is our assumption
[12:33:48] <cehteh> twnqx: that only raises the barrier, but doesnt make it impossible
[12:33:49] <LeoNerd> Then I don't have to touch your AVR chip's internals at all... other than to recap its plastic package.
[12:34:18] <twnqx> cehteh: absolutely, no discussion
[12:34:20] <Emil> theBear: the bootloader has a key which the firmware update is validated against. If an attacker erases the chips and puts in a new firmware and bootloader the freshly flashed device no longer can know what the original key was
[12:34:21] <cehteh> removing the reset pin physically would also be some good idea :FD
[12:34:25] <Emil> thus it will accept any firmware and any code
[12:34:39] <Emil> so as a precaution the user could try to flash it with multiple keys
[12:34:41] <limpkin> Emil: we have a mechanism to protect against that actually
[12:34:48] <twnqx> cehteh: i have already soldered wires to pins i... lost... during soldering
[12:34:51] <Emil> and if any of the work the device is not secure anymore
[12:35:09] <theBear> Emil, they can only put the code to overwrite that bootloader if they already know how to generate the right response to the bootloader to make it flash/do ANYTHING to begin with, thus it's a moot point
[12:35:38] <Emil> theBear: -.-
[12:35:42] <Emil> you are as confused as NicoHood
[12:35:54] <Emil> you can always reprogram the bootloader
[12:35:59] <LeoNerd> NicoHood: This proposed scenario is a very silly one - why would you lend me your password-storing device, and then still trust it when you receive it back again? You quite rightly have no idea what things I might have done to it... But that's not limited to the AVR security model - that applies far far wider
[12:36:18] <theBear> tho places like hackaday and non-genius dudes blogs will mean "stupid made for ease with ZERO security/paranoia involved bootloader, like the generic only-slightly-flawed arduino stk-500-clone that is oh so widely used these days"
[12:36:21] <Emil> this whole shit could have just been avoided if everyone just stuck to the correct answer of "enable "disable reprogramming"-fuse
[12:36:22] <twnqx> NicoHood: to put it simply, using a key is a nice hurdle. the way you want to implement it, it's more like a minor roadbump than something difficult to overcome. like others suggested, you apparently could brute-force the key
[12:36:55] <theBear> Emil, how can you do that IF you can't write the non-bootloader zone code VIA the bootloader in the first place ?
[12:37:00] <limpkin> twnqx: except for a large enough password size and timeout _before_ try
[12:37:13] <twnqx> timeout? it's an avre, just reset it
[12:37:25] <limpkin> hence the _before_ emphasize
[12:37:34] <Emil> twnqx: probably couldn't brute force the key
[12:37:45] <limpkin> eg let a few seconds pass before checking the key
[12:37:52] <theBear> i suggested that it's trivial to make an infinitely unlikely to be bruteforced potentially in several lifetimes kinda crypto challenge/response deal that would make bruteforcing at best an impractical shot-in-the-dark
[12:37:58] <twnqx> and if the potential gain from hacking the device is >20k€, it's pointless anyway :P
[12:38:04] <Emil> theBear: what's the problem?
[12:38:12] * LeoNerd decides this discussion has now got pointless and silly... so will depart to the pub instead.
[12:38:21] <Emil> LeoNerd: an excellent solution
[12:38:45] * Emil agrees and will depart to the electronics cave after acquiring some food
[12:38:50] <theBear> oh, i suppose assuming infinite time and recording when a challenge repeats maybe that statement is wrong, but i ain't seeing a problem, i just forgot HOURS ago who isn't "getting this" so i refuting any statements on a line by line basis if they appear less-than-totally-succint/accurate :)
[12:38:51] <twnqx> or rather not pointless, but if the gain is sufficient, AVR is the wrong hardware for security
[12:39:11] <theBear> i'm a sucker for needing people to not-misunderstand a concept
[12:39:28] <twnqx> reminds me i have a meeting with a blackbox security test next week :)
[12:39:39] <twnqx> WITH physical access, muahaha
[12:40:44] <twnqx> 3 days of dismantling a machine to figure out how easy it would be to make it believe it saw something that's not there :)
[12:41:52] <theBear> i kinda been looking forward to another hackercon locally, was pleasantly surprised at not just national, but local attendees at the maybe 3rd or so in a new local series
[12:42:41] <twnqx> well, probably just 2 days dismantly and trying to get access, and 1 day of reassembling :P
[12:44:00] <twnqx> and then the impendig doom of explaining *really* secure random number generators according to some higher-than-common-criteria standards to chinese developers
[12:44:11] <twnqx> *sigh*
[12:44:32] <twnqx> at least, free flight to china, and hopefully some extra days in shenzhen :3
[12:46:38] <theBear> my fine-work and like-new-ery skills are at a world class level in recent times if you get an offer but you can't take it for some reason, sounds like a fine few days to me :)
[13:07:36] <cehteh> so .. int to string code fixed :D
[13:08:07] <cehteh> brainfart
[13:24:17] <jancoow> Hi. I'm trying to read analog values from the ADC in a atmega128. It works, but i don't understand which bit actually says which ports. It now reads from port F0. But i wanna read from port F3 or multiple ports for example
[13:24:28] <jancoow> https://jancokock.me/f/23aee is the current code
[13:24:36] <jancoow> If someone could help me it woul be great!
[13:26:01] <cehteh> datasheet
[13:26:11] <Jartza> usually it's ADMUX register
[13:26:19] <Jartza> check datasheet which bits set what port
[13:26:39] <jancoow> cehteh Jartza: yeah i'm checking the datasheet and it should be admux indeed
[13:27:45] <cehteh> on the first page you have the pinout graphics which usually include the alternate pin functions
[13:27:50] <cehteh> ADC0 ADC1 ....
[13:28:14] <cehteh> not first page, but somewhere at the beginning
[13:28:44] <cehteh> err AINx
[13:29:00] <jancoow> yeah i see. There i can see which ADCx is which PFx right ?
[13:29:14] <cehteh> yes
[13:30:04] <jancoow> so it should be bit 4 of the ADMUX
[13:30:36] <cehteh> use the names
[13:30:38] <WormFood> http://wormfood.net/avrbaudcalc-testing.php <-- I'm gonna change a few internal things, that won't affect how it looks now, but I'm basically done with this round of changes. I changed a LOT of stuff. I changed the display of the "display all possible clock speeds/bit rates for a given bit rate/clock speed" tables. Any comments or suggestions?
[13:32:02] <cehteh> WormFood: well the most important question for me is 'why' (because i rather use the macros from util/baud.h) .. but otherwise good work, go on :D
[13:32:22] <WormFood> why? Because that doesn't give you information.
[13:33:14] <jancoow> cehteh: so what i though i shoudl do is ADMUX |= (1 << ADC3); BUT ADC3 isn't declared for some reason. What should be the names?
[13:33:24] <WormFood> I want to generate 162.5k bit rate. I don't have a proper crystal. I want to go through my junk pile, and see what I do have, that will work. How do you figure out what will and won't work?
[13:33:43] <cehteh> you can dump the infos it generates with cpp .. but i acknolege your tables are useful for a big overview
[13:33:45] <WormFood> You want to run that task through your macro?
[13:34:35] <WormFood> It's also handy, for quickly trying to pick a good clock, that does the speeds you want, at a glance.
[13:35:02] <cehteh> jancoow: check the datasheet carefully, i dont know that mega, but on other registers such bits are sometimes placed at odd places, maybe in some completely different register
[13:35:13] <WormFood> Also, your macro won't really tell you shit. It just sets it to the closest value it can, without warning for values that are out of spec.
[13:36:04] <WormFood> When you need to work with bit rates, and not just set something that knowingly works, you'll find my tool really handy.
[13:36:43] <cehteh> WormFood: calm down ... i didnt want to crizitze or insult you, my feedback is just my opinion that this page is 'useful' but (for me) it seems you put more efforts into it than (I) can gain from it
[13:37:06] <WormFood> It's not a tool that most people would need.
[13:37:20] <WormFood> The people that do need it, really appreciate it.
[13:37:35] <cehteh> WormFood: on another note .. once i searched something related to UART and your page was pretty high in the google ranking :D
[13:37:48] <WormFood> I'm in the top 30, for just "baud"
[13:38:19] <cehteh> you should do SEO and not baudrate calculating :D
[13:38:19] <WormFood> There are a lot of web sites linking to that page. A lot of good sites. That is why it is ranked so high.
[13:38:27] <WormFood> This is organic SEO
[13:38:35] <WormFood> I didn't do anything, except write a useful tool.
[13:39:03] <WormFood> I shared the link here twice. Someone referenced it on a mailing list, and from there, other people started picking it up, and linking to it.
[13:39:04] <cehteh> :)
[13:39:17] <WormFood> It's the most popular page on my site, and there are no links to it, from any of my pages.
[13:40:18] <cehteh> reminds me of the linux-vserver "Great Flower Page" .. when you know the term to search for you get great information .. but maybe not what everyone expects
[13:40:23] <WormFood> Also, if you want to build an EX-494 frequency programmer, for some models of Icom VHF and UHF radios, my page also comes up pretty high. At least it did, last time I checked.
[13:41:13] <jancoow> cehteh: I don't get it really
[13:41:29] <WormFood> I'm about to do a radical overhaul on my website. I'm getting it all setup to work smoothly, and nobody's links to my pages break.
[13:42:00] <WormFood> Fortunately, I don't have many pages on my site, so it's easy for forward stuff that I care about.
[13:42:30] <cehteh> jancoow: uhm i would have to read the datasheet too
[13:43:01] <cehteh> mega128 u saied?
[13:43:08] <jancoow> yes!
[13:43:22] <jancoow> for some reason the ADCx aren't defined (0 to 7)
[13:44:22] <WormFood> I noticed various odds-n-ends stuff that wasn't uniform like that. I never could figure out a solid reason why they do that.
[13:45:03] <cehteh> jancoow: page 242 ADMUX
[13:45:47] <jancoow> cehteh: I See! But when i do ADMUX |= (1 << 0x01); it should be ADC1 right? but for some reason its ADC2
[13:45:55] <cehteh> ADMUX |= (1<<MUXx) ....
[13:46:43] <cehteh> you get it wong 1<<1 is 0010 that is ADC2
[13:46:57] <cehteh> and use the MUX macros
[13:47:07] <jancoow> oh wait
[13:47:09] <jancoow> omg..
[13:47:09] <WormFood> ALWAYS use the macros
[13:47:10] <jancoow> sorry
[13:47:13] <jancoow> that was stupid
[13:47:18] <cehteh> :D
[13:47:24] <jancoow> and yeah i though the macro was ADC0, but it's MUX1
[13:47:34] <WormFood> not only will it make your code more portable, it will also make it easier to debug, and less error prone
[13:47:42] <cehteh> datasheet is the TRUTH!
[13:48:10] <jancoow> cehteh: does there stand "mux1" in your datasheet? Mines (on paper) not
[13:48:54] <cehteh> https://www.mikrocontroller.net/part/ATMEGA128
[13:52:39] <julius> what happens if a power supply only outputs up to 2a and the circuit wants 4, can it damage the power supply?
[13:52:53] <cehteh> yes
[13:53:05] <cehteh> depends of course
[13:53:16] <WormFood> It won't damage a properly designed power supply
[13:53:25] <julius> so oversize the supply just in case
[13:53:33] <cehteh> some shut down, some reduce voltage, some try constant restarts, some blow fuses, some start burning
[13:53:51] <WormFood> Sometimes reduced current can damage the device you're powering
[13:53:54] <cehteh> but dont expect it to work :)
[13:53:55] <julius> thing is you dont know which power supply does what
[13:53:59] <WormFood> It all depends on the device.
[13:54:07] <julius> a water pump
[13:54:14] <cehteh> well in this case i guess he meant the DC motor
[13:54:19] <julius> yes
[13:54:25] <cehteh> that will not damage from undercurrent
[13:54:26] <WormFood> I built my own power supply once. Output 9-18 volts, at about 20 amps.
[13:54:35] <julius> nice
[13:54:40] <cehteh> but if you supply you avr from the same power supply it will brown out
[13:54:53] <julius> good point
[13:55:22] <cehteh> esp for starting currents of a motor you better make the PS somewhat biggier
[13:55:38] <WormFood> It was an old solid state RF amplifier, that was busted. Even one of the diodes in the rectifier circuit was busted. So, basically I started with a transformer, and a diode.
[13:55:41] <cehteh> maybe put a extra fuse on the motor
[13:56:22] <WormFood> And even my power supply had over current protection.
[13:56:31] <cehteh> with relays i had some luck putting the coils behind a small resistor and big cap
[13:57:09] <cehteh> you also want to denoise the motor with some caps
[13:58:21] <cehteh> DC motors are nasty
[13:58:44] <julius> isnt there some relation between duty cycle when using pwm and current?
[13:59:33] <julius> or will the motor always start with the same current, no matter what
[13:59:47] <cehteh> in some complex way (aka, i dont know the details) .. motor inductance, brush sparks, stator position, moon phase
[14:00:16] <julius> ok
[14:00:39] <cehteh> for startup you want to give it a extra kick and then fast pull back the pwm to the desired value, esp at low duty cycles
[14:00:50] <cehteh> what are you planning to do?
[14:01:12] <julius> im gonna start with two power supplys, one 5v for the avr and another 12v for the pump. its a pc power supply that can do 70w i think
[14:01:24] * cehteh thinks he would nowadays almost always prefer a brushless motor
[14:01:44] <julius> i want to water my plants, theres a capacitive moist sensor in the earth
[14:01:51] <cehteh> be careful that the 70W are on the 12V rail
[14:01:51] <jancoow> julius: in a pc power supply 5v and 12 v lanes are seperated
[14:02:13] <cehteh> ah i have some pumps in the cellar panning to build a watering system someday too
[14:02:15] <julius> cehteh, yes...but this one is for a "small case" and it only outputs 12v
[14:02:17] <jancoow> but sometimes the grounds are connected
[14:02:59] <julius> it runs a via low power cpu, well it was low power like 5 years ago.
[14:03:21] <julius> just got two car washer pumps for 10€, used
[14:03:40] <cehteh> i buyed some small camping water pumps 12V too
[14:04:04] <julius> so run the pump at 100% for a short time to get the motor turning and then retreat to a lower duty cycle
[14:04:44] <cehteh> posisbly you dont need 100%
[14:04:46] <jancoow> i've played with some nibe heatpumps of 3kw :)
[14:04:52] <jancoow> controlled by a raspberry pi though;
[14:04:53] <julius> jancoow, in what way is it interresting if the grounds are connected in a real psu?
[14:04:57] <cehteh> (for startup)
[14:05:17] <julius> jancoow, nice...how high did you pump the water?
[14:05:18] <cehteh> http://www.amazon.de/Comet-Tauchpumpe-Elegant-Durchlauf-Spannung/dp/B001CV02U4/ i got such ones
[14:05:47] <cehteh> i dont plan to pwm them
[14:05:57] <cehteh> just full power and regulate them with a ventil
[14:05:57] <jancoow> julius: around 1km into the ground and up
[14:06:15] <julius> thats a "man" pump
[14:06:24] <jancoow> they where big, yeah ;p
[14:06:34] <julius> something tim taylor would have used to hose his garden
[14:06:49] <jancoow> used for ground heating
[14:07:10] <julius> uh, i did a course on that
[14:07:18] <jancoow> yes?
[14:07:21] <jancoow> cool!
[14:08:34] <jancoow> but yeah, these where 3 fase AC motors so not really related to your question ;po
[14:11:06] <julius> its was about geothermic energy
[14:11:11] <julius> not about the electronics part
[14:11:24] <julius> but one of the pictures jump right into my head
[14:21:43] <jancoow> Jartza: oh btw. I passed my driving license last week ;p
[14:21:59] <jancoow> if you still remember me
[14:26:42] <julius> congratz
[14:30:44] <Jartza> jancoow: congrats :)
[14:36:23] <julius> WormFood, youre still in china?
[14:38:26] <Jartza> I measured the power consumption of my latest Tagsu hw & firmware
[14:38:27] <Jartza> https://www.youtube.com/watch?v=NbVvsdfWj8Y
[14:38:29] <Jartza> pretty nice now
[14:48:40] <wondiws> Help! "Could not establish communication with the tool" :S
[14:48:50] <wondiws> AVR studio error when using stk500
[14:49:36] <jancoow> Thanks!
[14:49:40] <jancoow> Jartza: cool!
[14:57:27] <Jartza> wondiws: stk500 drivers installed?
[14:57:51] <Jartza> I've seen that problem though. there was some hardware errors in stk500 and it sooner or later gives up
[14:57:56] <Jartza> try replugging it
[14:58:05] <Jartza> jancoow: yeah, about half of the "original"
[14:58:10] <wondiws> Jartza, I don't think there is stk500 drivers: it's just UART. I did need to install the USB to UART bridge. This might be a problem though
[14:58:19] <wondiws> Jartza, I did have less problems on another laptop though
[14:58:29] <wondiws> it's just fragile
[14:58:30] <Jartza> ahh, you use uart and not usb
[14:58:53] <wondiws> Jartza, it's MySmartUSB
[14:59:06] <wondiws> so it is USB, but with the CP201 or something UART bridge
[14:59:36] <Jartza> oh sorry, I confuse it with stk600 now
[14:59:50] <Jartza> stk500 was the older one
[14:59:59] <wondiws> Jartza, I think stk500 is the only one where you have to explicitly add it via the tools menu
[15:00:31] <wondiws> I can open COM3 in Putty, but even that sometimes fails
[15:00:41] <Jartza> well, I use usbasp and avr isp mk2
[15:00:56] <Jartza> they seem to work much better than those atmel hugeboards :)
[15:01:19] <wondiws> Jartza, this isn't a hugeboard, this is a dongle like thing
[15:01:40] <wondiws> Jartza, http://www.harald-sattler.de/assets/images/2011-04-05_IMG_0296_Bildgrosse_andern.jpg
[15:02:26] <Jartza> oh. so that isn't stk500
[15:06:46] <Jartza> no idea about that programmer
[15:07:10] <Jartza> seems to have CP2102
[15:07:24] <Jartza> https://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx
[15:07:29] <Jartza> seems to be that driver
[15:09:35] <antto> figured it
[15:09:50] <antto> -mmcu was not passed to the linker
[15:11:51] <wondiws> Jartza, the driver installs automatically
[15:11:59] <wondiws> in linux, I can download though
[15:12:05] <wondiws> altough first try didn't work
[15:12:21] <antto> with avrgcc 4.3.3, in my project i only have -mmcu=atmega2561 in the compiler settings, and it links
[15:13:05] <antto> but with avrgcc4.8.2, not.. and thus ld doesn't agree that the objects match the architecture
[15:13:19] <antto> i added -mmcu=atmega2561 to the linking options - boom, it compiles
[15:13:34] <antto> no more __muluhisi
[15:13:44] <Jartza> ohh
[15:13:52] <Jartza> I just moved over to 4.9.2 :)
[15:14:02] <Jartza> the "official" atmel toolchain
[15:14:02] <antto> same thing
[15:14:20] <Jartza> I used 4.8.2 for quite a long
[15:14:46] <antto> i guess on older avrgcc, the linker somehow catched the -mmcu setting from the compiler, or it autodetects it from the passed objects, or i don't know what
[15:14:56] <antto> but on newer versions it has to be specified
[15:15:11] <antto> so, the "stock" avr-libc works
[15:15:41] <Jartza> although, I'm pretty much getting back to 4.8.2
[15:15:50] <Jartza> seems 4.9.2 doesn't optimize as well
[15:16:41] <Jartza> for example Tagsu firmware. 5624 bytes with gcc 4.9.2 and 5498 bytes with 4.8.2
[15:17:09] <Jartza> 126 bytes bigger firmware and no other changes than just compiler
[15:17:17] <wondiws> Jartza, success now
[15:17:24] <Jartza> wondiws: yay!
[15:17:48] <wondiws> Jartza, but it's always so "fragile" with those programmers, I've had that problem before quite often
[15:18:13] <wondiws> sometimes it just decides it doesn't feel like it
[15:25:28] <Jartza> oh
[15:25:39] <Jartza> this chinese usbasp that cost like $2 or less has been working nicely
[15:25:47] <Jartza> at least after I used arduino to first update it's firmware :)
[15:27:47] <antto> updating the firmware on mine didn't fix it at all
[15:27:52] <antto> it kept sucking
[15:28:18] <Jartza> seems there are also multiple hardware versions
[15:33:40] <Deskwizard> antto: I had the same problem as yours
[15:34:42] <antto> with the usbasp?
[15:35:08] <Deskwizard> yep
[15:46:10] <antto> mine was labeled "betemcu.cn" or something such
[15:51:20] <wondiws> Jartza, that's just one of those bit-bang programmers?
[15:51:34] <wondiws> I think I have one of those as well
[15:51:44] <wondiws> and I also need to update the firmware
[15:52:21] <Jartza> wondiws: http://www.fischl.de/usbasp/
[15:53:30] <Jartza> http://www.ebay.co.uk/itm/261574745774
[15:53:33] <Jartza> this is the usbasp I have
[15:53:43] <Jartza> updated it with the latest firmware from fischl.de and it works nicely
[15:54:10] <Jartza> I bought 10 of them, because I sometimes organize avr "coding camps"
[15:54:28] <Jartza> updated firmware of first one using arduino as programmer
[15:54:35] <Jartza> then updated the rest of them using the first usbasp :)
[15:55:58] <Jartza> seems that the ones that say "LC technology 2.0" are with better hw
[15:56:52] <wondiws> Jartza, yes, "fischl" rings a bell, I must have the same
[15:59:47] <Jartza> anyhow, that £1.6 programmer worked really well
[22:31:50] <nikomo> Anyone know how long it typically takes for avr-gcc to get updated, when new versions of gcc are released?
[22:32:11] <nikomo> -Wmisleading-indentation looks kinda nice, that's coming in GCC6
[22:32:46] <Casper> good question, never checked it
[22:32:57] <Casper> I would have assumed at the same time
[22:33:13] <nikomo> Arch Linux currently ships on stable, avr-gcc 5.3.0-1 and gcc 5.3.0-4, so that's pretty close together
[22:33:39] <nikomo> that's just packaging updates afaik, the version after tack
[22:36:00] <nikomo> there's warnings on shift overflow, might have to disable those. especially with microcontrollers, sometimes you just really do need to throw out a bit
[22:41:22] <Casper> look like I'm late on versions... gcc: 4.7.3 avr-gcc: 4.9.2 :D