**** BEGIN LOGGING AT Wed May 18 02:59:58 2016 May 18 03:55:05 lol, always nice such config options.... May 18 03:55:07 "To the best of my knowledge this is dead code that no one cares about." May 18 03:55:10 default y May 18 03:58:23 haha May 18 03:58:31 there are some gems in the kernel sources May 18 04:02:54 how about May 18 04:03:04 selected by: (slightly cleaned up for readability) May 18 04:03:12 INFINIBAND && (PCI || BROKEN) && HAS_IOMEM && NET && INET && ((m && MODULES) || IPV6!=m) May 18 04:03:15 || PCI && SCSI && SCSI_LOWLEVEL && ((NET && BE2ISCSI) || (ATA && SCSI_IPR)) May 18 04:03:52 that is seriously the most random-looking set of conditions I've ever seen May 18 04:04:24 haha cool ! May 18 04:04:58 IPV6!=m ... but either compiled-in or disabled is fine apparently? May 18 04:05:11 lol May 18 04:05:49 and wtf does m && MODULES even mean?! May 18 04:06:30 since when is 'm' something that can appear as a clause May 18 04:07:02 that does seem odd .. probably has some magic meaning May 18 04:08:08 but apparently INFINITEBAND and networking combined may cause problems on a system with IOMEM, if it uses PCI or is broken May 18 04:08:20 (this is on IRQ_POLL btw) May 18 04:10:04 but, thanks to 'make oldconfig' I learned about KCM... for many message-based TCP protocols you can now have the kernel split the datastream into messages and even demultiplex them to multiple userspace sockets May 18 04:10:13 if you can manage to describe it using BPF May 18 04:16:47 ah never mind it looks like multiple userspace sockets is just for load balancing, no explicit routing May 18 04:18:44 oh neat there's an LLVM backend for making BPF programs? didn't know that May 18 04:20:00 ,lol May 18 04:20:13 "zmatt discovers the kernel" :P May 18 04:25:08 that's one nice side-effect of really going through kernel config.... May 18 04:25:33 going through the list of syscalls can be similarly illuminating May 18 04:26:25 in both cases though there's also the downside that there tends to be some distance between abstractly knowing some functionality exists vs being able to put it to actual use May 18 04:27:31 zmatt: heh yes I can imagine May 18 04:36:35 and there's the.. "cool! I want to play with this! ... I don't really have time to play with this, nor even any real application for it, but I want to play with it anyway!" May 18 04:36:44 like userfaultfd() May 18 04:37:10 zmatt: thats why i have a collection of arm and microcontroller boards littering my desk :D May 18 04:39:26 hehe, I try to protect myself from myself May 18 04:39:50 I did not buy an usbarmory, I did not enable userfaultfd() in kernel config May 18 05:14:29 oi May 18 05:48:34 damnit rmk stop being such an asshole about this patch... http://www.spinics.net/lists/linux-mmc/msg36706.html May 18 05:49:58 you'd think that with variations of the same patch being submitted again and again and again by different people they'd at some point start to get the point that this is something people want May 18 05:50:07 and not a single good argument against them has ever been given May 18 05:52:50 hahaha May 18 05:52:59 they're kernel devs for a reason zmatt ... May 18 05:53:39 and fuck UUIDs... they're horrid, they're ugly, they're verbose, they're meaningless. they're the absolute last resort when you have no stable and meaningful way to identify something May 18 05:54:48 I'm seriously considering subscribing to linux-mmc and just post yet another patchset for this May 18 05:55:22 do eet May 18 05:58:52 I want to, but I shouldn't. annoying a maintainer on purpose is not very productive, especially with me being a kernel n00b May 18 05:59:39 in my very small number of posts I already managed to piss off rmk once May 18 06:00:34 he was wrong then too, but I apologised anyway (while still subtly pointing out his argument was flawed, though this did not get a reply anymore) May 18 06:08:26 heh May 18 06:09:19 there we go, it's always important to give clear error messages May 18 06:09:21 if sys.byteorder != 'little': May 18 06:09:21 raise RuntimeError("life is too short to dwell on the past") May 18 06:09:47 eexxxcelent May 18 06:12:24 hey May 18 06:12:37 I just noticed I only have /dev/mmcblk1 May 18 06:12:40 no /dev/mmcblk0 May 18 06:12:47 aha! May 18 06:13:01 rcn to the rescue?? :D May 18 06:13:59 where IS rcn?! May 18 06:14:21 good question May 18 06:14:30 I'm beginngin to wonder whether jkridner hasn't locked him up in a cage or something .. May 18 06:16:41 I just realized how bizarrely empty my /dev is... or rather, how we've gotten used to /dev being ridiculously full of crap May 18 06:17:07 zmatt: I -think- you might wanna reboot .. whilst there's still something IN Dev .. May 18 06:17:45 lol, I meant on my bbb, and I just booted it May 18 06:18:09 ah .. I would assume systemd-devd has restrained what it puts there now May 18 06:19:13 zmatt: any idea why I would have to manually modprobe a cp210x driver .. ? it won't auto-load .. May 18 06:19:32 what is it? May 18 06:19:33 unless I need to sort a udev rule out .. May 18 06:19:45 serial uart bridge May 18 06:19:57 like ftdi or prolific May 18 06:20:03 ah usb May 18 06:20:06 except this is silabs May 18 06:20:43 modprobing should not be necessary... something wrong with your modaliases db thingy? May 18 06:20:56 possibly .. May 18 06:20:56 try depmod May 18 06:22:04 yeah that looks like it probably was it May 18 06:22:16 you're welcome May 18 06:24:19 I had to insmod a module for a capture card for ages, before I realised a depmod meant it would modprobe automagically lol May 18 06:24:48 and these days its in-kernel .. tw68 widgets May 18 06:25:10 which remnds me .. May 18 06:26:50 4.4.4-bone5 still calls eMMC /dev/mmcblk0 May 18 06:27:02 it was fixed recently May 18 06:28:38 4.4.8-bone10 also calls eMMC /dev/mmcblk0 May 18 06:32:02 that be the 'bone 'patches ;) May 18 06:37:38 so it happened somewhere between 4.4.8-bone10 and 4.6.0-bone3 May 18 06:37:48 on 4.6.0-bone3 it's /dev/mmcblk1 May 18 06:39:18 and considering a patch for it was still rejected 3 weeks ago on linux-mmc it's safe to assume it's an rcn patch :) May 18 06:41:16 not even remotely surprising May 18 06:41:33 unless the discussion ended differently... still reading the thread May 18 06:43:09 isn't the emmc conncted to conroller mmc1 ? May 18 06:43:42 yes May 18 06:44:07 hmm.. isn't that a slight improvement then .. May 18 06:45:07 that's the whole point, it has finally been fixed May 18 06:48:03 next question, why is my spi device called spi1 when it's in fact spi0 May 18 06:48:22 EW EW EW EW damnit ti May 18 06:49:01 it should have worked right by default May 18 06:49:03 ~/.../drivers/spi$ grep of_alias_get_id spi.c May 18 06:49:04 master->bus_num = of_alias_get_id(master->dev.of_node, "spi"); May 18 06:49:11 however.... May 18 06:49:24 ~/.../drivers/spi$ grep bus_num spi-omap2-mcspi.c May 18 06:49:24 static int bus_num = 1; May 18 06:49:24 master->bus_num = bus_num++; May 18 06:49:36 nice, very nice May 18 06:49:54 oh lovely May 18 06:58:30 I think the fix is really just removing those two lines though May 18 06:58:39 spi core should take care of the rest May 18 06:58:52 compiling... May 18 07:19:53 works May 18 07:19:55 :) May 18 07:58:55 and a nice udev rule to get /dev/spi/$OF_NAME instead of /dev/spidev$bus.$cs .. yay for stable identifiers May 18 08:21:22 zmatt: /dev/ is not an ABI ;) May 18 09:07:53 Hi, I want to enable PWM (BBB, debian Jessie). I have to setup the general pinmux but I don't know what file choose in /opt/source/beaglebone-universal-io ? May 18 09:08:23 between LICENSE cape-univ-audio-00A0.dts cape-universal-00A0.dts config-pin Makefile cape-univ-emmc-00A0.dts cape-universala-00A0.dts README.md cape-univ-hdmi-00A0.dts cape-universaln-00A0.dts May 18 09:08:46 cape-universaln-00A0 ? May 18 09:21:02 uname -a May 18 09:21:04 Linux beaglebone 4.1.18-ti-r53 May 18 09:21:31 KotH: I have no idea what you could possibly mean by that May 18 09:21:45 ew, cape-universal ... May 18 09:22:17 does that even include pwm support? May 18 09:22:58 zmatt: that was a comment on your udev rule change :) May 18 09:23:35 I'm following a tuto with that cape... May 18 09:25:21 I don't know May 18 09:26:45 With 4.1.X kernel, PWM is working, right ? May 18 09:28:19 dirkk: I can't guess what your tutorial is saying, but in current images cape-universal is enabled by default, so there's nothing you need to do for that part May 18 09:29:50 zmatt: I found a post on googlegroup. I think I have to uncomment line in uEnv.txt May 18 09:30:47 if you have a recent jessie image, cape-universal is enabled by default, so if that's what is desired then you don't need to do anything May 18 09:31:23 KotH: I still have no idea what you could possibly mean May 18 09:33:04 zmatt: Ok, assuming it's enabled by default, I should have something by doing ls /sys/devices/ocp ? May 18 09:33:40 zmatt: than it wasnt a good joke ^^' May 18 09:41:50 dirkk: it's /sys/devices/platform/ocp on my system, but I'm running a very different kernel May 18 09:59:29 zmatt: Thanks ;) I can find ocp:PX_XX_pinmux/ the rep May 18 09:59:38 *in May 18 14:15:26 i would like to know why i am unable to power on a USB barcode scanner using beagle even when a phone is charging properly from the same usb port. May 18 14:19:04 i would like to know why i am unable to power on a USB barcode scanner using beagle even when a phone is charging properly from the same usb port. May 18 14:25:00 ydv, the beaglebone probably isnt able to provide the power to run the barcode reader May 18 14:25:06 have you tried a powered hub? May 18 14:25:31 yes i did, with the 5V input adapter May 18 14:25:48 is it detected? May 18 14:26:05 is it displayed using lsusb? May 18 14:27:07 i did't get you,could you please elaborate where can i find lsusb. is it accessible on cloud9? May 18 14:30:57 lsusb is a command which shows attached usb devices May 18 14:31:40 i would like to add that the scanne ris plug-and-play device which is detected automatically by linux machine (Ubuntu) and Windows May 18 14:36:32 Apologies. May 18 14:37:03 Hello any staff member here? May 18 14:38:04 define staff May 18 15:28:13 lol May 18 16:49:49 Hi... is there a 2 GB Image of Deb8.3 for a old BBB-Rev.B May 18 16:49:52 ? May 18 16:53:17 SierraX: yup should be .. let me refresh my web page .. May 18 16:53:48 .. they keep changing the lists .. May 18 16:53:54 used to be a good one on elinux .. May 18 16:55:55 SierraX: do you want/need a flasher image, or just a uSD standalone one? May 18 16:57:37 actually . it seems the good folks have removed 98% of the flasher images.. so you have to force it manually .. May 18 17:27:50 broke my mmc with May 18 17:28:35 a to big image... how to force it manually? May 18 17:29:35 The 8.2 image from december and dist_upgrade? May 18 17:37:09 SierraX: start with http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#microSD.2FStandalone:_.28lxqt-2gb.29_.28BeagleBone.2FBeagleBone_Black.2FBeagleBone_Green.29 May 18 17:37:28 but re-mount your uSD card .. and change thus: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC May 18 17:48:33 Ok... xzcat pipe dd is running... we will see what happen May 18 17:54:00 hello May 18 17:54:19 anybody home??? May 18 17:55:20 knockknock ;-) May 18 17:56:06 nope, nothing to see here, move along ... May 18 17:58:51 i am curious what people are doing to get audio out from the BBB... i've looked at some usb soundcards... saw there was a cape (which seems to be discontinued).... May 18 17:59:16 is there an easy way to get audio from the hdmi port? May 18 18:00:33 mtnman: audio is available on the hdmi, but there are some gotcha's with which resolutions 'suit; the on-board framer chip May 18 18:01:07 mtnman: otherwise, tbh, usb is quick-/cheap-est unless you go down the I2S route .. May 18 18:01:16 or is it mcasp on this board *gets confused* May 18 18:03:11 holy monkeys .. https://polyvection.com/product-category/plaindac/ .. think I'll get a couple May 18 18:04:11 except they're outta stock May 18 18:04:25 maybe I'll hunt down the gerbers an get some made then .. -sheesh- May 18 18:04:48 veremit how would you connect the polyvection dac to the bbb? May 18 18:05:03 three/four wires to the i2s pins :) as per instructions May 18 18:05:30 you are assuming i have seen the instructions. May 18 18:05:48 where do these exist? May 18 18:06:15 I'm just looking for them .. -sigh- along with some board gerbers .. haha May 18 18:07:25 i have also just seen some hdmi splitters which split audio/video... May 18 18:07:40 yeah I've heard about those on ML May 18 18:16:08 hey May 18 18:16:24 has anyone had any success using JSFiddle with their beaglebone? May 18 18:27:08 veremit: mcasp is the name of the peripheral May 18 18:27:22 veremit: it supports i2s, but also a variety of other tdm formats May 18 18:27:37 zmatt: are you (and/or co) using it? did you say something abouthaving a bb test platform with it? May 18 18:28:17 yeah, 16-channel audio to an external dsp May 18 18:28:51 16-channel from the bbb?! and what's the dsp? May 18 18:30:02 yeah iirc for some reason linux refused 32 channels May 18 18:30:13 phew May 18 18:30:28 maybe a hardcoded limit somewhere May 18 18:31:10 oh I'm sure you'll find that some day .. :D May 18 18:33:31 well we may want to transfer audio from dsp to bbb also, so then only one data line is available per direction May 18 18:33:55 oo yikes .. May 18 18:33:59 so what dsp you using? May 18 18:34:16 and a 24.576 MHz master clock doesn't allow more than 16 channels (* 32 bits * 48 kHz) May 18 18:34:35 adau1452 May 18 18:37:34 zmatt: any scope for increasing clock .. or you gonna hit major issues .. I'd imagine you might be better simply deploying a second bbb :D May 18 18:38:13 mcasp0 has more than 2 data lines actually, and mcasp1 is also available, but there's a lot of pinmux overlap and mcasp1 is only partly pinned out May 18 18:38:25 don't be silly May 18 18:38:51 We're using McAsp1 for audio capture and McAsp0 for audio playback. May 18 18:39:05 yeah that's a sensible choice May 18 18:40:07 since asp1 can only be used in slave mode, and I'd prefer to have data+clk+fs going in the same direction May 18 18:40:52 although 25 MHz isn't *that* high so using it as slave transmitter should work too, but better safe than signal integrity headache :P May 18 18:41:21 Have a custom board with some codec chips the assemble the data into a TDM frame and pass it to the McAsp1. Works pretty well. Sadly we haven't gotten the FIFO to work so we're using one the PRUs to snarf the data and the other to scatter it. May 18 18:41:55 Ragnorok: +1 May 18 18:42:02 Prolly could do it all in one, the the scatter PRU is set up to assume an interrupt when data is ready and it was simpler to use the other PRU for that. May 18 18:42:14 oh, alsa works here May 18 18:42:17 brb May 18 19:43:59 May I ask how I can connect video camera to Beagleboard? May 18 19:44:52 Or where can I find related documents for video camera support? May 18 19:44:58 Jeffreyke: usb? May 18 19:47:52 Actually I want to know which video camera plugged onto Beagle board, it can be automatically recognized. Then I can find that device in /dev/video0? May 18 19:50:28 Hi veremit: I'm not sure standard BeagleBoard's linux's support range? May 18 19:51:37 Jeffreyke: lots of people using <=HD webcams May 18 19:51:45 ther eis no CSI or equivalent on the BB processors May 18 19:55:17 veremit: thanks. That means Linux ubuntu supported video camera, BeagleBoard's linux also can support natively. Is it right? May 18 19:56:06 I know no reason why v4l shouldn't be the same in BBB kernels as mainline .. one is a descendant of the other May 18 19:58:21 do you know BBB kernel support VLC well? May 18 19:59:28 why wouldn't it? its linux ... May 18 20:02:44 Scuttlebutt here is a BBB is not intended as a multimedia device. rPi is more suited to that. BBB is more of an embedded/industrial controller. May 18 20:04:57 broadly correct, and nice term Ragnorok :) May 18 20:28:52 do we have recent android images for a bbb ? May 18 20:29:16 sorry, what's android?! May 18 20:29:20 :D May 18 20:30:04 well .. May 18 20:32:20 seems ti got lost during 4.2.2 May 18 20:38:43 For both beaglebone and rasberry pi it seems that Android is not really being actively worked on by a lot of people. Not sure why, it just seems to be the case. May 18 20:39:52 Where I work we looked into it b/c a customer was interested in using Android with the BBB, but it seemed very much like a DIY, up hill battle. May 18 20:40:41 agreed May 18 20:41:06 yet it should be too far , as our mighty kernel rules the hw and the rest is userspace.. May 18 20:41:29 the 3d part and proper gles libs are a must May 18 20:42:17 well we will see how i end up , i am currently downlaoding the linaro aosp gits .. which seem to take 2 days for my companys lines May 18 20:43:15 so my point is, now that the droid kernels are mostly upstream ones, it should be easyier then before May 18 21:10:15 opengl es/es2 actually works May 18 21:11:17 zmatt: w00t May 18 21:11:50 that was just a reaction to "the 3d part and proper gles libs are a must" ... not a recent achievement or anything :P May 18 21:13:30 oh heh right May 18 21:15:08 last time I did anything with 3d on the bbb was somewhere last year May 18 21:29:53 o.O wtf... if I declare the watchdog device as a child of l4_wkup (which is where it resides) it completely vanishes... no error, but also no /dev/watchdog* nor any trace of it in /sys May 18 21:30:22 declaring it as a child of &ocp however works fine May 18 21:32:11 other peripherals (e.g. gpio0, uart0, adc, rtc) have no issue living inside l4_wkup May 18 21:32:50 o.O May 18 22:56:56 ok, fixed May 18 22:58:13 hey zmatt, do you know of a P/N for a simple, cheap tracking regulator off the top of your head? May 18 22:58:42 tracking regulator? those were not terribly common but I did find one at TI May 18 22:58:53 'k May 18 22:59:38 http://www.ti.com/product/TPS7B4253-Q1 May 18 23:02:33 there's also a cheaper 150 mA one May 18 23:05:38 don't look too bad... $0.40/1000 and SOT23-5 May 18 23:06:10 ohh nice, "irq 187: nobody cared" May 18 23:06:12 [ 4.662549] handlers: May 18 23:06:12 [ 4.662565] [] dma_ccerr_handler May 18 23:06:44 so edma was asserting an error but the dma_ccerr_handler disagreed on that point May 18 23:06:49 sweet May 18 23:51:40 *chuckle* May 18 23:53:52 ohh and I can more or less reproduce it May 18 23:57:05 looks like the serial console itself is triggering May 18 23:57:52 ok sweet, fuck 8250-omap then, back to omap-serial it is :P May 19 00:01:12 hahaha really.. May 19 00:09:55 zmatt: I know you're a firm fan of the omap=serial .. but I'm still waitinf for the uber zmatt-omap-serial with rs485 and other alient protocols fully omap-centric :D May 19 00:19:46 the plot thickens May 19 00:20:21 every single time so far the traceback is immediately preceded by: May 19 00:20:21 random: nonblocking pool is initialized May 19 00:40:43 veremit: do you need dma? (with most serial protocols the benefit seems doubtful to me) May 19 00:41:13 zmatt: never really had use for it so far, but my colleague is gonna be working on an ethernet -> rs485 bridge (like wiznet, but better) May 19 00:41:15 if not, uio is a fine option :P May 19 00:41:40 we use rs485 a *lot* .. so I need to get *something* besides stm32 working with it May 19 00:42:20 rs485 is an electrical standard, it says very little about what you do with the line May 19 00:42:38 zmatt: indeed .. but you need hardware to drive that TXEN ;) May 19 00:45:15 also known as "gpio" May 19 00:45:22 zmatt: correct May 19 00:45:45 and some software mumbo-jumbo to catch the start and end of packets :P May 19 00:46:04 how much time after txempty do you have to shut off the transmitter? May 19 00:48:18 it depends on your half-duplex requirements .. but most applications Iv'e seen .. its a couple of bit-widths typically May 19 00:48:37 or .. max. of 1-2 bit widths .. 0.5 is pretty good May 19 00:49:01 .... at what kind of bitrate? May 19 00:49:16 115200 is our favourite May 19 00:50:22 i.e. 4 us ? right, use PRU. May 19 00:51:00 zmatt: yeah I think for some reason all software implementations are crap .. its overkill for the PRU, but tbh, if its there .. May 19 00:51:27 zmatt: presumably you can set up, say 4 uarts with rs485 independently, and still do TXEN with the PRU(s) ?! May 19 00:51:58 bbb would be more than adequate for us May 19 00:52:41 PRU will have no problem with that May 19 00:53:38 though you can't be entirely careless there either May 19 00:53:58 peripheral accesses add up May 19 00:53:59 right May 19 00:54:13 PRU will spend most of its time twiddling its thumbs May 19 00:54:24 indeed May 19 00:54:53 you *might* be able to get edma to do the job for you, that would be a very sweet hack May 19 00:55:44 the easiest way might be by leaving the receiver enabled while transmitting May 19 00:55:59 then you can easily trigger on "reception" of the last byte May 19 00:56:12 thats dirty lol May 19 00:57:21 maybe, but very fast :) May 19 00:57:31 and actually easy to arrange May 19 00:58:58 think the pru would be better .. it would even count bits -urgh- lol May 19 00:59:10 s/would/could/ May 19 01:27:42 either could work fine, it's mostly a matter of what you'd consider easier May 19 01:28:02 zmatt: half-decent hardware capable of managing the timing internally haha May 19 01:28:18 even the stm32 has a 'hack' .. but its a good hack at least May 19 01:28:31 thikn you -can- do it from a delay on the fifo empty .. May 19 01:28:35 but its crude May 19 01:29:49 minor detail: pru receives no irqs from uarts 3-5 May 19 01:30:46 zmatt: its still on the back burner for now .. but if I were to get it working .. I think it would be an option for us. It falls into the "copious free time" basket though :/ no resource available May 19 01:32:51 edma would probably be easiest, at least for acting as "master" (send message, quickly turn around and be ready to receive reply) May 19 01:33:09 yea edma sounds like a good option May 19 01:33:42 quickly comprehending a received message and responding within a narrow timeframe would absolutely be a PRU job obviously May 19 01:38:59 also quite cool, TI designed the ethernet subsystem to support multiple receive and transmit queues, and three sets of irq registers which can independently subscribe to those events for those queues, allowing in principle three cores to use the ethernet interface May 19 01:39:24 and then they connected both cortex-a8 and PRU to "core 0" of the ethernet subsystem and left "core 1" and "core 2" irqs unconnected May 19 01:39:30 hai when will beagleboard x15 is released May 19 01:39:58 when the lords of the FCC are pleased May 19 01:40:42 then simultaneously they will provide supporting gpio cap for that May 19 01:40:43 2115 (the "x" is 2100) May 19 01:41:26 because we developer gpio is must know May 19 01:41:34 The X-15 is a very interesting design, and I like their retro choice of its name. May 19 01:41:48 ya me too May 19 01:42:21 holy fark .. have a PC again .. thanks chromium for taking over all my memory *and* swap :/ May 19 01:44:53 zmatt: the problem isn't so much a fast reponse/turnaround, just avoiding bus collision May 19 01:45:56 zmatt: I think the am335x would be a perfect IO unit for our machines, replacing two ethernet IO modules and some dodgy usb->rs485 circuitry .. May 19 01:46:07 but nobody wants to resource utilising it May 19 01:49:35 ehm, if you're not using a protocol that explicitly excludes collisions then you'll certainly have a lot more fun... turning the transmitter off quickly doesn't seem to me like particularly important in that May 19 01:50:37 you'd need something like carrier-sense, collision detection, suitable backoff May 19 01:51:07 zmatt: we're only using microcontrollers haha May 19 01:51:12 for that part .. May 19 01:51:12 yes, and? May 19 01:51:15 its not .. fast. May 19 01:51:37 but yeah .. some collision detection, etc etc would be luxurious May 19 01:52:29 if you consider that luxury then leaving the transmitter on for a couple of bytes is not going to matter either May 19 01:54:13 consider studying how apple's LocalTalk worked May 19 01:58:25 yeah... just keep retrying lol May 19 01:58:28 it actually elegantly first sent a tiny 'ping' to the recipient before sending the actual packet... collisions could only happen on the ping since all parties would know it granted the sender a timeslot May 19 01:58:30 its not a lot worse than tcp May 19 01:58:40 erm ip* May 19 01:58:51 it also verified the recipient was ready to receive it (limited hardware...) May 19 01:59:07 so the actual datagrams never needed to be retransmitted May 19 02:00:15 or, well, I suppose there's still a tiny chance it could be the victim of random failure May 19 02:03:12 and LLAP (LocalTalk Link Access Protocol) "does not require suitable hardware to detect the occurrence of collisions." May 19 02:04:20 remember this is 30-year old tech, so it's not fancy ;) May 19 02:07:11 google Inside AppleTalk if you're interested, the pdf floats around May 19 02:07:26 (for some reason it looks awful in chrome's built-in pdf viewer but fine in xpdf) May 19 02:13:14 yeah I got kpartsplugin -> okular :D May 19 02:13:26 even in chromium May 19 02:21:01 networking stack fitted in 6 KB ... that's with automatic address assignment and peer-to-peer name resolution (needless to say, AppleTalk never presented anything as human-unfriendly as a numeric identifier) May 19 02:21:15 6 KB of ram May 19 02:21:16 sorry May 19 02:24:37 heh, ok never mind LLAP actually did some tricks that were highly dependent on the Ziloc SCC May 19 02:24:44 *Zilog May 19 02:24:51 oh well May 19 02:28:32 yea Zilog May 19 02:35:43 the PRU can touch its own registers, right? May 19 02:35:52 like enabling OCP port for full memory access May 19 02:36:54 easy enough to test, but why wouldn't you do that already during subsystem setup? May 19 02:43:59 interesting, a BBB and a DSP powered from two adjacent USB ports of the same machine May 19 02:44:35 but they turn out to have significant ground potential, and if I connect their ground planes together I measured 150 mA flowing through that connection **** ENDING LOGGING AT Thu May 19 02:59:59 2016