#avr Logs
Oct 05 2017
#avr Calendar
12:14 AM day__ is now known as daey
12:18 AM rue_house: fight for the good!
12:38 AM * Casper looks at rue_house... and consider getting the garden hose
12:52 AM rue_house: whaaaat
12:52 AM rue_house: nobody will listen to me when I'm telling them about hobby servo control pulse resolution
01:07 AM JanC is now known as Guest53841
01:55 AM Casper: Good, 10% of the floor is now dried! yay! only 90% to go!
01:55 AM * Casper hosed down the floor inside
01:55 AM Casper: and it's all rue's fault!
02:32 AM rue_bed: ?
02:33 AM Casper: * Casper looks at rue_house... and consider getting the garden hose
02:34 AM Casper: but seriously, I have a small "frost" refrigerator that needed to be defrosted
02:34 AM Casper: I just hose it down
02:34 AM Casper: then once it's restarted and restocked, I just hose down the floor, drop some soap, and wash it
02:35 AM Casper: then remove as much water as possible... very uneven, so hard to remove water... then use fans to dry it out
02:35 AM Casper: it's almost dry now
09:19 AM rue_house: #define SetBit(BIT, PORT) (PORT |= (1<<BIT))
09:19 AM rue_house: #define ClearBit(BIT, PORT) (PORT &= ~(1<<BIT))
09:35 AM merethan: I´m looking for a way to update application code over i2c. This kind of rules out avr109 as it is designed to run over a duplex connection, whereas i2c is master-slave based (slaves never initiate any communication).
09:36 AM merethan: Can someone recommend me a protocol, code or good read?
10:01 AM webshinra: hello world
10:01 AM noHitW_work: hi
10:03 AM merethan: hello webshinra
10:04 AM noHitW_work: weekend starts in 10 minutes
10:28 AM Emil: merethan: you have a bootloader
10:28 AM Emil: Your bootloader can use all peripherals
10:29 AM merethan: I´m still figuring out how.
10:29 AM Emil: The easiest would be to use a chip that "directly" translates serial data to i2c
10:29 AM merethan: i2c (or twi) is master-slave oriented, where only a master can initiate communication.
10:29 AM Emil: and just modify the bootlaoder to accept i2c instead of serial
10:31 AM merethan: Yeah well that´s easiers said than done is it not?
10:33 AM merethan: Let´s see how Xboot does it
10:42 AM polprog: im having a hard time writing an uart handler
10:43 AM polprog: i need to copy a buffer to another buffer on a certain event.
10:43 AM polprog: so far, i tried strcpy (bufer's zeroed) then zeroing it agan
10:44 AM polprog: that didnt work,
10:44 AM polprog: so i tried to copy it char by char in a loop...
10:44 AM polprog: that failed either
10:44 AM NoHitWonder: *too
10:44 AM polprog: yeah too
10:44 AM polprog: ;/
10:44 AM polprog: now im getting absolutely strange errors
10:45 AM polprog: buffer index vars getting out of hand
10:45 AM polprog: i think ill try to write it again starting over with an empty isr
10:53 AM Emil: polprog: hm?
10:53 AM Emil: what's the issue?
10:54 AM Emil: polprog: if you use strcpy your data needs to be null terminated, otherwise it will overflow
10:54 AM Emil: also
10:54 AM Emil: copying or zeroing buffers is inefficient
10:54 AM polprog: shit
10:54 AM polprog: now i know
10:55 AM polprog: i forgot to null terminate on CR
10:55 AM Emil: lol
10:55 AM polprog: duh
10:55 AM Emil: knew it
10:55 AM Emil: "my low level buffer copy fails when using strcpy"
10:55 AM Emil: That's like, instantly obvious :D
10:55 AM polprog: also, i have to copy it because i set a cross-file flag var that indicates the command should be executed in the next main loop cycle
10:56 AM Emil: What kind of uart handled are you writing?
10:56 AM Emil: what for?
10:56 AM polprog: PC comms
10:56 AM Emil: you are writing on pc side?
10:56 AM polprog: no, avr side
10:56 AM polprog: PC side is a terminal
10:56 AM Emil: but I mean
10:56 AM Emil: what kind of data are you doing
10:56 AM Emil: do you have time constraitns
10:56 AM Emil: et cetera
10:57 AM Emil: I pretty much never use the functions provided in string.h
10:57 AM polprog: simple command interface, no time constraints. i type a command, it gets copied, and executed on the next main loop iteration (buffer ops are asynchronous)
10:57 AM Emil: avr side
10:58 AM Emil: polprog: wellthen, just write data out syncrhonously
10:58 AM Emil: and push the data onto a ringbuffer until you get a end mark
10:58 AM Emil: an end mark*
10:58 AM Emil: when you get data
10:59 AM Emil: Also
10:59 AM Emil: Keep in mind
10:59 AM Emil: that if your pc application doesn't do line buffering you must provide rudimentary command editing yourself
11:00 AM polprog: yeah, i know
11:00 AM Emil: as a hint
11:00 AM Emil: you do want to leave it pc side
11:00 AM polprog: yes but i need to decode the command on the avr
11:00 AM Emil: of course
11:00 AM polprog: the pc side is simple
11:00 AM Emil: but in addition to that you need a state machine shit
11:01 AM Emil: Any humorous animu recommendations
11:01 AM polprog: samurai jack
11:02 AM Emil: wait lol wrong channel
11:02 AM polprog: lol
11:02 AM Emil: also samurai jack is awesome but not the kind I'm looking for
11:03 AM carabia: https://github.com/firmata/firmata.js
11:03 AM carabia: ooo nice
11:30 AM polprog: that's interesting
11:30 AM polprog: oh wait
11:30 AM polprog: i should malloc the last command buffer as well
11:32 AM polprog: okay
11:32 AM polprog: so it works
11:33 AM polprog: i also know that trying to write into an illegal memory area causes a reset, like when overflowing a bugger or writing to a non malloc'd char *
11:33 AM polprog: heh
11:59 AM polprog: the best part is that SPI stopped talking, yiss...
12:04 PM carabia: did i hear malloc
12:04 PM carabia: *shivers*
12:04 PM polprog: yes?
12:04 PM polprog: we are the knigts who say... *malloc*
12:04 PM carabia: what are you working with
12:05 PM polprog: meaning?
12:05 PM polprog: an m8
12:06 PM carabia: 1k ram
12:07 PM polprog: you think i should not be mallocing a 64-byte buffer, instead just define it as a 64-element array?
12:07 PM carabia: yes
12:08 PM polprog: ill add that to the to do list as soon as i sort spi out
12:09 PM carabia: though you will find different opinions around here i'm sure, but that's how i'd do it
12:09 PM carabia: dynamic allocating seems overkill to me on a device like that
12:09 PM cehteh: malloc on avr? *shudder*
12:10 PM carabia: hi5
12:11 PM polprog: wellm malloc recently came to my mind.
12:11 PM polprog: previously i just allocated everything statically
12:12 PM carabia: don't get any ideas
12:13 PM polprog: i mean i recently saw it somewhere and thouhgt, "hey, i forgot that function existed"
12:16 PM carabia: don't get any ideas
12:16 PM polprog: what do you mean
12:25 PM carabia: these ideas on using malloc and all, it's bad for you, just like liberal propaganda
12:26 PM polprog: for(uint8_t i = calloc(1, 1); i < 10; i++)
12:31 PM polprog: gah bloody delays again
12:31 PM carabia: are you working on the timer?
12:31 PM carabia: wait, i mean the temp sensor
12:32 PM polprog: yes
12:33 PM carabia: how elaborate is it? as in, what all functionality does it have?
12:33 PM Emil: polprog: wait wat
12:33 PM Emil: polprog: you are not mallocing on avr?
12:33 PM polprog: see
12:33 PM Emil: You are not mallocing, right?
12:33 PM polprog: actually i havent changed that yet
12:34 PM Emil: Don't tell me you are mallocing
12:34 PM Emil: please no
12:34 PM polprog: carabia: nothing much, just sends the temp via uart
12:35 PM Emil: polprog: sometimes you seem like a clever person
12:35 PM Emil: but today that was struct down a few notches
12:35 PM polprog: excuse me
12:35 PM carabia: *struct intensifies*
12:35 PM polprog: i learned programming in java
12:35 PM Emil: carabia: oops :D
12:36 PM carabia: struct emil_t { int intensifies; } emil;
12:36 PM Emil: that can hold any value!
12:36 PM carabia: sick.
12:36 PM Emil: now typedef it
12:36 PM carabia: all hail linus, linus say no typedeffing structs
12:37 PM carabia: says, even
12:37 PM Emil: agreed
12:37 PM Emil: typedefs are cänser
12:37 PM carabia: he's a poser
12:37 PM Emil: >2017-10-05 20:04:19 +0300 < polprog> i learned programming in java
12:37 PM Emil: That's like shouting: "It's not my fault if I'm an idiot!"
12:37 PM carabia: i like typedefs, linus can shove his stupid opinions up his big arse
12:38 PM Emil: get the fuck out of my network
12:38 PM polprog: i was 10 back then
12:38 PM polprog: for fucks sake
12:38 PM Emil: ;D
12:38 PM Emil: typedeffing is stupid as fuck
12:38 PM polprog: the equation for opinions on this channel is n+1 where n is the number of users online i feel...
12:38 PM carabia: seriously, the argument is like shaky at best
12:38 PM polprog: i dont think so. i always typedeffed
12:39 PM carabia: polprog is intelligent after all.
12:39 PM Emil: no
12:39 PM carabia: also, polprog isn't it quite a simple thing to do, pardon me?
12:40 PM polprog: are we gonna argue about indentation style ?
12:40 PM Emil: \t mastterace spaces btfo
12:40 PM polprog: carabia: the thing im building?
12:40 PM carabia: yes
12:40 PM polprog: yeah
12:40 PM polprog: it's simple
12:40 PM polprog: when it works
12:40 PM carabia: could use those 1-wire sensors and all
12:40 PM carabia: and just pipe data to uart, seems simple nuf
12:41 PM carabia: but you've been at it for about two weeks or so, can't remember when i was last here
12:41 PM carabia: so there has to be a catch
12:41 PM Emil: that would be using malloc
12:41 PM carabia: does it have to be written in javascript running on an interpreter on top of a java vm?
12:41 PM polprog: not really
12:41 PM carabia: as someone linked a java vm for avr I think
12:42 PM polprog: it's more like, there's this chip i havent used in my life before, and then there's school so there are weeks i dont do electronics at all
12:42 PM polprog: if i worked 9 to 5 on it i would probably been done twice
12:43 PM carabia: once you've worked on one atmega, you've pretty much worked with all of them
12:43 PM carabia: apart from the u2/3/4 ones, I figure
12:43 PM Emil: Fuck I'm feeling tired
12:43 PM polprog: it's not about the atmega, i know that and i know m8 quite well
12:43 PM carabia: ah, so the temp sensor?
12:44 PM carabia: what are you using for temp sensing?
12:45 PM polprog: adt7320
12:46 PM carabia: SPI, fancy!
12:46 PM carabia: srsly is this qfn?
12:47 PM polprog: yes
12:48 PM polprog: but that mofo doesnt want to cooperate
12:51 PM carabia: seems pretty straightforward
12:51 PM carabia: in what way is it not co-operating?
12:52 PM polprog: protocol quirks
12:52 PM polprog: i dont know mysel
12:52 PM polprog: f
12:52 PM polprog: ;)
12:52 PM carabia: what you do know, though is what you're getting vs. what you're expecting
12:58 PM mudkip908_ is now known as mudkip908
01:00 PM polprog: i wish m8 had jtag... :'(
01:01 PM Tom_L: if pigs could fly...
01:03 PM carabia: jtag... kidding me again?
01:03 PM LeoNerd: What would you use the JTAG for?
01:03 PM carabia: for debugging a temp sensor?
01:03 PM carabia: oh, how alienated CS makes you from the world...
01:03 PM polprog: never studied cs
01:04 PM polprog: it was just easier to debug with jtag
01:04 PM polprog: but as you can see i managed to fix uart handling
01:04 PM LeoNerd: That'll be due to the tooling though
01:04 PM carabia: you're doing uart by default
01:04 PM carabia: use uart.
01:04 PM LeoNerd: If there were decent tools around dW you could just use dW
01:04 PM polprog: ^^
01:05 PM polprog: not sure if CS people even get to touch a transistor
01:06 PM carabia: LeoNerd: dW is kind of silly and unnecessary
01:06 PM carabia: also, why do "open source" hardware (what the fuck does that even mean) people use avr stuff, as debugwire clearly is not communist-friendly
01:07 PM polprog: i dont feel comfortable disabling the reset pin
01:07 PM polprog: every design of mine has a reset header
01:07 PM LeoNerd: dW is great on the smaller devices, so you don't have to dedicate 4 pins to JTAG
01:07 PM polprog: yeah
01:08 PM polprog: but on such a mega16
01:08 PM polprog: the ability to use DDD to have a live view of any given variable in real time is just glorious
01:13 PM polprog: s/ability/possibility
01:17 PM polprog: hungry, ill commit and eat someting
01:26 PM carabia: well, on a serious note, i for one fail to understand the need for hw debugging on simple devices such as those
01:28 PM polprog: it's nice to have
01:32 PM carabia: well, "nice", alright. but not necessary in any way to get things rolling
02:23 PM NoHitWonder: are you sure linus is against typedeffing structs? since there's some in subsurface source
02:23 PM NoHitWonder: https://github.com/torvalds/subsurface-for-dirk/blob/master/core/units.h
02:28 PM cehteh: most likely he has not looked at *every* line of the code and when someone trustworth sends it to him he'll integrate it
02:29 PM cehteh: .. and looking, these typedefed structs are the only way in C to make real types (as in typesafe)
02:30 PM polprog: it's like saying you'll always use while instead of for. sure, it works, but why bother
02:31 PM cehteh: all code is fine as long it works, the trick is to write code where debugging is easy and prolly already points out an error at compile time
02:32 PM polprog: agreed
02:32 PM NoHitWonder: those units are pretty crucial part of the software so i'm pretty sure he has looked at it
03:15 PM ayjay_t: hmmm a uart BER is decreasing when I add significant delays between transmits
03:15 PM ayjay_t: but the RX has a 4byte deep FIFO so i feel like it shouldn't matter since i'm only sending 2 bytes at a time
03:16 PM ayjay_t: so Byte...10ms...Byte is fine, but Byte..10us..Byte is 50/50
03:18 PM Emil: ayjay_t: on what device
03:18 PM Emil: on what receiverf
03:18 PM Emil: on what baudrate
03:19 PM ayjay_t: baudrate is 115200
03:19 PM ayjay_t: its xmega-->nxp_kl82
03:19 PM ayjay_t: baudrates are a pain in the butt to match
03:20 PM ayjay_t: i almost always use SPI i don't know why i chose uart this time
03:20 PM ayjay_t: transmissions look fine on the line
03:21 PM cehteh: do you do 1:1 data ratio, like echoing back?
03:22 PM ayjay_t: um i have disabled it at the moment, but when it goes into product yes there will be a 1:1 data ratio + CRC
03:22 PM ayjay_t: still with the BER it has we're looking at .5 tranmission rate with all the NAKs coming from those error checking
03:22 PM cehteh: sometimes its favorable to give the receiving side a little boost
03:22 PM ayjay_t: a boost?
03:23 PM cehteh: make the baudrate a bit faster on the receiving side
03:23 PM ayjay_t: oh really
03:23 PM ayjay_t: weird
03:23 PM ayjay_t: i never would have thought of that
03:24 PM cehteh: the receiver should cope well, but when it echoes back it gives a little headroom for the timing
03:25 PM ayjay_t: ohh well, hmm
03:25 PM ayjay_t: i'm just not buying it
03:25 PM cehteh: imagine sender sends at full speed and is just a very little bit faster than the receiver (which echos back) eventually buffer on that side will stall
03:25 PM ayjay_t: okay hold on
03:25 PM ayjay_t: right the buffer will fill up
03:26 PM ayjay_t: but my chunks are only two bytes big!
03:26 PM antto: i use synchronous usart between two xmegas
03:26 PM antto: it's quite solid
03:26 PM ayjay_t: yeah tbh the xmega is not the one i'm worried about
03:26 PM cehteh: how long are the pauses?
03:26 PM ayjay_t: between chunks or bytes?
03:26 PM cehteh: yes
03:27 PM ayjay_t: haha okay, well, between bytes its been 10us now its 10ms doing great
03:27 PM antto: ayjay_t wait, are you sending bytes by clocking wait?
03:27 PM ayjay_t: huh antto?
03:27 PM ayjay_t: and between chunks its on my command
03:27 PM antto: ...or interrupt-driven
03:27 PM ayjay_t: polling
03:28 PM ayjay_t: <_< >_>
03:28 PM antto: but i mean.. send_byte(uint8_t x) { USART.DATA = x; while (busy) {}; } ?
03:28 PM ayjay_t: right
03:28 PM ayjay_t: again, the xmegas are actualyl doing great
03:29 PM ayjay_t: i'm scoping the output and they hit the mark everytime
03:29 PM antto: which flag do you use to poll for "busy" ?
03:29 PM ayjay_t: even when i get an error
03:29 PM antto: cuz there are more than one options there
03:30 PM ayjay_t: yeah but the thing is, the xmegas are fine
03:30 PM antto: k
03:30 PM ayjay_t: https://paste.ofcode.org/p8i5ZYQRzgVekUfC6ckFQa
03:30 PM ayjay_t: just because ur curious
03:31 PM antto: DRE is going to say "i'm not busy" after the first byte you send
03:32 PM antto: even tho that first byte has not been sent out yet
03:32 PM antto: in theory, it might not matter
03:33 PM ayjay_t: both bytes seem to get out
03:33 PM ayjay_t: i mean, obviously with a 10us-10ms wait...
03:34 PM ayjay_t: i can always really on echo and CRC but this should be improved
03:37 PM ayjay_t: actually cehteh i think i should try and make that baudrate a bit faster
03:37 PM aarcane: Will const char[] end up in the text section of my ELF or will they go onto the stack?
03:37 PM ayjay_t: thats one of the most interesting things i've heard in a while
03:38 PM polprog: aarcane: that depends
03:38 PM cehteh: ayjay_t: just try
03:38 PM polprog: aarcane: making it const doesnt make it go to .text
03:38 PM cehteh: or actually make it slower you dont send much data?
03:38 PM polprog: thats a myth
03:38 PM cehteh: 9600 baud?
03:39 PM polprog: ayjay_t: what clock source are you using?
03:39 PM cehteh: ayjay_t: but remmeber, a 5% timing error is 5% .. at 9600 baud and at 115200 baud :D
03:39 PM aarcane: polprog, I'm just trying to keep a lookup table used for one function only from wasting extra cycles on the stack every time it's called
03:40 PM polprog: aarcane: use PROGMEM
03:40 PM cehteh: on atmega and attiny i sometimes used the serial signal to calibrate osccal
03:40 PM antto: isn't the table lookup gonna be slower if the data is on the flash?
03:40 PM polprog: it's a case of compromise between ram usage and speed
03:41 PM cehteh: aarcane: how big is that table?
03:41 PM ayjay_t: cehteh: matching the bauds is a pain!
03:41 PM cehteh: you may abstract it in a #define .. xmacro and then try different implementations, in many cases gcc is pretty good to optimize a switch/case
03:42 PM cehteh: or you may see if you can deduce some arithmetic function from it
03:42 PM ayjay_t: i have bscale really high and that way i can use BSEL to fine too
03:42 PM ayjay_t: tune*
03:42 PM aarcane: cehteh, about 17 instructions long or so
03:42 PM aarcane: cehteh, but it's called in a tight loop
03:42 PM cehteh: i dont know about xmegas, but on atmega i never had problems with uart
03:42 PM antto: i've made myself a function that calculates the "optimal" USART settings for a given bitrate for the xmega USARTs
03:43 PM ayjay_t: yeah again... it's def not the xmega
03:43 PM ayjay_t: but you know what, since the bauds are inexact and use different functions to derive them
03:43 PM cehteh: well then on the other side
03:43 PM polprog: my latest problems with uart error rate were solved by enabling u2x
03:43 PM antto: and another function that takes the usart settings and calculates the actual bitrate
03:43 PM ayjay_t: my xmega might actually be about 5% faster than the kl82
03:43 PM antto: then, consecutive bytes will get out of sync and get corrupted
03:44 PM cehteh: just let the kl82 send some calibration signalk "UUUUUUUU" was it? right? thats a square wave
03:44 PM cehteh: analyze that and adjust along
03:44 PM aarcane: thank you polprog.
03:44 PM cehteh: and 5% is a lot for serial
03:44 PM polprog: aarcane: np
03:44 PM antto: if you can, attach the xmega TX to a computer (via uart-to-rs232 or ftdi or something), and see if you get "sane" data there
03:45 PM ayjay_t: oh eyah no it's totally sane date for sure
03:45 PM ayjay_t: i mean, it works with a signficant delay between bytes
03:45 PM cehteh: logic analyzer
03:45 PM ayjay_t: and yeah i scoped it
03:45 PM ayjay_t: so what i did is just lowed down the xmega a bit
03:45 PM ayjay_t: lets see
03:45 PM antto: the xmega usart has a fractional baudrate thang btw
03:46 PM antto: if ya wanna get pimpin'
03:46 PM cehteh: and since you have a lot time to spare, can you include a warm up byte in your datastream for handshake, maybe even simple checksum
03:46 PM cehteh: struct {char magic; char data[2]; char data_xored;} ...
03:46 PM aarcane: I don't know what the exact problem you're having with serial is... but when I started doing USART serial stuff, I was getting garbage over the com port, because I didn't have the correct FCPU macro because the datasheet was bugger all about the default clock speeds. I had to measure it with a 1000ms delay and an LED to realize it was off by a factor of 2 from what it was supposed to be
03:47 PM cehteh: but *usually* serial should be much more robust
03:47 PM cehteh: how long are the wires between them any noise/distrubances? capacitance/inductance?
03:48 PM ayjay_t: cehteh: yeah its a soldered on hackjob connecting two seperate boards
03:48 PM ayjay_t: each rx-->tx pin has two jumpers being held together by an oscilloscope probe
03:48 PM ayjay_t: which turned out to be really convinient heh
03:49 PM ayjay_t: there WILL be post processing checksums etc but for now... just trying to improve ber *shrug*
03:49 PM cehteh: just let both side spew out "UUUUUUUUUUU" .. scope that side by side and see if the phase matches
03:49 PM ayjay_t: oh jeez thats a great ide
03:50 PM ayjay_t: cehteh u wanna give me a job
03:50 PM * ayjay_t holds his hands out
03:50 PM cehteh: lol
03:51 PM cehteh: when done, pack your scope into a box and send it to me, seems you dont need it much and i could use one :D
03:54 PM ayjay_t: hmmm matching phase...
04:02 PM Emil: pls giv all good scopes to me
04:02 PM Emil: regards no scopes
04:02 PM Emil: I wish I had a good digiscope
04:07 PM ayjay_t: so its literally a 180 degree phase shift
04:07 PM ayjay_t: the xmega is a lil faster as planned, about 30ns
04:17 PM ayjay_t: so i guess this is what hardware flow control is used for?
04:18 PM ayjay_t: tbh i haven't used UART since college
04:18 PM ayjay_t: I almost always use SPI
04:19 PM LeoNerd: SPI is nice, if one-sided
04:19 PM ayjay_t: right, for comm between two actually independent chips...
04:20 PM bss36504: I just use SPI2CART, the best comm protocol ever invented
04:20 PM ayjay_t: oh i get it
04:20 PM ayjay_t: its a portmanteau of the three most comomly taught comm protocols
04:21 PM ayjay_t: um but, huh this uart is really.. finicky
04:21 PM bss36504: You must be fun at parties ;)
04:22 PM ayjay_t: i.. i'm in a microcontroller IRC channel
04:22 PM ayjay_t: talking about microcontrollers
05:55 PM ayjay_t: hmm so i ended up a) lowering the baudrate (to about half)
05:55 PM ayjay_t: but on the nxp chip, you can increase the RX sampling frequencing, which i guess improves synchronization. so that helped too, i think
06:11 PM carabia: <bss36504> I just use SPI2CART, the best comm protocol ever invented
06:11 PM carabia: =D
06:11 PM HighInBC: I like how ayjay_t explained it after
06:11 PM HighInBC: made it funnier
06:12 PM carabia: indeed
06:12 PM carabia: the topic is tl;dr, seems something vaguely related to debugging silly serial comms
06:12 PM carabia: i.e. boring and irrelevant
06:13 PM carabia: though not necessarily irrelevant but implies something is being done wrong
06:25 PM ayjay_t: Most of IRC is pretty serious about their /topics
06:25 PM ayjay_t: I mean, maybe #avr is different
06:25 PM Lambda_Aurigae: we are kind of laid back here.
06:25 PM Lambda_Aurigae: we will discuss anything from microcontrollers to explosives.
06:26 PM carabia: ayjay_t: your perception seemingly stopped working there for a sec
06:26 PM Lambda_Aurigae: so long as our discussions on microcontrollers don't interfere with the discussions on explosives.
06:26 PM carabia: "topic" in this context referred to whatever the topic was you were talking about
06:26 PM ayjay_t: huh?
06:26 PM carabia: Lambda_Aurigae: but what happens when they coincide?
06:26 PM ayjay_t: i wasn't addressing your comments carabia
06:26 PM Lambda_Aurigae: carabia, then we have FUN!
06:27 PM carabia: amen seems not fitting, i'll go with allah akbar.
06:27 PM rue_house: do I buy 1pcs for $4 or 10 pcs for $18
06:27 PM Lambda_Aurigae: amen just means "I believe"
06:27 PM Lambda_Aurigae: rue_house, 10.
06:27 PM carabia: allah akbar means boom time
06:27 PM carabia: +just
06:28 PM Lambda_Aurigae: I see "akbar" and think, "It's a trap!"
06:28 PM Lambda_Aurigae: but that's Admiral Ackbar
06:29 PM Lambda_Aurigae: http://buttersafe.com/2017/10/05/haunted-move/
08:04 PM robinak is now known as robink
08:23 PM trafaret1: hi there
08:23 PM trafaret1: can I ask you questions about programming microcontrollers?
08:25 PM trafaret1: I'm newbie in this field, sorry for this silly questions. I want to programming PIC and ARV, and I have the difficulty with picking up suitible compiler for that
08:26 PM trafaret1: maybe you suggers me some of them, but I want to use it under Emacs
08:33 PM Tom_L: avr-gcc for avr
08:35 PM LeoNerd: emacs is a text editor; isn't directly involved in running a compiler. So... whatever really :)
09:19 PM cehteh: i bet you can implement a compiler in elisp :)
09:43 PM ravon_ is now known as ravon
10:32 PM rue_house: trafaret1, use AVRs, 8 bit, they rule
10:32 PM rue_house: want to know how to get started?
11:14 PM rue_shop3: no, ok