**** BEGIN LOGGING AT Fri Feb 01 02:59:56 2019 Feb 01 03:02:36 some BSP other than the BBB uses strongly ordered Feb 01 03:02:48 but the BBB BSP is very hole-y in RTEMS Feb 01 03:02:55 like, no SPI support for instance Feb 01 03:03:14 it's BSP-dependent? not just architecture-dependent? that sounds like hell Feb 01 03:03:39 yeah they have a bit of code reorganization to do Feb 01 03:05:00 and I'm trying to understand your beagle_spi_read_write_bytes code... and how it could possibly ever work at all Feb 01 03:07:17 lol Feb 01 03:07:36 we more or less followed what LK was doing, because we had no idea how to make it work with just the TRM Feb 01 03:07:55 I'm downloading the SDK from TI directly to see from the source Feb 01 03:08:22 at the very least I don't think it can work if either tx_buf == NULL or rx_buf == NULL Feb 01 03:08:34 ah, and I understand why it could work... it's just *incredibly* inefficient Feb 01 03:09:23 because we wait for the interruption between each byte ? Feb 01 03:10:35 actually never mind, I don't understand why this code works Feb 01 03:13:02 I'd expect a second TXEMPTY before the first RXFULL, and the assertion on line 274 to fail as a result Feb 01 03:13:12 oh wait Feb 01 03:13:34 maybe I should check the documentation of rtems_event_receive Feb 01 03:13:44 I just noticed the first argument Feb 01 03:13:47 sc = rtems_event_receive(EVENT_RXFULL, RTEMS_WAIT, BBB_SPI_TIMEOUT, &received_events); Feb 01 03:13:54 the events can only be EVENT_RXFULL Feb 01 03:14:01 yeah I overlooked that Feb 01 03:14:16 so the assertion is genuinely superfluous Feb 01 03:14:23 yeah Feb 01 03:14:38 because we didn't understand why the code didn't work we put asserts and traces everywhere Feb 01 03:15:11 and yeah it is inefficient. if you check with a scope, you'll see a pause after every byte Feb 01 03:16:02 so the problems may stem from a too low SPI (mean) freq Feb 01 03:16:02 (with or without fifo... you're basically not using the fifo currently, even if you enable it) Feb 01 03:16:10 I see Feb 01 03:16:17 dunno, that shouldn't cause problems other than poor performance Feb 01 03:16:38 yeah Feb 01 03:16:46 at least that can exacerbate race conditions elsewhere Feb 01 03:17:33 I don't expect beagle_spi_read_bytes or beagle_spi_write_bytes to work though Feb 01 03:17:59 yeah they don't matter Feb 01 03:18:22 they're legacy from earlier dev Feb 01 03:18:26 e.g. spi_write_bytes will cause the receive buffer/fifo to fill up with data you never read, and then the transfer stalls Feb 01 03:18:51 we were using them in write-only mode Feb 01 03:18:55 for testing with a scope Feb 01 03:18:58 yeah Feb 01 03:20:11 anyway, ask me again tomorrow or so, I kinda have to focus on things Feb 01 03:20:30 yeah no problem, thanks a lot for your time Feb 01 03:36:12 Does anyone know where I might find getting-started information or python examples for the RS485 CAN CAPE for the BeagleBone Blank Rev 3? Feb 01 11:36:16 hello Feb 01 11:38:34 can anyone help me how to start bbb kernel development? Feb 01 11:38:42 i have no idea where to start Feb 01 11:39:20 i mean driver development* Feb 01 11:39:21 do you want to write your own Kernel or do you want to extent e.g. the Linux or BSD kernels? Feb 01 11:39:49 Id like to write drivers in C Feb 01 11:40:43 leniwiec: get a copy of ldd3 and work though it from cover to cover on your desktop machine. Feb 01 11:40:47 i did stm32 bare metal programming in the past Feb 01 11:40:57 got it, thanks for help Feb 01 11:40:58 what LetoThe2nd says Feb 01 11:41:05 after that, jumping to the bbb is just a minor task :-) Feb 01 11:41:26 https://lwn.net/Kernel/LDD3/ Feb 01 11:43:33 looks like that approach was not lazy enough (his nick is literally "lazyperson") Feb 01 11:44:14 well, honesty is the best policy ;) Feb 01 13:59:30 m Feb 01 15:50:30 Hey all, made LDgraphy suited for a transparent polygon scanner.. see https://www.youtube.com/watch?v=SofTXG5s_MA Feb 01 15:51:02 beaglebone, 3D printing, hexastorm https://hackaday.io/project/21933-open-hardware-transparent-polygon-scanner **** BEGIN LOGGING AT Fri Feb 01 18:03:54 2019 Feb 01 20:54:36 i know it is not 1975 anymore but Feb 01 20:54:50 correct Feb 01 20:54:55 i would really love to have a hardcopy printed desk reference of the am335x TRM Feb 01 20:55:01 it's such a wonderful document Feb 01 20:55:39 we had a printout of an old revision of the dm814x TRM, which we recently tossed away Feb 01 20:55:48 frown. Feb 01 20:56:31 trm printout just really isn't as useful as it may seem. apart from combining poorly with revisions, you can't search it Feb 01 20:56:34 i bought a am3359 BGA IC off digikey for no other reason to drill a hole in it & add to my keychain Feb 01 20:56:40 oh ofc Feb 01 20:56:40 hehe Feb 01 20:56:51 for me it'd be purely artistic Feb 01 20:57:17 one's bookshelf contents speaks volumes about them Feb 01 20:58:26 (the am3359 did not last very long) Feb 01 20:58:56 the 386 CPU i have attached similarly is only just barely scraping by after a year's worth of wear&tear Feb 01 21:00:03 yeah the dm814x would probably survive a lot better... https://www.dave.eu/sites/default/files/dido-main.png Feb 01 21:03:24 ouch Feb 01 21:03:26 sharp Feb 02 02:51:04 Hey, can I use a BBBW in a mini maker faire? Feb 02 02:52:28 I was going to show off a robot thing w/ the BBBW. Feb 02 02:53:15 You know? What are the rules? I know I am not affiliated or anything but I thought I might need permission. Feb 02 02:58:49 Open Source! **** ENDING LOGGING AT Sat Feb 02 02:59:56 2019