#avr | Logs for 2015-08-28

Back
[01:58:14] <Jartza> morning
[06:41:16] <Lambda_Aurigae> morning Jartza
[06:53:11] <Emil_> Hey
[06:53:24] <Emil_> There's an Atmel application note
[06:53:52] <Emil_> ATMEL AVR134: Real Time Clock (RTC)
[06:53:57] <Emil_> Have any of you implemented this?
[06:55:57] <Lambda_Aurigae> I played with it years ago when I got my first atmega128.
[06:57:11] <LeoNerd> I'd probably use a real RTC chip if I wanted that
[06:58:51] <LeoNerd> Correction: I *am* using a real RTC chip because I *do* want that ;)
[06:59:10] <Lambda_Aurigae> same here.
[06:59:37] <Lambda_Aurigae> nice to have the battery backup on the RTC chip so it keeps running even when the CPU is down or busy doing something else like getting a flash update.
[06:59:38] <LeoNerd> Currently using a DS1307 but if I wanted a bit more precision I might try one of the temperature-compensated ones like the DS1323
[06:59:44] <LeoNerd> Yah.. the battery is good
[07:00:36] <Lambda_Aurigae> one board I have uses an ultracap to keep the RTC and NVSRAM chips live.
[07:01:15] <Lambda_Aurigae> another uses a coin cell battery for same function.
[07:01:33] <Lambda_Aurigae> both are 8052 processor based units though.
[07:05:46] <Emil_> The point is that I'd like to sleep for ~minute
[07:05:55] <Emil_> So I should just use the internal timing then
[07:06:11] <LeoNerd> If you want "about a minute" you can just use 60 seconds
[07:06:23] <LeoNerd> The RTC clocks are more for litearlly that; realtime. I.e. wallclock time
[07:06:48] <Emil_> Yeah, I know
[07:06:59] <Lambda_Aurigae> can use a 16bit timer with lots of prescaler.
[07:07:16] <Emil_> Yeah I have implemented sleeping and watchdog before
[07:11:49] <Emil_> And a question
[07:12:10] <Emil_> have you run atmega32u4@16MHz@3,3v?
[07:12:17] <Emil_> Does it run at all?
[07:12:20] <Emil_> Or unstable?
[07:12:34] <LeoNerd> Check the datasheet
[07:12:44] <LeoNerd> There's a graph showing acceptable frequency vs. supply voltage
[07:13:15] <Emil_> I know, but avr is very conservative (they have to be able to guarantee stuff)
[07:16:32] <Emil_> I'd rather not change the crystal (bough some pro micros from ebay)
[07:16:55] <Emil_> wait
[07:17:04] <Emil_> Could I software prescale the 16MHz to 8MHz?
[07:17:21] <Emil_> or is the problem with the pll or other circuitry?
[07:18:15] <Lambda_Aurigae> 32u4 should run at 16MHz at 3.3V just fine.
[07:18:21] <Lambda_Aurigae> that's smack in the middle of its range.
[07:19:48] <Emil_> Where did you find such a grpah? I can only find current consumption by voltage by frequency
[07:19:52] <Emil_> in the complete datasheets
[07:20:13] <Lambda_Aurigae> page 387 of the datasheet.
[07:20:16] <Lambda_Aurigae> hmm
[07:20:22] <Lambda_Aurigae> guess it won't run that fast at 3.3V
[07:20:42] <Lambda_Aurigae> it wants 4.5V for 16MHz.
[07:20:44] <Emil_> Yeah
[07:20:50] <Emil_> That's what I saw, too
[07:20:54] <Lambda_Aurigae> you can prescale the clock though.
[07:21:09] <Emil_> Are you sure it's page 387?
[07:21:31] <Lambda_Aurigae> 387 by the pdf counting
[07:21:35] <Tom_itx> u chips run at 16Mhz at ~5v
[07:21:36] <Emil_> That's the serial bus requirements
[07:21:39] <Lambda_Aurigae> 386 by the page numbering.
[07:21:42] <Emil_> ah
[07:21:46] <Lambda_Aurigae> section 29.6 maximum speed vs vcc
[07:21:55] <Emil_> Well, I'll be damndd
[07:21:56] <Lambda_Aurigae> just downloaded the datasheet.
[07:22:07] <Emil_> they had to go "maximum speed" instead of "maximum frequency :D
[07:22:37] <Emil_> Anycase, the attiny85 can be pretty safely software overclocked to ~32MHz
[07:22:47] <Lambda_Aurigae> yes.
[07:22:53] <Lambda_Aurigae> but different core and no usb peripheral.
[07:22:58] <Emil_> true
[07:23:05] <Lambda_Aurigae> I've clocked atmega1284p at 33MHz too.
[07:23:13] <Lambda_Aurigae> everything worked fine except for the ADC.
[07:23:21] <Emil_> But anycase, you are saying that I can just burn the fuse to prescale by 2
[07:23:23] <Lambda_Aurigae> ADC gave some really strange readings.
[07:23:58] <Lambda_Aurigae> there is a div/8 fuse.
[07:24:03] <Lambda_Aurigae> not sure about a div/2
[07:24:21] <Emil_> Yeah but isn't that div/x for the pll?
[07:24:32] <Lambda_Aurigae> but you can start up the div/8 and change that in software.
[07:24:44] <Lambda_Aurigae> I haven't done much with the ones with PLL though.
[07:24:53] <Lambda_Aurigae> and,,,I would love to stay and chat but gotta go to work.
[07:25:08] <Emil_> Hahah :D
[07:25:11] <Emil_> Okay, thanks!
[07:25:14] <Emil_> I'll see what works
[07:33:22] <Emil_> Another question!
[07:33:37] <Emil_> So far I have used the usbasp to program my things
[07:33:46] <Emil_> but the pro micro has an usb port
[07:34:53] <Tom_itx> Lambda_Aurigae work hell.. it's friday!
[07:40:27] <Emil_> So how do I program it now?
[07:48:49] <Tom_itx> 32u4?
[07:48:57] <Tom_itx> via DFU programmer or FLIP
[07:49:20] <Tom_itx> from the USB port
[07:49:23] <Emil_> Is there an easy get started guide?
[07:49:27] <Emil_> I'm reading the application note
[07:49:35] <Emil_> http://www.atmel.com/Images/doc7618.pdf
[07:49:39] <Tom_itx> 32u4?
[07:49:50] <Emil_> Yeah
[07:50:29] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_User_manual_index.php
[07:50:33] <Emil_> my environment is linux
[07:50:36] <Tom_itx> look at the firmware update section there
[07:50:43] <Tom_itx> that might help you get started
[07:50:53] <Tom_itx> apply changes where needed
[07:50:57] <Tom_itx> ie different chip
[07:51:23] <Tom_itx> To put the USBTinyMkii into DFU programming mode, push and hold the 'HWB' button. While the 'HWB' button is depressed press the 'RESET' button then release both.
[07:51:53] <Tom_itx> gnd the hwb pin then gnd reset together
[07:52:11] <Emil_> If the chip is completely empty I have to use the usbasp?
[07:52:21] <Tom_itx> they ship with a bootloader
[07:52:25] <Tom_itx> unless someone removed it
[07:52:41] <Emil_> there's an arduino bootloader
[07:52:47] <Tom_itx> gotta run
[07:52:56] <Emil_> Okay
[07:52:58] <Emil_> but thanks!
[07:53:03] <Emil_> That was good helP!
[16:39:36] <metRo_> hi all
[16:39:45] <metRo_> I have a problem on my pcb with an atmega328p
[16:39:50] <metRo_> the clock isn't ok
[16:39:56] <metRo_> and I can't find why
[16:40:00] <metRo_> since it worked before
[16:40:03] <metRo_> :s
[16:40:21] <metRo_> on other pcbs
[16:53:18] <metRo_> a simple uart program
[16:53:27] <metRo_> it send the data on time
[16:53:31] <metRo_> a 1s delay looks ok
[16:53:34] <metRo_> but the data isn't
[16:53:37] <metRo_> help me please
[16:54:03] <metRo_> i;m trying to send 0x55
[16:54:04] <Chillum> what are you using for a clock source?
[16:54:37] <metRo_> external clock
[16:54:42] <metRo_> I got 0xb5 on terminal
[16:55:43] <metRo_> Chillum: i'm using it http://pt.mouser.com/Search/ProductDetail.aspx?R=TSX-3225_16.0000MF09Z-AC3virtualkey64320000virtualkey732-TX325-16F09Z-AC3
[16:55:53] <metRo_> and I have been using it before with sucess
[16:56:00] <metRo_> success*
[16:56:09] <metRo_> 12pF capactiors
[16:56:28] <metRo_> _delay_ms(1000) keep it send the char at one second
[16:56:36] <metRo_> I going to try a pwm
[16:56:42] <metRo_> to see if it works ok
[16:56:49] <Chillum> no idea what is wrong then. Assuming the baud rate matches
[16:57:00] <Thrashbarg> and the fuses
[16:57:25] <metRo_> Low Fuse 0xFF High Fuse 0xDE Extended Fuse 0x05
[16:57:57] <metRo_> if I set the fuse for internal osc should I be able to test uart>
[16:57:58] <metRo_> ?
[16:58:55] <Thrashbarg> external clock or external crystal?
[16:59:04] <metRo_> Im using an external crystal
[16:59:05] <metRo_> sorry
[16:59:06] <Thrashbarg> ok
[16:59:12] <Thrashbarg> (a detail)
[16:59:16] <metRo_> tell me
[16:59:23] <metRo_> ah ok
[16:59:32] <metRo_> if i set the fuse for internal osc
[16:59:51] <metRo_> can I evaluate if the problem is my crystal or not, right?
[17:00:10] <Thrashbarg> I would expect so, assuming the UART speed works with the new value
[17:00:22] <Chillum> I tend to try to get a bare system working and then add to that
[17:00:38] <Chillum> if nothing is hooked up but the xtal and it is still a problem, then you have really narrowed it down
[17:00:46] <metRo_> I set INTRCOSC_8MHZ_6CK_14CK_65MS
[17:00:50] <metRo_> with 9600 baudrate
[17:00:59] <metRo_> baudrate prescaler is the same?
[17:01:25] <Thrashbarg> what crystal frequency are you running it at?
[17:01:31] <metRo_> 16mhz
[17:01:54] <metRo_> but now im trying with the internal oscilator
[17:02:25] <Thrashbarg> yeah so IIRC you change the baud rate value by -1?
[17:02:54] <Thrashbarg> to run at 8MHz
[17:02:58] <metRo_> #define BAUD_PRESCALLER (((F_CPU / (BAUDRATE * 16UL))) - 1)
[17:03:14] <Thrashbarg> ok so it's automatic :P
[17:03:20] <metRo_> ok
[17:03:27] <metRo_> tried with internal oscilator and it is working
[17:03:33] <Thrashbarg> ok so there's the problem :/
[17:03:55] <Thrashbarg> brb need to feed the cat lol
[17:04:52] <metRo_> my cap is eating my smd cap
[17:04:54] <metRo_> lol
[17:05:37] <Chillum> it in increase its catpacity
[17:05:58] <metRo_> so i'm using a 12pf
[17:06:05] <metRo_> should I try 20pf?
[17:06:08] <metRo_> less
[17:06:08] <metRo_> more?
[17:06:11] <aandrew> hm
[17:06:25] <Thrashbarg> I've gotten away without the capacitors... do you have the clock connected to anything else?
[17:06:41] <Thrashbarg> or can you check to make sure there are no shorts to other things
[17:06:50] <aandrew> attiny25 says it has 8MHz internal rc and an 8x PLL which defaults to the intrc source clock. does that mean that little bugger will do 64MHz CPU clock?
[17:06:56] <metRo_> could the PCB proprietaries from one version to other to change it?
[17:06:56] <Chillum> without caps, or with the wrong caps it will sometimes work but fail unpredictably
[17:07:10] <aandrew> the datasheet goes on to show that 20MHz is pretty much it and only at 5V
[17:07:26] <Thrashbarg> Chillum: true. Depends on the layout, given the tiny capacitances
[17:07:50] <metRo_> Thrashbarg Chillum the clock signal is connect to the xtal only
[17:07:55] <metRo_> without any short
[17:08:30] <Thrashbarg> try a different ATmega?
[17:09:13] <metRo_> i'm going to try with other board
[17:09:21] <Thrashbarg> ok
[17:21:28] <metRo_> Thrashbarg: same result
[17:21:36] <metRo_> im going to try another caps
[17:21:41] <Thrashbarg> ok
[17:22:00] <metRo_> should I increase the value?
[17:22:47] <Thrashbarg> sure, the datasheet says 12-22pF
[17:28:21] <metRo_> Thrashbarg: another test before change caps and it is working at 9600
[17:28:29] <metRo_> at 115200 it isnt working
[17:28:33] <Thrashbarg> ahh
[17:28:40] <metRo_> lets hope it works with bigger caps
[17:28:48] <metRo_> and lets hope I have them at home
[17:29:06] <Thrashbarg> wait if it's working at 9600 and not at 115200, that'd suggest the baud rate error calculated from the crystal is too great
[17:29:13] <metRo_> the only diferent before previous version of the PCB was the factory house
[17:29:53] <metRo_> so doesnt it mean the problem is at cap?
[17:30:10] <metRo_> sorry my english :/
[17:30:10] <Thrashbarg> sure sounds it
[17:30:17] <metRo_> ah ufa
[17:32:06] <Jartza> evening
[17:32:33] <Thrashbarg> you're running on a 16MHz clock, the prescaler is 16 on the UART, so the UART runs at 1MHz. You're asking for 115.2kHz... actual speed is 125k
[17:32:37] <Thrashbarg> way out
[17:33:31] <Jartza> aandrew: nope, attiny25 can't run @64MHz, if you want to run cpu from internal pll, there's prescaler /4
[17:33:43] <Jartza> but it means you can run it @16Mhz without oscillator
[17:34:09] <Thrashbarg> whereas at 9600 bps the actual speed is 9615, so that's more tolerable
[17:34:17] <Jartza> ...and actually even 20Mhz if you "calibrate" the oscillator a bit higher (or even >20Mhz, but that's against the specs)
[17:40:32] <aandrew> Jartza: my fuses are set for intrc, PLL, *no* prescaler (the fuse is for /8 though, are you referring to something else?)
[17:44:20] <metRo_> Thrashbarg: soldering 18pf caps
[17:44:40] <metRo_> cross fingers
[17:48:36] <Jartza> aandrew: if you set your cpu clock to PLL, it'll always use /4 of PLL
[17:48:48] <Jartza> and the internal RC is always 8Mhz
[17:49:05] <Jartza> the PLL is internal RC * 8 divided by /8 fuse (if set)
[17:49:38] <Jartza> so in other words, if you disable the /8 fuse, the PLL will be 64MHz and if you set your CPU to use PLL, then it'll be 64MHz / 4
[17:50:46] <Emil_> Jartza: Eh?
[17:51:02] <Jartza> https://www.dropbox.com/s/8s2gs13noa7rgp0/Screenshot%202015-08-29%2001.27.41.png?dl=0
[17:51:13] <Emil_> You can also disable the /4 and run it at 32MHz
[17:51:39] <Jartza> can, but shouldn't :)
[17:51:45] <Jartza> if you want to run within specs
[17:51:55] <metRo_> Thrashbarg: still the sameee
[17:51:59] <metRo_> :(
[17:52:34] <Thrashbarg> metRo_: I did say the baud rate will be too wrong to run at 115200 bps because it doesn't divide into 16MHz with accuracy
[17:52:46] <Emil_> Eh
[17:52:56] <Emil_> "If you want to run within specs then you can't do it
[17:53:03] <metRo_> Thrashbarg: so what you would suggest to correct this?
[17:53:15] <metRo_> but I have run it with 115200 a lot of time with success
[17:53:20] <metRo_> :s
[17:53:57] <Jartza> Emil_: yes. the specs say max. speed 20Mhz
[17:54:10] <Thrashbarg> well if you want to make sure the thing is running at all, you can connect an LED through a resistor from +5V to the UART TxD pin and program it to spit out characters continually
[17:54:15] <Thrashbarg> if the LED lights, it's transmitting
[17:54:27] <Thrashbarg> or better still use a logic probe or oscilloscope
[17:54:36] <Jartza> I'm no mathematician, but I'm pretty sure 32Mhz is "over 20Mhz"
[17:54:53] <Emil_> Jartza: you are completely missing my point
[17:55:07] <metRo_> Thrashbarg: it is transmitting
[17:55:09] <Emil_> Attiny is stable at 32MHz
[17:55:16] <Emil_> And works well
[17:55:20] <metRo_> but I'm sending out 0x55
[17:55:29] <metRo_> and it receives 0xA5 sometimes
[17:55:31] <Jartza> Emil_: I'm not missing. I said "you could"
[17:55:38] <metRo_> or 0xB5
[17:55:42] <metRo_> othertimes
[17:55:46] <Jartza> depends of course, what you want to do with the chip.
[17:55:46] <Thrashbarg> metRo_: that'd be the difference in buad rates at work
[17:56:06] <Jartza> if you're just fooling around, sure you can overclock all the chips you get into your hands :)
[17:56:06] <Thrashbarg> the terminal expects 115200, the ATmega is transmitting something different, so the bits only line up a little
[17:56:44] <metRo_> Thrashbarg: but why is it happening if it never happened before within this project :s
[17:56:52] <Jartza> still it's against the specs and not recommended by manufacturer.
[17:57:20] <Thrashbarg> metRo_: not sure, I don't know what you're doing in detail :P
[17:57:21] <Jartza> so if you want something long living, I suggest to stay within specs
[17:57:45] <metRo_> the same components,turns out it was the same pcb manufacture
[17:57:49] <Jartza> and if the chip is not enough, get a bigger chip :)
[17:58:31] <Thrashbarg> metRo_: if you can find a baud rate crystal to try it you might have better results
[17:58:40] <Jartza> attiny[248]5 can do a lot with 20Mhz
[17:58:48] <Thrashbarg> metRo_: also you might've been doing something differently to what you're doing now, without knowing
[17:58:57] <metRo_> what is a baudrate crystal?
[17:59:10] <Thrashbarg> metRo_: a crystal that divides evenly into common baud rates
[17:59:32] <metRo_> I thought 16mhz was one of that
[17:59:36] <Thrashbarg> no
[17:59:44] <Thrashbarg> 18.432MHz is
[18:00:04] <Jartza> yeah
[18:00:17] <Jartza> called "the phone company oscillator"
[18:00:18] <Jartza> :P
[18:00:23] <Thrashbarg> heh
[18:00:25] <metRo_> do you think i'll have more success with 57600?
[18:00:53] <metRo_> I can't change the crystal
[18:01:00] <metRo_> so I need to change the baudrate
[18:01:10] <Thrashbarg> metRo_: you know 9600 works, so try 19200, 38400, 57600
[18:01:20] <Thrashbarg> see how highi it'll go without error
[18:01:23] <Thrashbarg> *high
[18:01:25] <aandrew> Jartza: hm, I must read the datasheet again
[18:01:27] <aandrew> thank you
[18:01:54] <Jartza> no prob
[18:02:07] <Jartza> believe be, I've read attiny25/45/85 datasheet quite a lot :D
[18:02:13] <Jartza> me*
[18:02:26] <aandrew> yeah I don't doubt that at all
[18:03:17] <Jartza> I actually made this small piece of code which sets the chip to internal PLL and then uses UART @ 9600bps as a reference and calibrates the chip to 20MHz :)
[18:03:40] <Thrashbarg> neat
[18:03:44] <Jartza> because "I had an idea". unfortunately the internal RC has that much jitter it can't be used for VGA
[18:03:49] <Jartza> but the idea was nice
[18:03:54] <Thrashbarg> haha yea
[18:04:19] <Jartza> could still be useful, if you want to run the chip @20Mhz without ext.clock
[18:04:23] <Thrashbarg> I made a ZX81 but didn't have a 6.5MHz crystal, so I used an RC oscillator... lots of jitter on the screen
[18:04:34] <Jartza> yea
[18:04:44] <Thrashbarg> eventually got a 6.5536MHz crystal, close enough
[18:05:49] <Lambda_Aurigae> Jartza, so, it failed on internal rc oscillator, eh?
[18:06:37] <metRo_> Thrashbarg: it is working at 57600
[18:06:55] <metRo_> grhhh
[18:07:08] <metRo_> it have been working for a year
[18:07:13] <metRo_> new pcb and kaboomm
[18:07:14] <metRo_> :s
[18:07:24] <Thrashbarg> you might want to let it run for a bit to make sure there are no errors
[18:07:29] <Thrashbarg> yeah :/
[18:07:55] <Jartza> Lambda_Aurigae: well, it works, but lot of jitter
[18:08:17] <Jartza> got the picture and colors, but not just stable enough
[18:08:24] <Lambda_Aurigae> can imagine.
[18:08:51] <Lambda_Aurigae> it's not stable enough for long term serial comms...vga is much more sensitive.
[18:09:11] <Lambda_Aurigae> metRo_, you need to figure out what is different between the two boards.
[18:10:12] <metRo_> Lambda_Aurigae: none in that part of the pcb
[18:10:23] <metRo_> I have made 20pcbs and all have that problem
[18:10:31] <Lambda_Aurigae> then something has changed.
[18:10:33] <metRo_> all the pcbs I have made before working ok
[18:10:50] <Jartza> Lambda_Aurigae: but the good news. all three colors have stayed in sync for like 10 days now
[18:10:55] <Jartza> and I only sync them at boot
[18:11:08] <Lambda_Aurigae> that's good.
[18:11:15] <Lambda_Aurigae> that's on the one with the oscillator, yes?
[18:11:20] <Jartza> yeah
[18:12:19] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxNXZ5VHZ1eUFEMWc/view?usp=sharing
[18:12:21] <Jartza> this one :)
[18:12:38] <Lambda_Aurigae> nice little board.
[18:12:39] <Jartza> 10 minute board "design" and home etched
[18:12:56] <Lambda_Aurigae> should be able to make it 1/4 that overall size if you use smt components.
[18:13:00] <Jartza> just wanted something a bit more reliable than breadboard
[18:13:10] <Jartza> yeah, the final PCB will be arduino compatible shield
[18:13:14] <Lambda_Aurigae> it's impressive that it works on breadboard though.
[18:13:16] <Jartza> (which can of course be used without arduino too)
[18:13:45] <Thrashbarg> I'll be doing the same today, making a PCB of a project.... though I'm not using anything to hold it together at the moment except solder :/
[18:13:46] <Jartza> or nucleo...
[18:14:05] <Lambda_Aurigae> hmmm..
[18:14:08] <Lambda_Aurigae> deadbug it Jartza !!!
[18:14:18] <Jartza> hehe
[18:14:34] <Thrashbarg> never squash a deadbug.... tends to hurt
[18:14:38] <Lambda_Aurigae> stack the attiny chips and pull out the pins that don't cross connect.
[18:14:44] <Jartza> I was wondering today, what is deadbugging called when you don't turn over the chip? :)
[18:14:55] <Jartza> bug torturing?
[18:14:59] <Lambda_Aurigae> to me deadbugging is wiring it without any board.
[18:15:13] <Lambda_Aurigae> just use the chip as the center and build from there.
[18:15:20] <Jartza> yeah, but the term comes from the chip being upside down, legs up
[18:15:28] <Thrashbarg> yea
[18:16:41] <metRo_> Thrashbarg: change it to 76.8k
[18:16:52] <Jartza> let's see if I have time to write the blog post finally on weekend
[18:16:56] <metRo_> looks like it is the highest baud rate for 16mhz with low error
[18:17:00] <metRo_> it is working
[18:17:06] <Jartza> we had some hard time at customer this week :)
[18:17:15] <Jartza> small bug in board
[18:17:57] <Jartza> byebye 200 boards... 10 layers, 3/3mil, populated with a LOT of wlcsp chips and stuff
[18:19:13] <Jartza> https://www.dropbox.com/s/oz10nngpubfy3ye/MOV_0442.mp4?dl=0
[18:19:23] <Jartza> for those who haven't seen the attiny85 vga yet :)
[18:21:10] <aandrew> Jartza: ouch
[18:21:19] <aandrew> Jartza: I'm always nervous as hell when we get a new board in
[18:21:30] <Jartza> well. they worked nicely for like 5 days
[18:21:42] <Jartza> two teams used them for developing
[18:21:45] <aandrew> especially when you start getting dense like that when there's a small problem it's not always blue-wire-fixable
[18:21:52] <Jartza> both teams have their own cpu on board :)
[18:22:08] <Jartza> then we finally got the cpu-to-cpu communication protocol implemented
[18:22:22] <Jartza> and well.. two teams debugged why it doesn't work
[18:22:35] <Jartza> after half an hour, two teams wondered why nothing works
[18:22:53] <Jartza> just a teeny bug in level shifter, voltages were wrong way around
[18:23:14] <Jartza> aandrew: yeah, these boards aren't fixable
[18:23:31] <Jartza> now the cpus are also gone
[18:31:23] <Jartza> but well. sleepy time! night all!