#avr Logs

May 08 2017

12:00 AM rue_shop3: ... and the 3d printers to make brackets for holding baords to be drilled....
12:03 AM rue_shop3: hmm.... maybe I should do a run of my tiny13 boards...
12:28 AM Casper: rue_shop3: do you know of a way to repair the contact in a remote? the carbon thing on the membrane/rubber...
01:16 AM rue_bed: silver trace pen
01:49 AM Snert: an ink eraser - burnish up the contacts under the rubber button.
01:50 AM Snert: rough up the underside of the rubber button lightly where it makes contact. Not a lot, just break any surface hardening of the black rubber.
01:50 AM Snert: or the black "contact material". Whatever it is.
01:51 AM Snert: failing that, toss it.
01:55 AM Casper: the carbon/black layer was too thin...
01:56 AM Casper: a cotton swab with alcohol removed the shiny, but you can see that it already made it thin...
01:56 AM Casper: rue_bed: wouln't the silver trace pen crack since that is very flexible?
01:56 AM Snert: did the swab pick up any black? like the rubber came off?
01:57 AM Casper: a bit yes
01:57 AM Snert: I always burnish up the contacts on the board first. The mess with the rubber if necessary.
01:59 AM Snert: at any rate, you should be able to trigger proper operation by bridging the contacts with with tweezers.
01:59 AM Snert: if not, then the electronics are actually bad.
01:59 AM Casper: or just buy a new remote :(
01:59 AM Snert: ya. less than 10bucks.
02:00 AM Casper: more like 50-100
02:00 AM Emil: rue_bed: oh I can also make my own boards
02:01 AM Emil: but that TDFN is not something I'd like to touch there
02:01 AM Emil: also vias are cancer to make
03:17 AM eballetb` is now known as eballetbo
03:46 AM antto: so, cehteh, you say if i use atomic access to a variable - i don't need the "volatile" on it?
05:41 AM cehteh: antto: volatile is not about atomic access, it is about accesses to the variables dont get optimized or reordered by the compiler
05:42 AM antto: i've read that "if you access a variable from both the main thread and interrupts - declare it volatile"
05:42 AM antto: or at least that's how i understood it
05:42 AM cehteh: thats not exactly true
05:42 AM antto: i think it meant 1byte variables
05:43 AM cehteh: if you access the variable in a atomic context it doesnt need to be volatile (no interrupt can modify it and the atomic context ensures proper memory barriers)
05:43 AM antto: okay
05:43 AM cehteh: if its *only* a 1 byte variable or a register which gets mutated by hardware then it needs to be volatile
05:44 AM antto: registers are declared volatile in the io headers already
05:44 AM cehteh: and instead having tons of atomic contexts you can put one around your if() code
05:45 AM antto: but in what situation would i use volatile in my own code then?
05:45 AM cehteh: there is a slight performance penality for the check (hey maybe that check needs already protected by atomic, not to have a race condition)
05:45 AM LeoNerd: Any variable that gets touched by interrupt handlers as well as mainline code
05:45 AM cehteh: but you save a lot code
05:46 AM cehteh: LeoNerd: nop .. not when his main code accesses it in an atomic context, then it doesnt need to be volatile
05:47 AM LeoNerd: Not true
05:47 AM antto: what if() code? do you mean the stuff i pasted yesterday?
05:47 AM LeoNerd: 'atomic' means "Don't let anyone else interrupt me while I'm in the middle of performing this operation"
05:47 AM cehteh: do you have the paste still ..
05:47 AM LeoNerd: 'volatile' means "Dear gcc; please do not presume you can optimise around guessing when to look in main memory for this value; always do exactly as described in code"
05:47 AM LeoNerd: These are unrelated concepts
05:48 AM cehteh: LeoNerd: thats what i am saying .. but atomic comes with a memory barier
05:48 AM antto: cehteh, https://www.pastebin.ca/3808846
05:48 AM cehteh: those memory barrier prevents gcc optimization across it
05:48 AM LeoNerd: Ahright; well it may be that gcc's idea of atomic also implies volatile...
05:48 AM cehteh: while within the atomic context gcc can still optimize
05:48 AM cehteh: thats far better than defining everything volatile
05:49 AM cehteh: antto: line 70 cc
05:49 AM antto: getchar() ?
05:49 AM cehteh: the atomic blocs there
05:50 AM cehteh: you can put everything in one atomic block ..
05:50 AM antto: yes.. but then it will be a longer one
05:51 AM cehteh: and instead a return inside you use a else .. momeent
05:52 AM cehteh: https://www.pastebin.ca/3809224
05:53 AM cehteh: it is not really longer, except for the "if(tmp)" which is now inside the atomic block
05:53 AM cehteh: but i already suspect you had an race condition there anyway
05:54 AM antto: hm!?
05:54 AM cehteh: next, instead restorestate atomic blocks i prefer to have 2 flavors of such function one with and one without atomic blocks, thats cheaper
05:54 AM antto: race condition where?
05:55 AM LeoNerd: I find it's not hard to wrap code in uint8_t save_SREG; cli(); ... SREG = save_SREG;
05:57 AM cehteh: yes
05:58 AM cehteh: https://www.pastebin.ca/3809227
05:58 AM cehteh: no need to save sreg when you know if you are in a atomic context
05:58 AM cehteh: and in most cases (if not all) you know it
05:59 AM antto: cehteh, i will pretty much always call the atomic version
06:00 AM cehteh: race condition: tmp = (rxiw == rxir); .. .then you end the atomic context, interrupt happen, rxw or rxir gets changed in interrupt? .. then you if(tmp) with the pre-interrupt state
06:00 AM cehteh: i havent checked your code carefully, but that smells like such a race condition
06:01 AM cehteh: which is really annoying and hard to debug later :D
06:01 AM cehteh: because it happens once in a billion times that your program does the wrong thing
06:02 AM antto: rxir is changed in the main thread only, rxiw in the interrupt
06:02 AM antto: in case of reception
06:02 AM cehteh: so you have a race condition there
06:02 AM cehteh: and many more
06:03 AM cehteh: note: atomic blocks should be small yes, but that doesnt mean the code inside has to be small, if there are if's then only one path is taken
06:04 AM cehteh: you should be very wary about such races .. otherwise you have a real pita with debugging
06:04 AM antto: i don't think that if has a bug, but i might be wrong
06:05 AM cehteh: if one of rxiw or rxir is changed in an interrupt then yuu have a race there
06:05 AM antto: if the interrupt happens, it could change rxiw
06:05 AM cehteh: why do you use a tmp anyway?
06:06 AM antto: to have a smaller chunk of time with interrupts disabled
06:06 AM cehteh: https://www.pastebin.ca/3809235
06:06 AM cehteh: that introduces a race
06:07 AM cehteh: just remove the tmp
06:07 AM cehteh: and a comparsion is essentially a single cycle substraction for a cpu, quite cheap
06:07 AM antto: i tried to inspect the asm but it's hard
06:08 AM cehteh: well there is a cmp asm instruction iirc ... i meant internally to the cpu
06:08 AM antto: i can't figure it out without having the original code next to it
06:08 AM antto: and getting that from the compiler was tricky
06:08 AM antto: i tried -S, objdump..
06:08 AM cehteh: well .. try to understand why you have a race condition there
06:08 AM antto: i get it
06:09 AM antto: this will only cause a problem when the FIFO is 1 byte away from running out of capacity
06:09 AM cehteh: atomic blocks should be short, but too short is an error :)
06:10 AM cehteh: its not the question when it will cause an error but if
06:10 AM antto: so with or without it, i think the difference will be 1 byte sooner "f*ck up" than the actual maximum capacity
06:10 AM antto: yes, it will
06:10 AM cehteh: less code, more correct code like i shown
06:10 AM antto: i'll rewrite it then
06:10 AM cehteh: for example are you sure that you dont loose the byte later etc
06:11 AM antto: i have a 4.8kHz timer interrupt which i want to not disrupt from the main thread
06:11 AM cehteh: having code correct without such corner cases in the first place will make such headaches go away
06:11 AM cehteh: no matter what you do, when you use atomic blocks this interupt gets blocked eventually
06:11 AM antto: i know
06:12 AM cehteh: doesnt matter if you pack one more or less instruction in a atomic block
06:12 AM antto: i don't want to miss a tick from the timer
06:12 AM cehteh: thats the 4.8khz?
06:12 AM antto: yes
06:13 AM cehteh: to miss a tick you need to miss 2 such interrupts
06:14 AM cehteh: as long your atomic blocks are faster executed that 4.8khz (how many micoseconds are that?) you are fine
06:14 AM cehteh: tad faster because interrupt overhead and stuff
06:15 AM cehteh: on what clock do you run your chip 8 ? 16Mhz?
06:15 AM antto: 16MHz
06:15 AM antto: i currently have a ton of volatile global variables x_x
06:16 AM cehteh: approx 3300 clocks per 4.8khz
06:16 AM antto: originally one of the big functions was being called directly from a timer, i rearanged that, but still a pile of variables are volatile
06:16 AM cehteh: so your interupt handlers and atomic block each should be less than 3000 cycles and it will work
06:17 AM cehteh: in muos my ISR's do only the bare minimum pushing handlers to a queue which is executed by the main scheduler
06:17 AM cehteh: prolly a good idea when you do something similar
06:18 AM antto: i have another naughty timer too 1kHz, which does LED PWM where those leds are actually on shift registers
06:18 AM cehteh: does that need to be exact?
06:19 AM cehteh: well you should do the math if the mpu can guranteed to cope with your problem
06:19 AM antto: i'll just write it and see if it works
06:19 AM cehteh: and delegate most stuff to hardware somehow, pwm and such
06:19 AM antto: yeah
06:20 AM antto: i'm thinking to rewrite the PWM stuff to use non-blocking writes
06:20 AM cehteh: problem is that in some cases it may barely work and fail in some corner cases, unless your execution paths are constant time which isnt the case
06:20 AM LeoNerd: PWM... nonblocking...?
06:20 AM cehteh: why do you need 1khz for leds?
06:20 AM antto: i have an EEPROM and 74hc165 (buttons) and 74hc595 (LEDs) onto the SPI
06:21 AM LeoNerd: Ah; you're doing that trick :)
06:21 AM antto: currently, all of that code uses blocking read/write to the SPI
06:21 AM LeoNerd: I really dislike the 74'165 for button input lately. It sortof seems OK in theory, but then you find it doesn't *quite* play ball nicely on SPI
06:21 AM LeoNerd: And also no interrupt output
06:21 AM LeoNerd: These days I always put buttons like that on a PCF8574 or similar
06:21 AM LeoNerd: You get an interrupt line, avoiding the need to poll like you do on a 165
06:22 AM LeoNerd: The other problem with a 165 is that its SO line is never hiZ, so it doesn't behave politely with other SPI devices, whereas the 8574 is a proper I²C slave, so it's wellbehaved
06:22 AM antto: so i need to have a semi-lit LED state on some LEDs, and i do that by doing manual PWM from the 1kHz timer
06:22 AM antto: however, the code there simply uses blocking write to the SPI
06:23 AM LeoNerd: I usually find that SPI is fast enough to just perform blocking writes
06:23 AM antto: i'm thinking to pimp it up to use non-blocking write
06:23 AM antto: yes
06:23 AM antto: my SPI freq is 4MHz
06:23 AM LeoNerd: Certainly, something like a 595 can easily take basically the fastest SPI you can output from an ATmega
06:23 AM cehteh: anyway fix your code first, less volatile, no race conditions etc
06:23 AM antto: but still.. the code there probably waits a few cycles between each byte to the shift registers
06:23 AM LeoNerd: If you just spinwait on that, you'll probably actually get better throughput than doing the whole interrupt wait
06:23 AM LeoNerd: Don't forget all the overheads involved in interrupt in the first place
06:23 AM cehteh: i bet then it will be 1/4 of the size only :) .. run faster and more reliable
06:23 AM LeoNerd: Interrupt is great for things like I²C and ADC, slow peripherals
06:24 AM antto: cehteh, size is not a problem
06:24 AM cehteh: isrs have quite some overhead yes
06:24 AM antto: this is atmega2561 \o/
06:24 AM cehteh: well size translates to speed too
06:24 AM cehteh: and length of blocking
06:24 AM cehteh: when you have some fast things going on you have to cycle count eventually
06:25 AM LeoNerd: Currently, I have some code that performs 1024-byte string writes to a 400kHz I²C slave, and even *that* I currently don't bother interrupting for
06:28 AM LeoNerd: I may sometime write myself a nonblocking "send this string" I²C function, that can ping me later when it's done
06:28 AM LeoNerd: But..e h.. that's effort and in practice there's not a lot else I'd be doing on the CPU anyway
06:29 AM antto: i've been thinking about fully interrupt-driven SPI, but it's less easy compared to UART
06:30 AM LeoNerd: Problem with SPI is, look at it this way. 4MHz clock, 8 bit words. We're talking a mere 16 CPU instructions per byte written down SPI
06:30 AM LeoNerd: The interrupt overhead /alone/ is more than 16 instructions
06:30 AM LeoNerd: Interrupt-driven SPI at 4MHz will be *slower* than a spinlocked loop
06:31 AM antto: well, i am actually surprised that i don't get flickering on the LEDs
06:31 AM antto: so you're probably right
06:31 AM antto: it was just an idea
06:32 AM antto: there are more important things i need to fix first
06:48 AM Emil: LeoNerd: only if you call a function
06:48 AM Emil: LeoNerd: 4Mhz spi will take 32 cycles to send out a byte
06:50 AM Emil: if your isr doesnt call function snd doesnt do other stupid shit you have like 24 cycles to do your thing
06:50 AM Emil: also I just came up with an idea about shifting the stack pointer in which case it is really quite efficient
06:52 AM Emil: LeoNerd: so I dont know how did you come up with the 16 instuctions
07:00 AM LeoNerd: Er.. because I can't divide :)
07:00 AM LeoNerd: 16/4 = 4, not 2 ;)
07:01 AM LeoNerd: 4 instructions per bit
07:05 AM Lambda_Aurigae: we need an AVR with a CoPper and BlITter.
07:05 AM LeoNerd: Teehee
07:05 AM Lambda_Aurigae: CoProcessor and BlockImageTransfer.
07:06 AM Lambda_Aurigae: like the amiga.
07:06 AM LeoNerd: Already my latest AVR project has two chips in it; a main ATmega328P, and an ATtiny841 to do DMX offloading to
07:06 AM LeoNerd: I was considering adding a third, somehow connected via some SPI RAM, to offload WS2812s onto
07:07 AM LeoNerd: The idea would be that the main chip renders an RGB framebuffer into that SPI RAM, then hands it over to the second chip which then takes over that RAM and spits it down the IO lines to the LEDs, before interrupting the main chip again to say it's finished
07:07 AM LeoNerd: That'd remove all the timing-sensitive logic out of the main chip
07:07 AM Lambda_Aurigae: yup.
07:07 AM Lambda_Aurigae: I've done similar with AVR VGA generation
07:07 AM LeoNerd: Yah.. I imagine VGA has quite similar timing conditions
07:09 AM Lambda_Aurigae: used microchip spi ram.
07:10 AM Lambda_Aurigae: is really nice.
07:10 AM LeoNerd: For me, the tricky part is working out how to dual-master that RAM
07:10 AM Lambda_Aurigae: specially running it in SQI mode....clock data out 4 bits at a time.
07:10 AM LeoNerd: I wonder if actually using an ATmega328PB with its two SPI ports might make that simpler. I still need SPI to talk to other devices
07:11 AM Emil: LeoNerd: so interrupt driven spi is still faster ;)
07:11 AM Lambda_Aurigae: write your framebuffer into the sram, set the ram pointer to the beginning and set it to clockout mode.
07:11 AM Lambda_Aurigae: then just pulse the clock line and it toggles the data out.
07:12 AM Emil: Yeah why I was thinking about adding another avr was to collect sound data
07:12 AM LeoNerd: Lambda_Aurigae: Oh I thought about that too, but outputting to a WS2812 requires you to always toggle the data line, you just toggle it different timings to output 1s or 0s.
07:12 AM Emil: because pushing 450 bytes @ 800kbps takes 4.5ms
07:13 AM LeoNerd: So if that was being output directly to a 2812, you'd need to store at least 3 or 4 bits in the SPI RAM, per bit of actual RGB data
07:13 AM LeoNerd: I'd prefer an offload chip to mediate it
07:13 AM Lambda_Aurigae: aahh..never futzed with those ws2812 units.
07:14 AM Emil: The protocol is cancer, too
07:14 AM Emil: unfortunately
07:14 AM Emil: and they dont respect timing
07:14 AM Emil: but otherwise they arr pretty kawaii :)
07:14 AM LeoNerd: The APA102s are generally much nicer because you can output to them with straightup SPI
07:15 AM LeoNerd: Just those chips are a lot more expensive, as compared all the dirt-cheap WS2812 tape you can buy off eBay/Aliex/...
07:16 AM Emil: yeh:/
07:16 AM LeoNerd: 2812 isn't too bad to drive, really. It's a bit odd and custom "speshul snowflake", but they come up all the time and everyone has code for it so in practice it works out OK
07:17 AM Emil: ooh
07:17 AM Emil: those work like shift registers
07:17 AM Emil: LeoNerd: no I mean
07:17 AM LeoNerd: APA102s? Yeah, they're *really* nice. you literally just write it like an SR
07:17 AM Emil: the ws is easy to drive
07:18 AM Emil: but because they grab the first data they get and push the rest downwards...
07:19 AM Emil: you can't shift data out
07:19 AM Emil: might buy a roll of that apa102s because it would allow for no gaps in data output
07:20 AM Emil: though what would be even more awesome is if you could shift individual channels
07:22 AM Emil: hmm, or I could sample slower
07:22 AM LeoNerd: The other nice thing about the APA102s is that their internal PWM clock is a lot faster than 2812s
07:22 AM Emil: Sampling at 48kHz has the issue of sound data not changing much between samples
07:22 AM LeoNerd: If you mount 2812s on any sort of moving object, you can see the PWM flicker if it moves too fast. The APA102s are much faster than that
07:23 AM Emil: yeah I read
08:56 AM catphish: i'm using an atmega2560, i'm a little unclear on PWM outputs, is it possible to have a PWM active with any of the following duty cycles? 0%, 100%, 50%?
08:57 AM catphish: i'm sure i can find the answers if i keep digging through the datasheet, but hoped someone might happen to know
08:59 AM rue_bed: yea, you have 8 or 16 bit resolution
09:00 AM rue_bed: so 0/255% 128/255% or 255/255% are all options
09:01 AM rue_bed: the 8 or 16 bits depend on which timer your using
09:01 AM catphish: i just found some info, i'm using fast pwm mode, it seems that 100% is possible, 0% is not
09:01 AM rue_bed: 0% is, you just load a zero into it
09:02 AM catphish: "If the OCRnx is set equal to BOTTOM (0x0000) the output will be a narrow spike for each TOP+1 timer clock cycle. Setting the OCRnx equal to TOP will result in a constant high or low output"
09:02 AM rue_bed: ? never seen that
09:03 AM catphish: this means 0% is impossible, but 50% might be possible, if 0 was always off and 1023 was always on, 50% (exactly) would be impossible
09:03 AM catphish: because 128 != 255/2
09:03 AM LeoNerd: Yah; the various PWM modes have various abilities to set hard on/off
09:03 AM LeoNerd: I believe the phase-correct modes should cope with static output at either end
09:04 AM catphish: LeoNerd: i believe you're correct
09:04 AM catphish: i'm actually particularly interested in 50%
09:05 AM catphish: so, if 0-255 is really 1-256 (and 0 is not possible) then 127 would be 50% :)
09:05 AM catphish: i hope i'm making sense
09:18 AM cehteh: you can set TOP to 3, then with proper configuration you have 0, 25, 75, 100%
09:19 AM cehteh: + 50%
09:20 AM antto: pwm fast between 25 and 75% to get virtually 50%
09:20 AM * antto hides
09:21 AM antto: wtf xchat.. why would you happen to have a huge close button right there >:(
09:22 AM cehteh: you saied you going to hide :D
10:03 AM Emil: rue_bed: >%
10:03 AM Emil: Oh yeah you mean (x/255)%
10:04 AM Emil: Also you have to use a specific type of pwm (write the right bits) so that 0 is actually 0
10:04 AM Emil: and that 100% is actually 100%
10:04 AM Emil: otherwise you will have glitches
10:04 AM Emil: catphish: so 0% is possible and so is 100%
10:05 AM polprog_: nothing a scope cant spot and fix
10:05 AM polprog_: also, percent is relative ;)
10:05 AM polprog_ is now known as polprog
10:06 AM Emil: polprog: having exactly low on the scope as is having exactly high on the scope
10:06 AM Emil: and "anything in between"
10:07 AM polprog: just joking
10:13 AM catphish: Emil: i believe with phase correct PWM, 0 is indeed 0
10:13 AM Emil: yap
10:13 AM Emil: And 100 is indeed 100
10:13 AM catphish: but no 50%, right?
10:13 AM Emil: yes 50%
10:14 AM catphish: how would you do 50%
10:14 AM Emil: also you can select which fast pwm mode you want, up counting or down counting
10:14 AM xentrac: depends on where you set TOP, no?
10:14 AM catphish: i guess setting TOP to an even value?
10:14 AM Emil: with iir down counting your 0 will be 0 but your 100% will be just a tiny bit under 100%
10:19 AM catphish: i'm experimenting with H bridge outputs to create sine wave outputs, going to try oscillating my output between +v and -v instead of +v and 0v, so i'd quite like to make sure my center point is actually correct :)
10:20 AM catphish: as i'd like my 50% PWM to average 0v exactly
10:22 AM Emil: Remember to make sure your h bridge protects against shorting
10:24 AM catphish: it does, each side of the H bridge is actually driven by a logic inverter, the avr controls one side, the other side is inverted in hardware
10:24 AM catphish: so it's conveniently impossible for a sotware bug to drive a short circuit
10:24 AM cehteh: rednek method: use some capacitative coupling to draw the center to 50% ...
10:27 AM catphish: right now i generate a sine wave by holding one side of the H bridge low for half a sine wave, and generating the shape with the other half
10:27 AM catphish: then swapping, holding the other side low to generate the negative half of the wave
10:27 AM catphish: it works very well, but i want to experiment with the other way, always switching between full + and full -
10:28 AM catphish: http://solar.smps.us/pwm_sinewave.png vs http://www.vanatoo.com/uploads/images/class-d.jpg
10:29 AM Emil: catphish: that inverter design is still suspectible to short
10:29 AM catphish: Emil: how?
10:29 AM Emil: catphish: especially at higher frequencies
10:30 AM catphish: oh, due to the switching times?
10:30 AM Emil: because it doesn't generate dead time
10:30 AM catphish: yeah, i'm concerned about dead time, hasn't been an issue yet as far as i've observed
10:30 AM Emil: But it probably doesn't matter to you
10:30 AM Emil: It just means that it'll heat up a bit more
10:30 AM catphish: i wonder if my driver ICs are fixing it for me
10:31 AM Emil: prolly
10:31 AM catphish: i'm using a logic inverter driving the 2 inputs of an IR2110 http://www.infineon.com/dgdl/ir2110.pdf?fileId=5546d462533600a4015355c80333167e
10:31 AM catphish: it's a pretty cool chip, and i know it does some kind of timing compensation
10:32 AM catphish: or it may just be that my devices are switching fast enough that the short circuit isn't noticeable to me
10:33 AM catphish: next time i don't have a load connected, i'll run it and see how much it draws
10:34 AM Emil: what's your switching frequency?
10:34 AM catphish: 16kHz
10:35 AM Emil: lol you probably aren't seeing anything then
10:35 AM Emil: that's a strange number though
10:35 AM catphish: more precisely, it's 16MHz / 1024
10:35 AM Emil: Ah
10:36 AM catphish: (ie a 10 bit PWM on a 16MHz atmega)
10:38 AM xentrac: so you're probably only getting shoot-through during the transition time of your inverter, which is probably about 5 nanoseconds
10:38 AM Emil: yeah
10:38 AM Emil: which will probably doesn't matter here at all :D
10:38 AM Emil: I thought were at MHz or something
10:38 AM Emil: ;)
10:39 AM xentrac: once per cycle, so 5 nanoseconds per 63000 nanoseconds or so
10:40 AM catphish: i don't have the PWM resolution to go any faster on my little atmega
10:41 AM catphish: also my load is nice and inductive, so i don't really need to go much faster
10:42 AM Emil: nice
10:43 AM Emil: Good to know you understand the principles
10:45 AM xentrac: (I'm figuring once per cycle because on the other transition, the other side of the bridge will turn off first)
10:48 AM catphish: Emil: i'm actually designing a 3-phase motor driver, it works pretty well, but experimenting with different ideas
10:48 AM catphish: thanks for the pointers
11:17 AM enhering is now known as Guest2368
11:41 AM grafi__ is now known as grafi_
12:03 PM Emil: MFW I even manage to put something like this to the schematic
12:03 PM Emil: https://emil.fi/jako/kuvat/2017-05-08_19-33-02_N89rVvoz.png
12:03 PM Emil: :D
12:04 PM NoHitWonder^2: what software that is?
12:04 PM NoHitWonder^2: looks like eagle
12:06 PM Emil: KiCad
12:06 PM antto: iz Kicad
12:06 PM antto: very ki, much cad
12:06 PM Emil: polprog: you can tell what's wrong with that, right?
12:07 PM antto: are you sure that's a crystal and not an oscillator?
12:07 PM Emil: yes
12:08 PM Emil: the symbol particularly suits AMB8
12:08 PM antto: why do you use a net label for GND?
12:08 PM * antto is about to slap Emil
12:08 PM Emil: Lol
12:08 PM * Emil slaps antto back
12:08 PM Emil: Because it's easier to refactor if need be
12:09 PM * antto refactors Emil, completely
12:09 PM * Emil becomes the new ruler of mankind
12:09 PM Emil: Thanks, I guess
12:10 PM * antto secretly connects the local GND to global GND
12:10 PM * antto waits to see how Emil gets zapped by his own creation
12:10 PM Emil: In every corner atm hides this: https://emil.fi/jako/kuvat/2017-05-08_19-40-43_coxAHHG4.png
12:11 PM Emil: It's also faster imho
12:11 PM Emil: you can just pull wire, k, l, type GND, enter, enter
12:21 PM antto: or just "c" and duplicate a ground symbol
01:18 PM Emil: that requires moving the mouse :D
01:33 PM antto: it's not an elephant, it's a mouse
01:34 PM xentrac: hmm, what's the bandwidth of a signal recorded on a VHS videotape?
01:35 PM xentrac: nominally NTSC as broadcast is 6MHz wide, but some of that is the guard band and audio
01:43 PM Emil: >Shenzhen, United Kingdom
01:44 PM Emil: Something doesn't match here
01:44 PM Emil: antto: I wish there was a completely keyboard only way to use kicad
01:44 PM Emil: xentrac: 4MHz iirc
01:44 PM Emil: but don't quote me on that
01:45 PM Emil: https://en.wikipedia.org/wiki/NTSC#Transmission_modulation_scheme
01:45 PM Emil: I was quite close
01:49 PM xentrac: That page says 6MHz
01:49 PM xentrac: But what's the bandwidth you get out of a VCR?
01:50 PM antto: Emil why are you avoiding the mouse?
01:51 PM specing: Emil: the only thing that doesen't add up is that Shenzhen in china is not called New Shenzhen
01:51 PM Emil: antto: because keyboard is faster to use and more efficient
01:52 PM antto: maybe your mouse is not configured properly
01:52 PM antto: or you're a linux h4x0r
01:53 PM antto: by default in a bunch of OSes, mouse acceleration is enabled by default
01:55 PM xentrac: https://en.wikipedia.org/wiki/VHS claims, "VHS tapes have approximately 3 MHz of video bandwidth and 400 kHz of chroma bandwidth"
01:56 PM Emil: antto: are you a winfgt?
01:56 PM antto: a wat?
01:56 PM Emil: I'm, too, but transitionin towards linux h4x0r
01:56 PM daey_ is now known as daey
01:56 PM specing: ya'll need da nipple mouse
01:57 PM antto: chances are high that mouse acceleration or as windows calls it "enhance mouse movements" is enabled by default
01:58 PM antto: and that thing is aweful if you're used to linear mouse response
01:58 PM Emil: specing: nipple mouse is bloody awful to use
01:58 PM Emil: specing: the concept is neat, though
01:59 PM Emil: antto: no I know how to use a mouse and have no problems with it
02:00 PM antto: then just use it.. look how cute it is
02:00 PM Emil: _I'd prefer h4x0r linux_
02:00 PM antto: KEWT
02:01 PM antto: there's a reason why linux h4x0rz can't paint in gimp
02:01 PM specing: Emil: which nub do you have?
02:01 PM specing: Emil: you need the rim, others suck
02:02 PM specing: and the dome one is usually shipped with laptops
02:02 PM polprog: Emil: its a mighty CRYZONATOR!
02:02 PM polprog: what the hell is that symbol xD
02:08 PM polprog: < Emil> antto: I wish there was a completely keyboard only way to use kicad
02:08 PM polprog: http://www.mkl211015.altervista.org/ide/aide2001.gif
02:14 PM polprog: as for that separate vcc power and label its my pet peeve, all 74 series symbols have discrete vcc and gnd - try to route separate boards with that. i have to edit the sybols every time
02:14 PM Emil: specing: I dont have the nub but have used it
02:15 PM Emil: polprog: what's that?
02:15 PM Emil: also I should try gEDA
02:15 PM polprog: i dont know, looks like old altium
02:15 PM specing: I used gEDA in the past
02:15 PM polprog: geda was terrible for me, i couldnt get it to work. kicad was way smoother
02:15 PM specing: polprog: thats because you are not 1337 enough
02:16 PM polprog: and its even better when you download the converted eagle symbold and footprints B)
02:17 PM Emil: >eagle
02:17 PM polprog: specing: i was close to designing pcbs with pen and paper in the beginning :P
02:17 PM Emil: ttett
02:17 PM specing: polprog: tbh I think that way is faster
02:17 PM Emil: polprog: where are those symbols and footprints, though
02:17 PM Emil: also
02:17 PM polprog: Emil: let me find that site
02:17 PM specing: polprog: rough scretch on paper, then schematic and layout
02:18 PM Emil: I've noticed that kicad is moving towards morr eagleshit approach where you select parts first instead of designing
02:18 PM specing: in school I saw them do layout directly, from schematics on whiteboard
02:18 PM polprog: what do you mean, Emil
02:18 PM specing: just take 0.1" mm pad and ctrl-c ctrl-v
02:18 PM specing: very fast
02:21 PM polprog: Emil: there was a site with a zip of all libs converted library.oshec.org
02:21 PM polprog: its down but theres a git repo with scriprs
02:21 PM polprog: scripts*
03:00 PM Jartza: https://www.youtube.com/playlist?list=PLkN1JJOgrBAmVDe5_sPLZrGzQo8Re-A4R
03:00 PM enhering: Good afternoon˜
03:00 PM enhering: !
03:03 PM Emil: Jartza: nice
03:07 PM Jartza: Emil: it was nice weekend :)
04:56 PM Emil: Hmm
06:45 PM Tachyon` is now known as Tachaway
11:45 PM daey_ is now known as daey