**** BEGIN LOGGING AT Mon May 07 03:00:01 2018 May 07 03:27:51 set_: sir May 07 03:27:56 if you your still awake May 07 03:36:33 Hey black_13! May 07 03:36:37 Oops! May 07 04:22:49 Almost Mon, FunDay! May 07 05:03:56 Monday-FunDay! May 07 06:20:51 what is the default mode of each pin in bbb? May 07 07:05:53 umbaman: gpio unless the pin is used for some specific purpose May 07 07:07:22 e.g. some pins are in use when eMMC and/or hdmi is enabled, and two pins are used for i2c (for cape autodetection) May 07 07:09:51 umbaman: you can use my show-pins script to inspect the current pin configuration: https://github.com/mvduin/bbb-pin-utils/#show-pins May 07 07:49:13 Hi, what is the lightest method to reproduce an RTSP video stream into LCD7 ? May 07 07:51:38 ideally something that just renders the video directly into framebuffers via drm May 07 07:51:50 (i.e. no X or whatever) May 07 07:54:53 I don't know if gstreamer is efficient/"light", I did find it has a "kmssink" plugin and a third party "gstdrmsink" plugin May 07 07:56:10 thanks zmatt. pin configuration can only be set during boot? May 07 07:58:22 umbaman: pin configuration is typically determined by the device tree, which is loaded at boot. to increase flexibility you can use device tree overlays, although runtime-loading of these is deprecated and will eventually go away. these days however, on the default image something called "cape-universal" is enabled which makes all the pins runtime-configurable using the "config-pin" utility May 07 07:58:53 all pins not occupied by a fixed function, that is May 07 08:38:22 trying gstreamer.... May 07 08:58:24 the goal is to play a network camera into beagle LCD7 May 07 08:59:00 I've tried VLC in graphic environment, it kills cpu , useless.... May 07 09:01:27 it will heavily depend on the resolution and encoding used and how well-optimized the decoder is for cortex-a8 + neon of course May 07 09:02:01 it's really not a task at which the am335x is well-suited May 07 09:06:28 but....how to make it work without desktop environment ? x window system ? May 07 09:06:56 I answered that part already May 07 09:07:36 ah yes... May 07 09:07:44 render video directly into framebuffers via drm. for gstreamer I found you two sink plugins you can try, there may be other players that can do this as well May 07 09:12:27 cheers zmatt May 07 09:17:28 just trying to understand how to get kmssink and compile it... :-(( May 07 10:23:48 oh, I see, it's not part of any gstreamer package... even though its documentation is? that's really weird May 07 10:24:32 I don't understand why a plugin like that wouldn't be a standard sink, the preferred one even when not using a window system May 07 11:56:21 Hi, it have been a while again since I played with the bealge bone black. today I downloaded one-debian-9.3-iot-armhf-2018-03-05-4gb.img(.xz) and dd the image to an sd-card. I have a onder bealge bone ( with smaller MMC) and I am booting from sdcard. Booting is .. kinda slow (e.g. I get messages like "loading /lib/firmware/BB-ADC-00A0.d 711 bytes read in 1201 ms (0 Bytes/s) and after starting kernel I do no May 07 11:56:27 t see anything any more on the serial May 07 11:56:50 dmesg on my host does show ndis_host 3-1.4.2:1.0 enp59s0u1u4u2: unregister 'rndis_host' usb-0000:3b:00.0-1.4.2, and similar May 07 11:57:08 I am powering for a powerport of a hub rated to 2 AMP May 07 11:57:32 should I expect aserial to pop up? May 07 11:57:49 I mean .. a login or similar after kernel startup May 07 11:58:01 typically people connect via network, most commonly via usb (rndis) May 07 11:58:59 yea.. not me will need memtest or similar in uboot May 07 11:59:01 though a login *should* also pop up on the serial console... but that's almost never used by anyone, so if it somehow managed to break in the latest images I doubt it would get noticed very soon May 07 11:59:43 the command line is probably ok ish e.g. debug: [console=ttyO0,115200n8 ....] May 07 11:59:56 u-boot is accessible only on the serial console of course. to enter its commandline you press space when it tells you to May 07 12:00:00 the O is a bit fishy May 07 12:00:39 yeah it should technically be ttyS0 now, but ttyO0 is also accepted as a backwards-compatible synonym May 07 12:01:24 (it's ttyOx when using the omap-serial driver and ttySx when using the 8251-omap driver) May 07 12:01:41 uhh, 8something-omap May 07 12:02:23 8250-omap, that May 07 12:34:19 zmatt: how do you setup the shared memory between the PRU and the CPU in C++? May 07 12:34:47 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/pru/src/pru.cpp#L60 May 07 12:35:06 We do this, but it seems to not write immediately to the PRU May 07 12:35:47 because the PRU still uses the old value when executing a program May 07 12:38:16 I know I had a similar "issue" before when doing the automatic emmc install (the serial was only spawn after the full install happend but this is different0 May 07 12:38:24 board_name=[A335BNLT] ... May 07 12:38:25 board_rev=[0A5A] ... May 07 12:45:13 zmatt: it seems hard to find kmssink or gstdrmsink supported.... do you think to compile 3+ years old sources on a jessie distro could work ??? May 07 13:10:49 I tried different options (e.g. init=/bin/sh , adding additional console=ttyBla) but so far does not perhaps that I am having some incompatibilities betwen the BL0 and uboot May 07 13:11:16 uEnv.txt in /boot does not contain any reference to the console hence .. there are some more params hidden somehwere May 07 13:15:23 keesj: the default value of the console kernel parameter is hardcoded in u-boot, and is correct May 07 13:15:58 keesj: can you pastebin the full output you're seeing on the serial console? May 07 13:16:35 fred__tv: debian jessie is also 3 years old :P May 07 13:17:48 current stable release is stretch, current testing release is buster May 07 13:20:03 https://pastebin.com/dm5W5DYD May 07 13:20:32 SPL is .. also recent I see May 07 13:20:33 bou4: ew! there's absolute no reason to use /dev/mem here May 07 13:24:11 how would you read and write to the shared RAM in C++? May 07 13:24:18 because it works now May 07 13:25:02 prussdrv already maps the shared memory, you only need to ask it for its address May 07 13:25:26 see the prussdrv_map_*() functions, or use prussdrv_get_virt_addr() May 07 13:28:59 you shouldn't have any need for PRU_ADDRESS May 07 13:30:40 prussdrv_map_prumem(PRUSS0_SHARED_DATARAM, &addr) May 07 13:31:08 thanksss May 07 13:31:49 (or prussdrv_get_virt_addr(SHARED_MEMORY_OFFSET) ) May 07 13:33:51 also, SHARED_MEMORY_SIZE is wrong. although 64KB of the pruss address space is reserved for the shared ram, only 12KB is present on the am335x May 07 13:35:05 * zmatt . o O ( hmm, I should add some autodetection for that to py-uio ) May 07 13:36:25 alrighty May 07 13:36:29 I rewrote it May 07 13:36:49 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/commit/fc29a7ce71ea3310efe7ced103f120d9a262c453 May 07 13:38:25 no need to check the return code, it cannot fail May 07 13:39:08 if it fails to map the memory, prussdrv_open() will fail May 07 13:39:59 Alrighty May 07 13:40:40 also, you may want to change the return type to volatile ulong * May 07 13:40:49 either that or you need to use explicit compiler barriers May 07 13:44:30 ( https://pastebin.com/b2jy4L4w ) May 07 13:54:25 Alrighty, fixed! May 07 13:55:14 I suppose CLKXDIV has no effect if you se an external transmit clock source? May 07 13:55:56 correct May 07 13:58:17 (also where I said "volatile ulong *" I really meant "ulong volatile *" but I know writing it like that isn't conventional, even though it makes way more sense) May 07 13:58:20 :P May 07 13:58:37 also consider using uint or uint32_t May 07 13:58:52 long means (in practice) "a pointer-sized integer" May 07 13:59:02 which is a strange thing to ask for in this situation May 07 13:59:13 while int is always 32-bit in practice May 07 13:59:31 (I'm ignoring things like 8-bit microcontrollers and such here) May 07 13:59:40 Okidoke! May 07 13:59:47 Will write it on my todo-list May 07 14:00:00 At the moment I am trying to configure the McASP for the 8th time or so May 07 14:00:10 I always get interrupted by other problems :p May 07 14:29:54 does savenv no longer exist in uboot? May 07 14:31:11 zmatt: do you know the addresses for SRCTL_0 to SRCTL_5? May 07 14:31:30 Oh nvm May 07 14:31:41 forgot about hexadecimal for a second :p May 07 14:57:04 Hello, I am having an issue with wifi on my beaglebone blue. Anyone knows if there is a way to check if the chipset is working properly ? t the moment the device doesn’t show in /sys/class/net May 07 15:03:25 keesj: persistent environment has been disabled in the standard u-boot for beaglebones May 07 15:04:11 keesj: unintentionally leftover bits of saved environment causing boot issues can be a really painful experience May 07 15:07:42 manu2018[m]: hmm May 07 15:25:02 hello May 07 15:25:15 The 5V supply of Beaglebone Black does not work May 07 15:25:21 I don't know why May 07 15:25:33 it just stopped working, the leds do not light up May 07 15:25:50 what were you doing when it stopped working? May 07 15:26:26 i was trying to flash emmc May 07 15:27:00 so it worked once and the next time i tried supplying dc power the leds stopped glowing May 07 15:27:13 that sounds odd May 07 15:27:53 does it power led not turn on at all anymore, or a very short blink of the power led? May 07 15:28:50 short blink of pwr led May 07 15:29:38 ? May 07 15:29:51 okay, so almost certainly the processor is dead. the big question is how the hell that happened May 07 15:30:15 nothing is connected to the expansion headers right? May 07 15:30:36 nope May 07 15:32:06 which image were you trying to flash to eMMC ? May 07 15:32:17 ubuntu May 07 15:34:25 God straft onmiddellijk May 07 15:34:28 lol May 07 15:35:40 what? May 07 15:35:46 is there a way to fix this? May 07 15:37:18 Guest8685: no, it's dead. I'm really not sure what could have happened, or where the blame could lie. I mean, it's possible for software to cause hardware damage, but it would require a really serious screw-up in the kernel or device-tree May 07 15:37:31 which image did you flash *exactly* ? May 07 15:37:35 as in, which url? May 07 15:41:20 almost nobody uses ubuntu, but I'd still expect them to get smoke-tested automatically at the very least May 07 15:41:30 https://elinux.org/Beagleboard:BeagleBoneBlack_Debian May 07 15:42:32 the pwr led lights up when connected via usb May 07 15:42:37 to laptop May 07 15:43:06 oh May 07 15:43:12 D4 remains lit and D2 led keeps blinking May 07 15:43:20 so it's not dead at all May 07 15:43:33 Adapter doesn't supply the necessary current? May 07 15:43:46 but it supplies for arduino May 07 15:43:57 Can it handle 1A? May 07 15:43:59 how much current can it supply? May 07 15:44:06 5V/1A May 07 15:44:15 it worked once May 07 15:44:41 maybe it's broken? that's the most plausible explanation since it sounds like the beaglebone itself is working fine May 07 15:46:03 the adaptor is broken? May 07 15:46:15 it sounds like it May 07 15:46:34 oh May 07 15:46:40 if the board were broken, it wouldn't matter how you power it May 07 15:47:00 okay May 07 15:47:14 can i flash emmc on usb supply? May 07 15:47:46 has always worked fine for me May 07 15:48:15 which image would you recommend? May 07 15:48:40 first download link at http://bbb.io/latest-images May 07 15:50:05 okay thanks i'll give another try May 07 15:50:24 zmatt: I did everything that the datasheet asks May 07 15:50:30 to initialize the McASP May 07 15:50:50 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/pru/pru/main.p May 07 15:50:54 as can be seen in main.p May 07 15:52:17 https://pastebin.com/8CQa1fre May 07 15:52:23 is the output of your program May 07 15:52:32 i think something's wrong, but I don't understand the interface May 07 15:53:26 which datasheet? May 07 15:53:41 ...MotorCape! May 07 15:54:09 bou4: it doesn't look like the codec is outputting a clock. also, ignore the actual clock rates listed. my code has no way of knowing the clock rate in the case of external clock and probably just made some assumptions which are invalid in your situation May 07 15:54:23 Guest8685: he wasn't talking to you, he was talking to me May 07 15:55:02 okay May 07 15:56:05 I checked with a scope and all clocks are running May 07 15:56:39 what color are the lines below xHCF ? May 07 15:56:56 also, double-check pinmux May 07 15:57:14 (e.g. using my show-pins script) May 07 15:57:34 https://imgur.com/a/qV8M9jg May 07 15:57:37 also, tx/rx hclk should probably be internal, not external May 07 15:59:31 okay, lightblue = stationary input, so it's not seeing any clock May 07 15:59:41 if you're saying a clock is being provided, then pinmux is probably wrong May 07 16:00:35 P9.31 / hdmi audio clk 100 fast rx down 7 gpio 3.14 P9.29 / hdmi audio fs 101 fast rx down 7 gpio 3.15 P9.30 102 fast rx down 7 gpio 3.16 P9.28 / hdmi audio data 103 fast rx down 7 gpio 3.17 May 07 16:00:41 voila May 07 16:00:47 they're configured as gpio May 07 16:00:52 indeed, it doesn't get exported by my device tree May 07 16:01:07 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/pru/device-tree/beaglebone-black-codec-pru.dts May 07 16:01:13 is it because status != okay? May 07 16:01:14 "exported" is not the word you're looking for here May 07 16:01:36 devices with status != "okay" are ignored May 07 16:01:41 is it not because of my device tree? May 07 16:02:52 the pinctrl properties should be attached to pruss May 07 16:03:02 not the mcasp0 device May 07 16:04:22 also, unrelated: you can indicate the codec reset is active-low by using <&gpio1 18 1> instead of <&gpio1 18 0>. then you can rename it "codec-reset" since the kernel will invert the value-attribute for you. (it still needs to be "init-low" though, that refers to actual output level) May 07 16:06:16 aha, good idea! May 07 16:07:06 yes, my pins are properly configured right now! May 07 16:08:21 https://imgur.com/a/ZUnok5p May 07 16:08:24 what does this mean/ May 07 16:09:36 brb my attention is needed here May 07 16:30:07 bou4: I've updated asp-monitor to annotate (in case of hclk) or omit (in case of clk/fs) assumed clock rates May 07 16:30:33 it also looks like I started working on a better version with more verbose output, but never finished it May 07 16:32:08 how do you actually write to the data port XBUF? May 07 16:32:15 I think that is one of my mistakes May 07 16:32:21 I now changed it to use the configuration port May 07 16:32:25 you haven't released the clock from reset May 07 16:33:03 the data port of mcasp0 is at address 0x46000000 May 07 16:33:37 oh never mind May 07 16:33:45 releasing clock from reset isn't needed in case of external clock May 07 16:33:58 normally i released everything from reset May 07 16:34:03 as described in the datasheet May 07 16:34:35 "-HDSF" that first - is bit 0 (or 8) of GBLCTL May 07 16:34:53 but like I said, it doesn't matter since you're using external clock May 07 16:35:21 so normally if i write to XBUF i will hear it? May 07 16:37:40 there's a config bit that selects whether you're going to use config port (0x480382xx) or data port (0x460000xx) May 07 16:38:05 it doesn't matter much which one you use (other than for efficiency), but it does need to be set correctly May 07 16:40:27 keep in mind that transmit underflow (the big red "R" on line 4) is a fatal error and requires starting the reset procedure from scratch May 07 16:41:23 alright May 07 16:41:37 receive overflow (the second big red R on the same line) is not a fatal error, the data is simply discarded May 07 16:41:41 it seems i still have a lot of work to do May 07 16:43:43 the red C is clock check failure, which you can ignore since you're not using the clock check feature May 07 16:44:24 does my code look good at first sight? May 07 16:44:33 atm i'm writing a macro to write a sample and read a sample May 07 16:56:27 "AMUTE functions as an output" ... there's no AMUTE pin on the AM335x May 07 16:56:51 no need to configure anything related to it May 07 16:57:20 okayyy May 07 16:58:50 but overall it looks okay so far, except of course that once the single sample you wrote to XBUF has been transmitted an underflow occurs May 07 17:00:35 alrighty, good to hear it May 07 17:08:18 basic outline for synchronous rx/tx operation without fifo would be: https://pastebin.com/ZkGJutjJ (assuming I didn't make any mistake, but I'm fairly sure I didn't) May 07 17:08:34 enabling the fifo would probably be a good idea though May 07 17:09:11 at the very least to be able to read/write the data in pairs May 07 17:12:58 hmm, i can't seem to get it not overflowing May 07 17:13:03 underflowing May 07 17:13:17 yes, indeed May 07 17:13:36 what does your code currently look like? May 07 17:14:17 https://pastebin.com/yhE8yFpY May 07 17:15:04 uhhhhh, okay you actually *are* overflowing May 07 17:15:24 how? May 07 17:15:31 in my macro i check the XDATA bit May 07 17:15:34 ohh May 07 17:15:38 never mind May 07 17:16:04 https://pastebin.com/FUMDmFsm May 07 17:16:06 then it would have been helpful to include that :P May 07 17:16:09 this is the macro i am speaking o f May 07 17:16:56 uhh what? May 07 17:17:11 your macro is trying to read XBUF May 07 17:17:54 holy May 07 17:18:16 that is definitely wrong May 07 17:19:06 you presumably meant to poll SRCTL_2 :P May 07 17:20:39 or poll RSTAT and then clear the event by writing to RSTAT (using this approach instead of polling SRCTL is required to be able to use fifo and/or irq) May 07 17:21:01 https://pastebin.com/RgFGNgTg May 07 17:21:05 this is what i meant May 07 17:21:22 eh yeah XSTAT sorry, not RSTAT May 07 17:21:50 Is writing to XSTAT necessary? May 07 17:21:57 absolutely May 07 17:22:01 As i thought that writing to XBUF clears it already May 07 17:22:13 I think? May 07 17:23:07 I will try to adjust my code May 07 17:23:37 normally interrupt status bits are not self-clearing, but some peripherals are weird and do sometimes spontaneously clear them... the i2c peripheral is one example. I don't recall mcasp doing this May 07 17:26:12 https://pastebin.com/VnySCNMZ May 07 17:29:03 hum, hold on, I'm a bit confused now May 07 17:31:08 okay, never mind, it's auto-clearing May 07 17:31:45 they just didn't bother documenting this in the register spec but just mention it somewhere in the chapter :P May 07 17:32:13 "This flag is cleared when the XDATA bit is written with a 1, or when all the serializers configured as transmitters are written by the processor." May 07 17:33:09 yes, i thought i read that too somewhere May 07 17:33:49 also, if that weren't the case, the 'set' instruction in your case was pointless since you already know it was set, and clearing the irq should have been *before* acting on it (by writing XBUF), not after May 07 17:34:47 also you were clearing all status bits, not just the one you handled, so you would have concealed errors May 07 17:35:37 you may want to test bit 8 to detect errors and jump to an error handling routine (e.g. "halt" for now :P ) May 07 17:35:50 to avoid getting unwanted clockcheck errors, configure its min/max to 0/255 May 07 17:39:14 will configuring it with interrupts make it easier to fix the underruns? May 07 17:39:19 nope May 07 17:39:27 configuring it with fifo will May 07 17:39:44 but I don't understand why it even does that May 07 17:39:48 the PRU runs at 200MHz May 07 17:39:56 that's way faster than 48kHz May 07 17:39:59 it probably shouldn't May 07 17:40:13 so there may just be something else wrong, if you're still having the problem May 07 17:40:18 so my guess is, i am doing something terribly wrong May 07 17:41:37 also, the limiting factor isn't the pru's core speed. it'll be spending most of its time doing absolutely nothing at 200 MHz while waiting for lbbo instructions to complete May 07 17:42:30 the "ping time" to mcasp is dozens of pru cycles May 07 17:56:22 i think i found a mistake May 07 17:56:31 for some reason my codec isn't generating a frame sync anymore May 07 18:51:58 I see there are some webinars on the BBB and related context on Element 14 soon. More info! May 07 18:52:34 I am waiting to see the PRU section. I have not gotten into PRU stuff yet. May 07 18:53:08 ... May 07 18:53:38 I also got some info. on new Capes coming out. RelayCape and MotorCape...I think I will look into these once available. May 07 18:56:27 ... May 07 18:57:00 I saw that Mouser is selling them. Are they made in the US w/ US mfg. parts? May 07 19:07:03 Ut Oh...I got the RelayCape and LoadCape. I cannot wait to try out some odd motor control on these Beagle Capes. May 07 19:08:39 Power! May 07 19:08:52 bbl May 07 20:13:05 Hello, I am having an issue with wifi on my beaglebone blue. Anyone knows if there is a way to check if the chipset is working properly ? t the moment the device doesn’t show in /sys/class/net May 07 20:20:55 hmm, can't seem to find the mistake, will have to check everything from the beginning May 07 20:42:47 bou4: what's asp-monitor saying? May 07 20:43:11 still the same as before, underrunsss May 07 20:43:12 manu2018: wifi not showing up sounds odd... maybe check the board identification in eeprom? May 07 20:43:48 though I left everything at the lab, since I needed a mental break, but am now reading the code again May 07 20:43:49 bou4: can you show me your code again? May 07 20:43:59 ok May 07 20:44:25 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/pru/pru/main.p May 07 20:44:41 manu2018: head -c 16 /sys/bus/nvmem/devices/0-00500/nvmem | hexdump -C May 07 20:44:50 I can push my latest update in a minute or 5 as I am currently installing Altium on Windows and my source is on Linux May 07 20:45:07 but the latest update just adds the write sample macro and a loop which writes samples May 07 20:45:19 and I don't think that's where the mistake lies May 07 20:46:23 it kinda has to though May 07 20:46:32 but I think I somehow fried the LRCK of my codec May 07 20:47:12 (can that occur from misconfiguring FSX on the McASP?) May 07 20:47:16 accidently configured the pin as output? everything looked fine in your screenshots of asp-monitor though May 07 20:47:34 yes it is possible, but you didn't have it misconfigured in the images you showed me May 07 20:48:53 yes, that's true, but even when I checked and visually saw that there was nothing but noise on LRCK your program said otherwise May 07 20:49:07 noise? May 07 20:49:12 something periodic May 07 20:49:17 not much of a clock signal May 07 20:49:49 my program can't analyze the signal of course, it just shows it's been observed to toggle May 07 20:50:28 that's maybe what it saw May 07 20:50:40 because it was somehow period, but not the 48kHz signal that I expected May 07 20:50:49 and there is no way the codec can be configured to only generate a bit clock May 07 20:51:00 so there must be something wrong with the PCB or the codec internals May 07 20:51:57 so it was periodic but not a clock? that sounds very very strange May 07 20:52:09 it was like really really really attenuated May 07 20:52:20 like 300mVpp May 07 20:52:57 that sounds really weird May 07 20:53:29 but that also sounds like it wouldn't toggle the input on the am335x May 07 20:55:53 zmatt, hmm, true May 07 21:02:44 zmatt: 00000000 aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 4c 41 32 |.U3.A335BNLTBLA2| May 07 21:05:02 manu2018: okay that's fine May 07 21:05:07 manu2018: what image are you using? May 07 21:05:41 does /sys/class/mmc_host/mmc2 exist? May 07 21:06:11 bone-debian-9.4-iot-armhf-2018-03-28-4gb.img.xz May 07 21:06:40 zmatt: yes /sys/class/mmc_host/mmc2 exists May 07 21:06:47 hm May 07 21:07:10 but the wlan0 interface doesn't show up at all? any errors about it in the kernel log? May 07 21:29:27 https://github.com/BelaPlatform/Bela/blob/master/pru/pru_rtaudio_irq.p#L1090 May 07 21:29:38 is it possible that my lack of doing that, causes the underrun? May 07 21:30:26 no May 07 21:32:29 the comment makes no sense (there's no PLL involved there), but probably they had to add the delay because they aren't properly waiting for HCLKRST release to complete (since they're "polling" R/XGBLCTL instead of GBLCTL) May 07 21:32:44 that's my best guess anyway May 07 21:33:21 alrighty May 07 21:33:32 learned a lot from you May 07 21:33:40 of course there's no harm in adding a delay anyway just as experiment May 07 21:33:58 may I mention you in my final report? May 07 21:34:38 uh, sure May 07 21:35:34 I do see they're using the fifo May 07 21:51:23 What changes that? May 07 21:51:29 That I have a buffer to write to May 07 21:51:34 Instead of sample by sample? May 07 21:51:50 yeah, the ability to write data in advance May 07 21:52:43 also, when using the data port, the ability to write/read multiple words with a single sbbo/lbbo May 07 21:55:52 still, you're right that pru should have absolutely no trouble whatsoever with keeping the transmitter fed even without fifo May 07 21:56:43 over 10us (2000 pru cycles) per word May 07 22:00:40 then I think I will first try to search where my mistake lies May 07 22:00:45 at first May 08 02:22:22 Hi May 08 02:24:11 Someone can help me.. i recent buy a bbb and i try to configurate this on ubuntu, but i cant connect to the server of bbb May 08 02:26:25 i run this script mkudevrule.sh but the step two no change on the file start.html May 08 02:35:03 there wouldnt happen to be a new FDIS drivers for MaxOSX that anyone knows about? May 08 02:35:12 been looking for the past few hours May 08 02:35:55 the drivers on the latest image dont install May 08 02:36:20 version 2.4.2 install fine from here: http://www.ftdichip.com/Drivers/VCP.htm May 08 02:37:57 FTDI* May 08 02:38:18 i got this error https://ghostbin.com/paste/feaw3 May 08 02:38:32 :( someone can help me May 08 02:39:16 trying to make my own do_patch.sh file, but i really dont know what i am doing May 08 02:46:10 ToRA: why do you think you need these? May 08 02:46:36 s0d0ma: you don't need to configure anything or make any udev rule May 08 02:46:36 because the instructions say to install both files May 08 02:47:01 Step #2: Install drivers May 08 02:47:13 Mac OS X Network Serial Install both sets of drivers. May 08 02:47:30 but the FTDI installer doesnt work May 08 02:47:51 in the README for the FTDI drivers link that website i linked earlier May 08 02:48:16 ToRA: "With the latest images, it should no longer be necessary to install drivers for your operating system to give you network-over-USB access to your Beagle. In case you are running an older image, an older operating system or need additional drivers for serial access to older boards, links to the old drivers are below." May 08 02:48:18 i grabbed the latest drivers (2.4.2) and those install fine, but there is a .sh file that patches those drivers May 08 02:48:23 -- https://beagleboard.org/getting-started May 08 02:48:49 zmat: but when i try to connect the bbb to my computer dont find the ip by default of the bbb, when i execute "dmesg" that show me that error May 08 02:49:01 (ty for the response) May 08 02:50:02 this is indeed for an older image May 08 02:50:36 ToRA: even then you don't need FTDI drivers unless you're using an FTDI serial cable to access the serial console May 08 02:50:56 s0d0ma: looks fine to me, it's being detected correctly as far as I can tell May 08 02:51:54 ToRA: I'll admit the getting-started page could be clearer about which drivers are needed/useful under which circumstances May 08 02:52:20 well it is a virtual FTDI serial using the USB May 08 02:52:20 zmat: bro but in the start.html dont apear on the step 2 fine.. like dont detect the driver May 08 02:52:47 s0d0ma: ? May 08 02:53:07 i ran the drivers on that page (that i was having trouble finding, thank you for the link) and those actually installed fine. it needs to restart, so i will restart and see if that works May 08 02:53:49 zmat: look May 08 02:53:50 https://ibb.co/idonm7 May 08 02:54:39 s0d0ma: you seem to be running an old image, so you may want to consider reflashing to a new one May 08 02:54:55 even still, what do you want me to look at here? May 08 02:55:24 everything is looking fine so far May 08 02:56:07 are you getting an error on attempting step 3 ? May 08 02:57:55 i thought it was a virtual FTDI serial cable, but now i am thinking that's not the case May 08 02:58:12 or maybe it is May 08 02:58:31 i still cant connect to the device using the 192.168.7.2 address May 08 02:58:33 ToRA_: some old boards had an integrated FTDI chip for the serial console, but that's not the case for the beaglebone black nor later boards May 08 02:58:57 that's an unrelated issue altogether May 08 02:59:18 at least i know not to chase that driver issue May 08 02:59:57 wait wait **** ENDING LOGGING AT Tue May 08 03:00:03 2018