**** BEGIN LOGGING AT Wed Jan 09 02:59:57 2019 Jan 09 03:08:11 i did not find so much support for bbx-15 Jan 09 03:36:20 I just got one a month ago. But I don't think anyone actually knows if there is another batch in the works or not. Jan 09 03:36:34 the choices for add in boards is indeed thin. Jan 09 03:37:26 it's the base board of the am572x evm, so I don't expect it to just vanish **** BEGIN LOGGING AT Wed Jan 09 04:53:11 2019 Jan 09 13:31:38 m Jan 09 13:51:38 n Jan 09 13:52:03 might be a zmatt question but Jan 09 13:52:19 "what comes in the alphabet after 'n'?" Jan 09 13:52:35 is there any danger in providing power via the normal 5V barrel jack on the BBB while also doing the same on the SYS_5V pin? Jan 09 14:12:27 kremlin: Are you asking about the BB Blue or the BB Black? Jan 09 14:25:22 kremlin: you mean VDD_5V ? SYS_5V is a power output, not an input Jan 09 14:25:58 the VDD_5V pins on the P9 header however are directly connected to the barrel jack with a trace Jan 09 14:27:03 so providing power via both sounds like a bad idea Jan 09 15:40:58 zmatt: even if it's the same source? Jan 09 15:41:03 rar_rar: black Jan 09 16:04:26 kremlin: same source? eh, no, obviously that's no problem Jan 09 16:04:31 but, why? Jan 09 16:04:52 the PCB i designed has issues Jan 09 16:05:00 and i am loathe to pay again and wait for rev B Jan 09 16:05:59 lol Jan 09 16:06:15 so, just to check, which pins of P9 are you providing power to? Jan 09 16:07:07 P9 pin 5 Jan 09 16:07:28 ok good, so not actually sys_5v Jan 09 16:07:50 i am using the sys_5v to power some ICs though Jan 09 16:07:54 shift registers Jan 09 16:07:57 yeah that's fine Jan 09 16:07:57 very very low current Jan 09 16:08:00 should be OK Jan 09 16:08:16 sys_5v can provide a fair bit of power Jan 09 16:10:13 i really wish all the GPIO pins were 5v logic level Jan 09 16:10:19 half of this board is level translation Jan 09 16:11:06 the am335x already does crazy magic to support 3.3v I/O, it would really be a lot more comfortable at 1.8v Jan 09 16:11:45 (that crazy magic can't be done for the analog inputs, which is why those are 1.8v) Jan 09 16:14:16 btw, for a future revision: when providing 5v power to the bbb, use P9.06 in addition to P9.05. Officially the individual pins have insufficient power rating (max 1A per pin) so you're supposed to use both Jan 09 16:14:18 the IC datasheets im using always give input voltage minimums in reference to a Vcc of 4.5V Jan 09 16:14:23 and they're usually like Jan 09 16:14:27 ~3.15V Jan 09 16:14:31 which is _very irritating_ Jan 09 16:14:37 because you know the 5V value is juuuuuust over 3.3 Jan 09 16:14:48 ah gotcha Jan 09 16:14:53 on my board both are wired actually Jan 09 16:16:09 so, why do you need to provide power via the barrel jack as well? are the traces to P9.05+06 too thin or something? Jan 09 16:25:15 zmatt: yes :) Jan 09 16:25:27 because of a rather personally embaressing issue Jan 09 16:25:30 (i used an autorouter) Jan 09 16:26:23 well, using an autorouter isn't an intrisic issue, as long as it has been provided with appropriate constraints Jan 09 16:28:33 the TopoR autorouter is neat... it can route pcbs like this: https://m.eet.com/media/1202163/P111_5.jpg Jan 09 16:31:44 and make traces thinner where necessary while keeping them thicker whenever enough space is available: https://www.eremex.com/images/434662.jpg Jan 09 16:38:01 zmatt: the autorouter screwed me over because it only would output one trace size Jan 09 16:38:14 i.e. crappy autorouter :) Jan 09 16:38:21 they are all crappy :) Jan 09 16:38:25 see above Jan 09 16:38:44 these are the last of the problems our ape brains can still beat the computer on Jan 09 16:40:20 someone posted a manual layout of a really tight pcb on reddit with a joke along the lines of "let me see you autoroute that", so someone took the pcb, removed the trace routing, and ran it through TopoR, and it had no problem autorouting it Jan 09 16:40:48 but with probably 80 miles of traces and enough vias to make the board structurally unsound :-) Jan 09 16:41:00 no, it produced basically the same output Jan 09 16:41:24 oh Jan 09 16:41:26 wow Jan 09 16:41:47 :( Jan 09 16:42:49 did you see the two images I linked? Jan 09 16:43:04 looking now Jan 09 16:43:15 oh wow Jan 09 16:43:25 this sure is curvy for an autotrace Jan 09 16:43:53 wonder if the AR has the capacity to follow length-matching constraints Jan 09 16:43:56 yeah it uses straight lines whenever possible and curves around obstacles/constraints Jan 09 16:44:01 it does Jan 09 16:44:28 including the use of wiggly lines when needed (I forgot the official name for those) Jan 09 16:44:37 serpentine Jan 09 16:47:01 also what the hell is this... o.O https://www.eremex.com/images/434667.jpg Jan 09 16:47:16 is that just two layers? this looks uncomfortably tight Jan 09 16:47:26 I wish I could zoom in Jan 09 16:53:55 neat, it can also swap "equivalent" pins (e.g. different GPIOs) whenever doing so simplifies the pcb Jan 09 16:55:57 Hey zmatt, I had a question about py-uio. Can I have two different python scripts running at the same time, one talking to PRU0 and the other talking to PRU1? Jan 09 16:56:35 I tried it, but it seems that the first PRU stops running when I start accessing the other in the second python script. Jan 09 16:56:49 you're probably calling pruss.initialize(), which resets everything Jan 09 16:57:05 Yeah, I am doing that. Jan 09 16:57:35 So, should it be ok if I only call initialize in one script and be sure to start that one first? Jan 09 16:58:36 yes, or check whether both cores are halted before calling it (but beware that doing so is a race condition if both scripts start at the same time) Jan 09 16:59:06 you can reset the individual core with core.full_reset() Jan 09 16:59:22 Ok, thanks! Jan 09 16:59:37 zmatt: that's a space heater Jan 09 17:00:11 kremlin: ? Jan 09 17:00:20 the last board you linked Jan 09 17:00:37 the "i can't tell if this is a ratsnest or the actual layout" board Jan 09 17:02:08 hunter: also, one subtle detail to be aware of: autodetection of the sizes of the various pruss memories (iram/dram) is normally done in initialize() (since it messes with the contents of the memory it isn't safe to do when stuff is running), so without initialize the sizes will seem larger than they actually are Jan 09 17:02:26 this isn't usually a problem, it's just a detail to be aware of Jan 09 17:02:50 getting those sizes from "platform knowledge" is still on the to-do list Jan 09 17:02:57 Ok! Jan 09 17:05:22 you may want to just give a quick glance at the source code of initialize() to know what exactly you're skipping. it's pretty simple: https://github.com/mvduin/py-uio/blob/master/src/uio/ti/icss/__init__.py#L76-L106 Jan 09 17:06:10 Would it be correct to say that py-uio is a wrapper for uio which is written in C? Jan 09 17:06:40 py-uio is a pure-python library for working with uio devices in general, and uio_pruss in particular Jan 09 17:07:43 Gotcha, so you could say uio_pruss a tool that uses the uio library to interface with the PRU? Jan 09 17:07:53 uio_pruss is a kernel driver Jan 09 17:08:55 in general, uio is a kernel infrastructure to give userspace direct access to hardware peripherals Jan 09 17:10:13 uio_pruss and uio_pdrv_genirq are two specific uio kernel drivers, the first one specific to PRUSS (with PRUSS-specific irq handling), the latter generic for platform devices (with generic irq handling) Jan 09 17:10:26 Ok, so then for simple peripherals uio kind of lets you make your own driver in userspace. Jan 09 17:10:31 yep Jan 09 17:11:27 the kernel driver just lets you mmap() the peripheral's memory-mapped registers, and the kernel driver receives the peripheral's interrupts (if any) and passes them along to userspace Jan 09 17:13:56 within py-uio I have three namespaces: uio for the generic uio code, uio.ti for classes that represent specific peripherals of TI SoCs, and uio.ti.icss for the pru-icss (aka pruss) specific stuff Jan 09 17:23:37 Ok, so when you do "from uio.device import Uio" is that a library you wrote, or another Python library? Jan 09 17:24:05 everything in the uio namespace is part of py-uio and written by me Jan 09 18:33:42 hi all ! Jan 09 18:33:58 i want to contribute to beagle community Jan 09 18:34:13 can you guide me ? Jan 09 18:34:31 if you're looking for gsoc, see https://beagleboard.org/gsoc Jan 09 18:34:48 (that's usually what people mean when they say "i want to contribute") Jan 09 19:52:28 zmatt: So the way you interact with a device through UIO is by reading and writing from the files at /dev/uio/pruss (for the PRU)? Jan 09 19:53:15 And this file /dev/uio/pruss is created by the uio_pruss kernel driver? Jan 09 19:57:33 the uio_pruss kernel driver creates 8 uio devices (one for each interrupt, any of them can be used to access the memory/registers), either udev or the kernel creates the /dev/uio0-7 (or whatever numbers they get) device files for them (I'm not sure), udev creates the symlinks in /dev/uio/ based on the udev rules that come with py-uio Jan 09 19:58:25 read()/write() on those device files is used for the interrupt interface, mmap() (with slightly non-standard behaviour) is used for the memories and memory-mapped registers Jan 09 20:37:19 zmatt, This relates to PRU Jan 09 20:37:48 When running config-pin P9_28 pruin, I get the following errors: Jan 09 20:38:04 P9_28 pinmux file not found! Jan 09 20:38:06 are you booting from eMMC or sd card? Jan 09 20:38:15 bash: /sys/devices/platform/ocp/ocp*P9_28_pinmux/state: No such file or directory Jan 09 20:38:24 Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_28_pinmux/state Jan 09 20:38:31 if booting from sd card, assuming you don't care about the contents of eMMC wipe it using: sudo blkdiscard /dev/mmcblk1 Jan 09 20:38:34 then reboot Jan 09 20:38:55 isn't it related to the need to disable HDMI? Jan 09 20:39:16 oh that's possible too, is that one of the conflicting pins? Jan 09 20:39:26 yes Jan 09 20:39:27 if so, uncomment the appropriate line in /boot/uEnv.txt to disable audio Jan 09 20:39:39 P9.28 / hdmi audio data 103 fast down 2 asp 0 data 2 mcasp@48038000 (mcasp0_pins) Jan 09 20:39:49 yeah Jan 09 20:39:55 P9_27 was ok Jan 09 20:40:12 just search for "audio" in /boot/uEnv.txt, you'll find the line Jan 09 20:40:39 meaning that config-pin worked Jan 09 20:40:43 P9.27 105 fast rx down 7 gpio 3.19 << lo P9_27 (pinmux_P9_27_default_pin) Jan 09 20:41:20 you don't need to elaborate something that was already clear Jan 09 20:41:25 :) Jan 09 20:42:30 ;) I am not that smart to know what is clear and what is not :) Jan 09 20:45:34 Do not see audio that I can disable: https://pastebin.com/GrqtUqXK Jan 09 20:45:51 line 30 Jan 09 20:46:26 if you don't care about hdmi video either, you can also disable line 29 Jan 09 20:46:31 *uncomment line 29 Jan 09 20:49:18 and reboot? Jan 09 20:49:25 yes Jan 09 20:51:21 oh, I see now. Those lines are to disable things (not to enable). Shall I disable audio, video, or both? Jan 09 20:51:49 if you want to use that particular pin, disabling audio suffices Jan 09 20:52:13 whether to disable video depends on whether you care about video or about having a bunch more pins available :P Jan 09 20:52:32 thanks! Jan 09 21:03:15 Thanks! Disabled now. BTW, I think your great show-pins would be better if it does not show 'hdmi audio data' when the pins are in default Jan 09 21:03:27 P9.28 / hdmi audio data 103 Jan 09 21:04:24 the first column is a description of what the processor pin is connected to (which obviously isn't affected by software configuration), not what it's being used for right now (which you find in the right columns) Jan 09 21:04:56 see README Jan 09 21:13:10 read it. sorry, I do not get the point. But you do not need to respond. Just wanted to provide you with a suggestion. And most likely I am wrong anyway :) Jan 09 21:17:19 like, if you configure the pins to pruout and use pru to bang out a valid i2s signal then you'll hear it on a tv connected to the bbb's hdmi port Jan 09 21:17:28 the fact that you use the pins for pru doesn't change that it's the hdmi audio data pin Jan 09 21:17:43 if you don't care about hdmi audio this isn't a problem though Jan 09 21:19:21 (unless maybe there's something in the DT that ensures the hdmi framer's audio input is disabled or muted. it's possible, I didn't check) Jan 09 21:23:28 After configuring pins, now I have: Jan 09 21:23:36 P9.28 / hdmi audio data 103 fast rx 6 pru ... Jan 09 21:24:03 it has nothing to do with hdmi. My understanding that everything is configurable Jan 09 21:24:23 and hdmi is just a default configuration. Correct? Jan 09 21:24:28 it is still connected to the hdmi framer Jan 09 21:24:54 Oh, I see Jan 09 21:25:45 the pcb connects that particular processor pin to pin 28 of the P9 header and the audio data input of the hdmi framer Jan 09 21:26:32 which is why you can't have hdmi audio when you want to use that pin for other purposes Jan 09 21:27:10 but isn't it true that after reconfiguring, the pin is not any longer connected to hdmi framer? Jan 09 21:27:25 reconfiguring the cpu doesn't magically alter the pcb Jan 09 21:27:32 the pcb trace is still there Jan 09 21:28:14 OK. Thanks! Jan 09 21:32:15 I kind of thought that the P9.28 after reconfiguring is connected to PRU. I guess I am confused. What can I read to remove my confusion :) Jan 09 21:33:28 it is connected to pru, but that's inside the SoC (when I said "processor" earlier, I meant SoC of course) Jan 09 21:37:57 https://pastebin.com/vwyNnJhW Jan 09 21:39:26 the thing you reconfigure is which peripheral signal inside the AM3358 is internally connected to that pin of the AM3358 Jan 09 21:40:07 everything outside the AM3358 is just a bunch of copper pcb traces and tin solder, there's nothing reconfigurable about that Jan 09 23:03:33 Zmatt, Thanks a lot for the diagram! In my simplistic view both (HDMI and PRU) are symmetrically attached to P9.28. Thus, I am not convinced that P9.28 belongs more to HDMI that it belongs to PRU :) Jan 09 23:08:52 https://pastebin.com/raw/hgPCAcGr this is why it belongs more to HDMI than to pru Jan 09 23:12:22 the mux (along with some other settings of the I/O cell in the AM335x) is what changes based on the /boot/uEnv.txt settings and (when applicable) config-pin Jan 09 23:31:58 Thanks again! Nice diagram. BTW, how to you draw those? Just using the regular vi or soemthing more powerful? I like adding those into my code. Jan 09 23:32:47 yeah just vim (with :set ve=all) Jan 09 23:33:17 and these aren't particularly nice diagrams, but I didn't want to use box drawing characters since most web browsers manage to fuck up spacing if you do Jan 09 23:36:30 BTW, I just got Derek Malloy V2 Exploring Beagleboard. kindle addition. You probably do not need those, but I can see quite a few things have chanfed Jan 09 23:36:34 changed Jan 09 23:42:08 https://pastebin.com/raw/jL40Mn8K these a nicer diagrams Jan 09 23:43:13 (if your browser messes up the alignment, try changing your fixed-width font to DejaVu Sans Mono) Jan 09 23:43:55 actually it's not completely perfect for me with that font either, but it's close Jan 09 23:45:09 line width of the horizontal line of ├ and ┤ seems to be different from normal horizontal lines Jan 09 23:47:23 ah Molloy just released a new edition? Jan 09 23:48:05 well, then with a bit of luck it will actually be uptodate for a few months ;) Jan 09 23:53:39 I was able to paste your diagrams to Notepad and VisualStudio. Nice. How to you draw those? Jan 09 23:53:47 vim Jan 09 23:54:33 just did a search and replace for the horizontal and vertical pieces and fixed up the corners and T-pieces Jan 09 23:54:56 What symbols. Those are not neither underscores nor -- Jan 09 23:55:47 they're box drawing characters: https://pastebin.com/raw/H1WavZ0k Jan 09 23:56:26 they've been around since DOS ;) although unicode did add some new ones Jan 09 23:58:41 cool! I see them in wikipedia. Do you enter them by some kind of esc sequences, or copy/paste from somewhere? Jan 09 23:59:59 As far as Malloy, I got the kindle version, released likely today. The paper version will be released in a few days. Jan 10 00:00:38 the last pastebin is a text file I have to copy-paste from... I should probably add some xcompose sequences for them, but I don't use box drawing that often and I'm lazy :P Jan 10 00:02:05 Thanks! **** ENDING LOGGING AT Thu Jan 10 03:00:02 2019