Back
[00:10:38] <SWPadnos> hmmm - actually, FEC for a full byte should be only 11 or 12 bits total - the implementation I've used before was to send two nibbles separately, which required 7 bits per nibble (but could correct one bit errors per nibble, not per byte)
[00:55:26] <jepler> does the percentage required for FEC decrease when you do more than one bit at a time? I thougt that 72 bits was enough to do SEC/DED on 64 bits of data (parity RAM)
[00:56:26] <SWPadnos> ECC will also only correct one-bit errors, and detect 2-bit errors (across the 64-bit word)
[01:08:43] <jepler> if I do a proof-of-concept in the next few days, I think I'll do it with CRC-16 -- it looks like avr-libc has a version already included.
http://www.nongnu.org/avr-libc/user-manual/group__util__crc.html
[01:09:39] <SWPadnos> I can give you an asm version of CRC-32 that's table-driven
[01:09:58] <SWPadnos> it uses 512 bytes of space for the table, plus ~30 words for the code (maybe less)
[01:09:59] <jepler> only if you have it handy
[01:13:38] <SWPadnos> I'll take a look - I know I have it around
[01:14:23] <SWPadnos> it's a bit big for a tiny, but it's fine on any mega or "normal" AVR with sufficient code space (and the LPM instruction)
[01:15:47] <SWPadnos> oh yeah - I thought of a way to do the data passing in HAL
[01:16:01] <SWPadnos> actually, I think I may have just been remembering previous discussions on the topic
[01:16:26] <SWPadnos> basically, describe the packet with a string insmod parameter
[01:16:38] <jepler> yeah -- and that's been done several times now, in sampler and streamer
[01:16:49] <SWPadnos> we're still talking about bits and bytes
[01:16:51] <SWPadnos> yep
[01:21:18] <jepler> here are the easy ones: signed/unsigned, width in bits, extend-to-32-bits, convert to float
[01:21:38] <jepler> the hard one is "how do you do an encoder with index pulse"
[01:26:52] <SWPadnos> I don't know that you can
[01:27:19] <SWPadnos> you can send the index pulse bit, and you can send the delta from the last update
[01:27:41] <SWPadnos> maybe if there's an index pulse, the delta becomes an absolute xbalue
[01:27:43] <jepler> you'd latch the index pulse and on the receiving side it would not do the normal sign extending
[01:27:43] <SWPadnos> value
[01:28:00] <SWPadnos> I think we saidthe same thing?
[01:28:04] <jepler> yeah I think so
[01:28:09] <jepler> but if you happen to lose that particular packet...
[01:28:15] <SWPadnos> yer screwed
[01:28:22] <jepler> the way emc uses the index pulse for threading, that's OK
[01:28:28] <jepler> but for homing it would be bad
[01:28:37] <SWPadnos> that's why I like the idea of a packet sequence number. if that's wrong, you have a real problem
[01:29:31] <SWPadnos> well, remember that the servo period is normally 1ms, so if we're talking about a 1ms packet rate, it's going to be mostly the same
[01:30:35] <SWPadnos> so the problem there is that things that should be internal to the driver become external, because they're exported as HAL pins by the packet driver
[01:30:48] <SWPadnos> and onnected to HAL pins for hte hardware "interpreter"
[03:35:44] <jtr> jtr is now known as jtr_
[15:56:16] <alex_joni> hope that does the trick
[15:57:00] <alex_joni> * alex_joni sighs .. bbl
[16:02:19] <SWPadnos> we can link chat.freenode.net to the irc.freenode.net dir, if chat will be more reliable for the logger
[16:03:16] <SWPadnos> jepler, I think the baud rate will be dependent on the reference clock more than the chip type
[16:03:46] <jepler> SWPadnos: but it looks like the 1.8mumbleHz clock is standard on PCs
[16:03:51] <SWPadnos> most PCs don't change the 1.194304 MHz clock
[16:04:06] <SWPadnos> oh - the 1.8432 MHz clock - right
[16:04:58] <jepler> SWPadnos: but yes, I was being inexact -- it's the clock that the 16550 uses, not some property of the chip itself.
[16:05:03] <SWPadnos> but it's possible that a 16450 or a6550 has the ability to do something like the "fast mode" on an AVR, where it uses a /8 divider instead of /16
[16:05:08] <SWPadnos> right
[16:06:59] <SWPadnos> I think the other chips mentioned are just multi-channel versions of the 16550 (the 16850 and 16950)
[16:08:28] <jepler> "setserial -a /dev/ttyS0" shows me that baud_base is 115200 -- which I believe indicates that 115200 is the highest baud rate linux thinks is available.
[16:08:32] <jepler> baud_base baud_base
[16:08:34] <jepler> This option sets the base baud rate, which is the clock fre-
[16:08:37] <jepler> quency divided by 16. Normally this value is 115200, which is
[16:08:40] <jepler> also the fastest baud rate which the UART can support.
[16:09:24] <SWPadnos> hmmm. if I get a chance today, I'll install my multiport serial card and see what Linux tells me
[16:09:47] <SWPadnos> I know it can do either 460.8k or 921.6k
[16:09:51] <alex_joni> right.. on onboard serials I can't set more than 115200 on doze either
[16:10:10] <alex_joni> only the USB plugged stuff can do better
[16:12:26] <SWPadnos> I have a ByteRunner card that can, but I'm not sure what setserial will say about it
[16:14:59] <owhite> test
[16:15:06] <SWPadnos> error
[16:15:18] <owhite> would anyone here be able to answer a tkemc programming question?
[16:15:41] <SWPadnos> it's possible, but the real expert (who wrote it) isn't here at the moment
[16:15:51] <owhite> got it.
[16:16:31] <owhite> tkemc has radio buttons on the side, and I'd like to re-use them to launch other programs, like C executables. looking for suggestions.
[16:16:39] <owhite> ...a way to make shell calls basically.
[16:16:52] <SWPadnos> exec [your shell call]
[16:17:05] <SWPadnos> do you have emc or emc2?
[16:17:08] <owhite> emc2
[16:17:31] <SWPadnos> ok, take a look at the halshow script - that executes halcmd to do all the dirty work
[16:18:10] <SWPadnos> the main thing you need to be careful of is that tcl/tk deals with command line arguments differently from the way yo'd expect the shell to
[16:18:23] <owhite> would it be obvious where in tkemc where halcmd is used?
[16:18:42] <owhite> not finding it with a string search.
[16:18:42] <SWPadnos> I thikn there's a function with "halcmd" as part of the name :)
[16:18:58] <owhite> noper.
[16:19:02] <SWPadnos> hmmm - do_hal_cmd (or command) ?
[16:19:12] <SWPadnos> this isn't in tkemc, it's in halshow
[16:19:40] <owhite> ah. well there looks like there are exec commands in tkemc that I could at least start with.
[16:19:57] <owhite> what be the relationship between tkemc and halshow?
[16:20:17] <owhite> (bearing in mind that I'm happy to start poking around in the code and docs and not take up a lot of your time)
[16:20:21] <alex_joni> owhite: they are both written in tcl
[16:20:28] <SWPadnos> I think there's a menu item in tkemc called something like "Show HAL"
[16:20:27] <alex_joni> but that's about it :)
[16:20:36] <SWPadnos> written mostly by the same guy, too :)
[16:20:42] <alex_joni> :-P
[16:20:57] <alex_joni> yeah, ray added that.. but I added a menu entry at some point too :P
[16:20:57] <owhite> got it, the point being I could look at halshow and see how it does exec commands.
[16:21:06] <SWPadnos> right
[16:21:15] <alex_joni> yes, or grep through tkemc and see how it calls halshow
[16:21:24] <owhite> got it.
[16:21:25] <alex_joni> would it be bad to have it bound to the menu?
[16:21:31] <owhite> * owhite greps.
[16:21:43] <alex_joni> that's way simpler than instead of the check boxes
[16:21:57] <SWPadnos> halshow.tcl is in the tcl/bin directory
[16:22:29] <SWPadnos> hmmm - you won't want to look there ;)
[16:22:44] <SWPadnos> I forgot that we changed it to use a pipe instead of separate execs :)
[16:23:09] <owhite> I'm liking the check boxes for my application. I'd like tkemc to run an exec on a usb-controlled relay box. the relays connect to ventilation of my machine.
[16:26:43] <SWPadnos> a google search, or possibly a manpage, will tell you how to use exec
[16:27:13] <SWPadnos> you then need to fire an event whenever a checkbox gets checked or unchecked
[16:27:22] <christel> [Global Notice] Hi again! I'm afraid we jumped the gun a bit too early, the network is not under a DDoS attack, it appears one of our staffers found a bug in our ircd. We should be all set and good now. Thank you for using freenode and have a good day.
[16:27:28] <alex_joni> those are radio buttons
[16:27:29] <SWPadnos> and in that event, you use exec to run the USB control doohickey
[16:27:33] <SWPadnos> oh
[16:28:00] <alex_joni> so maybe selecting one and pushing a button is what you want
[16:28:35] <jepler> checkbutton .c -variable checkbutton_state -command { exec shell-command $checkbutton_state }
[16:28:56] <owhite> got it. stuffing "exec ls" into this....
[16:29:09] <owhite> set radiorel [radiobutton $coordsel.rel -text [msgcat::mc "relative"] -variable coords -value relative -command {"exec ls"} -takefocus 0]
[16:29:21] <owhite> was not appreciated by the interpretter.
[16:29:47] <jepler> {"exec ls"} won't work, it's too much quoting
[16:30:24] <jepler> but even after you remove the extra "", you won't see the output, because tcl's exec gives the stdout of the shell command as the result -- it's a bit like popen() in C
[16:30:25] <owhite> * owhite hacks.
[16:30:46] <owhite> yeah, I'll have it write a file or something.
[16:31:20] <jepler> checkbutton .c -variable checkbutton_state -command { exec echo $checkbutton_state > /dev/tty }
[16:31:36] <jepler> this variation will let you see the output on the terminal
[16:31:42] <owhite> bim badda boom.
[16:31:47] <owhite> so very nice.
[16:33:14] <owhite> jeepers I thought this was going to be hard.
[16:33:41] <owhite> I guess I'll ask another question then...
[16:33:51] <jepler> go ahead
[16:34:19] <alex_joni> jeepers creepers, where'd ya get those peepers?
[16:34:36] <SWPadnos> thank you, Mel Torme
[16:34:47] <owhite> I know this is going to get me into trouble....I use a pico systems UCS board. how hard would it be to drive the i/o pins by gcode commands?
[16:35:15] <owhite> nah. check that. I know that's a pretty unspecific question.
[16:35:23] <SWPadnos> not too hard. unless you have both flood and mist coolant on your machine
[16:35:52] <alex_joni> owhite: would M commands be ok?
[16:35:58] <owhite> yah. actually I've been using flood and coolant. I think there are a couple other i/o pins though.
[16:36:03] <owhite> m commands are fine.
[16:36:06] <SWPadnos> you can also yse M1xx codes to do this
[16:36:17] <alex_joni> a simple M-code script which does 'halcmd sets signal 1'
[16:36:29] <SWPadnos> or an m-code that runs the USB relay board program
[16:36:33] <alex_joni> M101 P1 to set it on M101 P0 to turn off
[16:36:33] <owhite> ooh. that sounds interesting.
[16:36:52] <alex_joni> owhite: in your ncfiles folder (specified in the ini) there are 2 example M-codes
[16:37:11] <alex_joni> M100+ are for the user, if there is such an executable file
[16:37:15] <alex_joni> e.g. M101.sh
[16:37:25] <SWPadnos> jus tM101
[16:37:27] <SWPadnos> no sh
[16:37:30] <owhite> would anyone mind pointing to the best place to look at M-code to halcmds? is that in Hal_Documentation.pdf I got?
[16:37:32] <SWPadnos> or M102,c
[16:37:37] <SWPadnos> err M102.c
[16:37:38] <alex_joni> err.. no .sh
[16:37:42] <owhite> wow. that should be a great start.
[16:38:01] <owhite> I'd like to look around before using up my budget of questions. :-)
[16:38:02] <alex_joni> owhite: look at /usr/local/emc2/ncfiles/M101
[16:38:09] <jepler> owhite: the documentation doesn't really spell it out
[16:38:14] <owhite> very cool.
[16:38:37] <alex_joni> if that file exists when emc2 starts up, and it's executable then it gets added to emc2 list of M-codes
[16:38:46] <jepler> owhite: basically, you can manipulate the value of a HAL signal with 'halcmd sets'. To manipulate a pin in the same way, connect it to a dummy signal with no writer, and use 'sets'
[16:38:46] <alex_joni> similarly you can create M102-M199
[16:39:10] <owhite> wow. that is so nice.
[16:39:23] <alex_joni> owhite: say you want to turn the pin ppmc.0.digital-output-10 on/off
[16:39:32] <owhite> * owhite listens intently.
[16:39:34] <alex_joni> you probably know the correct name of the pin
[16:39:36] <jepler> you can pass 2 values to an m1xx script: P- and Q-
[16:39:38] <alex_joni> * alex_joni doesn't ;)
[16:39:51] <alex_joni> halcmd newsig pin1 bit
[16:39:57] <owhite> you get to blab away because you are an elder. :-)
[16:40:06] <alex_joni> linksp pin1 ppmc.0.digital-output-10
[16:40:10] <alex_joni> sets pin1 1
[16:40:25] <alex_joni> now the pin on the USC should be turned on
[16:40:29] <alex_joni> sets pin 0
[16:40:31] <alex_joni> now the pin on the USC should be turned off
[16:40:40] <alex_joni> sets pin1 0 of course ;)
[16:40:41] <owhite> what's the linksp about ?
[16:40:47] <alex_joni> link signal to pin
[16:40:57] <jepler> alex_joni: how's the support for M62..M65 in 2.0.x? Was it not yet implemented?
[16:40:59] <alex_joni> we first defined a signal called pin1 of the type bit
[16:41:05] <alex_joni> jepler: I think it was there
[16:41:19] <alex_joni> M64/M65
[16:41:25] <alex_joni> that's another way of doing it
[16:41:27] <owhite> that is so unbelivablyabsopurbly useful.
[16:41:55] <alex_joni> owhite: we got more ;) as jepler reminded me there are some special inputs/outputs from the motion controller
[16:42:03] <jepler> http://linuxcnc.org/docs/html/gcode/main/#sec:M62-to-M65:
[16:42:05] <alex_joni> which you can turn on/off with M64 and M65
[16:42:54] <alex_joni> M62/M63 are for example to turn a laser on just before the move starts
[16:43:08] <owhite> yah I have a laser.
[16:43:16] <owhite> I've been using um....
[16:43:31] <alex_joni> oh, then M62/M63 is probably what you want
[16:43:34] <owhite> M05 and M09.
[16:43:39] <jepler> the HAL pins that those control are called motion.digital-out-NN
[16:43:52] <owhite> right.
[16:43:55] <alex_joni> M62 P1 would turn motion.digital-out-01 on
[16:44:01] <alex_joni> M63 P1 would turn motion.digital-out-01 off
[16:44:31] <alex_joni> you need then (or even before that) to link the motion.digital-out-01 pin to one pin on the USC
[16:44:47] <alex_joni> linkpp motion.digital-out-01 ppmc.0.digital-out-17
[16:44:54] <alex_joni> linkpp links pin to pin
[16:44:56] <owhite> thing is I have a laser chiller, the laser power supply, and now I'm installing ventilation.
[16:45:27] <owhite> sort of running out of I/O control. thought I'd buy a separate USB-relay board, and control using that.
[16:45:40] <owhite> do you think M-codes could drive something out the serial or USB?
[16:45:49] <owhite> that would be really great.
[16:45:57] <alex_joni> owhite: you can hack something to do that
[16:46:01] <alex_joni> how about parport?
[16:46:08] <jepler> how are you at C programming? You can write a "userspace HAL component" to hook the USB device up to emc's HAL
[16:46:10] <alex_joni> sorry.. disregard that :)
[16:46:10] <owhite> parport is taken by my UCS card.
[16:46:18] <alex_joni> owhite: just realized that :D
[16:46:40] <alex_joni> jepler: even a simple program to toggle a bit would be enough
[16:46:49] <alex_joni> and triggered by an M1xx code
[16:47:24] <jepler> alex_joni: yes, but if you have your USB relays hooked to HAL you can start doing things like run them based on ladder logic
[16:47:31] <owhite> I can write in C, but I'd be more comfortable just making C-code that worked on the command line.
[16:47:39] <alex_joni> jepler: sure.. but it's a bit more work
[16:47:45] <owhite> then calling the command line operations from the M-codes.
[16:48:06] <owhite> easy to test for me.
[16:48:07] <alex_joni> owhite: that's probably the simplest/most trivial solution
[16:48:16] <alex_joni> but it doesn't offer much flexibility lateron
[16:48:28] <alex_joni> owhite: emc2 has an integrated PLC
[16:48:36] <owhite> mm-hm.
[16:48:41] <alex_joni> which you could set up to drive your IO automagically
[16:48:46] <owhite> I saw that in the docs but didnt quite get it.
[16:48:55] <alex_joni> like : if laser-on more than 10 msecs, turn on chiller
[16:49:00] <alex_joni> and so on..
[16:49:16] <alex_joni> after laser off, wait 1 minute, turn off chiller
[16:49:32] <owhite> but is that the same thing as going with the M-codes or a different approach?
[16:49:42] <alex_joni> different approach
[16:49:50] <alex_joni> basicly this would all happen by itself
[16:49:57] <alex_joni> if set up appropiatedly
[16:50:09] <alex_joni> so you wouldn't have to worry about g-codes which doesn't include it
[16:50:12] <SWPadnos> kind of like an auto-lube system
[16:50:34] <owhite> wow.
[16:50:35] <alex_joni> owhite: of course this can only happen if you can define some rules
[16:50:44] <owhite> where should I start reading up?
[16:50:56] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Sample_HAL_And_ClassicLadder
[16:50:58] <SWPadnos> you can also run a PID, if you have a temperature sensor
[16:51:18] <alex_joni> or rather
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?LadderProgramming
[16:51:32] <alex_joni> that's a poor excuse of a intro to ladder programming page ;)
[16:51:51] <owhite> holy crap!
[16:52:06] <owhite> which one of you freaks made all that documentation?
[16:52:25] <alex_joni> owhite: I think about 20% of the stuff is actually documented :(
[16:52:39] <alex_joni> maybe 40% to be optimistic :P
[16:52:39] <owhite> * owhite has lots of programmers working for him, knows how it goes when it comes to getting them to write docs.
[16:52:51] <alex_joni> we all feel that way :)
[16:52:53] <SWPadnos> and we're just playing, so it's even harder ;)
[16:53:37] <alex_joni> owhite: the first place to look is inside your EMC2_User_manual
[16:53:50] <alex_joni> it should be installed along with emc2 in the menu (if you're running Ubuntu)
[16:53:55] <owhite> darn I was really hoping not to get rtfm-ed.
[16:53:58] <owhite> :-)
[16:54:10] <alex_joni> what's not there might be here:
http://linuxcnc.org/docs/html/
[16:54:22] <SWPadnos> well, you don't expect us to do *everything* for you, do you? :)
[16:54:22] <alex_joni> and there's some stuff in the wiki:
http://wiki.linuxcnc.org/
[16:54:36] <alex_joni> owhite: how about wtfm ?
[16:54:43] <SWPadnos> slam!
[16:54:54] <alex_joni> at least the missing bits :P
[16:54:58] <SWPadnos> heh
[16:55:25] <owhite> so if I go this route, do I start hacking on the univstep_load.hal? or does that get left alone?
[16:55:40] <SWPadnos> that's up to you
[16:55:47] <alex_joni> owhite: you probably want to look at the stepper_cl example
[16:56:02] <SWPadnos> if you want to add a separate hal file for this, you just need to name it in the 'HAL' section of the ini file
[16:56:18] <SWPadnos> or if you prefer to do it all in one file, then that's good, too
[16:56:21] <alex_joni> then integrate some stuff from there either in one of the existing .hal's or into a new one
[16:56:34] <alex_joni> I think a new file would make it easier to upgrade lateron
[16:56:48] <alex_joni> just replace the stock .hal file with the new .hal files
[16:57:03] <owhite> sample-configs doesnt have a stepper_cl, was that a typo ro stepper_hal?
[16:57:23] <owhite> s/ro/for/
[16:57:29] <alex_joni> demo_step_cl I think
[16:57:44] <alex_joni> yup.. that should be the name
[16:58:50] <owhite> okay. now lemme axe something...
[16:59:03] <owhite> * owhite scrolls up and reads.
[16:59:06] <SWPadnos> ace away
[16:59:08] <SWPadnos> axe
[16:59:54] <owhite> hm. sorry if you've covered this already.
[17:00:17] <owhite> ...but I can use the PLC to make exec calls? I think the way I'd like to do this is...
[17:00:25] <SWPadnos> no
[17:00:29] <SWPadnos> I don't think so
[17:00:30] <owhite> oh.
[17:00:51] <owhite> so if I have a USB-to-relay board how should I drive that? m-codes?
[17:01:02] <SWPadnos> there's another part to the PLC scenario - the userspace HAL component you write to control the USB relay board
[17:01:20] <alex_joni> owhite: you can either hack M-codes to control the USB board directly
[17:01:40] <alex_joni> or write a "driver" .. basicly an application which reads/writes to the USB board and exports some HAL pins
[17:01:43] <SWPadnos> that can just use exec, but there needs to be something that acts as the glue between HAL pins and the USB controller software
[17:01:55] <alex_joni> those HAL pins you can then link to the PLC or to any other HAL pins
[17:01:59] <SWPadnos> yes
[17:02:43] <owhite> well, you're definitely talking a new language to me, so let me start reading up on things and see if I can put this all together.
[17:02:59] <owhite> I dont like taking up a lot of bandwidth with questions I can answer myself.
[17:03:10] <owhite> ...well, eventually...maybe. :-)
[17:05:05] <owhite> * owhite logs all the discussion.
[17:05:09] <owhite> lunchtime!
[17:05:26] <SWPadnos> not logging any more :)
[17:05:38] <SWPadnos> now we can talk about the real solution!
[17:08:46] <Lerneaen_Hydra> 42 is the solution, obviously
[17:08:58] <SWPadnos> damn. what was the question?
[17:09:59] <Lerneaen_Hydra> hmm, you
[17:10:05] <Lerneaen_Hydra> 'll have to wait a while
[17:10:20] <SWPadnos> like - until the end of the universse? ;)
[17:10:38] <Lerneaen_Hydra> unfortunately you'll die a few seconds before the answer is revealed, along with the rest of humanity
[17:10:48] <SWPadnos> and everything else
[17:10:56] <Lerneaen_Hydra> due to the construction of an intergalactic highway
[17:11:02] <Lerneaen_Hydra> by the vogons
[17:15:45] <alex_joni> yeah, but the mice still know the answer
[17:18:16] <SWPadnos> no, the question
[17:18:25] <SWPadnos> no, wait, the answer
[17:18:50] <alex_joni> if they would know the question they wouldn't have built the supercomputer
[17:18:52] <alex_joni> :P
[17:19:12] <SWPadnos> and if they ever find out, the universe will be annihilated
[17:20:35] <alex_joni> don't think that annihilated, but it won't make any sense anymore :P
[17:37:15] <anonimasu> :)
[17:38:46] <Lerneaen_Hydra> it will instantly cease to exist and be replaced by something even more complex & hard to understand
[17:38:53] <Lerneaen_Hydra> some other people say this has already happened
[17:41:16] <skunkworks> :)
[17:42:26] <alex_joni> yeah, last time the answer was 2
[18:07:33] <jepler> alex_joni: that's funny
[19:44:18] <alex_joni> jepler: probably if you're familiar with h2g2
[20:00:39] <alex_joni> jepler: do you plan to do something else on #132493 ?
[20:02:48] <alex_joni> cause it looks done to me.. it's a bit off (10 seconds or so on the splash g-code) but that's OK imho
[20:03:34] <jepler> what's that as a percentage?
[20:03:42] <alex_joni> 10/45 seconds
[20:03:49] <jepler> 25% off ain't that great
[20:04:02] <alex_joni> yeah, but I bet it's not a percentage
[20:04:11] <jepler> but no I don't envision doing anything more complex with it
[20:04:15] <alex_joni> bet it's less on longer files.. I can test
[20:04:47] <alex_joni> I suggest closing it then, and maybe we'll get a feature request to make it better
[20:05:23] <jepler> I'll set it to 100% then
[20:05:33] <alex_joni> there's a open/close switch aswell
[20:05:47] <jepler> I'll make sure to do both
[20:06:07] <alex_joni> I noticed you can have a task set to 100% without it beeing closed
[20:10:05] <alex_joni> jepler: I can easily help to close that if needed
[21:26:08] <alex_joni> you know what's funny?
[21:26:47] <alex_joni> that jmk writes way better code out of his head then JonE with the logic analyser :D
[21:27:10] <skunkworks> And he tells it like it is.
[21:27:19] <skunkworks> not one to hold back ;)
[21:31:36] <SWPadnos> heh
[21:31:41] <SWPadnos> he beat me to it ;)
[21:32:13] <anonimasu> :D
[21:32:17] <SWPadnos> the driver code isn't necessarily intuitive, but we did the best we could with the documentation at hand