Back
[00:05:02] <_ami_> Casper: i shall try that tonight. Although i could just enable verbose mode in arduino ide and see how ide uploads the code to arduino. i won't be using external programmer so it should not overwrite bootloader. avrdude -F -V -c arduino -p ATMEGA328P -P /dev/ttyACM0 -b 115200 -U
[00:06:45] <Casper> that will work
[00:06:55] <Casper> the flash in the avr is divided in block
[00:07:12] <Casper> the bootloader can erase each block individually
[00:07:29] <_ami_> cool. good to know, thanks
[00:07:30] <Casper> the external programmer can not do that, all it can do is a full chip erase
[00:07:59] <Casper> avrdude can talk to the bootloader or to an external programmer
[00:08:48] <_ami_> Casper: noted down. thanks for the insights
[00:10:28] <_ami_> Casper: you like automake/make? automake is kind of outdated.
[00:11:06] <_ami_> cmake is far better to manager and understand. and requires less typing than make.
[00:11:26] <_ami_> manage*
[00:20:09] <Casper> less typing? copy Makefile, make, make flash
[00:22:25] <inflex> :)
[00:22:46] * inflex ponders how to make an effective home-made solder fume extractor/filter
[00:23:04] <inflex> Still, considering you can get them for about $99, hard to justify
[00:23:47] <Casper> inflex: pipe, fan, pipe, outside
[00:23:54] <_ami_> ah, the make flash thing. i just have to add a command in cmake for uploading the code to arduino then after i could also do make flash or make upload :)
[00:24:37] <_ami_> btw, linking is real pain in ass sometimes if u do with the help of Makefile. it go nuts :)
[00:25:01] <_ami_> i am talking about linking different custom libraries with your code.
[00:25:22] <Casper> _ami_: yeah, save lots of headache (make flash), specially since the avrdude line is kinda long
[00:25:30] <_ami_> indeed
[01:50:46] <Valen> inflex: sucking is harder than blowing
[02:31:33] <Casper> Valen: specially since you can't suck more than 1 atmosphere of pressure...
[02:31:51] * Casper wonders what would be considered the upper limit...
[02:32:04] <Casper> probably when stuff turn into liquid due to pressure...
[05:08:59] <Emil> twnqx: that would be awesome!
[05:09:40] <twnqx> that's to late now... at work, only back to my home desktop in the evening
[05:09:59] <Emil> twnqx: damn :D
[05:10:12] <Emil> But I can wait if you deliver ; )
[05:11:02] <twnqx> but it's just a modified version of
https://github.com/chrschmidt/spitool/blob/master/serial.c
[05:11:16] <twnqx> 'cause that code can't handle 2mbit for real
[05:11:30] <twnqx> gets() has too much overhead :D
[05:47:35] <Emil> twnqx: I'm just curious why doesn't
http://linux.die.net/man/3/cfsetospeed and
http://linux.die.net/man/3/cfsetispeed list those additional speeds : /
[05:48:06] <LeoNerd> I really dislike the termios bitflag interface for setting speeds
[05:48:24] <LeoNerd> I'd much prefer a separate ioctl call that just takes an `int baud` directly
[05:48:47] <Emil> https://github.com/torvalds/linux/blob/183c948a3cb3efbf45eabed41fa7ee04c19378fc/drivers/usb/serial/cp210x.c#L553
[05:48:47] <LeoNerd> E.g. there's no bitflag for 250kBaud, which is DMX512's speed
[05:48:55] <Emil> And here we have speeds supported by the cp2
[05:49:04] <Emil> the driver for ch340g is super annoyingly build
[05:50:09] <Emil> https://github.com/torvalds/linux/blob/183c948a3cb3efbf45eabed41fa7ee04c19378fc/drivers/usb/serial/ch341.c#L55
[05:50:40] <Emil> LeoNerd: but yeah, tell me about it
[05:50:52] <Emil> Linux would really use an overhaul in getting that shit to work
[05:50:56] <Emil> could *
[05:52:19] <Emil> I think we should really just move onto getting raw universe data from the usb
[05:52:34] <Emil> instead of limiting ourselves to shitty serial emulators
[05:53:08] <LeoNerd> Yeah.. sometimes it's nicer to talk a lower level than just CDC
[05:53:40] <Emil> and it would actually be easier to implement, I reckon. Just have a socket you can read and write to
[05:53:53] <Emil> which would simply pass the data to and from the usb device
[05:54:01] <LeoNerd> Having message boundary-preseving packets instead of a continuous bytestream would be nice
[05:55:40] <Emil> true
[05:56:20] <Emil> but from the programming perspective it is still a byte stream, really
[06:04:10] <twnqx> Emil: dunno.
https://github.com/chrschmidt/spitool/blob/master/buspirate.c lines 36+ has them
[06:05:18] <twnqx> /usr/include/bits/termios.h has them (included via <termios.h>)
[06:30:42] <Emil> twnqx: I have not /usr/include/bits/termios.h
[06:30:48] <Emil> termios.h is in /usr/include/ for me
[06:31:09] <twnqx> my termios.h includes bits/termios.h :>
[06:31:21] <Emil> well, the fuck :D
[06:31:37] <twnqx> gentoo does things straight from the kernel
[06:31:46] <Emil> Ah, Gentoo
[06:31:52] <Emil> Debian <3 here
[06:32:09] <twnqx> </3 debian here
[06:32:57] <megal0maniac> Debian <3 fwiw
[06:33:53] <Lambda_Aurigae> debian ballsack?
[06:34:14] <twnqx> obsolete software and "we are god and backport everything correctly, we know better than the respective developers"
[06:34:45] <megal0maniac> Lambda_Aurigae: It's not pretty, but it gets the job done
[06:35:12] <twnqx> i'll never forget how debian ruined months of development for me
[06:35:25] <twnqx> by not having NPTL 2 years after it came to linux
[06:36:41] <inflex> welcome to the world of geeks & nerds doing stuff without parental supervision ;)
[06:57:24] <Emil> twnqx: but I'm scared
[06:57:33] <Emil> I'll just go to LSF
[06:57:40] <Emil> skip the arch and gentoo phase completely
[06:58:37] <metRo_> hi all
[06:58:54] <Lambda_Aurigae> hello metRo_
[06:59:21] <metRo_> I have a unsigned long variable and I'm trying to use it as a buffer argument
[06:59:38] <Lambda_Aurigae> that's nice.
[06:59:38] <metRo_> I tried to use (uint8_t *) &variable
[06:59:49] <metRo_> but the result isnt correct
[06:59:54] <Lambda_Aurigae> uint8_t is an 8bit integer.
[07:00:06] <metRo_> the buffer argument input is a uint8_t buffer[]
[07:00:07] <Lambda_Aurigae> not long in any sense of the word.
[07:00:09] <Lambda_Aurigae> try 16
[07:00:13] <metRo_> and I say the size
[07:00:26] <metRo_> the function also get the size parameter
[07:01:12] <metRo_> can't I consider the unsigned long variable as 4 byte memory space?
[07:01:16] <metRo_> like a buffer
[07:01:17] <Lambda_Aurigae> might help if you posted a code snippet rather than half of one line.
[07:01:42] <Lambda_Aurigae> unfortunately, I'm about to head to work so no code reading for me.
[07:02:22] <metRo_> Lambda_Aurigae: 1 minute please
[07:03:21] <metRo_> Lambda_Aurigae: can you take a look
http://pastebin.com/FX8czgQb
[07:03:29] <metRo_> only 6lines :p
[07:04:09] <Lambda_Aurigae> this looks like something from arduino.
[07:04:37] <Lambda_Aurigae> not knowing how the SerialUSB.write function works, I have no clue.
[07:05:08] <metRo_> if I create a 4 size buffer
[07:05:21] <metRo_> it works ok
[07:05:27] <metRo_> and it takes the buffer as a pointer
[07:05:33] <Emil> because the compiler doesn't know what you mean
[07:05:37] <Emil> it doesn't read your mind
[07:06:25] <Emil> If you have a unsigned long (4 bytes) just print an unsigned long. Those arduino libraries are handicapped to the max to support that
[07:06:55] <Emil> If you want to store 4 different 8 bit values then have a buffer of 4 bytes and print them
[07:16:19] <Emil> metRo_: anycase, you shouldn't cast it to uint8_t *
[07:16:26] <Emil> it's a number, you need to pass the address of that number
[07:17:47] <Emil> SerialUSB.write((uint8_t *)&Voltagemem, 4);
[07:17:50] <Emil> That might work
[07:51:26] <twnqx> Emil: the other way around for me
[07:51:37] <twnqx> i was on LFS, then scripted the building process
[07:51:47] <twnqx> then i found gentoo was just that and more, so i switched
[07:51:51] <twnqx> and never looked back
[08:01:25] <Emil> :D
[08:25:11] <metRo_> Emil Lambda_Aurigae was my bad (not only mine)... my friend change the type for float for some reason -.-' and I didn't check it again since last time I looked into the code...
[08:45:40] <Emil> metRo_: It works now? Good
[08:53:48] <metRo_> Emil: yes :) I had it this way too SerialUSB.write((uint8_t *)&Voltagemem, 4); for some reason copied it wrong to pastebin
[08:54:03] <LeoNerd> Ugh.. don't do that
[08:54:22] <LeoNerd> I reserve a special Circle of Hell for anyone who does that kind of thing
[08:54:31] <LeoNerd> It's really not hard to do it right. So stop doing it wrong
[09:00:32] <Emil> LeoNerd: do what?
[09:00:54] <LeoNerd> Taking pointers to multibyte values and casting them to uint8_t* so as to write out "the underlying bytes"
[09:00:57] <LeoNerd> in some stupid crap way
[09:01:03] <LeoNerd> If you want to serialise values, do it properly
[09:02:40] <twnqx> how is the right way?
[09:02:44] <LeoNerd> Serialise it
[09:02:49] <twnqx> yes. how.
[09:02:53] <LeoNerd> Turn it into bytes in a well-defined way
[09:03:04] <twnqx> i'd call that well defined
[09:03:11] <cehteh> :)
[09:03:11] <LeoNerd> .write((uint8_t[]){v >> 24, v >> 16, v >> 8, v}, 4)
[09:03:13] <LeoNerd> for example
[09:03:17] <LeoNerd> There. I have decided it shall be big-endian
[09:03:20] <twnqx> wow
[09:03:22] <LeoNerd> I have written 4 bytes all controlled by me
[09:03:26] <LeoNerd> never once did I have to care what the compiler does.
[09:03:28] <twnqx> because that's nearly no overhead
[09:03:32] <LeoNerd> I don't care what endianness the compiler picks
[09:03:35] <twnqx> for a slow as f*** micro
[09:03:36] <LeoNerd> It most likely compiles the same way
[09:03:48] <LeoNerd> Try it. I wouldn't be surprised if in this case it creates the same assembly code
[09:03:52] <LeoNerd> Except that mine is a lot more portable
[09:04:44] <twnqx> dunno
[09:04:54] <twnqx> there is only one endianness on the avr 8bit platform
[09:05:20] <LeoNerd> *shrug*
[09:05:27] <LeoNerd> I don't care. This way it works no matter what the compiler does
[09:05:37] <LeoNerd> I've written my -intentions- and left the compiler to work out how to implement it.
[09:05:46] <LeoNerd> This is the essence of writing computer programs in high(er) level languages, like C
[09:05:59] <LeoNerd> If I wanted to instruct the machine on exactly how to behave I'd be writing assembly code
[09:08:03] <twnqx> and how do you correctly serialize an array of uint8_t?
[09:08:51] <LeoNerd> Hm?
[09:09:00] <twnqx> how do you serialize an array of uint8_t
[09:09:16] <LeoNerd> It's already serialised, surely?
[09:09:29] <LeoNerd> In this case "serialise" means "to turn into an array of uint8_ts so that you can write() them"
[09:09:35] <LeoNerd> So the question is already in the required answer form
[09:10:24] <twnqx> yes, but changing the underlying type would not have been caught to begin with
[09:11:08] <twnqx> and i am not sure that your .write would have correctly serialized a float, but that's a different story
[09:11:26] <LeoNerd> Hah,. yes.. floats
[09:11:27] <cehteh> who uses floats on avrs :S
[09:11:32] <twnqx> <--
[09:11:41] <LeoNerd> floats are fun. If you want to properly serialise a float in a properly platform-neutral way, I suggest the Beej method
[09:11:48] <cehteh> you do something wrong then
[09:12:01] <twnqx> not always avoidable
[09:12:02] <cehteh> (most likely at least)
[09:12:11] <LeoNerd> Beej is good on /real/ machines with /real/ FPUs... I'm not sure you'd be using true floats on an AVR though
[09:12:15] <cehteh> so far i could *always* avoid them
[09:12:25] <LeoNerd> But fortunately, the method is quite compatible with conversions to/from fixed-point representations
[09:12:49] <twnqx> how about "get the real value from an ADC with a 10:1 voltage divider at the input"
[09:13:05] <cehteh> well yesterday i had some fun with a libary for rationals .. but that was just some proof of concept, will do that properly someday
[09:13:20] <cehteh> twnqx: for sure not with floats
[09:13:32] <twnqx> good enough with the resolution of an avr
[09:13:35] <cehteh> because floats are inexact and not base10 based
[09:13:46] <cehteh> you cant even represent 0.1 in a float
[09:13:49] <twnqx> so what, 10/11 is not a rational number wither
[09:13:54] <LeoNerd> float representations waste bits just recording the size of the exponent scale
[09:13:57] <LeoNerd> Fixed-point doesn't
[09:14:14] <cehteh> twnqx: fixed point math ftw
[09:14:16] <LeoNerd> Generally in hardware devices, you know the rough range and precision of values you'll be working with. You don't -need- the flexibility of a true float
[09:14:28] <twnqx> i can agree with that notion
[09:14:44] <LeoNerd> If your value represents a voltage, you know that the hardware isn't capable of distinguishing nanovolts, nor your power supply of producing gigavolts
[09:15:02] <twnqx> yes, else i would not be happy with a float. would have to be at least a double.
[09:15:07] <cehteh> instad of float Volts; you use int16_t milliVolts; or int32_t microVolts; or something like that
[09:15:14] <LeoNerd> So maybe a int32_t of microvolts would be just fine
[09:15:30] <LeoNerd> An IEEE double requires 64bits of storage.
[09:15:37] <cehteh> you completely misunderstand how floats are working
[09:15:37] <twnqx> nah, i thing 8.8 would be good enough
[09:15:41] <twnqx> think*
[09:15:45] <twnqx> what?
[09:15:46] <LeoNerd> It's likely the true range and precision of your values ought to be able to fit in 32 bits for most purposes
[09:15:58] <twnqx> i doubt i have a misunderstanding how floats work
[09:16:06] <cehteh> you just shown that
[09:16:10] <twnqx> huh?
[09:16:19] <cehteh> floats dont have decimal digits
[09:16:22] <twnqx> yes
[09:16:25] <twnqx> obviously
[09:16:33] <twnqx> x bit base + x bits exponent
[09:16:35] <cehteh> floats are inexact
[09:16:39] <twnqx> by nature, yes
[09:16:46] <LeoNerd> Floats are just as inexact as fixedpoint
[09:16:52] <cehteh> floats are bloated .. in ram and code
[09:17:06] <twnqx> they are just 32bit, handling them is a bit more expensive, though
[09:17:18] <cehteh> lots more expensive
[09:17:24] <LeoNerd> Look.. I'll make it simpler. Floats have all the same properties as fixedpoints, except that in a float, the exponent is stored dynamically in RAM, whereas in fixedpoint it is statically implied by the surrounding source code
[09:17:27] <LeoNerd> That is all the difference
[09:17:30] <twnqx> but imho not as much as you think, thanks to exactly the normalization involved
[09:17:40] <LeoNerd> They both have the same abilities and limitations, aside from the differences in behaviour of that exponent
[09:17:47] <twnqx> yeah, i used fixed point math already 25 years ago,m thank you
[09:18:03] <cehteh> LeoNerd: having a fixed point also defined the exactnss and what you can do and what not
[09:18:55] <Emil> LeoNerd: are you silly? Doing that takes a fuckton of cycles
[09:19:13] <twnqx> Emil: i am not sure
[09:19:28] <twnqx> for his example at least, the compiler would not shift, but use array access
[09:19:35] <LeoNerd> Emil: Try compiling it. Look at the assembly output
[09:19:37] * cehteh wish do have a float format where one can pass one bit for exactness around
[09:19:42] <LeoNerd> avr-gcc is really not silly about shifts.
[09:20:11] <twnqx> i'd like to have a fixed point type in C
[09:20:16] <Emil> twnqx: tell me about it
[09:20:22] <LeoNerd> twnqx: I was just wondering if rust could do it
[09:20:40] <LeoNerd> Whether you could mark the fixedpoint exponent as part of the static type of a variable
[09:20:44] <twnqx> (and yes, i know there are indeed gcc extensions, but as you go on about portability...)
[09:21:20] <twnqx> that's almost as portable as my fun program that uses int128_t :P
[09:21:34] <LeoNerd> Oh that reminds me - rumour has that latest avr-gcc can now synthesize a uint24_t
[09:21:36] <twnqx> which basically limits you to gcc on 64bit arches.
[09:21:45] <LeoNerd> I should try that, as that will save me $lotsofbytes on timers
[09:21:58] <twnqx> gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9)
[09:22:16] <twnqx> dang, i should update
[09:23:46] <cehteh> LeoNerd: and i with it would do 32 bit increment/decrement inline instead calling a generic function
[09:23:51] <LeoNerd> Hah
[09:23:58] <LeoNerd> Ohman... the thing I really wish gcc could do is multiply by 3
[09:24:06] <LeoNerd> i * 2 becomes i + i
[09:24:14] <LeoNerd> i * 4 becomes (i + i) added to itself
[09:24:22] <cehteh> hah
[09:24:23] <cehteh> yes
[09:24:25] <LeoNerd> i * 3 becomes r23 = i; r24 = 3; call _imul3
[09:24:25] <twnqx> hm
[09:24:34] <LeoNerd> Come on gcc.. it's not that hard!
[09:24:42] <cehteh> yes seen that to
[09:24:46] <twnqx> i am pretty sure on x86 it had an update for it
[09:24:50] <cehteh> but +3 is not that common
[09:24:58] <cehteh> but increment/decrement is
[09:24:58] <twnqx> *3 you mean
[09:25:05] <LeoNerd> It is if I have 3-byte wide elements in my arrays
[09:25:06] <cehteh> eh yes
[09:25:10] <LeoNerd> because 2byte function pointer + 1 byte flag
[09:25:18] <twnqx> on x86, it uses an address calculation of the form n*x+x
[09:25:27] <LeoNerd> arr[i].flags |= FLAG; <== involves a call to __imul3
[09:25:37] <LeoNerd> because sizeof(arr[0]) == 3
[09:25:54] <LeoNerd> If I waste bytes and make 4-byte sized array elements, then gcc makes a more efficient multiply-by-4 and it's faster
[09:26:06] <twnqx> but i guess avr doesn't have such complex address calculation methods :P
[09:26:56] <twnqx> or rather, (x << n) + x, with n = 1,2,4,8
[09:27:07] <LeoNerd> Yah.. x86 is crazy though
[09:27:10] <LeoNerd> We all know this ;)
[09:27:11] <twnqx> or just 0,1,2,4? damn :/
[09:27:19] <twnqx> my x86 asm is rusty :(
[09:27:25] <LeoNerd> Also the last piece of silicon that actually natively executed x86 was manufactured in.. what... 1998?
[09:37:48] <Emil> LeoNerd: what does that mean?
[09:38:04] <LeoNerd> "that"? You'll have to be more specific
[09:38:17] <Emil> Your last message
[09:38:45] <LeoNerd> The Pentium Pro.. I believe that was the last native-silicon implementation of an x86 machine
[09:38:55] <Emil> LeoNerd: yeah, but what does that mean? :D
[09:39:15] <LeoNerd> It means that beyond that, everything was a RISC machine with an x86 decoder frontent
[09:39:17] <LeoNerd> frontend
[09:39:23] <Emil> We still use x86 (albeit x86-64)
[09:39:32] <LeoNerd> Sure. But the silicon doesn't execute it natively
[09:39:38] <Emil> LeoNerd: :o
[09:39:42] <Emil> what happens there, then?
[09:39:56] <LeoNerd> All modern x86 chips are RISC machines that have a converter on the front. x86 code is just an efficient way to pack the instructions for it
[09:40:03] <LeoNerd> and has certain back-compat advantages :)
[09:40:24] <twnqx> well
[09:40:35] <twnqx> i'd rather say backward compatible than efficient...
[09:40:46] <twnqx> it's very expensive to decode
[09:40:46] <LeoNerd> Mm.. it's fairly size-efficient
[09:40:54] <LeoNerd> It's nice on the I-cache
[09:41:12] <twnqx> there is no i-cache any more, they store trancoded instructions
[09:41:17] <twnqx> transcoded*
[09:41:25] <LeoNerd> Mmm
[09:41:46] <twnqx> and i think the decoder is larger than the execution units these days
[09:42:06] <LeoNerd> Wouldn't surprise me at alk
[09:42:16] <LeoNerd> Hell, the decoder on the original 4004 is still quite large
[09:42:29] * LeoNerd has the 4004 at the per-transistor level on paper :)
[09:43:27] <twnqx> http://www.visual6502.org/JSSim/ :3
[09:43:53] <LeoNerd> Ahyes.. the 6502
[09:44:15] <LeoNerd> Is the decode block here that prom block across the top?
[09:44:22] <LeoNerd> That certainly looks very decody
[09:44:47] * LeoNerd looks atannotated floorplan
[09:45:04] <LeoNerd> Hmm. it just calls that the PLA
[09:48:01] <Emil> twnqx: are you back from work?
[09:48:08] <twnqx> no
[09:48:13] <Emil> Okay
[09:48:16] <twnqx> just 4:18pm here
[09:48:30] <Emil> you are 4 minutes off!
[09:49:23] <twnqx> yeah
[09:49:30] <twnqx> this laptop loses time on suspend/resume
[09:49:33] <twnqx> don't ask me why
[09:50:29] <Emil> twnqx: no ntp?
[10:37:00] <Emil> twnqx: yet? :D
[10:41:18] <twnqx> ... no, that was just a wlan outage due to access point updates
[10:41:23] <Emil> https://emil.fi/jako/serial.c.txt
[10:41:28] <Emil> Here's what I have at the moment
[10:41:49] <Emil> Which works
[10:42:35] <Emil> It's trivial to add a switch statement for cfset*speed but I'd like to know what to use for the faster speeds
[10:42:41] <twnqx> here's a hint
[10:42:56] <twnqx> don't read by the byte :P
[10:43:00] <Emil> I know :D
[10:43:20] <Emil> But I'm interested in this being a byte stream, mostly
[10:43:31] <Emil> without any buffering
[10:45:24] <Emil> Besides, readinb bytebybyte is actually what mostly happens
[10:45:34] <Emil> even if I tried to read n bytes
[10:50:38] <twnqx> my other code has transparent buffering :P
[10:51:14] <Emil> twnqx: please share, master
[10:53:08] <twnqx> sur, will do
[12:51:10] <dsal> If I'm putting an atmega328p on a board, are there any other required components?
[12:51:30] <cehteh> *the* 100nF cap
[12:52:03] <LeoNerd> The? I usually put two on; one for each VCC/GND pair
[12:52:16] <cehteh> inductor and another cap (or 2) when you want to use the analog parts properly,
[12:52:23] <dsal> What's that do? (EH(acker) noob)
[12:52:34] <dsal> No analog
[12:52:40] <cehteh> yes or 2 .. or more .. but at least one .that is the "the" cap
[12:52:51] <dsal> Just driving an spi thing and taking serial
[12:53:33] <cehteh> also crystal or another clocksource, maybe caps for it when you want external clock
[12:53:41] <LeoNerd> If you're doing serial then you'll want a crystal + its two loadcaps
[12:53:46] <cehteh> and when you need a stable frequency then you want that
[12:53:48] <LeoNerd> Internal osc. isn't precise enough
[12:54:15] <cehteh> you may calibrate internal osc .. but that needs some precaution
[12:54:19] <dsal> Yeah. I kind of want to do 115.2k, so need a weird crystal anyway
[12:54:22] <LeoNerd> Isn't it prone to drift?
[12:54:35] <cehteh> yes it is
[12:54:58] <cehteh> so you have to calibrate it to operating conditions .. and/or add some dynamic calibration
[12:55:22] <cehteh> and you only get ±1% even with calibration
[12:55:34] <cehteh> osccal is coarse
[12:56:02] <Emil> cehteh: how do you do dynamic calibration?
[12:56:07] <cehteh> connect all VCC and GND lines
[12:56:28] <dsal> Yeah, my attiny ppm -> pwm thing was more simple since clock doesn't matter much.
[12:56:45] <cehteh> i have an api for that in muos, sync with external signals like 1sec pulse or so
[12:56:55] <dsal> I think if read a pullup was recommended on reset, so I did that.
[12:57:11] <cehteh> you call it with a 'now' timestamp and a what time should have elapsed since last call
[12:58:01] <cehteh> you can leave reset completely unconncected, it has a weak pullup .. but better you add some, if you connect it in any way you should add a pullup
[12:58:35] <cehteh> also any unconnected pins should be pulled up or down, at least on battery powered devices
[12:58:43] <Lambda_Aurigae> Emil, I've done dynamic calibration using the internal RC oscillator by having the PC connected at the far end send a string of UUUU and adjusting internal frequency until I can see it at the AVR then sending an OK back.
[12:58:45] <cehteh> you can just enable the internal pullups for those
[12:58:58] <dsal> Do you need that for atmega?
[12:59:31] <cehteh> any cmos .. but its only a 'recommendation' the chip may draw more power when you dont do that
[12:59:37] <Lambda_Aurigae> atmega should have, at a minimum, decoupling cap on the VCC/GND pair and a pullup on the reset(even 100K ohm resistor works)
[13:00:02] <cehteh> wont matter on development/breadboard and when you have some power supply, but for battery powered devices its a good idea
[13:00:07] <Lambda_Aurigae> any inputs should be pulled either high or low...standard for all digital electronics.
[13:00:08] <Emil> Lambda_Aurigae: You should use some other character
[13:00:11] <Emil> to guarantee sync
[13:00:21] <dsal> Maybe I'll just NC it. I didn't actually order a board yet.
[13:00:29] <Lambda_Aurigae> Emil, autobaud stuff has used U for many many years.
[13:00:58] <Emil> Lambda_Aurigae: sure, but characters with higher entropy are better
[13:00:59] <cehteh> Emil: at least you should not connect unused pins directly to gnd or vcc .. in case of a programming error shit happens :D
[13:01:10] <Emil> cehteh: wrong hilight ; )
[13:01:18] <cehteh> er dsal :)
[13:01:38] <Lambda_Aurigae> Emil, depends on how you handle it...with U you get a nice square wave.
[13:02:06] <Emil> Lambda_Aurigae: but yeah, I was wondering if there was some dark magic to get a good frequency reference
[13:02:08] <cehteh> and any output which drives voltage driven things (fet, cmos, ....) must have a pullup/pulldown
[13:02:31] <Lambda_Aurigae> Emil, all kinds of dark magic...dozens of ways to handle it that I've seen over the years.
[13:02:37] <cehteh> when the chip reboots or otherwise faults outputs may be high-z leaving your output foating
[13:03:05] <LeoNerd> Ahyes, I forgot that once when swapping from BJTs to FETs
[13:03:14] <LeoNerd> Suddenly lots of random noisy behaviour on reboots
[13:03:16] <cehteh> having for example a motor driven by a fet on a floating pin calls for desaster
[13:03:23] <LeoNerd> Mmmmmm
[13:03:30] <Lambda_Aurigae> cehteh, it's called uncertainty..
[13:03:32] <LeoNerd> Especially an H-bridge ;)
[13:03:37] <Lambda_Aurigae> robots with those tend to jitter nicely..hehe
[13:03:43] <cehteh> Schrödingers AVR :)
[13:03:54] <Lambda_Aurigae> or Heisenberg's
[13:04:18] <dsal> cehteh: thanks for all the pointers.
[13:04:58] <cehteh> and dont worry too much .. arduino does everything saied wrong and still sells :D
[13:05:10] <Lambda_Aurigae> hehe.
[13:05:18] <Lambda_Aurigae> ardweeny for the WTF!
[13:05:18] <LeoNerd> "first-to-market" and all that ;)
[13:06:04] <cehteh> it would be really nice if there would be a PUD fuse .. buring pullups into the chip
[13:06:06] <Lambda_Aurigae> normally when you have an external crystal you need a pair of caps from the crystal pins to GND...otherwise the oscillator won't start...
[13:06:20] <Lambda_Aurigae> put said circuit on a solderless breadboard and 95% of the time you don't need the caps.
[13:06:36] <Lambda_Aurigae> solderless breadboard has enough stray capacitance to kick it right up.
[13:06:37] <cehteh> because the breadboard provides the capacity
[13:06:39] <cehteh> :)
[13:06:55] <cehteh> there are plenty wtf things which can happen
[13:07:33] <cehteh> any unterminates wires and traces can also become strange .. usually they dont, but shit happens
[13:07:37] <Lambda_Aurigae> I've seen people make that mistake many times..build it on breadboard,,,it works,,,transfer to stripboard or veroboard and half the time it won't function...add caps and away it goes.
[13:08:03] <Lambda_Aurigae> and I've used floating inputs with long traces connected to them as random number generators.
[13:08:23] <cehteh> not really random .. just undefined
[13:08:32] <Lambda_Aurigae> was random enough.
[13:08:38] <cehteh> lucky
[13:08:49] <Lambda_Aurigae> 8 input pins with long traces run all over the board that connected to nothing else.
[13:09:09] <cehteh> dont become half of them saturated over time?
[13:09:30] <Lambda_Aurigae> oh, you switch between input and output and back again then read the input.
[13:10:00] <Lambda_Aurigae> was more random than the random function on the XT or Commodore computers I love so much.
[13:10:06] <cehteh> lol ok
[13:10:43] <cehteh> i still have the plan to connect 2 zeners to the 20x gain amp another to the aref .. and see what happens
[13:10:46] <Lambda_Aurigae> those were predictable as they used a limited pseudo random table and a seed...and if you didn't seed then they always had the same pattern.
[13:10:57] <cehteh> dunno if it prduces enough noise, just a try
[13:11:26] <Lambda_Aurigae> that could produce some fun data I'm sure.
[13:12:28] <Lambda_Aurigae> hmm..make a little crystal radio and feed that into the ADC input for some nifty randomish noise too.
[13:13:02] <Lambda_Aurigae> but that takes a lot more software than just toggling the port direction and reading it.
[13:13:10] <cehteh> whoever controlls the airwaves controls your random :D
[13:13:18] <Lambda_Aurigae> yup.
[13:13:28] <Lambda_Aurigae> but, music these days is so flippin random anyhow.
[13:14:04] <Lambda_Aurigae> I can't tell a lot of modern music from random noise as it is.
[13:14:23] <liwakura> also, adc has some sort of jitter
[13:14:32] <Lambda_Aurigae> yup.
[13:14:41] <Lambda_Aurigae> it's just too sensitive for its own good.
[13:14:45] <cehteh> i have a plan to add a simple random api in my drawer .. just whenever one gathers something more or less random one calls random_push(uint8_t random, uint8_t quality)
[13:14:53] <liwakura> also considered using adc for random generator
[13:15:05] <liwakura> bu the thing is, i don't know what i should randomize
[13:15:14] <liwakura> *but
[13:15:33] <cehteh> the backend then xors(and shuffles) the randoms onto a small queue, advancing whenever quality sum exceds some limit
[13:16:15] <liwakura> i would use a pseudorandom generator and just disturb its output with the adc
[13:16:17] <cehteh> ADC is a good source .. WDC osc is too
[13:16:59] <cehteh> i want first bare trie random, i may add a slight debias but thats all
[13:17:10] <cehteh> using that as seed for a prng would be a layer above
[13:17:49] <Lambda_Aurigae> we used the 8pin input random thingie for a mapping bot a couple years ago...to introduce some random movement into its room search and map algorithm.
[13:17:49] <LeoNerd> Another source of entropy is the WDT
[13:17:50] <cehteh> plan here is to add a rng to linux servers
[13:17:58] <LeoNerd> Spin one of the timer units nicely fast, then sample it on WDT interrupt
[13:18:11] <cehteh> yes thats common
[13:19:07] <Lambda_Aurigae> http://www.sololearn.com/
[13:19:09] <cehteh> note: you can not make randoms any more works by adding bad random data, thats why i added this 'quality' parameter one can just add poor things, wiith low quality
[13:19:10] <Lambda_Aurigae> interesting.
[13:19:51] <liwakura> depends on how you do it
[13:19:58] <cehteh> no it does not
[13:20:07] <cehteh> there is some proof for that
[13:20:20] <liwakura> if you xor a absolutely non-random (a static) one over a otherwise randomized value
[13:20:28] <liwakura> it does not get less entropy somehow
[13:20:53] <cehteh> even if you feed 100% predictable data (like only zeros) into a random pool you can not make worse (of course not better either)
[13:21:02] <Lambda_Aurigae> I've seen people doing phd thesis on nothing but random numbers.
[13:21:10] <WormFood> I couldn't find any steel wool, so I got one of those dense foam pads, with an abrasive on the outside, for cleaning pots and pans. Works fuckin' great for PCBs.
[13:21:22] <cehteh> of course if you tell the pool that you feed high quality randoms if you dont, then it may fail
[13:21:38] <cehteh> WormFood: i use them too yes
[13:21:40] <Lambda_Aurigae> WormFood, green scrubby?
[13:21:43] <liwakura> if you use a pool it could have some bad side effects
[13:21:48] <WormFood> no
[13:21:54] <WormFood> It's brown
[13:21:55] <cehteh> liwakura: nope
[13:22:00] <Lambda_Aurigae> hmm.
[13:22:05] <WormFood> with gray foam
[13:22:11] <Lambda_Aurigae> I always use green scrubby pads for doing PCBs.
[13:22:16] <Lambda_Aurigae> abrasive but not too much so.
[13:22:18] <liwakura> cehteh: depends :D
[13:22:28] <WormFood> it looks like a rubber sponge, coated with sand paper.
[13:22:30] <cehteh> they are available in different colors for each grit
[13:22:36] <Lambda_Aurigae> aahh,,have seen those.
[13:22:42] <WormFood> They had 2 different sizes, so I picked the smaller one. It has a finer grit.
[13:22:55] <cehteh> liwakura: there is pretty much you can do on a random thing .. but not that
[13:23:03] <WormFood> well, these are Chinese, so they're too cheap to use different colors.
[13:23:06] <cehteh> you can do wrong
[13:23:08] <Lambda_Aurigae> have considered trying the Mister Clean Magic Eraser to see how that would work too.
[13:23:25] <liwakura> cehteh: using the same source twice would make it pretty bad
[13:23:31] <WormFood> And the combination of the foam, and the abrasive, seems to be just about the perfect combo for cleaning PCBs
[13:23:44] <WormFood> I expect it will also work great for cleaning component leads.
[13:24:07] <WormFood> They're a little expensive though. About $3 USD for a pack of 2.
[13:24:36] <cehteh> liwakura: i saied: adding bad randoms cant make it worse than it already is ...
[13:24:57] <cehteh> if you start and only use bad sources then of course you never get good randoms
[13:25:04] <WormFood> d'oh. I'm screwing up the price. They're 1/2 of what I said. About $1.50 usd for a pack of 2
[13:25:27] <cehteh> but when you have uncertain sources you can just add them together with better sources, they will never make it worse
[13:25:41] <liwakura> they could influence themselves
[13:26:01] <liwakura> uhm, gimme a second
[13:26:03] <cehteh> (of course the uncertain source should have no view on the internal state so that it could maliciously tamper with it)
[13:26:18] <liwakura> yeah, no feedback there
[13:26:19] <cehteh> i am only talking about adding
[13:26:43] <cehteh> anyway .. that is a nice property but it is kindof weak
[13:28:31] <WormFood> [01:40:58] <cehteh> there are plenty wtf things which can happen <-- I've seen my fair share of WTFs. Like a resistor, like 100k ohm, SHORT OUT! Yeah, I've seen a fuckin' resistor, read zero ohms. I also had a light sensitive EPROM once. If you turned out the light, or closed the case, the computer wouldn't work.
[13:29:10] <Lambda_Aurigae> hehe.
[13:29:13] <cehteh> you know the rpi2's flash of death? :)
[13:29:24] <Lambda_Aurigae> rPI has a light sensitive power control chip.
[13:29:30] <Lambda_Aurigae> flash sensitive anyhow.
[13:29:46] <WormFood> I had an old 286 with a bad refresh circuit on the dram. If you booted it, and immediately ran a ram test, it'd run for hours, showing no problems. within 15 seconds after stopping the ram test, the computer would crash.
[13:30:09] <WormFood> I had a monitor destroy a keyboard once.
[13:31:05] <WormFood> The keyboard was sitting on my lap. I reached up to wipe the dust from the monitor. The static electricity went through my body, to zap the keyboard, through my leg, to the back of the case. This was one of the original IBM PC keyboards, with the function keys on the left hand side.
[15:59:19] <LeoNerd> How annoying. The ATtiny841 only has 512 bytes of RAM. So I can't make a full-universe DMX512 master
[15:59:27] <LeoNerd> ... because the universe buffer would take every byte of that RAM
[15:59:44] <Lambda_Aurigae> so?
[16:00:02] <Lambda_Aurigae> Jartza built a vga adapter that used all 512 bytes of ram in the attiny85.
[16:00:12] <Lambda_Aurigae> all that ram was used for the video buffer in fact.
[16:07:12] <LeoNerd> Hmm... I don't know if I'd fit the remaining master logic in *just* the registers and those cheeky GPIO registers
[16:08:11] <Lambda_Aurigae> sounds like a challenge to me.
[16:08:25] <LeoNerd> It's either I²C or SPI slave
[16:08:31] <liwakura> you have like 40 registers you could use
[16:08:34] <LeoNerd> Which needs more of its own stuff
[16:08:50] <LeoNerd> Oh I suppose I could also use fully-populated registers of other hardware I'm not using
[16:09:00] <Lambda_Aurigae> Jartza fit most of the vt100 command structure plus a bitbanged uart in it.
[16:09:04] <LeoNerd> I don't need the ADC, so. hey.. lets use ADCL/ADCH
[16:09:26] <liwakura> also its GPIOR not GPIO
[16:09:56] <liwakura> today i found out that my USB AVR programmer is just an atmega8l itself
[16:10:12] <Lambda_Aurigae> liwakura, usbasp based?
[16:10:26] <liwakura> usbasp clone from china.
[16:10:27] <LeoNerd> liwakura: Yah.. most are :)
[16:10:30] <Lambda_Aurigae> yup.
[16:10:30] <liwakura> the black one.
[16:10:32] <LeoNerd> The Pololu one is a PIC
[16:10:43] * LeoNerd idly wonders how many PIC programmers are AVR-based
[16:10:48] <Lambda_Aurigae> very few.
[16:10:53] <Lambda_Aurigae> most pic programmers are pic based.
[16:11:03] <liwakura> now to my problem. its my only programmer
[16:11:06] <Lambda_Aurigae> I have one that is avr based but I made it myself.
[16:11:35] <liwakura> so i need to program one of my atmegas (usb to serial onboard) as stk500 or so
[16:11:55] <Lambda_Aurigae> or use v-usb/usbasp software and make another one.
[16:13:08] <liwakura> im quite limited in hardware, i only have 4 arduino nano boards and that atmega8l programmer
[16:13:33] <liwakura> so, i guess the stk over the nano boards is my only choice
[16:13:50] <Lambda_Aurigae> I understand there is an arduino program to turn said device into an avr programmer
[16:14:12] <liwakura> i have that in the Arduino IDE
[16:14:32] <liwakura> but i have certain issues with the Arduino stuff.
[16:14:38] <Lambda_Aurigae> same here.
[16:14:42] <Lambda_Aurigae> which is why I own none.
[16:14:56] <liwakura> tbh i don't want the to use any arduino sketches or libraries
[16:15:31] <Lambda_Aurigae> there are several stk500-ish programs out there for AVRs.
[16:17:11] <liwakura> is there a known fully compatible?
[16:17:12] <Lambda_Aurigae> I find I use my stk200 clone more than anything else.
[16:19:49] <Lambda_Aurigae> but, I also keep machines with parallel ports everywhere.
[16:20:10] <liwakura> oh
[16:20:17] <liwakura> i also have a parallel port
[16:20:25] <liwakura> i remember its 5 V
[16:20:30] <Lambda_Aurigae> yup.
[16:20:43] <liwakura> avrdude can bitbang spi over that
[16:20:52] <Lambda_Aurigae> isp, but, yes.
[16:21:12] <liwakura> and i coincidentally have plugs without cables soldered to them here.
[16:21:56] <Lambda_Aurigae> https://sites.google.com/site/emrirc/avrstuff
[16:22:06] <Lambda_Aurigae> several different stk200 programmers.
[16:22:22] <Lambda_Aurigae> unbuffered just uses some wire and 4 resistors.
[16:23:04] <liwakura> yessss
[16:23:12] <liwakura> i can solder that in like 5 minutes
[16:23:38] <liwakura> thanks for that link
[16:23:43] <Lambda_Aurigae> it works...that one was my second avr programmer.
[16:23:47] <liwakura> i was just about to google myself :D
[16:24:07] <Lambda_Aurigae> https://sites.google.com/site/emrirc/avr-ispdongle.pdf
[16:24:19] <Lambda_Aurigae> that's the first one I built..and it still works.
[16:24:29] <Lambda_Aurigae> 12+ years ago.
[16:25:53] <liwakura> hm. the only device with parralel port here has sabotage linux...
[16:26:16] <liwakura> where i just happened to add avrdude for
[16:26:34] <liwakura> 2 days ago
[16:27:34] <Lambda_Aurigae> and away you go.
[16:28:24] <Lambda_Aurigae> I've also built the 74125 and 74244 based ones inside a db25 hood.
[16:28:30] <liwakura> nah, i think ill do it tomorrow
[16:28:38] <liwakura> such thing requires careful planning
[16:28:54] <Lambda_Aurigae> I've also done it unbuffered with no soldering
[16:28:57] <liwakura> i have a work queue like have idea today, do it in 2 days
[16:29:01] <Lambda_Aurigae> just stick wires into the parallel port.
[16:29:10] <liwakura> Lambda_Aurigae: no resistors?
[16:29:26] <Lambda_Aurigae> wires in the holes and over to solderless breadboard..then with and without resistors.
[16:29:39] <liwakura> nice.
[16:29:39] <Lambda_Aurigae> resistors are mostly for protection of the parallel port.
[16:33:45] <carabia> Anyone done any FAT (MS) stuff?
[16:34:05] <Lambda_Aurigae> only with a small toying around with fatfs.
[16:34:18] <carabia> Alright. I've got one for ya
[16:34:51] <Lambda_Aurigae> and many years ago, editing floppy disks with fat on them.
[16:35:38] <LeoNerd> carabia: me. Only FAT16
[16:35:38] <Lambda_Aurigae> mostly for data recovery.
[16:35:38] <LeoNerd> I do 2GiB SD cards with them
[16:35:38] <carabia> FAT16 supports long filenames too, yes?
[16:35:38] <LeoNerd> The size of the FAT is unrelated to LFN support
[16:35:41] <LeoNerd> You can put LFNs on 12/16/32, or not
[16:35:56] <carabia> The way it splits the filenames, it precedes the real entry with the extended filename in 16-bit chars (at least FAT32)
[16:36:05] <LeoNerd> Ohyes.. UTF-16. How fun
[16:36:19] <carabia> and it sets the first byte to "offset"
[16:36:28] <carabia> and the last in line is OR'd with 0x40
[16:36:37] <carabia> well, technically the first entry...
[16:36:41] <carabia> whatever. Not my point
[16:36:47] <Lambda_Aurigae> you will notice that even fat32 keeps backwards 8.3 compatibility.
[16:36:49] <LeoNerd> I'm not sure about LFNs,.. I don't need to use them so I don't implement it
[16:37:04] <carabia> Well my question isn't strictly about LFN's
[16:37:13] <carabia> It's about dir entries that are flagged "archive"
[16:37:16] <Lambda_Aurigae> LFN is an optional on all fat systems.
[16:37:40] <LeoNerd> "archive" is the modification flag, basically
[16:37:49] <carabia> hmm?
[16:37:52] <carabia> please explain
[16:37:53] <LeoNerd> Any mutation operation ought to set that flag. Nothing clears it automatically
[16:37:58] <LeoNerd> Backup software clears it
[16:38:08] <LeoNerd> It's a really cheap way to work out what files need saving on an incremental backup
[16:38:18] <LeoNerd> These days things like rsync use modification timestamps instead
[16:39:15] <carabia> Hmm
[16:39:47] <Lambda_Aurigae> https://en.wikipedia.org/wiki/Archive_bit
[16:41:17] <LeoNerd> Ooh oops. I forgot to set that in my own implementation
[16:59:31] <Lambda_Aurigae> one could use the archive bit for whatever one wanted really.
[17:00:10] <carabia> So, I created this fat32-volume with windows. I created a bunch of .txt files in it, with "New -> new text file", and they are given the default name until i rename them
[17:00:50] <carabia> And now I'm seeing a bunch of files in the root dir (with a hex editor), with default name, "archive bit" set, and having cluster addr 0x00000000
[17:02:11] <carabia> Are those basically ghosts of the renamed files or what the fuck's going on?
[17:02:19] <Lambda_Aurigae> checking.
[17:02:49] <carabia> Much obliged!
[17:08:17] <Lambda_Aurigae> ok..found what I was after, I think.
[17:08:40] <Lambda_Aurigae> so, bit five of byte 11 is the archive bit.
[17:08:55] <Lambda_Aurigae> what bytes are you reading as cluster addr
[17:10:42] <carabia> 20 and 21 hi
[17:10:49] <carabia> 26 27 lo
[17:12:04] <Lambda_Aurigae> ok...according to this, 0 is empty file.
[17:12:13] <carabia> And yeah bit five, if you count from 0
[17:12:23] <Lambda_Aurigae> 20 and 21 are reserved.
[17:12:29] <carabia> the entries are 0x20 so that would point to archive
[17:12:32] <Lambda_Aurigae> but this could be fat12.
[17:13:31] <Lambda_Aurigae> are those entries linked into the directory structure?
[17:13:58] <carabia> fat32 doesn't have a separate root dir, per se
[17:14:06] <carabia> root's treated just as any other dir
[17:14:12] <Lambda_Aurigae> yes.
[17:14:25] <Lambda_Aurigae> but are those entries on the disk actually linked into the directory structure?
[17:14:49] <carabia> https://staff.washington.edu/dittrich/misc/fatgen103.pdf I
[17:14:54] <Lambda_Aurigae> https://www.youtube.com/watch?v=5CzURm7OpAA this is awesome...about drones...totally offtopic.
[17:15:18] <carabia> I'm using this as a reference, and the FAT32 dir structure specifies hi and lo as 20 21 26 27
[17:15:43] <Lambda_Aurigae> ok..one I'm looking at must be fat12.
[17:15:54] <carabia> linked in, you mean as in the actual allocation table?
[17:16:32] <Lambda_Aurigae> as I remember the directory structure is a linked list...
[17:16:35] <Lambda_Aurigae> are they linked in?
[17:16:44] <carabia> yeah, the FAT is
[17:16:50] <carabia> hold on --
[17:18:39] <Lambda_Aurigae> is the first byte in the entry a zero?
[17:19:13] <Lambda_Aurigae> oops...didn't read that right..that means last entry.
[17:19:41] <carabia> The first byte in _those_ entries is 0xE5
[17:19:54] <carabia> Which is why this seems so fucked up.
[17:19:54] <Lambda_Aurigae> that means deleted.
[17:20:02] <Lambda_Aurigae> https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
[17:20:13] <Lambda_Aurigae> As a special kludge to allow undeleting files that were deleted by mistake, the DEL command will replace the first byte of the name by 0xe5 to signify "deleted". As an extraspecial kludge, the first byte 0x05 in a directory entry means that the real name starts with 0xe5.
[17:21:24] <carabia> Jesus fucking christ.
[17:22:34] <carabia> This is the first FS I'm having to work with. I hope all of them aren't as clusterfucked as this
[17:22:39] <WormFood> you didn't know that?
[17:22:43] <Lambda_Aurigae> they get worse.
[17:22:45] <Lambda_Aurigae> far worse
[17:22:47] <Lambda_Aurigae> try ext3
[17:22:48] <WormFood> FAT is fairly straight forward
[17:23:07] <WormFood> FAT is amazingly simple. I've fixed fat before with a hex editor.
[17:23:18] <WormFood> It don't get much simpler than FAT
[17:23:24] <Lambda_Aurigae> or worse, ext4 or,,,ntfs.
[17:23:36] <carabia> I guess I'll just have to adapt
[17:23:43] <WormFood> ext4/ntfs are in a totally different category of file systems
[17:24:04] <WormFood> they're typically journaled
[17:24:10] <Lambda_Aurigae> yup.
[17:24:16] <Lambda_Aurigae> but ext3 is pretty horrid too.
[17:24:24] <WormFood> I doubt that.
[17:24:31] <Lambda_Aurigae> compared to fat it is.
[17:24:33] <WormFood> It's very reliable
[17:24:41] <WormFood> compared to what? Complexity?
[17:24:43] <Lambda_Aurigae> as far as trying to hack it up.
[17:25:29] <carabia> Oh well in any case, thanks a bunch Lambda_Aurigae . Saved me a lot of time trying to peruse this
[17:25:49] <carabia> And sorry for the off-topic.
[17:26:39] <Lambda_Aurigae> nothing else was going on so no worries on my side.
[17:26:45] <Lambda_Aurigae> I love going off topic.
[17:48:58] <cehteh> ok my random thingy works, and /dev/dsp has poor random here (mic off :)
[17:53:45] <cehteh> Entropy = 7.998271 bits per byte. ...
[17:54:14] <LeoNerd> Umm... very nearly 8bits of entropy per... 8bit byte.
[17:54:18] <LeoNerd> That sounds prettymuch ideal to me
[17:55:35] <cehteh> well i only gathering it, dont creating it, but with the quality factor i can control how much bad random it put into the pool to form a good random
[17:56:56] <cehteh> http://paste.debian.net/679865/
[17:57:03] <cehteh> quite simple code
[17:58:46] <cehteh> and dont forget to check for random availabiliy, else it returns 0 .. intentionally
[17:58:53] <Valen> might be worth reading
http://www.2uo.de/myths-about-urandom/
[17:59:40] <cehteh> i fed /dev/urandom into my code .. gives even better results, no wonder :D
[18:00:17] <cehteh> the dsp is not really good, thats why i choosen it as test
[18:01:05] <cehteh> true randomness exists only over infinite time :) everything else is just an approximation
[18:09:58] <Lambda_Aurigae> nothing is random...the gods know what's going to happen...
[18:10:02] <Lambda_Aurigae> :}
[18:11:55] <cehteh> gods are random
[18:12:09] <cehteh> fopen("/dev/god" ..) ...
[18:13:51] <Valen> from god import good_*
[18:15:38] <Lambda_Aurigae> #include <gods/glub.h>
[18:16:35] <Lambda_Aurigae> of them all, glub is my favorite.
[20:35:24] <dsal> Sorry to dig up something from earlier, but cehteh mentioned I need a 100nF cap in my atmega circuit... I forgot to ask how/where? :/
[20:36:28] <dsal> I don't see it mentioned in the datasheet (except for ADC use cases) and digging around in google searches I'm finding mentions of it, but not where to actually put it.
[20:37:04] <dsal> Oh hey, just found this:
http://www.avrfreaks.net/forum/decoupling-capacitor-vcc-pin
[20:37:18] <dsal> (searched for atmega 100nF decoupling)
[20:37:31] <eszett> Hi!
[20:37:53] <eszett> dsal... 100nf? hmm
[20:38:19] <eszett> 100nf is 0.1µf no?
[20:38:28] <dsal> That sounds right.
[20:38:40] <eszett> you need two of them for the basic circuit afaik
[20:38:53] <eszett> at least i have two in my basic circuit of an Atmega32u4
[20:38:59] <eszett> which AVR do you use?
[20:39:05] <dsal> I'm doing this with an atmega328p
[20:39:09] <eszett> hmhmh
[20:39:21] <dsal> No ADC, though I will probably have to find a good crystal, so I'm going to need a couple for that.
[20:39:32] <eszett> people would say "read the datasheet" but i know that this is an arrogant and shitty answer ;-)
[20:39:41] <dsal> Yeah, I've been digging through it.
[20:39:51] <dsal> It's actually pretty well written, but I don't know what I'm doing. :)
[20:40:02] <eszett> datasheets well written ... sheesh
[20:40:17] <eszett> check for "atmega328p basic circuit"
[20:40:32] <dsal> All the references to caps and decoupling are related to ADC specifically, so I assume it's something you're just supposed to know because you went to school or something.
[20:41:17] <dsal> Yeah, this looks interesting:
http://i.stack.imgur.com/zfOkV.gif
[20:41:25] <eszett> http://i.stack.imgur.com/zfOkV.gif
[20:41:30] <dsal> heh
[20:41:32] <eszett> "0.1u" is the one your looking for
[20:41:33] <eszett> yes
[20:41:53] <eszett> there is only one?
[20:41:56] <eszett> ok, maybe..
[20:42:20] <eszett> im really just a beginner like you
[20:42:48] <dsal> Cool. Yeah, I'm stumbling my way through and trying to learn a bit more each time I do something.
[20:43:14] <eszett> the problem is, each mistake i do, costs me a batch of pcbs which is about 160€ ;-)
[20:43:49] <dsal> ick. My latest design I uploaded to oshpark is $1.65 for three.
[20:43:53] * dsal goes small
[20:44:02] <dsal> The one before that was like, $.65.
[20:44:24] <dsal> This one is going to be bigger, though.
[20:44:27] <eszett> lol.. that makes life way easier
[20:50:29] <eszett> I have a question...
[20:50:45] <eszett> if the pads of the PCB are "silver" then there is solder on it off factory, right?
[20:51:09] <eszett> like on this board
https://www.youtube.com/watch?v=uJNjNOAxvqY#t=4m50s
[21:12:36] <inflex> eszett, usually is from HASL process
[21:40:03] <eszett> inflex: that means, there is a little bit of solder on it to avoid oxidation, but its not enough to use if for tacking a -- eg. -- qfp down, right?
[21:40:45] <inflex> yeah, I wouldn't rely on it for tacking
[21:40:54] <inflex> I always add my own for a tack down
[21:40:54] <eszett> hmm ever tried it?
[21:44:08] <eszett> i will try. Ill use a hot air gun and either the AVR is tacked down by HASL alone, or it is not.
