Back
[03:01:37] <liwakura> i've got timekeeping ready on my atmega :D
[03:01:54] <liwakura> with [ 123.456] linux-style timestamps in the debug serial
[03:02:13] <liwakura> just let me be happy about it. Its somehow cool-
[03:03:31] <cehteh> haha
[03:03:37] <cehteh> congrats
[03:06:48] <cehteh> blocking io? buffered?
[03:08:14] <liwakura> uhm, asynchronous with buffers and interrupts
[03:08:30] <liwakura> https://github.com/liwakura/avr-sh
[03:11:13] <cehteh> bug bug :D
[03:11:27] <liwakura> wha
[03:11:29] <liwakura> tell me
[03:12:01] <cehteh> your queue implementation, how do you detect if the queue is full?
[03:12:30] <cehteh> .. and then .. how if its empty
[03:12:44] <liwakura> by asking queue_len if its empty
[03:13:06] <liwakura> if queue_put is called on an full queue, data gets discarded
[03:13:16] <cehteh> well maybe it doesnt bug, but then you cant use one byte
[03:13:16] <liwakura> thats why i have RTS and CTS on PD2 and PD3
[03:13:47] <liwakura> cehteh: thats the cost, otherwise i wouldn't have a way to differentiate between 0 and QUEUE_LEN bytes
[03:13:51] <cehteh> aka better store read+length and not read,write
[03:14:28] <liwakura> then i have to do 2 counter operations on read, read++ and length--
[03:14:44] <cehteh> thats still cheaper than you are doing it now
[03:14:44] <liwakura> im worried what will happen if an interrupt occurs between the two
[03:15:09] <cehteh> disable interrupts
[03:15:37] <liwakura> won't the interrupts being triggered in that time being lost then?
[03:15:41] <cehteh> you have to make these volatile anyway
[03:16:00] <liwakura> yeah, just noticed that i forgot volatile. I wonder why it still works
[03:16:08] <cehteh> just coincidence
[03:16:23] <cehteh> that are really hard to find bugs
[03:16:43] <cehteh> once in a million times the interrupts happens at the wrong timing and it falls apart
[03:17:00] <liwakura> i dislike that kind of failure...
[03:17:09] <liwakura> because thats sorta, a bug
[03:17:33] <liwakura> systems aren't supposed to fail randomly
[03:17:38] <cehteh> http://git.pipapo.org/?p=muos;a=tree;f=src/muos/lib;h=6a7f52223bdd2c7898c128d739b994bfd517d0f7;hb=refs/heads/attiny
[03:17:52] <cehteh> my queues and stuff
[03:18:16] <cehteh> also avoiding modulo and doing if() branching instead
[03:18:33] <cehteh> this way the queues work with odd sizes efficiently too
[03:18:35] <liwakura> whats wrong with modulo?
[03:18:57] <cehteh> modulo can be costly as any division if the compiler cant optimize it
[03:19:02] <liwakura> cehteh: how i can git clone that thingie?
[03:19:13] <cehteh> and even optimizing it to shifts costs on avr
[03:19:29] <cehteh> git://git.pipapo.org/muos
[03:19:30] <liwakura> wasn't there some modulo instruction?
[03:19:43] <cehteh> iirc no
[03:20:13] <cehteh> i mean most avrs dont even have hardware multiplication (and no division either)
[03:20:31] <cehteh> comparsion is basically a substraction and branch, that should be cheap
[03:21:20] <liwakura> if i constrain the size to a power of 2, i just could use a logical and
[03:21:28] <liwakura> that wouldn't even need a branch
[03:21:40] <cehteh> yeah
[03:21:45] <cehteh> i just made it more generic, even for some cost
[03:22:14] <liwakura> im accepting PR's :D
[03:22:19] <cehteh> also with the option to use a struct { readpos:4; length:4 } bitfield
[03:22:28] <cehteh> that costs some code but saves 1 byte ram :D
[03:22:33] <liwakura> i see
[03:22:43] <cehteh> (attinys have very little ram, but flash might be enough)
[03:24:02] <liwakura> next thing, i wanna poll RX and count the TCN1 meanwhile to get possible UBRR values
[03:24:10] <liwakura> like baud rate autodetection
[03:24:32] <liwakura> maybe via interrupts because i think i have a fetish for interrupts.
[03:24:35] <cehteh> btw how doe flow control perform?
[03:25:08] <cehteh> i have xon/xoff on my list, but not high
[03:25:20] <liwakura> uart.c line 26ff writes an extra wire
[03:25:43] <liwakura> Im using the RTS/CTS hardware flow control thingie
[03:25:52] <cehteh> i mean did you test it,m does it work well, does the PC side flush some buffers still?
[03:25:56] <liwakura> currently only implemented for receiving
[03:26:19] <liwakura> uhm, my serial-to-USB converter seems to ignore the line. Or my PC does.
[03:26:26] <cehteh> haha
[03:27:03] <cehteh> the reason why i didint do it yet is because i have some doubts it will really work with tiny buffers
[03:27:09] <liwakura> but by reading the other line i can detect if the thing is attached to a computer or just to a power source
[03:27:25] <cehteh> well thats clear
[03:27:35] <cehteh> just wanted to know about flow control
[03:27:42] <liwakura> TX buffer can't overflow yet, since im waiting until its empty before i write other stuff
[03:27:54] <cehteh> bte in muos i have 2 queues for tx
[03:28:07] <liwakura> i've thought about the XON/XOFF thingie
[03:28:10] <liwakura> why 2?
[03:28:20] <cehteh> one binary 'compressed' queue and one small one for the interrupt
[03:28:41] <liwakura> oh
[03:28:42] <liwakura> i see
[03:28:48] <cehteh> allows to queue much more data than a single byte by byte queue would do
[03:30:10] <cehteh> integers are stored in the shortest possible way print(0) only stores a single char, print(65536) would need 3 bytes (one tag, 2 bytes unsigned 16 bit)
[03:30:31] <liwakura> hm
[03:30:39] <liwakura> sounds quite specialized
[03:30:52] <cehteh> strings (also progmem) are stored as 2 byte pointers on the queue
[03:30:59] <cehteh> yeah sure
[03:31:11] <cehteh> its about conserving ram
[03:31:31] <liwakura> hm.
[03:31:52] <cehteh> well its work in progress, not everything is implemented yet, but it works
[03:32:29] <cehteh> also the line editor with utf-8 support, finished that some time ago
[03:32:37] <liwakura> my concept for saving ram was more like just the default queue and copying from flash to there depending on the program flow
[03:33:22] <cehteh> but then you have to deal with queue stalls
[03:33:27] <cehteh> (earlier)
[03:33:45] <cehteh> here too .. when the queue is full one has to drop data or wait
[03:33:50] <liwakura> as soon as i get rid of that 7-digit display which i need to drive concurrently
[03:33:58] <liwakura> i can make uart_write blocking
[03:34:23] <liwakura> or just put the display things in some timer interrupt, but i don't like that display anyways
[03:34:52] <liwakura> purely aestethic reasons
[03:34:52] <cehteh> i am going to do that too, but i dont want to block the system
[03:35:14] <liwakura> thats why i love the interrupts
[03:35:36] <cehteh> not only interrupts here .. workqueues
[03:35:39] <liwakura> if i do all the time critical stuff, i can make my main() blocking like a default linux stdin program
[03:35:55] <cehteh> not even main blocks here :D
[03:36:09] <liwakura> what does your thing even do?
[03:36:28] <cehteh> little more generic OS like thingy
[03:36:51] <cehteh> scheduleing functionscalls, by timer or work queues
[03:37:27] <cehteh> prolly too much to call it a full OS its very simple
[03:37:31] <liwakura> im intending some sort of template i can reuse for actual useful projects
[03:37:37] <cehteh> haha same here
[03:38:05] <liwakura> until then, i use it as serial usb console
[03:38:22] <liwakura> with the atmega just watching the lines between the CH340 and the important device
[03:38:28] <liwakura> (hence the baud rate detector)
[03:38:53] <cehteh> currently i put the serial stuff aside and switched to attiny84 for the first real project for it :D
[03:39:05] <cehteh> controlling leds on a multicopter
[03:39:47] <liwakura> i have that irrational fear of interrupts colliding into each other
[03:39:52] <cehteh> parsing RC receiver signals, have a state machine from this signals which in turn defines some outputs (blink patterns)
[03:40:04] <cehteh> why? nothing happens then
[03:40:20] <liwakura> what if im missing an RX event?
[03:40:25] <cehteh> except .. one intereupt gets delayed which is pIta :D
[03:40:38] <liwakura> uhm.
[03:40:39] <cehteh> make your interrupts small and fast enough that the delay wont matter
[03:40:57] <liwakura> hm, i never asked what happens then
[03:41:02] <liwakura> they just get delayed?
[03:41:06] <liwakura> no discard?
[03:41:10] <cehteh> hey i use the input capture to parse the signal from the rc-receiver
[03:41:35] <cehteh> but the timer has its own overflow interrupts which increments a global counter
[03:41:40] <cehteh> *there* i had a collision
[03:41:53] <cehteh> timer may overrun while i have a input capture event
[03:42:00] <cehteh> that needed some special care
[03:42:02] <stephe> cehteh: i wanna build a multicopter one day :D
[03:42:06] <stephe> did you build your own?
[03:42:17] <cehteh> plenty
[03:42:31] <cehteh> https://twitter.com/CehtehCt recent work
[03:43:39] <liwakura> whats up with the lamp picture
[03:44:01] <stephe> cehteh: you write all the code from scratch?
[03:44:03] <cehteh> just someone asked me for it
[03:44:13] <cehteh> stephe: nope using others software :D
[03:44:35] <cehteh> hacked a bit on it
[03:44:41] <stephe> i guess it's quite difficult to do all that managing of motors?
[03:44:54] <cehteh> but well there are so many projects, i planned to start my own but i am lazy
[03:45:18] <cehteh> thats not so the problem, but there are other problems :)
[03:45:52] <cehteh> http://public.pipapo.org/IMAG0119.JPG tankcopter :D
[03:46:19] <stephe> that looks rad :D
[03:46:33] <stephe> tons of batterys
[03:46:40] <cehteh> flys 90km/h
[03:46:50] <cehteh> munches cows :D
[03:47:22] <cehteh> the smaller ones going to be much faster
[03:47:43] <cehteh> big one is a bit on the heavy side :D
[03:49:12] <cehteh> liwakura: so interrupts: the is always the 'interrupt enable' flag and one 'interrupt pending' flag (whatever that is, like timer overflow)
[03:49:32] <cehteh> for timers for example that makes each timer one bit wider
[03:49:47] <liwakura> so if im not delaying until an interrupts triggers twice, im not gonna lose anything?
[03:49:55] <cehteh> these 'pending' flags get set, even if some other interupt is in progress
[03:50:07] <cehteh> and when that interrupt returns, the pending one will be called
[03:50:21] <liwakura> that makes some things much easier
[03:50:23] <cehteh> and by calling the interrupt this bit gets cleared
[03:50:38] <cehteh> you cant not trigger the same interrupt twice
[03:50:49] <cehteh> but different interrupts can happen at overlapping times
[03:50:51] <liwakura> yeah i got it
[03:51:03] <cehteh> also for timers you sometimes need this extra bit
[03:51:11] <liwakura> i just wanted to know if discard or pending while interrupts are disabled
[03:52:03] <liwakura> driving an WS2812 or so LED chip will be next
[03:52:46] <cehteh> disableing interrupts with cli() will just disable the 'calling' of the interrupt
[03:53:00] <liwakura> i got it
[03:54:25] <cehteh> mhm for the tx/rx queues i dont call cli() sei() but specifically only disable the serial interrupts when pushing/poping something on the queues
[03:55:18] <liwakura> at first get rid of the modulo
[03:56:04] <stephe> can you use those ATOMIC macros instead of cli/sei?
[03:56:05] <cehteh> http://git.pipapo.org/?p=muos;a=blob;f=src/muos/hw/atmel/avr/cppm.c;h=602f2ee7890c15d99cded1616c9fddb7de25edee;hb=c4415cda5d3f3cf13b2ec87f6765adb6b1676d91#l54
[03:56:52] <cehteh> .. there you see some kludge handling the case the timer overflown, but the overflow interrupt wasnt called yet (because we are in capture interrupt)
[03:57:14] <liwakura> stephe: probably
[03:57:16] <cehteh> that was pita to figure out to make that correct
[03:57:41] <cehteh> the atomic macros wrap cli/sei only
[03:58:42] <cehteh> i got rid of a lot cli/sei in my scheduler by running it with interrupts disabled now :D it is small and would constantly cli/sei when checking queues
[03:59:18] <cehteh> so i disabled interrupts completely in the mainloop and only reenabling them when calling users functions or going to sleep
[03:59:26] <cehteh> that works like a charm
[03:59:34] <liwakura> by timer is at 4k7 seconds already...
[03:59:43] <liwakura> im afraid what happens at 65k seconds
[03:59:52] <cehteh> no overflow handling?
[04:00:03] <stephe> so your mainloop just checks peripherals for interrupt flag set then cehteh ?
[04:00:21] <cehteh> i have prescaler /1 now .. 16 bit timer overflows every few ms :D
[04:00:27] <liwakura> i just wrap around to 0, so i can use subtraction on those timestamps anytime
[04:00:33] <cehteh> stephe: nop, thats all done in interrupts
[04:01:54] <cehteh> i increment some global counter on overflow, with 16bit timer + 32bit global counter i have 48bit timestamps
[04:02:34] <cehteh> thats 1.1 years at 8mhz :)
[04:02:58] <cehteh> if thats not enough i can change the global counter to 64 bit ...
[04:03:09] <cehteh> (or choose a higher prescaler)
[04:03:12] <liwakura> i have 3 wrapping-around counters for 1/2 us, 1ms and 1s each
[04:03:20] <cehteh> urgs
[04:03:31] <cehteh> i have only one timer .. which does all
[04:03:32] <stephe> gonna need a lot of batteries to run your copter for 1.1 years :D
[04:03:39] <liwakura> cehteh: nah, not like timers
[04:03:56] <liwakura> more like one timer and 3 16-bit registers which keep time information
[04:04:10] <liwakura> but they overlap, so its not really 48 bit
[04:04:24] <cehteh> no overlap here,
[04:04:56] <liwakura> i know, overlap is not cool
[04:05:04] <cehteh> and priority queue with a sliding window implementation (to save ram :D) .. one can schedule functions at times in somewhat close future
[04:05:21] <liwakura> but now i can make begin = get_seconds(); blah(); duration = get_seconds() - begin;
[04:05:35] <cehteh> depeding on configuration, thats some ms to hours .. i later add some long time queue to for calendar like events
[04:05:43] <liwakura> or with ms or half us, respectively
[04:07:43] <cehteh> at 8mhz timer ticks are 0.125µs :D
[08:42:14] <flyback> http://www.eetimes.com/document.asp?doc_id=1329303&print=yes
[08:45:06] <LeoNerd> Subject: Your Farnell Order Has Been Shipped. *excitement intensifies*
[08:52:01] <lorenzo> LeoNerd: nice :) what did you get? I'm expecting a mouser shipment too.
[08:53:49] <LeoNerd> 3 lots of {isolated DCDC converter, 4channel ADuM digital isolator, max481}
[08:53:53] <LeoNerd> making an rs485 isolator
[08:55:11] <LeoNerd> I only really need two, but ... oshpark boards come in threes, and having a spare is good
[09:00:55] <twnqx> meh.
[09:01:02] * twnqx dislikes farnell
[09:01:21] <LeoNerd> They're not great.. but seems about the best way to get me some of these bits
[09:01:36] <LeoNerd> The more interesting parts like ADuM1402 don't seem to be around much on eBay..
[09:01:48] <twnqx> i prefer digikey and mouser. faster and cheaper.
[09:02:01] <LeoNerd> digikey /cheaper/?
[09:02:07] <twnqx> than farnell, yes
[09:02:14] <twnqx> than mouser... rarely
[09:02:15] <LeoNerd> I'm paying exactly zero postage with farnell, and no minimum order charge
[09:02:29] <LeoNerd> I am paying the cost of the chips and nothing else.
[09:06:36] <lorenzo> uhm, how?
[09:07:16] <LeoNerd> dunno.. usual web order
[09:07:40] <twnqx> i can't even order at farnell. they require my international tax id, which i obviously don't have, not being a compan
[09:07:41] <twnqx> y
[09:07:44] <LeoNerd> Actually, there might be a miminum order I'm not sure. My order is £25 or so, so maybe it's over that
[09:12:07] <LeoNerd> I would have liked to use digikey as they have lots more things that I can't see in farnell, just they seem to have this huge minimum order or additional charge thing
[09:14:08] <twnqx> i nornmally don't have problems hitting the 65€ from either mouser or digikey :P
[09:14:32] <LeoNerd> I don't think I've ever made an order that big
[09:14:40] <twnqx> "a bit of this, a bit of that, throw in some µCs one could use some day"
[09:14:59] <twnqx> also constantlxy filling up orders with random SPI flashes to complete my collection :)
[09:15:48] <lorenzo> twnqx: ever played with FRAM ones?
[09:15:56] <twnqx> no
[09:16:01] <twnqx> just spi nor flashes so far
[09:49:44] <LeoNerd> UARTs, RS485, and biasing... TTL UART idles high.. so should the RS485 receiver have bias resistors set to idle it to that condition..? That would mean pulling A low and B high, which seems to be the opposite to the way most people suggest biasing
[10:50:42] <stephe> twnqx: you're a flash collector?
[10:50:47] <stephe> do you use them or just collect :D
[10:50:59] <LeoNerd> Aha... Saviour of the universe?
[10:52:37] <twnqx> kinda collect them to test code
[10:52:46] <eszett> hi im back again!
[10:52:58] <twnqx> e.g. correct identification by jedec ID commands, etc
[10:53:15] <twnqx> (i also use flashs, but that's separate)
[10:54:15] <twnqx> welcome back :P
[13:18:18] <lorenzo> so, at90usb vs atmega32u4? :p
[13:20:14] <Tom_itx> U4 has adc
[13:20:20] <Tom_itx> 90 does not
[13:21:14] <lorenzo> ah I see
[13:21:32] <lorenzo> bah I have an arduino pro clone thing
[13:21:39] <lorenzo> but it has no ISP header so it's useless :/
[15:01:11] <liwakura> uhm
[15:01:21] <liwakura> no miso/mosi/sck pins?
[15:02:16] <LeoNerd> On...?
[15:05:42] <eszett> what does ICSP stand for? like ICSP 6 pin?
[15:05:57] <LeoNerd> "ICSP" is actually usually Microchip's PIC name
[15:06:04] <LeoNerd> AVR calls it just ISP
[15:06:46] <eszett> LeoNerd: im asking, because i wonder that its called "ISP Programmer", but "ICSP Header"
[15:06:58] <LeoNerd> Eh.. people are often inconsistent
[15:07:00] <eszett> is this just convention meaning both the same?
[15:07:10] <LeoNerd> Yah
[15:07:15] <LeoNerd> The acronyms tend to get mixed up
[15:07:35] <eszett> ok... that are the things which confuse me most in EE, its the nomenclature which is like Kraut&Rüben
[15:07:59] <eszett> Kraut&Rüben = topsy-turvy
[15:10:46] <eszett> additionally, all the name in my local eletronic shop are german, which makes it even more complicated
[15:17:48] <inkjetunito> achtung achtung alle steckvorrichtungen ohne zugentlastung
[15:20:57] <eszett> ja sonst kommt di polizei
[15:32:37] <NicoHood> void USB_Device_EnableDeviceAddress(const uint8_t Address){ (void)Address; }
[15:32:37] <NicoHood> what does this call do?? this sounds like a wrong line in the code
[15:47:40] <eszett> what is the difference "precision header pins" and standard ones?
[15:48:59] <Casper> one is preciselly made, while the other is less preciselly made?
[15:49:16] <eszett> hmm, precisely in what respect?
[16:32:16] <Casper> dimensions, shape, alignment...
[16:33:04] <Casper> standard one may not be true square pin, may be twisted a bit, may be at an angle, edges may be weird
[16:33:10] <Casper> but work fine
[16:33:20] <Casper> might make zero difference
[16:40:21] <eszett> Casper: oh, interesting. The electronic shop catalogue doesn write anything about it
[16:45:25] <eszett> So i order this header thing
https://www.conrad.de/de/buchsenleiste-praezision-anzahl-reihen-2-polzahl-je-reihe-2-econ-connect-mp70d4-1-st-1311389.html and pinch off 2x3 pieces as ICSP 6 Pin adapter, is that correct?
[16:56:16] <LeoNerd> You coooould... I wouldn't
[16:56:43] <LeoNerd> http://www.ebay.co.uk/itm/5pcs-2x3-Pin-6P-2-54mm-Double-Row-Female-Straight-Header-Pitch-Socket-Pin-Strip- I'd use these
[16:57:07] <LeoNerd> http://www.ebay.co.uk/itm/281263568635 even
[17:00:30] <eszett> 10 pieces 99 cent, free shipping, yes thats better
[17:01:11] <eszett> the pins look very brittle, tough:
http://www.ebay.co.uk/itm/10-New-2-54mm-2x3Pin-Double-Row-Female-Straight-Header-Pitch-Socket-Pin-Strip-UK-/201226352435?hash=item2eda067733
[17:02:39] <eszett> ahh, you mean 281263568635 as 5 pieces £2.50 . With stronger pins.
[17:03:32] <LeoNerd> Are you PCB mounting it, or trying to fly it loose on a cable?
[17:03:41] <LeoNerd> If it's on a PCB then those pins are fine
[17:04:31] <Jartza> evening
[17:08:23] <eszett> LeoNerd: I have 2x3 pads on my PCB, and id like to solder one of those 2x3 headers in, and use another one as plug into the former one
[17:09:08] <eszett> so, one PCB mount, the other one loose
[17:10:05] <LeoNerd> Ooh.. don't do that
[17:10:12] <LeoNerd> Almost universally, the target device has the pins
[17:10:20] <LeoNerd> The female side with the sockets on is part of the programmer or cable
[17:10:36] <LeoNerd> On the target device you want to put some plain 2x3 pin header
[17:12:09] <eszett> the programmer cable i have has loose ends, as for a breadboard.
[17:13:09] <LeoNerd> Hmm.. then get yourself another one.. you should be able to find a cable with a 2x3 IDC socket at both ends
[17:14:02] <LeoNerd> http://www.ebay.co.uk/itm/191725951761 these for example
[17:14:06] <eszett> you say, these are more stable then the DIY solution i planned?
[17:14:13] <LeoNerd> They're certainly more standard
[17:14:31] <eszett> hmm ok
[17:14:32] <LeoNerd> Literally, every AVR-based breakout board I've ever seen has a 2x3 pin header on.. occasionally boxed, often not. But always with the pins
[17:14:57] <eszett> the PCB i use is self made, with just the pads/drill holes in a 2x3 pattern
[17:15:59] <LeoNerd> OK.. so you probably want to stick one of
http://www.ebay.co.uk/itm/171457790689 these in it
[17:16:43] <LeoNerd> Or just some plain header. I tend to use box headers for long-lived development boards that live on breadboard, and plain header on "one-time" production units
[17:16:51] <eszett> ahh cool. lil bit more expensive than the DIY solution with those female headerpin rows
[17:17:04] <LeoNerd> A lot more durable though :)
[17:17:09] <eszett> hmm ok
[17:18:19] <eszett> as i see now, i have to use plain headers (male male or female-male) on the PCB, since there is not room enough for this spaceship
http://www.ebay.co.uk/itm/171457790689 ;-)
[17:19:13] <eszett> http://imgur.com/a/fSPEU
[17:19:47] <LeoNerd> Ah; you might want a pogopin adapter on that
[17:20:33] <LeoNerd> hrm.. nothing on ebay
[17:20:55] <LeoNerd> https://www.tindie.com/products/FemtoCow/pogo-pin-iscp-spi-programmer-adapter/?pt=full_prod_search these
[17:21:06] <LeoNerd> Pins to contact the bare pads on the PCB, so you don't have to use height on the board
[17:21:20] <eszett> ahh, with a pogopin i can spare me the soldering, and plug it in and out the drill holes/pads just as needed
[17:21:23] <LeoNerd> Not so convenient for development purposes, but great for final production units that get programmed once then probably never again
[17:21:42] <LeoNerd> For those occasional "in-the-field" upgrades
[17:22:14] <LeoNerd> I have a half-pitch one I use for space-constrained projects. ;) 0.05in spacing
[17:22:31] <eszett> exactle its for "program it once with a bootloader and never after again" (since the User will program the chip via USB thereafter)
[17:23:01] <LeoNerd> Right. Definitely no need to bother populating the board with a socket then
[17:23:08] <LeoNerd> Could you program the chip before you mount it on the board even?
[17:24:05] <eszett> you mean before i solder it on the PCB? yep... with this
http://de.aliexpress.com/item/Free-shipping-CHIP-PROGRAMMER-SOCKET-TQFP44-QFP44-PQFP44-TO-DIP40-adapter-socket-support-MCU-51-chip/32280177562.html
[17:24:35] <eszett> But i havent ordered this thing yet, a friend proposed it to me.. its basically just a breakout for TQFN, as to use on a breadboard circuit
[17:25:06] <LeoNerd> Yah; a socket adapter
[17:25:09] <eszett> there are many path leading to rome, but i would favour the pogo solution
[17:25:24] <LeoNerd> I mean.. might be useful to put the ISP pads on the board /anyway/ because it's a handy backup
[17:26:14] <eszett> yes its a must... you never know what happens. for example.. in the datasheet is written that ATmega32U4 comes with bootloader, but that information is obsolete.
[17:26:39] <eszett> I wondered why my chips are empty and asked the shopkeeper, he said "Atmel ships without bootloader nowaadays to save money"
[17:27:13] <eszett> so the datasheet misinformed me in that case. without ICSP pads i would have been pretty lost
[17:39:39] <twnqx`> i'd always add pads for ISP programming at least
[17:39:46] <twnqx`> just in case of some catastrophic failure
[17:40:05] <twnqx`> something like pads for pogo-pins
[17:40:19] <LeoNerd> Yah
[17:40:49] <LeoNerd> Oh.. just remember to put a drill hit in at least one of the pads, ideally two, maybe more. Without any holes, the pogo pins will tend to skate around on the surface
[17:40:54] <LeoNerd> at least one hole keeps them in place
[17:51:45] <eszett> i had even some other idea. To produce the PCB with drill holes, that allow a snug fit of standard header pins. By this, the pads/drill holes would be the receptables by itself
[17:51:49] <eszett> does this make any sense?
[17:52:49] <eszett> i came up (not testified!) with an diameter of 0,85mm for the pad holes, to have a snut fit
[17:52:55] <LeoNerd> Yeah that can work too.. usually pogo pins are large enough they'll fit unpopulated mount holes for pin headers
[17:53:20] <eszett> good
[17:53:22] <LeoNerd> Just if you were definitely committed to using pogo pins, you wouldn't necessarily need all 6 drill holes, so you might save some space on the other side of the board
[17:53:40] <LeoNerd> Put holes in 2 pads, then the other 4 pads become effectively single-sided SMT pads
[17:54:19] <eszett> because 2 pogo pins would keep the other 4 in position?
[17:54:44] <LeoNerd> Yah.. one pin alone is sufficient to stop it skating, but it might twist. Two pins will stop that
[17:54:50] <LeoNerd> You don't *need* more than two
[17:55:14] <eszett> interesting practical point, i can imagine it...
[17:55:31] <eszett> but drill holes cost like nothing when i order the PCBs anway
[17:55:38] * LeoNerd nod
[17:55:47] <LeoNerd> If you're not putting anything on the back then it doesn't matter anyway
[17:56:17] <eszett> yep..
[18:25:06] <LeoNerd> Hrm. I want "make install" to write the final byte of the EEPROM to a random value each time. I'm using that as my randomisation seed
[18:25:19] <LeoNerd> Nothing vital, just LED flickery effects..
[18:26:49] <Lambda_Aurigae> well, if you are using linux you could call a script that uses the $RANDOM variable to get a random number.
[18:27:16] <LeoNerd> Yah.. that's the easy part. How to feed that into avrdude as the final byte of EEPROM ?
[18:27:35] <Lambda_Aurigae> build a separate hex file that gets uploaded?
[18:27:45] <LeoNerd> hmm
[18:27:57] <Lambda_Aurigae> or have it write that number in the hex file you are using for eeprom if you are writing other data in.
[20:28:38] <eszett> I have a question. When i have a operation voltage of x the logic levels for HIGH are the upper 33% of that voltage, for LOW the lower 33%, and undefined the 33% inbetween, right?
[20:29:23] <Tom_itx> active high/low threshholds are given in the back of the pdf generally in the form of a chart
[20:30:24] <eszett> so there is no rule of thumb for the range (in percentage)?
[20:30:33] <Tom_itx> depends on the technology
[20:30:38] <eszett> AVR =)
[20:30:39] <Lambda_Aurigae> there are limits predefined by the technology.
[20:30:57] <Lambda_Aurigae> AVR generally resides in the TTL logic levels.
[20:31:21] <Lambda_Aurigae> https://learn.sparkfun.com/tutorials/logic-levels/ttl-logic-levels
[20:31:29] <Lambda_Aurigae> it is ttl level cmos logic,,,
[20:31:54] <Lambda_Aurigae> https://learn.sparkfun.com/tutorials/logic-levels/33-v-cmos-logic-levels
[20:32:14] <eszett> ah, sparkfun articles are easy to read, thanks
[20:33:02] <Lambda_Aurigae> welcome.
[20:33:14] <Lambda_Aurigae> the specifics for your chip are listed in the datasheet.
[20:40:08] <eszett> Lambda: For "input low voltage" it says "Min. -0.5" and "Max. 0.2 VCC - 0.1v", how to understand that negative value?
[20:43:23] <Lambda_Aurigae> how to understand what?
[20:43:29] <Lambda_Aurigae> don't go below -0.5 volts.
[20:43:44] <Lambda_Aurigae> if you have 2 batteries end to end... + to -
[20:43:52] <Lambda_Aurigae> then measure from the center point where the batteries touch.
[20:43:59] <Lambda_Aurigae> on one end it is a positive voltage.
[20:44:07] <Lambda_Aurigae> on the other end it is a negative voltage.
[20:44:21] <Lambda_Aurigae> simple first week basic electronics.
[20:44:37] <Lambda_Aurigae> all relative to your ground point.
[20:44:43] <eszett> sorry, i was abit confused
[20:45:54] <eszett> that means even 0.2v would prevent the atmega from reading a input as low?
[20:47:12] <eszett> ah, 0.2VCC is a fifth of VCC ok got it
[20:48:28] <eszett> So the range for VIL is from -0.5v to 0.9v
[20:49:30] <Lambda_Aurigae> easiest is to look at the pin threshold and hysteresis in the datasheet.
[20:49:40] <Lambda_Aurigae> for the atmega1284p it is page 532 and 533
[20:50:39] <Lambda_Aurigae> at 5V VCC the turn on level is about 2.7V for logic High(1)
[20:50:59] <Lambda_Aurigae> and bout 2.2V or below for logic Low(0)
[20:51:09] <Lambda_Aurigae> between 2.2V and 2.7V it can be indeterminate.
[20:53:50] <eszett> the sparkfun article about TTL levels gives a chart called "for a generic TTL device"
[20:54:18] <eszett> so the leves differ from atmega to atmega?
[20:54:22] <eszett> levels
[20:54:27] <Lambda_Aurigae> look
[20:54:28] <Lambda_Aurigae> at
[20:54:29] <Lambda_Aurigae> the
[20:54:31] <Lambda_Aurigae> datasheet
[20:54:38] <eszett> yea
[20:54:52] <Lambda_Aurigae> the levels actually differ depending on the voltage you are running the avr at
[20:55:28] <Lambda_Aurigae> with a VCC of 3.5V the logic low is about 1.5V max and logic high is about 1.8V minimum.
[20:55:40] <Lambda_Aurigae> nifty little charts in there to show you.
[20:59:34] <eszett> oh joy, now i found this chart.
[21:00:41] <Lambda_Aurigae> this is why I tell people....read the datasheet...cover to cover...it's in there.
[21:03:09] <eszett> Atmega32U4 at 5v VCC logic high is 1.6 or above, and logic low is 1.6 or below: page 403
http://www.atmel.com/images/atmel-7766-8-bit-avr-atmega16u4-32u4_datasheet.pdf is that correct?
[21:04:09] <eszett> there seems to be no inbetween undefined range
[21:10:05] <cehteh> mhm?
[21:10:26] <cehteh> where do you get that numbers from?
[21:11:19] <Lambda_Aurigae> looking at those charts it looks pretty close.
[21:11:49] <cehteh> 29.2
[21:11:49] <cehteh> DC Characteristics
[21:12:15] <Lambda_Aurigae> looking at 30.7, figure 30-22 and 30-23.
[21:12:45] <cehteh> ah ok
[21:13:23] <Lambda_Aurigae> aand, I'm off to bed.
[21:13:28] <eszett> good night
[21:14:03] <eszett> 30.7 yes
[21:15:09] <eszett> why is there no "inbetween" both logic levels?
[21:16:14] <aandrew> because then it would be analog
[21:17:25] <cehteh> there is some undefined range
[21:18:35] <eszett> cehteh: how much is it for the Atmega32U4?
[21:18:45] <cehteh> input schmitt trigger pulls it to the last value iirc
[21:19:10] <cehteh> dunno .. just never use digitial pins for analog
[21:19:55] <eszett> ok
[21:19:55] <cehteh> wont work reliably, signals are slower and unreliable
[21:20:14] <cehteh> if you want to toggle on some analog level better use the analog comparator
[21:21:28] <cehteh> there are few cases where one can abuse a digital input as toggle on a analog level, but one need to be sure it falls withing the defined ranges then and doesnt float to slowly inbetween
[22:28:31] <eszett> how come, that the values for logic levels, differ between the table "DC Characteristics" and the chart " Pin threshold and hysteresis"?
[22:29:06] <eszett> in both datasheets, Atmega1284p datasheet, and thhe Atmega32U4 datasheet
[22:30:27] <eszett> Chart 30.1.9 of the Atmega1284p datasheet tells for 5v VCC that logic High is ~2.7v or higher, logic Low is ~2.2v or lower. While Table 28.1 tells that logic High is ~3v or higher, and logic Low is ~1.5v or lower.
[22:30:58] <Tom_itx> probably depends on the operating voltage
[22:31:00] <Tom_itx> look closer
[22:32:17] <eszett> I read carefully. the Table "Pin threshold and hysteresis" give a fix value for the operating voiltage range VCC 2.4V - 5.5V
[22:32:33] <eszett> err, i mean the table ""DC Characteristics""
[22:33:06] <eszett> while the graph, gives a more specific value depending on operating voltage
[22:47:04] <Casper> eszett: the tables are more generic
[22:47:09] <Casper> like speed vs voltage
[22:47:35] <Casper> they usually say <=8MHz: 3.3V >8MHz 4.5V
[22:47:47] <Casper> which the graph show that it is not true
[22:47:53] <eszett> so i should really rely on the hysteresis charts, as Lambda cited from
[22:48:17] <eszett> the graph is the best source
[22:48:43] <eszett> Casper: ok, i just wondered, because the values i calculated differe alot from table <> chart
[23:48:12] <eszett> can i generate a certain voltage signal with my multimeter?
[23:49:48] <eszett> guess i cant
[23:54:02] <cehteh> no
[23:54:25] <cehteh> some very expensive ones (fluke) have a signal generator :D
[23:54:38] <cehteh> but you rather want that in a external device
