**** BEGIN LOGGING AT Tue Jul 23 02:59:57 2019 Jul 23 03:36:15 Is it normal for LEDs on the BBBW to burn out? Jul 23 03:37:58 Do not get me wrong. The board is in working condition except for that one LED. Jul 23 03:55:36 it seems highly unlikely that's even possible. it seems more plausible it just got misconfigured somehow Jul 23 03:59:40 Hmmm. Maybe Jul 23 03:59:58 I started the board. Only three lit. Jul 23 04:00:06 I could have altered it before. I will have to check. Jul 23 04:00:25 It is not the heartbeat pattern LEDs. Jul 23 04:10:14 Sorry. Two lit only, i.e. not three like described earlier. Jul 23 04:25:14 @zmatt: I have amps = 3.3v/330 ohms. amps or current = 0.01. What exactly can I use this 0.01 in relation to LEDs and how can I apply it. Jul 23 04:25:16 Serious? Jul 23 04:25:53 set_: that's not how it works Jul 23 04:26:16 I am trying to wrap my head around this idea. I have four basic math equations, right. I can solve for each of them but, w/ the BBB in mind, how can I use them w/ a GPIO pin of 3.3v? Jul 23 04:26:17 Oh. Jul 23 04:26:30 what LED is not working? Jul 23 04:26:34 No. Jul 23 04:26:41 This is no longer about the LED> Jul 23 04:26:49 It is about an external LED now. Jul 23 04:27:24 Iled = (3.3-Vf)/Rled Jul 23 04:27:40 ds2: The LED onboard that does not work is the furthest from the jack. Jul 23 04:27:47 It is not the heartbeat LEDs. Jul 23 04:27:57 BBBW. Jul 23 04:28:07 is the power LED? Jul 23 04:28:13 I think so. Jul 23 04:28:14 No. Jul 23 04:28:25 is it mechanically damaged? Jul 23 04:28:35 put it under a scope and inspect for broken traces Jul 23 04:28:41 I am not sure. Okay. Jul 23 04:28:47 set_: LEDs have a highly non-linear voltage-current relationship. picking a suitable series resistor basically means looking up the forward voltage and desired amount of current for the led, and then using (Vsupply-Vled)/Iled as series resistance Jul 23 04:29:05 Oh. Jul 23 04:29:06 Okay. Jul 23 04:29:08 or a good magnifier if you lack a scope Jul 23 04:29:20 I have a scope that is not accessible right now. Jul 23 04:29:36 I will have to get back to you on that idea. Jul 23 04:29:42 I think ds2 means a microscope rather than an oascilloscope in this context Jul 23 04:29:46 *oscilloscope Jul 23 04:29:49 Oh. Jul 23 04:29:50 or if you got a good driver, make sure the driver doesn't exceed Imax and just PWM it Jul 23 04:30:10 microscope. Nope on that one. Sorry. Jul 23 04:30:10 as long as the LED isn't over heated and doesn't exceed its Imax, it can save you a resistor Jul 23 04:30:27 using a led driver is better for efficiency yes Jul 23 04:30:29 I have a green LED and a 330 ohm resistor. Jul 23 04:30:30 *may be Jul 23 04:30:45 I am using a GPIO pin on the 3.3v header. Jul 23 04:31:12 I was putting together this "tutorial" and am failing miserably. "Got to be me." Jul 23 04:31:13 in general, the beaglebone's gpio's are not really well suited driving leds Jul 23 04:31:18 and 330 ohm sounds too low Jul 23 04:31:18 Oh. Jul 23 04:31:32 the limiting factor here isn't the led, it's the gpio Jul 23 04:31:33 For green or for LEDs in general. Jul 23 04:31:37 for the gpio Jul 23 04:31:39 Oh. Jul 23 04:31:41 I got it. Jul 23 04:31:52 gpios are means for digital logic, not for driving leds Jul 23 04:31:55 *meant Jul 23 04:31:58 So, I am lessening the voltage from the GPIO. Jul 23 04:32:02 Oh. Jul 23 04:32:04 no, the current Jul 23 04:32:04 Got it. Jul 23 04:32:11 oh...amps. Jul 23 04:32:33 Just in case the LED wants to explode. Jul 23 04:32:36 Right-o. Jul 23 04:32:42 no, to avoid destroying the beaglebone Jul 23 04:32:47 Oh. Jul 23 04:32:48 Ha. Jul 23 04:32:58 well, and the led too Jul 23 04:33:09 but you'll probably destroy the gpio before you destroy the led Jul 23 04:33:10 Man. I never thought LEDs were so difficult. Jul 23 04:33:23 they're not Jul 23 04:33:32 I thought, heh, plug 'em in and watch 'em go. Jul 23 04:33:54 What? There is tons of math, ideas, and logic. Jul 23 04:33:58 is = are Jul 23 04:34:33 Dang it. @zmatt: I guess I need to keep reading. I was ready for this small "tutorial" and bang. Busted. Jul 23 04:35:12 But...the LED that is not lit right now on my BBBW is the one closest to the SiP. Jul 23 04:35:29 i'd need to look up which led that is Jul 23 04:35:33 There are usually there that are lit in line. Jul 23 04:35:37 I can look it up. Jul 23 04:35:39 Hold on. Jul 23 04:35:57 There = Three Jul 23 04:36:00 what does the command "ip link" show on that bbbw ? Jul 23 04:36:32 besides the "lo", "usb0", and "usb1" interfaces, does it show a "wlan0" interface or an "eth0" interface? Jul 23 04:36:46 Yea. Jul 23 04:36:50 No. Jul 23 04:36:58 I wasn't asking a yes/no question Jul 23 04:37:15 Dang it. It seems I am in IPv6 instead of IPv4. Jul 23 04:37:19 Hmmm. Jul 23 04:37:31 wlan0. Jul 23 04:37:33 that command does not show any IPv4 nor IPv6 addresses, nor did I ask about any Jul 23 04:37:35 ok Jul 23 04:37:49 Oh. Jul 23 04:38:09 I have wlan0 and SoftAp0. Jul 23 04:38:21 if wlan0 shows up, that excludes the possibility of misprogrammed EEPROM (which afflicted BBBW boards at some point) Jul 23 04:38:33 Oh. I remember that issue a long time ago. Jul 23 04:40:52 So, I am limiting the amps from the non-ideal GPIO to the LED for lighting purposes. I may need to use something different, heh? Jul 23 04:41:20 I think ds2 stated that I should use a driver of some sort. Jul 23 04:41:36 I guess I should choose cheap to learn first off. Jul 23 04:41:48 I am going to try sparkfun. Jul 23 04:43:53 the beaglebone black just used transistors (+ series resistor for the led), the beaglebone black wireless (for its USR0-USR3 leds) just uses gpios directly with 1K series resistor Jul 23 04:44:52 1K series resistor will sufficiently limit the current to protect the gpio Jul 23 04:45:06 the actual current will depend on the characteristics of the led Jul 23 04:46:59 just toss in a transistor Jul 23 04:47:44 I mean, if you don't need a lot of brightness then just a series resistor may be fine Jul 23 04:47:53 you may be able to get away with direct conn if you use those superbright reds that use like 1mA Jul 23 04:48:37 the bbbw user leds are direct-driven by gpios and I don't recall them being particularly dim Jul 23 04:48:50 Okay. Jul 23 04:49:54 I can try a 1K. Jul 23 04:49:58 if you use a transistor, do make sure there's a sufficiently large series resistance both on the base (to the gpio, like 10Kohm or so) and to the resistor (appropriate value will depend on the LED and the desired brigtness) Jul 23 04:50:06 zmatt: are they active high or active low? maybe the AM33x are more tolerant of sinking then sourcing Jul 23 04:50:07 and to the LED I meant Jul 23 04:50:24 the AM335x is equally bad at sourcing as it is at sinking iirc Jul 23 04:50:27 just use a MOSFET and forget the base resistor Jul 23 04:50:43 set_: in other words, there's a ton of options Jul 23 04:50:54 I once had a transistor. Jul 23 04:51:09 just try a 1K series resistor and come back if you feel it's too dim Jul 23 04:51:15 I cannot remember where that tran. is right now. Jul 23 04:51:16 Okay. Jul 23 04:51:22 ds2: they are active-high Jul 23 04:51:30 i.e. sourcing Jul 23 04:52:03 I will come back if the 1K resistor makes my LED too dim. Jul 23 04:52:30 My 330 ohm from what i can tell does not make my green LED too bright. Jul 23 04:52:49 Photos? Jul 23 04:52:51 Hahahah. Jul 23 04:54:34 photos are useless for this... and it's not about 330 ohm being too bright, it's about it being *potentially* more current than the gpio appreciates... it might still be marginally okay, but it'll depend on the exact characteristics of the led Jul 23 04:54:51 Oh... Jul 23 04:54:58 1K is definitely safe Jul 23 04:55:01 My generic LED may compromise my GPIO. Jul 23 04:55:06 Got it. Jul 23 04:55:14 B/c... Jul 23 04:55:29 we know the voltage and amperage of the GPIO. Jul 23 04:56:33 I just wonder how I got involved in this generic LED business. I think I purchased them in 2014 from Adafruit. Jul 23 04:56:41 Anyway... Jul 23 04:56:48 This is good info. Jul 23 04:58:02 I think since I do not know the watts of my LED, I need to listen to the 1K ohm resistor idea. Brb. Jul 23 05:07:29 1K ohm resistor in full effect, my peoples. Way dim! Jul 23 05:09:47 t the very least a resistor. If your LED has a Vf of 3.2V and you need to drive it at 3ma then you would want to use a resistor of value (V-3.2)/i_led fixes the way dim thing. Jul 23 05:10:19 so (V-Vf)/i_led gets you the restor value. Jul 23 05:10:28 time to sleep Jul 23 05:11:08 strictly speaking, it isn't the GPIO that won't like it. It is the pin driver Jul 23 05:16:47 Aw. Jul 23 05:17:25 time to sleep for me too. The day is full of "blossoms" and "delight." Cough. Jul 23 05:37:58 ds2: aww, are you confusing poor set_ with technicalities? ;) Jul 23 06:02:20 zmatt: no...just preparing him in case he sees sysfs gpios appearing ok but nothing on the pin Jul 23 06:06:03 technically if those gpios appear in sysfs then that's a bug since those gpios are already claimed, albeit a deliberate bug => https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.14.y/patches/drivers/ti/gpio/0003-hack-gpiolib-yes-we-have-drivers-stomping-on-each-ot.patch Jul 23 06:09:54 some versions allow sharing of the gpio with kernel (:() Jul 23 06:10:31 yeah, kernels with the patch I just linked **** BEGIN LOGGING AT Tue Jul 23 06:45:28 2019 Jul 23 12:25:53 m Jul 23 12:44:25 f Jul 23 20:59:25 Hi Guys Jul 23 20:59:44 I am having a problem installing the roboticscape npm Jul 23 21:06:08 Using node 10 Jul 23 21:09:22 http://paste.debian.net/1092820/ Jul 23 21:14:47 plz help Jul 23 22:28:24 Looks like it failed to compile the object, did you make the Makefile ? Do you also understand make? Also it looks like CXX may not be defined as a Make macro I'm no make expert however. Jul 24 00:07:03 roboticscape includes a template makefile for people to use I think Jul 24 00:07:22 oh, npm, in that case everything should normally be taken care of Jul 24 00:07:28 but I'm too lazy to look at the paste right now Jul 24 01:11:54 how do I control a GPIO pin from the PRU? Jul 24 01:27:07 ksft: easiest is probably to use pru's dedicated gpios... you can't control all gpios in this way, but for the subset of pins for which it's applicable it's definitely more convenient: it basically just requires configuring the relevant pin(s) to pru_in or pru_out mode using config-pin, and then those pins will be wired straight into r31 (for input) or r30 (for output) of one of the PRU cores Jul 24 01:28:21 you can also access the gpio controllers using pru, which lets you read and control any gpio, albeit with reduced performance (and increased risk of losing deterministic execution time) Jul 24 01:28:26 config-pin is a utility I run on the main processor? Jul 24 01:28:42 yes, it's used for configuring pinmux Jul 24 01:28:48 (I only need one input and one output pin) Jul 24 01:31:05 does it come with the image on the website? Jul 24 01:31:38 some example pins are P8.12/11 for pru 0 out 14/15 and P8.16/15 for pru in 14/15 Jul 24 01:31:40 yes Jul 24 01:32:50 does deterministic execution mean each assembly instruction takes exactly one clock cycle? Jul 24 01:33:58 with deterministic execution I mean being able to know in advance exactly how much time each instruction will take... for most instructions that's exactly 1 cycle (5ns) per instruction Jul 24 01:34:45 what's the best way to sleep for 4 microseconds? Jul 24 01:35:01 I assume there's a better way than typing 800 noops? Jul 24 01:38:47 use a loop Jul 24 01:40:57 for example, using the "delay" macro I define here: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/common.h#L47-L56 you could do: https://pastebin.com/raw/Pvw0bArr to get exactly 4us of delay Jul 24 01:42:27 you could also use the "loop" instruction... especially for short (<= 255 cycle) delays that saves setting up a loop variable Jul 24 01:42:39 I see Jul 24 01:42:44 that repo looks useful Jul 24 01:43:29 it has a bunch of examples as well as python code that uses uio-pruss to load code into pruss and interact with pru cores Jul 24 01:43:52 so something like `loop label, 256` then `label` would delay 256 clock cycles? Jul 24 01:43:59 `label:`* Jul 24 01:47:40 you'd have loop label, n; nop; label: Jul 24 01:48:05 where n must either be a register containing a value in range 1-65535, or a constant in range 1-255 Jul 24 01:48:08 256 is not allowed Jul 24 01:48:15 https://pastebin.com/raw/vRY0wiq8 here's how you could wrap it into a macro Jul 24 01:49:01 beware that you cannot have nested harware loops Jul 24 01:49:30 every "LOOP" simply overwrites the hardware loop parameters Jul 24 01:51:05 oh, "from 0 to n" doesn't include n? Jul 24 01:51:20 no, loop 0 is simply invalid Jul 24 01:51:49 it says the parameter can be "from 0 to n" where n is 256 Jul 24 01:51:59 where does it say so? Jul 24 01:52:37 maybe I'm being rusty and the assembler takes care of this, but I don't think I am Jul 24 01:53:00 http://processors.wiki.ti.com/index.php/PRU_Assembly_Instructions#Hardware_Loop_Assist_.28LOOP.29 Jul 24 01:53:04 "OP(256)" Jul 24 01:53:12 I was a little surprised Jul 24 01:54:15 with "0 to n" they mean up to (but not including) n... they could have been a bit clearer on that Jul 24 01:54:30 oh wait Jul 24 01:54:32 no they don'\t Jul 24 01:54:33 uh Jul 24 01:54:54 okay now I'm confused, lemme check Jul 24 01:57:11 oh wow. that's annoying... it looks like the assembler subtracts 1 from the loop count if it's an immediate value (rather than a register) Jul 24 01:57:40 that's confusing Jul 24 01:57:46 yes indeed Jul 24 01:58:15 the example uses it like "loop EndLoop, 5" and says "Peform the loop 5 times" Jul 24 01:58:57 lemme see if I can do a quick empirical check Jul 24 02:03:23 ok, so I added a loop-count.pasm in the fw directory containing: https://pastebin.com/raw/TzhPfWFB and compiled it with "make loop-count.bin" which also produced loop-count.dbg Jul 24 02:04:10 then changed the "debugging.py" script to load loop-count.dbg and trace through it Jul 24 02:04:40 here's the output: https://pastebin.com/raw/zmtXzXVC Jul 24 02:05:05 so it looks like the loop instruction does work the same for immediate and register operands Jul 24 02:06:22 so it just has a funky encoding... as a special exception it has an off-by-one in its immediate argument encoding, but fortunately the assembler hides this fact. the only visible result is that it accepts immediate operands up to 256 instead of up to 255 like most instructions Jul 24 02:07:10 I see Jul 24 02:07:17 my guess would be that if you specify 0 as immediate operand, it just encodes a jump to the loop-end Jul 24 02:07:39 so `loop label, 256` then `label:` takes exactly 256 cycles? Jul 24 02:08:33 it resuklts in exactly 256 loop iterations, i.e. 256 cycles (excluding the execution of the "loop" instruction itself!) if the loop body is a single cycle Jul 24 02:08:51 so I can't leave the body empty? Jul 24 02:09:00 no Jul 24 02:09:02 I assumed it would take a cycle to change the counter each time Jul 24 02:09:07 it doesn't Jul 24 02:09:11 wow Jul 24 02:09:49 `loop label, 256`, then `noop`, then `label:` takes 257 cycles? Jul 24 02:09:57 yes Jul 24 02:11:12 notice how in my little test, my loop body contained 2 nops, and the loop count was 3, so it spent 6 cycles inside the loop in total: it just kept alternating between the two nop instructions (https://pastebin.com/raw/zmtXzXVC) Jul 24 02:11:48 ah, I see! Jul 24 02:13:03 zero per-iteration loop overhead is a typical nice feature of hardware-assisted loops Jul 24 02:13:40 I haven't done much low-level programming like this before, unfortunately Jul 24 02:15:08 note that if you're unsure what your code is doing, my debugging.py script may be of use... it single-steps through the code, printing each instruction before it executes, as well as logging any changes to registers Jul 24 02:15:22 oh, cool! Jul 24 02:15:27 obviously it completely destroyes performance Jul 24 02:15:36 that seems extremely helpful Jul 24 02:16:53 I guess I won't have to manually count how many cycles my code should take Jul 24 02:18:33 we used to do that once :p Jul 24 02:18:43 you can also use the cycle-counter and stall-counter registers to double-check things Jul 24 02:18:51 back in microcontroller+Assembly days :D Jul 24 02:19:34 once enabled, it counts the total number of cycles as well as the number of "stalls", i.e. cycles during which no instruction was executed. the difference between the two values is the number of instructions executed since the counters were reset and enabled Jul 24 02:20:42 how might a stall happen? Jul 24 02:20:55 every load/store instruction causes *at least* one stall Jul 24 02:21:34 slp also causes at least a few stalls (although once the core enters low-power mode, its clock is gated and the counters freeze) Jul 24 02:21:57 xin/xout can in some cases cause stalls, e.g. when both pru cores try to access the same scratchpad on the same clock cycle Jul 24 02:22:47 ah Jul 24 02:23:21 I think these instructions are the only ones capable of causing stalls Jul 24 02:35:11 * zmatt zZ Jul 24 02:37:11 good idea Jul 24 02:38:48 Hey! Jul 24 02:39:00 I have been reading up on PRU too. Jul 24 02:39:02 Yea boy! Jul 24 02:39:41 I am on the clpru, C code generation tools section right now. Jul 24 02:41:27 section of what? Jul 24 02:42:26 http://downloads.ti.com/docs/esd/SPRUHV7/##viewer?document=%257B%2522href%2522%253A%2522%252Fdocs%252Fesd%252FSPRUHV7%2522%257D&url=introduction-to-the-software-development-tools-stdz0590792.html%23STDZ0590792 Jul 24 02:42:36 SPRUHV7! Jul 24 02:43:10 I keep reviewing in case I have missed anything. Jul 24 02:43:26 Since, I am terrible at this subject. I keep trying to better my skill set. Jul 24 02:44:04 subject = PRU Sub. Sys. Jul 24 02:48:27 set_ the PRU subsystem is your basic simplified RISC nano processor. zmatt mentioned that it is easier to program it in assembly. I have no idea. However to mess with it you must have a plan. IE something to do. Such as PWM, blinking an LED, or communicating with a chain of LED's Jul 24 02:49:25 Right. Jul 24 02:49:32 Start w/ LEDs is what I learned. Jul 24 02:49:49 So try the traditional blink an LED because it's simple and easy to spot if it works. Jul 24 02:50:09 I guess I am thinking the command line is abusive to me. Jul 24 02:50:19 I never figured out the command line for PRU. Jul 24 02:50:37 Hello I am unable to install the roboticscape npm Jul 24 02:50:41 using node 10 Jul 24 02:50:50 I would appreciate some help Jul 24 02:52:27 set_ I am not sure the command line works directly the PRU. I believe you have to compile a program then send it too it somehow. As I said I've not messed with it. I was considering using it for 3rd harmonic modulation but I got distracted as usual. With an FPGA. :D Jul 24 02:53:18 ksft: http://downloads.ti.com/docs/esd/SPRUHV6/##viewer?document=%257B%2522href%2522%253A%2522%252Fdocs%252Fesd%252FSPRUHV6%2522%257D&url=read-this-first-stdz1066557.html%23STDZ1066557 is the assembly language tools. Jul 24 02:53:27 GenTooMan: Oh. Jul 24 02:53:54 So, the command line usually starts out like clpru or pasm. Jul 24 02:53:55 Right/ Jul 24 02:54:11 set_: and I'm pretty sure ksft is using pasm, not clpru Jul 24 02:54:17 Right. Jul 24 02:54:21 which is also what I generally use Jul 24 02:54:34 (although my py-uio library does support loading executables produced by clpru) Jul 24 02:55:04 clpru feels a bit silly to me since it destroys one of the key features of pru: deterministic execution timing Jul 24 02:55:13 Oh. Jul 24 02:55:29 last time I checked, its code output quality was also quite awful Jul 24 02:56:04 (in part because the PRU instruction set just isn't designed to be target by a C compiler, in part because the compiler was (is?) just dumb as rocks) Jul 24 02:56:37 As Confucious says, "Rocks can be broken into pieces." Jul 24 02:57:48 rebooting with a kernel that supports my SD card reader, back in a sec Jul 24 02:58:54 I'm going to resume attempting to get more sleep... and probably fail, but we'll see :P Jul 24 02:59:21 Okay. **** ENDING LOGGING AT Wed Jul 24 02:59:57 2019