#avr Logs
Jul 12 2019
#avr Calendar
12:14 AM day__ is now known as day
05:28 AM Jan-: hihi avr people
05:58 AM cehteh: hi
05:58 AM Jan-: I need to write something to receive serial data on any arbitrary pin.
05:58 AM Jan-: I know this will have been done a lot
05:58 AM Jan-: but I wouldn't mind doing it just for the experience
05:58 AM * Jan- headscratch
06:04 AM cehteh: have fon , just do
06:06 AM Jan-: oversampling :/
06:06 AM Jan-: this could actually get quite expensive in cpu time
06:07 AM cehteh: just pinchange interrupt and record the time the change happend
06:07 AM Jan-: yeah.
06:07 AM cehteh: use that to sync/reconstruct the signal
06:07 AM Jan-: and try to figure out what multiples fit
06:08 AM cehteh: rougly you also need to sync the clock
06:11 AM Jan-: well I guess you just implement the clock as a bit of timing based on how you calculate the timings
06:11 AM Jan-: er how you calculate the gaps between edges
06:13 AM day__ is now known as day
06:13 AM timemage: Jan-, this has to be rs232 type serial?
06:36 AM Maya-sama is now known as Miyu
09:59 AM rue_mohr: Jan-, I did software serial
10:53 AM gsi__ is now known as gsi_
12:58 PM Jan-: to answer the earlier question
12:59 PM Jan-: it's rs232 type serial at normal logic levels
12:59 PM Jan-: 3.3v which I understand the avr will happily read
12:59 PM Jan-: I think I have a decent approach worked out, I'll time between edges
12:59 PM Jan-: then you have to deal with frames where the last few bits are at the idle level, but that can be done with a timer.
01:05 PM timemage: Jan-, doing software serial at higher board rates on arbitrary pins requires turning off interrupts for the duration of the frame. with regard to 3.3v bit, that depends no what the operating voltage of the avr is. in the datasheet you can find can see how VIH and VIL and are listed in terms of VCC.
01:10 PM Jan-: See, I was going to do it by setting an interrupt on the pin
01:10 PM Jan-: I suspect it wouldn't be madly high bit rate, not megabaud or anything
01:12 PM timemage: Jan-, with a 16mhz avr, you'll probably find that 2400baud is doable that way. if no isrs are hogging time.
01:12 PM timemage: no /other/ isrs.
01:25 PM Jan-: at 6000 clocks per byte I would be shocked if it wasn't possible
01:26 PM Jan-: I'm not even that sure how to figure out how fast a serial port is going
01:26 PM Jan-: it's being driven by a python script on a linux computer and I have no clue how that stuff works
01:27 PM Jan-: hm defaults to 115200.
01:27 PM Jan-: hmm 138 clocks per bit
01:27 PM Jan-: that's getting tightish
01:55 PM cehteh: Jan-: 115200 wont really work on softserial .. why do you need that anyway ?
01:55 PM cehteh: there are avrs with 2 usarts
01:56 PM cehteh: or when you need softserial as 2nd serial, then at least default it to the port that can run slow
02:00 PM cehteh: when you know that data comes in short bursts you may also just queue the isr time aand process it later, but that costs some ram for the queue, 1 byte per transition, thus 10 bytes per character at worst, wont be reasonable to handle message that are longer than a few chars this way
02:02 PM Jan-: yes.
02:02 PM cehteh: better get a avr with 2 uarts
02:02 PM Jan-: the problem is I tend to use arduino boards specifically because it's super convenient to have the hardware serial available for debug
02:03 PM Jan-: in theory I could use the hardware serial and just some basic gates to route the signal to the serial devices I need to tal to
02:03 PM cehteh: wont change much to put debug on softserial
02:03 PM cehteh: when it crashes hardware serial doesnt work either
02:03 PM Jan-: it will change the hardware a lot as the usb is on the hardware serial
02:03 PM cehteh: wellyes
02:04 PM Jan-: I do have some stm32 boards
02:04 PM Jan-: but I don't really want to dive into that fresh on a new project
02:04 PM cehteh: 115200 will not really work
02:05 PM cehteh: as softserial
02:05 PM Jan-: I suspect it could be done, but yes, not very easily
02:05 PM Jan-: what's annoying is that this could totally be spi
02:05 PM cehteh: with some high optimized interrupt-less code maybe, not doing anything else
02:05 PM Jan-: it's just that the device in question wants a serial protocol
02:06 PM Jan-: I guess in reality I don't absolutely need to read their replies
02:06 PM Jan-: but it would be nice
02:06 PM cehteh: maybe a 2nd avr?
02:06 PM cehteh: bit ugly
02:07 PM cehteh: do you need only ok/error replies?
02:07 PM Jan-: mostly
02:07 PM cehteh: then some 2nd avr would be feasible
02:08 PM cehteh: handling rx and setting the state good/bad on a single pin
02:08 PM cehteh: which you pick up with your main avr
02:09 PM cehteh: still the timecode flap?
02:09 PM Jan-: nono
02:09 PM Jan-: that's only about 2400 baud tops that's easy :)
02:13 PM Jan-: well actually
02:13 PM Jan-: reading it is pretty easy
02:13 PM Jan-: syncing to it... I never really got working.
02:13 PM Jan-: became not fun and it's a personal project so screwit
02:32 PM cehteh: fuu __brkval stays uninitialzied until one sacrifices something to the memoy allocator
04:22 PM vmt: don't sacrifice anything to crt allocs on avrs pleeeeeeeeease
04:29 PM Jan-: is it worth adding spi uart devices to an atmega328
04:29 PM Jan-: or do I just give up and go to stm32 at that point
05:46 PM cehteh: Jan-: get an avr with 2x usart
05:47 PM cehteh: vmt: yes worked around that
05:48 PM cehteh: havent even tested if the code works with malloc, but it should
05:48 PM cehteh: anyway i have stack checking now
05:54 PM Jan-: cehteh: I need like five.
05:54 PM Jan-: Or possibly some AND gates for routing it
05:54 PM cehteh: WTF
05:54 PM Jan-: unless there's a better way to route serial data.
05:55 PM cehteh: what are you doing? 5x serilal is even tight on stm32 some bus protocol would be nicer
05:57 PM Jan-: Yeah.
05:57 PM Jan-: I'm controlling five power supplies
05:58 PM cehteh: you may mux the ports, when you only talk to one at one time or make some protocol translators when it isnt timing critical
05:58 PM Jan-: each of them takes serial control
05:58 PM Jan-: it's not huge amounts of data
05:58 PM Jan-: yes it could be multiplexed I guess.
05:59 PM Jan-: it's just that there are replies to listen to
05:59 PM Jan-: it's pretty low traffic
06:00 PM cehteh: its just reply, not initiated there?#
06:00 PM cehteh: then mux should work
06:00 PM cehteh: there are chips for that
06:01 PM Jan-: that or, just and gates :)
06:02 PM cehteh: https://www.atlas-scientific.com/product_pages/components/port_expander.html << works for you?
06:03 PM cehteh: 8:1 serial on a small board
06:03 PM Jan-: ooh handy
06:03 PM Jan-: I found a few multiplexer/demultiplexer chips that I think would do it
06:04 PM cehteh: there aere a lot others as well
06:04 PM Jan-: as well as some multi uart chips
06:04 PM Jan-: with spi control
06:04 PM Jan-: I mean as soon as you involve another chip you might as well just do that although the uart chips are quite expensive.
06:05 PM Jan-: Actually you could just common up all the reply lines...
06:05 PM cehteh: depens on how you want to drive the lines simple cmos/ttl levels are trivial
06:06 PM cehteh: but when you add other options like differential, current, other levels, isolation and so on it becomes expensive
06:06 PM Jan-: yes it's just around the inside of our box
06:06 PM Jan-: it can be normal ttl levels
06:06 PM cehteh: good then
06:06 PM Jan-: well the power supplies we're talking to are 3.3v
06:06 PM Jan-: but anyway
06:08 PM Jan-: I guess shorting two outputs together might be bad anyway :)
06:09 PM Jan-: resistors!
06:09 PM cehteh: resistors blur the signals
06:09 PM Jan-: yes.
06:10 PM Jan-: some of the serial multiplexer devices use analog multiplexers
06:10 PM Jan-: which are expensive
06:10 PM Jan-: at logic level I'd almost just do it with gates
06:11 PM Jan-: (which is what a digital multiplexer is, I guess)
06:12 PM cehteh: more or less they may do some magic sauce to condition the signals
06:13 PM * Jan- is annoyed by lack of free uart on mega328
06:13 PM * Jan- curse
06:13 PM cehteh: i hav 328pb here :D
06:13 PM cehteh: 2 uarts
06:14 PM * Jan- steals all of cehteh's microchips
06:14 PM Jan-: *yoink*
06:14 PM Jan-: the problem is I mainly work on arduino hardware as it's just easy
06:15 PM Jan-: I don't use the library I just treat it as a cheap avr dev board
06:15 PM Jan-: and they have 328s
06:15 PM Jan-: I have a 2560 board somewhere though.
06:15 PM Jan-: hmm cd4053
06:17 PM Jan-: analog multiplexer
06:17 PM cehteh: there are arduino clones with 328pb
06:17 PM Jan-: I think the 2560 might be better anyway
06:17 PM cehteh: maybe
06:18 PM Jan-: this project involves some quite "precision" control of leds
06:18 PM Jan-: might need lookup tables and stuff to do linearisation
06:18 PM Jan-: it might even be an stm32 project but I know nothing about stm32
06:18 PM cehteh: i shouldve picked a biggier one as well, wasnt aware how much this project grows
06:19 PM cehteh: id like to start with riscv
06:19 PM Jan-: avr is cool and all but when you can get an stm103 for $whocares then...
06:19 PM Jan-: the stm is a lot more powerful
06:19 PM cehteh: yep
06:19 PM Jan-: I guess it's also a lot more of a bitch to program
06:19 PM cehteh: almost anything is more powerful than avr
06:19 PM Jan-: some people asked me once how powerful they are
06:19 PM cehteh: *but* avrs are the easiest to use
06:20 PM Jan-: I said "kind of like a zx spectrum only clocked faster"
06:20 PM Jan-: I guess an stm32 is more like an early 90s pc or a very fast amiga or atari st or something
06:22 PM Jan-: and yes, the fact that I can write avr c in the arduino ide is the selling point
06:22 PM Jan-: I have no idea what the ide for the stm32 is like
06:22 PM cehteh: bleeh ardoino ide
06:22 PM cehteh: just use an editot
06:23 PM Jan-: It's just easy
06:23 PM Jan-: I'm not a proper neckbeard
06:23 PM cehteh: me sitting here one handed, broken collarbone
06:24 PM cehteh: had to do some config to make emacs useable
06:24 PM * Jan- checks cehteh's neck for beardiness
06:24 PM cehteh: yes beard
06:24 PM Jan-: how did you break it
06:25 PM * Jan- patpats gently
06:25 PM cehteh: couldnt brake before a curve with the roadbike
06:25 PM cehteh: tarmac was too smooth
06:25 PM Jan-: does that translate to "I was going too fast"
06:25 PM * Jan- suspects it does
06:25 PM cehteh: gone flying
06:26 PM cehteh: yeah
06:26 PM Jan-: is that for work or fun
06:26 PM cehteh: eh what?
06:26 PM Jan-: do you ride your bike for work
06:27 PM cehteh: i am not pro cyclist P
06:27 PM Jan-: yeah but lots of people do deliveries and stuff
06:28 PM cehteh: you dont do that with a roadbike
06:28 PM Jan-: oh people do
06:28 PM Jan-: I live in london, there are loads of cycle couriers around the city
06:28 PM Jan-: they are crazy
06:28 PM cehteh: usually they have simpler bikes, fixies or so
06:28 PM cehteh: dropbars yes
06:29 PM Jan-: I uhoh, I just know when they clip into me as they go by
06:29 PM * Jan- is only 5 feet 1
06:29 PM * Jan- not very sturdy
06:30 PM Jan-: well, I hope it gets better
06:30 PM Jan-: I would give you a big hug but you might not like it right now :(
06:30 PM cehteh: will take some time 2 months or so
06:30 PM cehteh: prolly not
06:31 PM * Jan- puts on her nurse's hat
06:31 PM * Jan- tucks cehteh up with blanket
06:31 PM Jan-: poor cehteh :(
06:31 PM Jan-: is it painful
06:31 PM cehteh: pff .. i have programming to do
06:32 PM cehteh: nice weird bug that only shows up after weeks, then stays and survives a avr reset
06:32 PM cehteh: i make the impossible happen
06:34 PM Jan-: sell the technology back to them
06:43 PM Jan-: how long does it take to get into and out of interrupts on an avr anyway
06:43 PM Jan-: I guess it's dozens of clocks
06:50 PM cehteh: nah avrs are very fast with that, evev netter than arm clocks wise
06:51 PM cehteh: 6 clocks iirc for the ise, bu add to that wakeup cost, opushing registers to the stack
06:52 PM Jan-: so it depends how many registers are in use
06:52 PM Jan-: although how does it know
06:53 PM cehteh: compiler/abi knows
06:55 PM * Jan- finds compilers a bit spooky
06:55 PM Jan-: compiler knoooooows
06:59 PM cehteh: you dont need to know which regs aer in use, but you save the ones you want to use
06:59 PM Jan-: I'm just thinkin
06:59 PM Jan-: I can *send* 100kbps serial easy enough
06:59 PM Jan-: it's the receiving
06:59 PM Jan-: though they are pretty short messages
07:00 PM cehteh: how short?
07:00 PM cehteh: 4 bytes?
07:00 PM Jan-: just a moment
07:00 PM * Jan- consults her notes
07:00 PM Jan-: 7e 8e 01 00 13 6a 7f
07:00 PM Jan-: typically 7 bytes when we're not in some sort of special "setup" mode
07:01 PM Jan-: the actual message is only 3 bytes, the rest is framing and crc
07:01 PM Jan-: and in theory I don't actually *have* to listen to the responses, I could just send the request and assume it is good.
07:01 PM cehteh: like i saied before you can just record timestamps in a queue from the isr, thats very fast and can be done without much registers
07:02 PM Jan-: yes that was the approach I wanted to use
07:02 PM Jan-: ring buffer of response times
07:02 PM Jan-: process at leisure
07:02 PM cehteh: but needs a lor ram
07:02 PM Jan-: Eh I don't know
07:03 PM cehteh: startbit + data thus 8 bytes for the timestamp per byte at worst
07:03 PM cehteh: 9byte
07:03 PM cehteh: times 7
07:04 PM Jan-: the thing is if you get a run of zeroes or ones you can end up with a time period that is more than 256 clocks
07:04 PM Jan-: so it might have to be 2 bytes per timestamp
07:04 PM cehteh: mhm other prescaler on the timerß
07:05 PM Jan-: well
07:05 PM Jan-: it's only 139 sysclocks per bit at sysclock/1
07:05 PM cehteh: there is at least one transition per byte
07:05 PM Jan-: are we sure that is always the case
07:05 PM cehteh: start/stop bit
07:05 PM cehteh: yes
07:06 PM * Jan- checks the code
07:06 PM cehteh: thats guraneed
07:07 PM Jan-: okay
07:07 PM Jan-: well then that's 1250 sysclocks per byte
07:08 PM cehteh: schould be possible to do this with a 8bit timer and 8 bit timestamps
07:08 PM Jan-: that would be a crap ton faster
07:08 PM Jan-: basically would need to use the divide by 8 prescaler
07:09 PM cehteh: cant you change the baudrate to something sabe=
07:09 PM cehteh: sane?
07:09 PM Jan-: possibly but it would mean poking at this firmware for these power supplies and I don't want to break it :/
07:09 PM Jan-: anyway are you sure it will be using a start bit
07:09 PM Jan-: I wrote software serial for another power supply and it didn't
07:10 PM cehteh: is it normal rs232 prtotocol?
07:11 PM Jan-: it's the protocol used by the opendps open source firmware replacement for the DPS5005 power supply
07:11 PM Jan-: this is the pc client for it: https://github.com/kanflo/opendps/tree/master/dpsctl
07:11 PM cehteh: https://de.wikipedia.org/wiki/RS-232#/media/Datei:Rs232_oscilloscope_trace.svg
07:12 PM Jan-: I guess it would be set up in this code: https://github.com/kanflo/opendps/blob/master/dpsctl/dpsctl.py
07:12 PM cehteh: too bad pics dint help you
07:12 PM Jan-: huh?
07:12 PM cehteh: they do?
07:13 PM Jan-: well, I have friends who can look at them, I didn't realise we'd met before :)
07:13 PM cehteh: we talked sometimes on arduino
07:14 PM cehteh: back at that timecode flap thing
07:14 PM Jan-: uhhuh
07:14 PM * Jan- thought cehteh was somehow familiar
07:14 PM * Jan- hands cehteh a cookie :)
07:15 PM * cehteh blocks cookies
07:15 PM Jan-: but, chocolate chip macadamia nut!
07:15 PM cehteh: mkay
07:16 PM cehteh: anyway serial encodes the clock by bein the start bit 1 ans the stop bit (which isnt really a bit) 0
07:16 PM Jan-: well like I said
07:16 PM cehteh: and then databits trabsitions between that
07:17 PM Jan-: are we sure about that
07:17 PM Jan-: because I know start and stop bits are optional at least sometimes
07:17 PM cehteh: for normal uart/rs232 yes
07:17 PM cehteh: nop
07:18 PM cehteh: not on rs232
07:18 PM Jan-: hmm actually my quick and dirty serial code DOES have start and stop bits
07:18 PM cehteh: stop bit timing is a bi whacky
07:18 PM cehteh: doesnt matter much
07:18 PM Jan-: well, once you've got 8 bits, who cares
07:19 PM cehteh: ok i was wron its not encodes the clock, but the phase
07:19 PM Jan-: see, if you look at that python the word "baudrate" comes up as an option
07:19 PM cehteh: transmissiob starts with the start bit transition
07:19 PM Jan-: but "stop" doesn't come up at all
07:19 PM Jan-: and "start" only comes up in places not related to serial
07:19 PM cehteh: but sender and receiver need to have faily close clocks
07:19 PM Jan-: so do we assume that the pyserial module uses start and stop bits by default?
07:20 PM cehteh: stop comes because its reqiured to invert the signal before the next stzart bit
07:21 PM cehteh: you may ignore the fact that there are stop bits and their length
07:21 PM cehteh: but there is always a start mark
07:21 PM Jan-: has to be really
07:21 PM Jan-: otherwise there's no difference between a stream of zeroes and an idle line
07:22 PM cehteh: which means at the en ti has to be in opposite polarity to the start condition
07:22 PM Jan-: serial normally idles high, right
07:22 PM cehteh: yes, but its not so uncommon to have it inverted
07:23 PM cehteh: actual rs232 is +/- 15v not ttl
07:23 PM Jan-: yes I was aware of that
07:23 PM Jan-: but this is just whatever is coming out of the pins on the avr and the stm on the power supply (they use stm)
07:24 PM Jan-: and yes that means a level shift, we have that sorted out
07:32 PM Jan-: ok so basically we wait for the pin to change, start timing edges until we have eight nine bits worth of stuff.
07:33 PM Jan-: in fact we just keep doing that forever.
07:33 PM Jan-: all we care about is the time between edges.
07:33 PM Jan-: if that time gets way too long, like more than a byte, we can assume the line has gone quiet.
07:33 PM cehteh: yes just dump pushing timestamps on the queue
07:34 PM cehteh: everything else can be done outside of the isr
07:34 PM Jan-: this seems worth at least trying
07:35 PM Jan-: eesh my serial sending code does everything inside the timer isr
07:35 PM Jan-: I need a queue_next_bit
07:36 PM cehteh: sending is different
07:36 PM Jan-: simpler
07:37 PM Jan-: this is just the isr: https://pastebin.com/yCTy6vsP
07:38 PM Jan-: it is designed to allow pretty accurate timing in one clock cycle trims
07:38 PM rue_bed: want to compare against mine?
07:39 PM Jan-: well okay though my ability to skim code is pretty limited so be nice
07:39 PM rue_bed: its for transmitting or recieving?
07:39 PM rue_bed: recieve , right?
07:39 PM rue_bed: looking over
07:39 PM Jan-: what I just pasted is the sender
07:39 PM Jan-: or at least the ISR for the sender
07:40 PM rue_bed: ok
07:40 PM rue_bed: send first then
07:40 PM Jan-: if you didn't want really precision timing or optional parity bits it would get a lot lot smaller
07:41 PM Jan-: by the way mark and space are inline
07:42 PM rue_bed: hah, I wonder if I have an interrupt version
07:43 PM Jan-: I am also going to sleep soon
07:43 PM rue_bed: https://pastebin.com/kk9nV7jk
07:44 PM Jan-: loop delayed, locked to 9600 baud
07:44 PM Jan-: pfft, I say again pfft :)
07:44 PM Jan-: mine can go at various speeds
07:44 PM rue_bed: aha
07:44 PM Jan-: though actually it has always been used at 9600 :)
07:44 PM rue_bed: ok hold on
07:46 PM Jan-: I hope mine isn't completely horrible
07:46 PM Jan-: I mean, it works
07:46 PM Jan-: and it has very accurate timing down to the basic clock rate of the cpu
07:47 PM rue_bed: https://pastebin.com/F9NvZKmd
07:47 PM rue_bed: better eh?
07:47 PM Jan-: would you be horribly offended if I said I couldn't really go through it all
07:48 PM Jan-: is it interrupt drivven#
07:48 PM rue_bed: scroll to bttom
07:48 PM rue_bed: the hander is at the bot.
07:48 PM rue_bed: the top is all the stuff to make it usefull
07:48 PM Jan-: I just searched on ISR
07:48 PM Jan-: heehee you did it in a switch case
07:49 PM Jan-: I just test what the bit index is
07:49 PM Jan-: but it's functionally the same approach
07:49 PM rue_bed: :)
07:49 PM Jan-: you end up needing 10 cases for 1 start, 8 data and up to 2 stop
07:49 PM Jan-: maybe more for parity and so on I'm not so sure
07:50 PM rue_bed: who uses parity?
07:51 PM Jan-: well it's in the options
07:51 PM Jan-: *shrug*
07:51 PM rue_bed: thats up there with using 7 data bits
07:51 PM Jan-: I found that the "modbus" protocol wanted parity set all the time but it might just have been using 2 stop bits which would look the same
07:51 PM rue_bed: or a buad rate of 1000000
07:51 PM Jan-: I need 115200 which is going to require efficient programming
07:51 PM Jan-: only 138 sys clocks per bit
07:52 PM rue_bed: yea, and what you gonna do with the data?
07:52 PM Jan-: nothing much there's usually only seven bytes of it and it only ever means "yessir."
07:52 PM rue_bed: why 115200?
07:52 PM rue_bed: k
07:52 PM Jan-: that's what the opendps firmware for the dps5005 power supply uses.
07:53 PM Jan-: sometimes you can get some more data if you ask for a full status report, it is mad and sends everything as ascii
07:53 PM Jan-: but even that's only a few dozen characters.
07:54 PM rue_bed: that first option is almost better at really high baud rates
07:54 PM rue_bed: yea, your locked into sending a char when your doing it, but, what else ya got to do?
07:54 PM Jan-: sorry what is
07:54 PM Jan-: oh well
07:54 PM rue_bed: that first code I posted
07:54 PM Jan-: it's an LED colour mixing light
07:54 PM rue_bed: with the delay loops
07:54 PM Jan-: so there might be quite some complicated maths going on to linearise everything and get the colour mixing right
07:55 PM Jan-: so it might be quite a big deal
07:55 PM * Jan- is not sure a little AVR is necessarily man enough for the job
07:55 PM rue_bed: 115200 is kinda silly
07:56 PM rue_bed: I have a serial rx for the t13, but not the t26
07:56 PM Jan-: eh well
07:56 PM Jan-: let's see if we can make it work
07:57 PM Jan-: I don't know if I'll have time to work on it over the weekend, but I hope I will, and I think I have a pretty decent understanding of how it needs to behave.
07:58 PM Jan-: anyway thanks I'm going to sleep now :)
07:58 PM rue_bed: https://paste.debian.net/1091413/
07:58 PM rue_bed: skim that first
07:58 PM Jan-: I can't skim
07:58 PM Jan-: you know that
07:58 PM Jan-: :)
08:00 PM Jan-: !!!PROCESSOR!!!!?
08:00 PM Jan-: also, are you actually in bed
08:00 PM rue_bed: yes
08:00 PM Jan-: you so smug
08:00 PM * Jan- pulls rue_bed out of bed by his foot
08:00 PM * Jan- climbs in
08:00 PM Jan-: Ahhhh.
08:01 PM rue_bed: hey hey
08:01 PM rue_bed: its 5' down...
08:01 PM * Jan- keeps rue_bed at bay with a sharp stick
08:01 PM Jan-: *jab*
08:01 PM * rue_bed hides under covers
08:01 PM Jan-: hey
08:01 PM rue_bed: *I just wanted a nap*
08:01 PM Jan-: personal space
08:02 PM rue_bed: !!!PROCESSOR!!!! <-- change this when porting to different processors
08:02 PM Jan-: oh hm.
08:02 PM * Jan- does not copypasta rue_bed's receiver code, or anything
08:02 PM rue_bed: tell me when you want the .h that goes with it
08:02 PM rue_bed: wait
08:02 PM rue_bed: did I post it on ...
08:02 PM rue_bed: oh my
08:02 PM Jan-: it's OK I would probably just steal all your ideas :)
08:02 PM rue_bed: I'm taking over the internet
08:02 PM Jan-: and redo it myself
08:03 PM rue_bed: it could be on my webpage, but it might be on github
08:03 PM rue_bed: google "rue_mohr"
08:03 PM Jan-: I don't need .h files anyway I write in the arduino ide
08:03 PM Jan-: :D
08:03 PM rue_bed: ... I'm taking over the internet... almost all those hits are me...
08:03 PM Jan-: it's an unusual name I guess.
08:03 PM rue_bed: mhm
08:03 PM Jan-: anyway my brain is starting to liquefy I have to sleep
08:04 PM Jan-: I've been up for 21 hours
08:04 PM rue_bed: I been online a loooooong time compared to... everyone
08:04 PM Jan-: thanks for all your help
08:04 PM rue_bed: ok
08:04 PM Jan-: I'll probably see you tomorrow if I can get some time to spend on this
08:04 PM rue_bed: I'm on and off
08:04 PM rue_bed: too much time on twitter and making things
08:04 PM rue_bed: (cause irc kinda died)
08:05 PM * Jan- makes room for rue_bed
08:05 PM * Jan- falls asleep
08:05 PM Jan-: *loud snoring*
08:05 PM rue_bed: ... why is my PPE still right here....
08:05 PM vmt: less twitter more code
08:05 PM * rue_bed puts muffs on
11:53 PM day__ is now known as day