**** BEGIN LOGGING AT Thu Jul 25 02:59:57 2019 Jul 25 03:00:34 no idea, presumably some historical reason which they now can't change due to backwards compatibility Jul 25 03:01:06 same for r30 being the default link register, which is also an awful choice (which I reset to r3.w2: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/common.h#L3-L5 ) Jul 25 03:02:13 why is that a bad choice? Jul 25 03:02:30 r30 is used to control gpios Jul 25 03:02:46 ahh, I thought that number seemed familiar Jul 25 03:02:47 not the optimal place to store a return address :P Jul 25 03:02:59 what is code origin? Jul 25 03:03:22 the offset in IRAM where execution begins Jul 25 03:03:30 I have absolutely no idea why you'd ever want that to be non-zero Jul 25 03:03:37 how does the code tell the processor where to find itself? Jul 25 03:04:00 especially since you can't use IRAM for any purpose other than instructions... you can't even access its contents while the cpu is running Jul 25 03:04:09 what do you mean? Jul 25 03:04:20 where to find the code itself Jul 25 03:04:43 I don't understand what you mean by that Jul 25 03:04:50 sorry Jul 25 03:05:04 what exactly happens to the code origin? Jul 25 03:05:30 how does the processor find it, I mean? Jul 25 03:06:14 I can't remember how the assembler treats it *exactly* since it's been quite a while since I looked at it, and I know there's no reason to ever have it nonzero Jul 25 03:06:55 all right, guess I'll set it to zero Jul 25 03:06:55 the processor has no idea. nor does the code loader. the code loader needs to be *told* where to start execution, which needs to match the code origin used by the assembler Jul 25 03:07:07 py-uio by default assumes 0, but you can specify a different value Jul 25 03:09:07 looks like I need to run `pasm -b foo.pasm` to get the machine code? Jul 25 03:09:33 with the makefile in the fw/ directory you can just do "make foo.bin" Jul 25 03:09:40 but yeah Jul 25 03:10:02 I want to learn by doing as much as I can myself Jul 25 03:10:08 fair enough Jul 25 03:13:30 in /dev, I have uio0 through uio7 but no directory called uio Jul 25 03:13:43 then you haven't installed the udev rule as instructed in the README Jul 25 03:15:06 ah, sorry Jul 25 03:15:46 the "BeagleBoard-X15 only" heading applies only to that paragraph? Jul 25 03:16:34 libprussdrv hardcodes the assumption that uio0..uio7 belong to uio-pruss, but I refuse to do so since I use uio for all sorts of stuff (e.g. on our main development beaglebone I have 30 uio devices) and py-uio also supports the bbx15, which has two pruss instances, so I use udev rules to create symlinks for uio devices that make it clear what you're using Jul 25 03:16:39 no, only to that paragraph Jul 25 03:16:51 I've wondered whether or not that may be confusing... I should see if I can restyle that somehow Jul 25 03:17:42 maybe put those two paragraphs in some kind of box? Jul 25 03:18:13 or just put horizontal lines above and below them? Jul 25 03:21:42 there, I think it's clearer now Jul 25 03:22:37 I agree Jul 25 03:23:37 do you have an API reference? Jul 25 03:27:32 weeeeelllll..... Jul 25 03:28:47 there's a wiki page with some notes on memory access (that are quite dry and generic and even predate all of the pruss code I think) Jul 25 03:28:53 I forgot to have the core halt at the end Jul 25 03:28:57 core.halt() is failing Jul 25 03:29:09 core.halt() is failing? o.O Jul 25 03:29:16 failing how/ Jul 25 03:29:19 it should never fail Jul 25 03:29:25 it should normally also never be needed Jul 25 03:29:27 raise RuntimeError("PRU core failed to halt") Jul 25 03:29:33 ehhh Jul 25 03:30:05 and is there a difference between core.halted and core.state.halted? Jul 25 03:30:08 that makes me wonder if your code managed to lock up in a bad way Jul 25 03:30:48 no there isn't Jul 25 03:31:06 my code was the single line "add r0, r0, 1" Jul 25 03:31:39 followed by whatever garbage was in IRAM after that line :P Jul 25 03:31:43 after ".setcallreg r3.w2" and ".origin 0" Jul 25 03:31:48 ...oh Jul 25 03:31:54 how do I stop it? Jul 25 03:32:14 if core.halt() isn't working... ehh... ehm.... Jul 25 03:32:46 reboot? Jul 25 03:33:05 try "core.control = 0" Jul 25 03:33:24 oh, now it says it's halted Jul 25 03:33:36 yeah it probably unwedged itself eventually Jul 25 03:33:45 reboot might still be needed, who knows what happened to the system Jul 25 03:33:56 especially since pru can access any memory and any resources on the system Jul 25 03:34:08 and you probably just executed a bunch of random bits as code Jul 25 03:34:11 I did it! Jul 25 03:34:13 it works! Jul 25 03:34:31 I fixed the assembly and loaded it and ran it successfully Jul 25 03:34:37 \o/ Jul 25 03:34:54 I guess I should be extremely careful about security Jul 25 03:35:17 or not, because no one's making a malicious lighting fixture Jul 25 03:35:24 you can also use pruss.initialize(fill_memories=True) as extra safety net... it will fill all pruss data memories with zeros and will IRAM for both cores with the halt instruction Jul 25 03:37:08 er, why does Emacs think C-backspace is C-h? Jul 25 03:37:22 if your code doesn't require access to anything outside pruss, you can disable the pru cores' master ports to the L3 interconnect by doing pruss.cfg.standbyreq = True Jul 25 03:37:40 this would mostly protect against accidents, since the pru cores *can* reenable that access themselves Jul 25 03:38:02 I'm a vim user, so I can't help you with any emacs questions Jul 25 03:39:28 ah, looks like weird terminal interactions Jul 25 03:41:01 huh, it worked even though I forgot to call pruss.initialize() Jul 25 03:41:27 pruss.initialize() is not a hard requirement, it just tries to reset pruss to a clean slate as much as possible Jul 25 03:42:01 e.g. if you want to inspect the state of pruss while it's running without touching it, you must *not* call pruss.initialize() Jul 25 03:42:25 ah Jul 25 03:42:32 the only hard requirement to be able to load code onto a core is that the core is halted Jul 25 03:54:35 the GPIO pins are all 3.3 V, right? Jul 25 03:54:41 yep Jul 25 04:03:20 which bits in r30 correspond to which pins? Jul 25 04:03:32 and is there something I have to do to connect them? Jul 25 04:04:35 you can use the config-pin utility to connect them Jul 25 04:05:38 (random remark: I just added a summary section at the top of https://github.com/mvduin/py-uio/wiki/Memory-access ) Jul 25 04:08:05 as for where you can find pru in/out pins, my pins spreadsheet ( https://goo.gl/Jkcg0w ) has both overviews of the P9 and P8 headers (in the sheets named "P9" and "P8") and an overview of all pru-related signal (the "PRU" sheet), which includes to which expansion header pin on the beaglebone they map (if any) Jul 25 04:14:59 not sure I understand the format of those tables... Jul 25 04:15:26 yeah, some could *probably* use a legend XD Jul 25 04:16:38 P9/P8 shows the pins for each expansion header in the centre (with some coloring that you can ignore for now), then next to each pin (outward from the center) are various modes available for that pin Jul 25 04:17:22 if those include for example "pru 0 in 3" then you can configure that pin to pru_in mode to get that signal to show up as bit 3 of r31 for pru core 0 Jul 25 04:18:30 if the modes available includes "pru 1 out 9" then configuring that pin to pru_out mode (or does config-pin call it "pruout" without the underscore? I'm not sure, I never use config-pin) will make it output bit 9 of r30 of pru core 1 Jul 25 04:19:25 r31 corresponds to P9? Jul 25 04:19:38 no Jul 25 04:19:51 inputs are read via r31, outputs use r30 Jul 25 04:19:54 ah Jul 25 04:20:14 r30 is a normal register, whose bits just happen to be used as the source for output signals Jul 25 04:21:08 r31 is not a normal register, reading from it yields various status signals, including gpios inputs and two signals from the interrupt controller (in bits 30-31), while writing to it sends an event to the interrupt controller Jul 25 04:22:51 the "PRU" tab shows similar info, but 1. it's sorted by functionality 2. it includes pins not available on the beaglebone's expansion headers Jul 25 04:23:33 most signals can be mapped to multiple pins, which is why you'll see repeated blocks there Jul 25 04:24:15 got it, I think Jul 25 04:24:54 can you see my selection on the PRU tab? (I think google docs shows my selection to other viewers) Jul 25 04:25:08 which is row 11 currently Jul 25 04:26:21 yes Jul 25 04:27:15 so, that line is a pin that supports four pru-related modes: pru 0 in 8, pru 0 out 8, pru 1 in 0, pru 1 out 0 Jul 25 04:27:30 but it's not available on the BBB's expansion headers, since the BBB column is blank Jul 25 04:27:49 ahh, got it Jul 25 04:28:41 what are the columns labeled "F"? Jul 25 04:29:14 function (i.e. the mode number)... not important if you're using config-pin, it's the lower-level way of specifying a pin mode Jul 25 04:30:23 basically it's the value written (along with some other config bits) into the appropriate element of the pin configuration register array Jul 25 04:30:30 the "Pin" column is the index into that array Jul 25 04:30:52 config-pin instead uses names for both Jul 25 04:31:17 is there a way to check the current mode with config-pin? Jul 25 04:31:28 (but this spreadsheet isn't documentation for config-pin, it's documentation for the hardware) Jul 25 04:32:11 yeah, try "config-pin $PIN" or "config-pin -l $PIN" or something like that, where $PIN is the pin name... I'm not 100% certain since, like I said, I don't use config-pin myself :P Jul 25 04:32:47 that just lists the modes Jul 25 04:33:04 it doesn't show the current mode? that's odd Jul 25 04:33:10 maybe try config-pin --help Jul 25 04:33:25 ah, it's -q Jul 25 04:33:59 another way to check the current pin configuration is using my show-pins utility, which provides a detailed and colorful overview: https://github.com/mvduin/bbb-pin-utils/#show-pins Jul 25 04:34:31 and I've even documented its output format :D Jul 25 04:39:57 what happens to pruout pins when the PRU is halted? Jul 25 04:40:31 pruout pins simply reflect the r30 register of the core, whether the core is running or not is irrelevant Jul 25 04:40:41 if the core is halted you can modify core.r30 using python code Jul 25 04:40:49 makes sense Jul 25 04:42:16 pruss.initialize() will call core.full_reset() on both cores, which will reset all registers (including r30) to zero Jul 25 05:03:02 what's the best way to delay for more than a few microseconds? Jul 25 05:03:35 I mean, unless you have something else to do for your pru core, spinning in a loop is still a perfectly viable option Jul 25 05:03:57 but it would take several thousand lines of assembly to use the loop instruction Jul 25 05:04:30 one loop with 256 iterations and n noops inside delays for about n microseconds Jul 25 05:04:42 several hundred lines, for what I'm trying to do Jul 25 05:05:26 my delay-macro works fine for up to 0xffffffff iterations (of 10ns each, which is nearly 43 seconds) Jul 25 05:05:29 do I write a loop with a register as the iterator and one of the branch instructions? Jul 25 05:05:44 oh, okay, I'll look at how you do that Jul 25 05:06:53 https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/common.h#L50-L52 Jul 25 05:07:13 where n would be a register (or register field) that's initialized to your desired delay time (in 10ns units) Jul 25 05:07:23 got it, thanks Jul 25 05:07:57 you could even stick a loop/nop-based delay loop inside it to further beef it up Jul 25 05:09:26 for example loop inner_loop_end, 198; nop; inner_loop_end: inside the delay-loop would make the outer loop use units of microseconds Jul 25 05:10:16 I chose to avoid the use of "loop" in my macro to ensure it could be used inside a hardware-loop (among other reasons) Jul 25 05:10:31 er, is "noop" an instruction? Jul 25 05:10:34 nop Jul 25 05:10:36 not noop Jul 25 05:10:38 ah Jul 25 05:10:41 oh actually Jul 25 05:10:42 lol Jul 25 05:10:46 https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/common.h#L30-L32 Jul 25 05:10:52 never mind, I declared it myself it seems Jul 25 05:10:54 still, I don't see it documented on the TI wiki Jul 25 05:10:57 oh Jul 25 05:11:02 I completely forgot I did Jul 25 05:11:04 I see Jul 25 05:11:13 it's just so common to have an actual "nop" mnemonic Jul 25 05:11:53 I think on ARM "nop" actually expands to a similar thing... nop = mov r0, r0 = and r0, r0, r0 Jul 25 05:12:19 if I remember correctly Jul 25 05:13:15 it's possible I'm mistaken or confusing things with some other architecture Jul 25 05:13:19 like PowerPC or so Jul 25 05:13:58 hmm, ARM Thumb at least has a separate NOP instruction. you know, maybe I'm actually thinking of PowerPC... oh well, doesn't really matter anyway Jul 25 05:18:08 macros are expanded by the assembler, right? Jul 25 05:18:14 yep Jul 25 05:21:04 can macro parameters be anything? Jul 25 05:21:32 pretty much I think yeah Jul 25 05:22:16 grammatically it probably has to be an expression or something, or maybe even just an arbitrary token-sequence, I'm not sure Jul 25 05:22:20 (thank you again for putting up with all my questions) Jul 25 05:22:34 it's fine, I'm watching some youtube at the same time Jul 25 05:33:41 what is a "byte burst"? Jul 25 05:34:11 a concept that only exists in the heads of whoever picked the awful names for the load/store instructions :D Jul 25 05:35:58 but basically lbbo ®, addr, offset, n is like memcpy( ®, addr+offset, n ); in C, if we pretend you can make a pointer into the register file Jul 25 05:36:42 it just loads n bytes from address addr+offset and writes them into n consecutive bytes of the register file at ® Jul 25 05:39:26 (&rX is offset 4*X in the register file, &rX.bY and &rX.wY are offset 4*X+Y in the register file) Jul 25 05:40:01 I see... Jul 25 05:46:22 if I copy just one byte into a register, will it do what I expect, or will endianness mess it up? Jul 25 05:46:46 and does lbbo just add its second and third arguments? Jul 25 05:48:22 1. that depends on what you want 2. yes it does Jul 25 05:49:01 note that lbbo &r3, addr, offset, 1 just copies one byte, into the first (lowest / least significant) byte of r3 Jul 25 05:49:07 the remaining three bytes of r3 remain unchanged Jul 25 05:49:14 I want the lowest bit of the register to equal the lowest bit of the byte I copied Jul 25 05:49:46 and the nth bit of the register to equal the nth bit of the byte I copied, for 0<=n<=7 Jul 25 05:50:02 yes, the pru cores on the am335x are configured into little-endian mode Jul 25 05:50:50 it looks like the second parameter to lbbo has to be a register? Jul 25 05:51:11 while the third can be register or immediate, yep Jul 25 05:51:19 that's the only difference between the two Jul 25 05:51:29 so to read from the beginning of the memory, I have to put 0 into a register first? Jul 25 05:52:03 also, the second parameter can be one of the 32 "constant registers" c0-c31, although (for reasons that are unclear to me) that also requires changing the opcode to lbco Jul 25 05:52:17 you can use a constant register for that Jul 25 05:52:58 c24 is the usual choice for that, although c28 also defaults to 0 Jul 25 05:53:53 what are constant registers? Jul 25 05:54:00 https://pastebin.com/raw/kdC9LhVB the list of constant registers on the am335x, and what they point to Jul 25 05:54:38 do those places in memory have special meanings? Jul 25 05:55:04 each line has a comment saying what it points to Jul 25 05:56:12 but are those just conventions or will I break something if I accidentally change that memory? Jul 25 05:56:19 note that c24-c31 are partially configurable. when using py-uio, you can assign values to core.c24 - c31 (also accessible as array, core.c[24:32]) as long as the core is halted, keeping in mind that not all bits of those constant registers can be modified Jul 25 05:56:37 those are not conventions, those are what's actually located at those addresses Jul 25 05:57:30 I don't know what half of those stand for Jul 25 05:57:45 then you probably don't want to access those addresses :) Jul 25 05:58:00 I'll try to avoid it! Jul 25 05:58:30 in general, any read/write to an address >= 0x80000 will exit the pru subsystem and access *some* resource somewhere on the SoC (or it will fail) Jul 25 05:58:31 what memory can I safely use? Jul 25 05:58:34 "core data ram"? Jul 25 05:58:58 so, there are three data memories inside pruss Jul 25 05:59:34 using py-uio those are pruss.dram0-dram2 Jul 25 06:00:20 and the uio_pruss driver reserves a chunk of main (ddr3) memory for use by pruss, which is pruss.ddr Jul 25 06:00:24 (see also https://github.com/mvduin/py-uio/wiki/Memory-access#summary ) Jul 25 06:00:58 officially dram0 is reserved for pru core 0, dram1 for pru core 1, and dram2 is intended to be shared by both Jul 25 06:01:09 in practice, both cores can access all three memories Jul 25 06:01:38 on the am335x, dram0 ad 1 are 8 KB each, dram2 is 12 KB Jul 25 06:01:42 what offsets are those at? Jul 25 06:02:43 from the perspective of pru core 0, dram0 is at address 0, dram1 is at address 0x2000, dram2 is at address 0x10000. for pru core 1, dram0 and dram2 swap places, so dram1 is at address 0 while dram0 is at 0x2000 Jul 25 06:02:54 so in both cases, the core's private data ram is at offset 0 Jul 25 06:03:09 got it Jul 25 06:03:11 in py-uio, this is also accessible as core.dram Jul 25 06:03:29 (including while the core is running) Jul 25 06:04:49 for the future: keep in mind that although both cores can access all three local memories, they cannot simultaneously access the *same* local memory. accessing shared memory therefore requires some care if absolutely deterministic execution timing is required Jul 25 06:05:11 on attempted simultaneous access, one of the cores will be forced to stall Jul 25 06:10:14 how does your delay macro work with values larger than 256? Jul 25 06:10:21 255* Jul 25 06:10:38 its argument, n, must be a register or register-field initialized to your desired delay time Jul 25 06:10:49 ah Jul 25 06:11:04 if you pass an 8-bit register field, then its maximum count is 255, but if you pass a full 32-bit register, then its maximum count is 0xffffffff Jul 25 06:11:44 when I try to use loop, it says "Instruction illegal with specified core version" Jul 25 06:11:58 pass -V3 as option Jul 25 06:12:38 again, maybe consider using the Makefile in py-uio's "fw" directory, or at least looking at it for inspiration :) Jul 25 06:13:25 fine Jul 25 06:13:39 am335x pruss has pru v3 cores Jul 25 06:19:01 (the "loop" instruction was introduced in pru v3) Jul 25 06:22:33 does the P8 expansion header not have any fixed 3.3 V pins? Jul 25 06:22:41 nope Jul 25 06:22:48 power is only available on the P9 header Jul 25 06:23:25 it would be the same effect but with more work to use a GPIO pin that I leave on all the time, right? Jul 25 06:23:52 I was about to suggest that *as a joke* ... you can't draw any significant amount of power from a gpio Jul 25 06:24:00 ah Jul 25 06:24:13 I don't think I need very much power, but I guess I'll still use the other one Jul 25 06:25:19 depending on the pin, you can draw 4 or 6 mA, but this may already result in the high-level voltage dropping from 3.3v to 2.85v Jul 25 06:26:02 drawing more than that exceeds specifications and may damage the pin in the long term (or the short term, if the limits are substantially exceeded) Jul 25 06:26:17 the chip I'm using says the maximum input current is 1 mZ Jul 25 06:26:19 mA* Jul 25 06:27:04 then *maybe* you can get away with it, but don't expect the output to remain 3.3v, I wouldn't be surprised if it drops below 3v even Jul 25 06:27:32 I strongly urge you to consider just running a wire to the P9 header for your power needs :) Jul 25 06:27:43 I am Jul 25 06:28:22 as I'm sure you can tell, I'm extremely experienced with electronics Jul 25 06:29:35 I hope nothing explodes... Jul 25 06:30:53 don't worry, any explosions are likely to have very limited radius Jul 25 06:31:06 that's good Jul 25 06:31:17 I'm counting on not being able to do too much damage with only 3.3 V Jul 25 06:31:57 but I'm also periodically checking to make sure the chip isn't heating up Jul 25 06:32:48 I mean, on TI's support forum I've seen a post from someone who managed to get smoke and flame coming from the AM335x itself... but iirc he was using it in an environment of 90 degrees celsius (and *probably* combined that with somehow making a short-circuit or something) Jul 25 06:34:03 huh Jul 25 06:34:08 it's room temperature here Jul 25 06:34:15 and I'm trying very hard not to short circuit it Jul 25 06:34:33 and if you do short-circuit, there's a decent chance the PMIC will notice and simply power off your BBB Jul 25 06:34:40 oh, cool! Jul 25 06:35:54 the most common way to cause damage to the BBB probably isn't short-circuit but overvoltage, especially when trying to interface it to independently powered electronics (especially anything involving voltages greater than 3.3v, but even 3.3v can kill the BBB if it's powered off) Jul 25 06:36:23 unfortunately, the thing I'm going to be trying to send data to has its own power Jul 25 06:36:30 and I forgot to get an optocoupler today Jul 25 06:37:09 but the pins coming out of it are exposed, and I don't die when I touch it Jul 25 06:37:20 it isn't supposed to output anything on them Jul 25 06:37:34 do you have a datasheet / electrical specs? Jul 25 06:38:16 for the thing I'm sending data to? Jul 25 06:38:21 yes Jul 25 06:38:30 I have the specification of the protocol it's supposed to use Jul 25 06:38:37 I don't care about the protocol really Jul 25 06:38:48 unless that includes electrical specifications Jul 25 06:38:53 a little Jul 25 06:38:56 it's DMX Jul 25 06:39:09 DMX requires an RS485 driver Jul 25 06:39:14 yes, I have one Jul 25 06:39:22 okay, that driver will have electrical specs Jul 25 06:39:29 yeah, I have that datasheet Jul 25 06:40:13 the BBB isn't interfacing via DMX to some fixture, the BBB is interfacing via LVCMOS signalling to your RS485 driver Jul 25 06:40:36 all right Jul 25 06:41:23 also, you shouldn't need any opto-coupler at the driver side, in fact a dmx controller is supposed to be non-isolated iirc Jul 25 06:41:38 I was hoping to implement RDM eventually Jul 25 06:41:44 that doesn't change things Jul 25 06:41:48 it doesn't? Jul 25 06:41:55 someone suggested using an optocoupler... Jul 25 06:41:57 isolation can't change based on transmission direction Jul 25 06:42:01 someone was wrong Jul 25 06:42:11 the controller is the grounding point for your dmx line Jul 25 06:42:34 dmx fixtures are required to be isolated Jul 25 06:43:09 (which is usually probably achieved by using an isolated power supply rather than using an opto-coupler) Jul 25 06:43:14 I'm a little surprised you know so much about DMX Jul 25 06:43:29 I worked for a company that produced dmx controllers and dmx dimmers Jul 25 06:43:34 ah Jul 25 06:43:52 I've written some of the firmware for aforementioned dmx controllers Jul 25 06:44:05 cool! Jul 25 06:44:18 so... yeah, that's why I know a fair thing about it :) Jul 25 06:44:49 why are fixtures isolated? Jul 25 06:44:58 to avoid ground-loops Jul 25 06:45:22 where might that happen? Jul 25 06:45:50 oh, nevermind, I get it! Jul 25 06:46:08 power ground (earth) -> controller -> dmx ground -> non-isolated-fixture-that-ignored-the-standard -> power ground Jul 25 06:46:55 that can easily be a loop of hundreds of meters Jul 25 06:47:28 yeah Jul 25 06:47:45 in case of e.g. outdoor events, the controller and fixture might also be on separate power generators.... who knows what sort of iffy power infra they might be on Jul 25 06:48:23 with a bit of luck and effort, you might be able to manage to melt the insulation of your dmx cable :D Jul 25 06:48:31 fun! Jul 25 06:49:13 whew, almost just connected pin 1 to 3.3 V Jul 25 06:49:42 I would advise against that Jul 25 06:50:29 especially since the 3.3v output from the beaglebone is, unfortunately, not coming from the PMIC but from a separate LDO which doesn't have any monitoring like the PMIC supplies have Jul 25 06:50:35 uh oh Jul 25 06:50:45 well, good thing I didn't Jul 25 06:51:02 yeah I'm not a fan of the BBB's power tree Jul 25 06:51:12 I don't know how to solder, so I was planning to test this at first by holding the wires up against the pins on the back of my XLR connector Jul 25 06:51:26 I'm not sure how much I trust my wire-holding ability Jul 25 06:51:44 what rs485 driver are you using? Jul 25 06:51:56 MAX3483 Jul 25 06:51:59 https://datasheets.maximintegrated.com/en/ds/MAX3483-MAX3491.pdf Jul 25 06:52:32 I've connected pins 2 and 3 of that chip directly to each other Jul 25 06:52:34 is that bad? Jul 25 06:52:43 nope, it's exactly designed for that Jul 25 06:52:47 great Jul 25 06:53:00 which output is DMX pin 2 and which is pin 3? Jul 25 06:53:10 (as long as you then also connect that pair to something that's pulling it high or low) Jul 25 06:53:33 I connected it GPIO to a GPIO pin Jul 25 06:53:41 er, directly to a GPIO pin* Jul 25 06:54:46 okay, it didn't work, but nothing exploded Jul 25 06:54:57 not even a small explosion! Jul 25 06:55:43 lemme open The Standard... especially since if you don't intend to keep the driver enabled continuously (i.e. if you want to support RDM eventually) you'll also need a biasing circuit Jul 25 06:56:09 I put a 120 Ohm resistor between DMX pins 2 and 3 Jul 25 06:57:10 I think the biasing is pretty flexible, but I'm realizing I might think that because of the same person who recommended an optocoupler Jul 25 06:57:34 yeah that's sufficient for dmx, but not for RDM. i.e. it's fine provided you leave the driver enabled continuously Jul 25 06:58:27 if I connect the wires, then enable the driver starting with the break, will it not work? Jul 25 06:59:42 btw, when you said "max 1mA" earlier, were you talking about the rs485 driver? because it draws 1.1 mA typ 2.2 mA max with the driver enabled *when unloaded*. it's not unloaded in your case, it has 120Ω load (if nothing is connected) or 60Ω load (when a terminated dmx line is connected) Jul 25 07:00:42 under short-circuit conditions (which a dmx controller is required to tolerate iirc), it is limited at 250 mA (max) Jul 25 07:00:55 where do you see that? Jul 25 07:01:14 oh! Jul 25 07:01:21 max3483 datasheet Jul 25 07:01:33 page 3 Jul 25 07:01:41 yeah, that makes a lot more sense Jul 25 07:01:47 good thing I'm not powering it with a GPIO pin Jul 25 07:01:51 :D Jul 25 07:02:05 in general, drivers require substantial power Jul 25 07:02:19 yeah, I thought that number seemed strangely low Jul 25 07:02:36 the DMX spec says the mark should be at least 0 seconds Jul 25 07:02:40 anyway, enabling the driver only when transmitting (like you would in case of RDM) is only permitted if you have a proper biasing circuit Jul 25 07:02:57 without biasing circuit, you must leave the driver enabled continuously Jul 25 07:03:07 otherwise the line becomes indeterminate Jul 25 07:03:12 that makes sense Jul 25 07:03:28 for now, I'm just trying to turn the light on, which a single packet should be able to do, right? Jul 25 07:03:37 basically the biasing circuit "drives" the line to mark-state whenever noone is driving it Jul 25 07:03:37 so there isn't any time I'm not transmitting? Jul 25 07:04:11 without biasing circuit, you have to drive the line to mark-state whenever you don't have anything else to transmit Jul 25 07:05:23 all right, I changed the end of my assembly to leave it in mark state Jul 25 07:05:45 does it matter which I connect to DMX pin 2 and which to 3? Jul 25 07:05:50 it does Jul 25 07:05:57 which is which? Jul 25 07:06:41 in idle / mark / "high" / logic-1 state, pin 3 should at a higher voltage than pin 2 Jul 25 07:07:37 so pin 5 of the chip is DMX pin 2 and pin 6 of the chip is DMX pin 3? Jul 25 07:07:49 er, no Jul 25 07:07:53 so A = dmx pin 3, B = dmx pin 2 Jul 25 07:08:06 yeah, that's what I meant Jul 25 07:08:10 (I think) Jul 25 07:09:11 hmm, the fixture still isn't turning on Jul 25 07:09:44 also, some fixtures will shut down / revert to a default state if nothing is tramitted for a while (e.g. a few seconds) Jul 25 07:10:26 and then I have to push a button or something to turn it back on? Jul 25 07:10:32 no, just send packets Jul 25 07:10:44 that's what I'm trying to do Jul 25 07:10:48 a single packet should at least elicit a momentary response Jul 25 07:11:24 assuming the fixture is at address 1, sending a break followed by a zero-byte followed by the data for the fixture should suffice to get it to react Jul 25 07:12:00 if it doesn't react, then you have probably messed up... somewhere... either in software or in hardware Jul 25 07:12:04 yep Jul 25 07:12:09 I'll look at those two things Jul 25 07:12:21 I hope you have an oscilloscope or logic analyzer to examine various lines :D Jul 25 07:12:30 I don't, unfortunately Jul 25 07:13:06 maybe I can use your debugger to look for software problems Jul 25 07:13:57 obviously running your program under my debugger will destroy all timing, and you'll probably want to change your delay loops to reduce the number of iterations Jul 25 07:14:05 but it may be able to catch dumb logic errors Jul 25 07:14:29 but can I just have it output to a file or something whatever's being written to the GPIO pin?? Jul 25 07:14:31 pinn?* Jul 25 07:14:34 pin?** Jul 25 07:14:57 also, to verify whether the hardware connections are right, you could try using an UART instead of PRU to generate signals Jul 25 07:15:29 I don't think UART can do the break and the start and stop bits correctly Jul 25 07:15:38 or you could try leaving the rs485 receiver enabled continuously, and connect its receive-output to the rxd of an uart to see if you can correctly receive the signal you're generating Jul 25 07:16:30 an uart can do all of that, you just have very poor control over the length of the break or mark-after-break Jul 25 07:17:02 and you can't have more than 2 (or maybe 3) stop bits (which some reaaaaaly crappy fixtures may require) Jul 25 07:18:08 it definitely is not a high-quality fixture Jul 25 07:18:36 OH! Jul 25 07:18:39 I need two stop bits! Jul 25 07:18:45 officially yes Jul 25 07:18:56 maybe that's it? Jul 25 07:18:56 most devices probably tolerate a single stop bit Jul 25 07:19:10 in fact they might be required to, I'd need to check Jul 25 07:19:43 nope, still doesn't work Jul 25 07:21:53 so, when testing with an uart, you could just create a large (albeit somewhat variable) number of stop bits by just writing the bytes one-by-one to the uart Jul 25 07:22:26 if you do that in linux on the BBB, that probably creates an inter-byte gap of dozens of microseconds Jul 25 07:23:05 you could insert an explicit delay to further increase it if you want to Jul 25 07:23:19 doesn't the UART send a parity bit and a start and stop bit? Jul 25 07:23:37 yes, where the parity bit is optional and not enabled by default Jul 25 07:23:43 oh Jul 25 07:23:59 but wouldn't the start or stop bit interfere with the continuous high or low voltage? Jul 25 07:24:10 ?? Jul 25 07:24:40 I have no idea what you mean Jul 25 07:25:20 if I want the voltage to be high for a few dozen microseconds, and I send 0xFF a few times with UART, won't the start or stop bit cause the voltage to go low briefly? Jul 25 07:26:31 basically to send a dmx packet (with shitty but acceptable timing) using an uart you'd do: enable break; wait 176us; disable break; wait 12us; for each byte { send byte; wait a bit; } Jul 25 07:26:47 if you want it to be high for a few dozen microseconds, don't send 0xff Jul 25 07:26:53 don't send anything Jul 25 07:26:58 high is its default state Jul 25 07:27:00 ...oh Jul 25 07:32:16 sounds like a pru job to me Jul 25 07:33:04 it is Jul 25 07:33:09 he is using pru Jul 25 07:33:26 but right now he doesn't know if it's not working because his pru program is generating a bad signal, or if there's a hardware issue Jul 25 07:33:35 testing with a regular uart can verify the hardware Jul 25 07:33:58 does py-uio have a way to run a specified number of steps? Jul 25 07:34:25 nothing better than just single-stepping that many times Jul 25 07:34:59 I don't yet have any support for software breakpoint (i.e. temporarily replacing an instruction with "halt" and then restoring the original instruction once it halts at that location) Jul 25 07:36:34 ooh, that would be useful Jul 25 07:37:00 it's not very hard to do, you can freely modify iram whenever the core's halted Jul 25 07:37:54 looking at the signal with a scope could tell something about the signal, I guess. Jul 25 07:38:19 09:12 <@zmatt> I hope you have an oscilloscope or logic analyzer to examine various lines :D Jul 25 07:38:22 09:12 < ksft> I don't, unfortunately Jul 25 07:38:23 if I had one I'd be doing that Jul 25 07:38:28 thinkfat: way ahead of you ;) Jul 25 07:38:36 zmatt: :) Jul 25 07:39:14 but, a rigol 1054Z is cheap, there's no reason not to have one ;) Jul 25 07:40:24 I've never had a use for one before Jul 25 07:41:05 yeah, that's the point with test equipment. you don't usually need it, but when you're in deep shit and you don't have one ... Jul 25 07:41:06 wait, how long is a clock cycle? Jul 25 07:41:21 it's 5 ns, isn't it? Jul 25 07:41:25 I thought it was 4 ns Jul 25 07:42:37 5ns Jul 25 07:42:51 all my timing is off! Jul 25 07:42:55 :) Jul 25 07:44:04 nope, still not working Jul 25 07:46:59 is there a way to count the number of cycles my code ran for? Jul 25 07:48:13 core.run( profiling=True ) Jul 25 07:48:31 then once it's halted, ( cycles, instrs ) = core.profiling_sample() Jul 25 07:49:21 hmm, why are those different? Jul 25 07:49:48 any lbbo instruction Jul 25 07:50:13 (more generally lbbo/lbco/sbbo/sbco) Jul 25 07:50:41 do those take two cycles? Jul 25 07:51:23 3 at minimum Jul 25 07:51:49 huh, they seem to have taken almost exactly two cycles each Jul 25 07:51:53 2+n cycles to load n words (where a "word" means an aligned 4-byte unit, or any part thereof) Jul 25 07:51:56 unless I did something wrong... Jul 25 07:52:34 I don't think there's any possibility for lbbo to take 2 cycles Jul 25 07:52:42 3 is the minimum Jul 25 07:52:48 I have 1064 more cycles than instructions Jul 25 07:52:57 I should be loading each of the 512 bytes Jul 25 07:53:13 might lbco take two cyclesS? Jul 25 07:53:22 cycles* Jul 25 07:53:55 lbbo/lbco takes 3 cycles total, i.e. 2 cycles in addition to the one cycle an instruction requires normally Jul 25 07:54:25 hence 512 lbbo instructoins would result in cycles >= instrs + 2 * 512 Jul 25 07:54:36 is there a way to definitively check how many times a particular instruction was run? Jul 25 07:55:38 put an "add" instruction next to that instruction to increment a counter in a register, check that register after execution? Jul 25 07:55:53 ah, I'll do that Jul 25 07:57:02 it says I ran it 512 times Jul 25 07:57:35 and exactly 1024 more cycles than instructions Jul 25 07:57:38 OH Jul 25 07:57:45 that means each one takes three cycles! Jul 25 07:57:50 :) Jul 25 07:58:47 huh, why is it taking fewer cycles now? Jul 25 08:00:48 oh, nevermind, it's because I fixed the timing Jul 25 08:00:56 lol Jul 25 08:04:47 I'm well within the timing tolerance in the spec Jul 25 08:12:52 does profiling slow it down? Jul 25 08:12:54 nope Jul 25 08:32:14 I turn P8_11 high with `set r30.t15`, right? Jul 25 08:34:24 assuming you're running on core 0 and the pin is configured right, yep Jul 25 08:34:51 maybe double-check with my show-pins utility ( https://github.com/mvduin/bbb-pin-utils/#show-pins ) ... sudo show-pins | grep P8.11 Jul 25 08:35:12 config-pin says it's pruout Jul 25 08:35:37 then presumably it is :) Jul 25 08:36:25 I was just suggesting a second way to verify that (confirming the same thing in two different ways is generally considered superior to doing the exact same check twice) Jul 25 08:37:01 "ocp/P8_11_pinmux (pinmux_P8_11_pruout_pin)" Jul 25 08:37:09 does that mean it's set correctly? Jul 25 08:37:33 probably, but I'd be more interested in the information immediately before that on the line Jul 25 08:37:51 13 fast rx down 6 pru 0 out 15 Jul 25 08:38:03 "pru 0 out 15" yep, then it's set right Jul 25 08:38:54 brb Jul 25 08:45:45 SOMETHING HAPPENED Jul 25 08:45:58 I took out the resistor I put between DMX pins 2 and 3 Jul 25 08:46:07 the light turned on, then faded out Jul 25 08:53:53 hmm, now it seems to have stopped working Jul 25 08:55:05 it works inconsistently, and sending packets every half second doesn't help Jul 25 08:56:08 and even though this fixture is supposed to have a few channels with at least different colors, I can only get it to turn on green Jul 25 08:56:37 what fixture is it? Jul 25 08:57:20 some cheap LED par I got on ebay Jul 25 08:58:09 this or something very similar: https://www.ebay.com/itm/Eliminator-Mini-Par-RGBW-LED-12x-1-Watt-RGBW-LED-Par-Light/362077289626 Jul 25 08:59:02 note btw that termination at the driver side is not required (when driving the line from one end), but termination on at least one end *is* required Jul 25 08:59:35 it should be allowed, though, right? Jul 25 08:59:49 allowed, and for RDM it's even required Jul 25 09:00:36 that's why I did it Jul 25 09:00:50 termination at the end of the line is more important in any case, at least until RDM Jul 25 09:01:42 I guess I'll focus on getting it to work without the termination for now Jul 25 09:13:57 it should have little or not impact Jul 25 09:14:02 *little or no Jul 25 09:14:11 provided your dmx line is terminated at the end Jul 25 09:15:30 well, it occasionally works without it and never seems to work with it Jul 25 09:18:14 that suggests hardware problems to me, and/or a dmx signal that's just on the edge of being acceptable by the fixture Jul 25 09:21:26 that could be the fixture's fault as easily as it could be mine Jul 25 09:23:57 well like I said previously, you could try using an uart to generate a signal (even if crappy) and/or use an uart to try to receive the signal you're generating with pru Jul 25 09:33:25 https://photos.app.goo.gl/bJT1pLgQ51eGwJ8L9 so, just for clarity, here are suggested schematics for the controller, a basic non-RDM version and an RDM-capable version: https://photos.app.goo.gl/bJT1pLgQ51eGwJ8L9 Jul 25 09:33:36 woops, didn't mean to include the link twice Jul 25 09:34:22 nRE can either be tied to 3.3v (receive continuously) or to DE (to mute your own transmissions) Jul 25 09:35:16 so I'll just receive my own transmissions if I have it both transmitting and receiving? Jul 25 09:35:18 the pull-up on RxD can be omitted if nRE is tied high. if nRE is tied to DE, then using internal pull-on on the RxD line may suffice (but in that case do double-check that internal pull-up is enabled on that pin) Jul 25 09:35:23 yep Jul 25 09:35:30 which may be useful for debugging Jul 25 09:36:33 the RDM spec says those resistor values are only for 5 V and need to be recalculated otherwise Jul 25 09:36:40 but it doesn't clearly specify how to Jul 25 09:38:02 well you don't need to, you can just grab 5V from pin 7 or 8 of P9 Jul 25 09:38:44 but the RS-485 chip only outputs up to 3.3 V Jul 25 09:39:05 .. and ? Jul 25 09:39:07 oh, does that not matter? Jul 25 09:39:22 I guess the idle voltages don't need to depend on the voltage I'm using when transmitting Jul 25 09:40:09 nope Jul 25 09:40:35 cool, that was easy Jul 25 09:40:46 keep in mind the line bias circuit has to be compatible with whatever drivers are in all the RDM-capable fixtures on your dmx line Jul 25 09:41:01 and you have no idea whether they use 5V or 3.3V drivers internally Jul 25 09:41:19 compatible in what way? Jul 25 09:41:21 nor do you need to know, that's just an implementation detail, the spec already dictates the voltages on the line Jul 25 09:41:28 shouldn't the standard biasing voltag-- Jul 25 09:41:30 oh Jul 25 09:41:46 that's just as true for yourself Jul 25 09:41:51 oh, I get it Jul 25 09:42:06 your transceiver is just one of the many transceivers on the dmx bus Jul 25 09:42:15 while the line biasing is basically "part of" the dmx bus Jul 25 09:42:43 well, thank you so much for helping me for the last eight hours Jul 25 09:42:52 I don't know what time zone you're in, but I need to go to sleep Jul 25 09:43:44 officially? CEST. in practice? my very own timezone: "whenever the fuck I happen to be awake" Jul 25 09:43:56 ;) Jul 25 09:44:59 have a good night! Jul 25 14:48:34 m Jul 25 19:32:21 somehow, I just accidentally got the light flashing before I thought I had started it, and I thought something was exploding when I saw it out of the corner of my eye Jul 25 20:30:26 ksft sorry I won't let you do it again? :D Jul 25 20:55:51 ksft: again, take comfort in knowing that any explosions created by the bbb are likely to have very limited radius. your coworkers/roommates will probably be fine Jul 25 20:58:10 ;) Jul 25 21:03:18 of course Jul 25 21:03:49 what happens if the PRU reaches a halt instruction and I call core.run() again? Jul 25 21:04:07 does it pick up where it left off like a breakpoint? Jul 25 21:04:55 yes and no... as long as the pc is on the halt instruction, it will just immediately halt again (withotu advancing the pc) Jul 25 21:05:23 I have made working breakpoints btw, I'm doing some final bits of cleanup before committing Jul 25 21:05:32 that was fast Jul 25 21:05:40 can I just increment core.pc, then? Jul 25 21:06:42 core.pc cannot be written directly, but you can pass a "pc" keyword-parameter to core.run(). this will however also reset the core, which means some bits of state will be lost (e.g. hardware loop state and carry-flag) Jul 25 21:06:43 hmm, apparently not Jul 25 21:08:04 huh, I just tried that, and now core.pc is 65183 Jul 25 21:08:12 lol what Jul 25 21:08:15 how Jul 25 21:08:20 oh, I see Jul 25 21:08:33 I forgot to assemble my new code with the halt instruction in the middle Jul 25 21:08:42 so it finished and then executed garbage Jul 25 21:08:58 again, you can consider passing fill_memories=True to pruss.initialize() Jul 25 21:09:30 I haven't been using pruss.initialize() because I want it to stay in mark state until it starts sending a packet Jul 25 21:09:52 ah Jul 25 21:10:09 I guess maybe I shouldn't reset r30 Jul 25 21:11:18 I would assume it would reset it Jul 25 21:11:29 in fact, I *did* assume it resets it Jul 25 21:11:32 maybe I should make it optional at least Jul 25 21:11:37 yeah Jul 25 21:11:57 fill_memories=True also used to be the default behaviour, until I hit a case where it was quite undesirable Jul 25 21:12:25 what were you doing? Jul 25 21:13:26 memory contained some shared variables that had to be left untouched or at least reinitialized in a particular way to avoid confusing userspace client processes when restarting the pru application Jul 25 21:14:06 ah Jul 25 21:14:24 hmm, I'm calling core.run(pc=51), and it keeps halting with pc 50 Jul 25 21:15:10 you don't have some branch back from whatever code is at/after pc=51 to before it? Jul 25 21:16:29 I don't think so Jul 25 21:16:59 it's in a macro which I use several times, but the pc should be different each time, right? Jul 25 21:17:07 sure Jul 25 21:20:53 oh, nevermind, I thought it was stopping somewhere else Jul 25 21:22:35 and I found a bug! Jul 25 21:25:36 in? Jul 25 21:26:35 my assembly Jul 25 21:33:14 I just pushed the breakpoint support Jul 25 21:35:51 it's sort of working! Jul 25 21:35:57 (my code, I mean) Jul 25 21:36:27 it turns off after about a second, even when I send a lot of packets, but I can control the channels briefly Jul 25 21:39:30 oh, it's because I *wasn't* sending a lot of packets! Jul 25 21:39:45 I was sending one packet and then doing nothing a lot of times! Jul 25 21:39:58 lol Jul 25 21:41:03 is core.run(pc=0) a good way to run it again? Jul 25 21:41:25 or core.run(reset=True) Jul 25 21:41:52 (which will reuse whatever ps it was started from last time) Jul 25 21:41:55 *pc Jul 25 21:42:18 specifying "pc" will make "reset" default to True rather than False Jul 25 21:42:33 ah Jul 25 21:44:53 what kinds of things can I pass to .write()? Jul 25 21:45:57 nevermind, looks like bytearray does what I want Jul 25 21:46:26 like the wiki ( https://github.com/mvduin/py-uio/wiki/Memory-access#summary ) says, a bytes-object or any other object that supports the buffer interface Jul 25 21:46:37 that includes bytearray and ctypes objects Jul 25 21:47:16 an iterable of ints probably works too, haven't tested that Jul 25 21:47:56 haha, it's working! Jul 25 21:50:49 the resistor still breaks it, though Jul 25 21:52:37 odd Jul 25 21:53:01 it's 120 Ohms Jul 25 21:53:05 that should be okay, right? Jul 25 21:53:36 yep Jul 25 21:53:45 you leave the driver enabled continuously? Jul 25 21:53:52 yeah Jul 25 21:54:05 hm Jul 25 21:54:06 curious Jul 25 21:54:09 er, unless reset=True changes the value of r30? Jul 25 21:54:14 no Jul 25 21:54:18 then yes Jul 25 21:55:10 curiou Jul 25 21:55:11 s Jul 25 21:55:19 hard to guess what might be going on electrically without a scope Jul 25 21:55:49 it's clearly sending the right signals Jul 25 21:56:25 I would assume that some current flows across the resistor, reducing the voltage difference between DMX pins 2 and 3 Jul 25 21:56:54 er, does that make any sense? Jul 25 21:57:04 yes it will reduce the voltage swing Jul 25 21:57:48 if the resistance in the fixture is at least 120 Ohms, the voltage difference there should be at least half of 3.3 V, right? Jul 25 21:57:58 and I think 1.5 V is the minimum for RS-485? Jul 25 21:59:00 the fixture should have very high impedance Jul 25 21:59:28 i.e. the fixture should be "invisible" on the dmx bus Jul 25 21:59:33 that makes sense Jul 25 21:59:46 otherwise you can't possibly have dozens of fixtures on one dmx line Jul 25 21:59:55 I was just wondering how that works Jul 25 22:00:20 rs485 receivers simply have high impedance and low capacitance Jul 25 22:01:14 if I wanted to use a different language than Python to control it, how difficult would it be to do myself what py-uio does? Jul 25 22:02:03 so, easiest is to use py-uio for initialization, and then just mmap your dmx buffer in whatever process you want Jul 25 22:02:13 ahh Jul 25 22:04:22 unfortunately uio doesn't support providing an offset to mmap() (instead offset/4096 selects the memory region to mmap, really ugly hack), but it's not hard to create an overlay that creates a new uio device just for your dmx buffer... that would also be preferable from a security point of view, since any process that controls pruss can control the whole system hence effectively has root privileges, ... Jul 25 22:04:28 ...whereas there's obviously no need for access to just the dmx buffer to be privileged Jul 25 22:06:52 why would I care where in memory it gets mapped to? Jul 25 22:07:09 you don't, that's not what I said Jul 25 22:07:52 oh actually I guess the buffer might actually be located at offset 0 in pruss if you placed it into dram0 Jul 25 22:08:13 oh, the offset is the part of the PRU's memory that's being mapped Jul 25 22:08:18 yeah, that's 0 for now Jul 25 22:09:09 yeah, when using an uio device there's no way to specify a non-zero offset (although you can use DT declarations to create a new uio device for some 4KB-aligned memory subrange) Jul 25 22:13:54 how do I create a new uio device that's just the memory I want? Jul 25 22:34:00 brb pizza Jul 25 22:52:36 ksft: note that for now you can just open /dev/uio/pruss/module and mmap() it, with a size of 8KB or 4KB depending on whether you want to mmap all of dram0 or just the first half of it Jul 25 22:53:40 then later you can switch to a dedicated /dev/uio/dmx device or something like that, but other than the path nothing would change Jul 25 22:54:05 I'll explain it in a bit, I'm distracted atm Jul 26 00:55:47 zmatt I do appreciate you knowledge of the arcane devices I sometimes have to touch. Not to sound cheesy, but I prefer to learn things and not be frustrated by them. Jul 26 00:56:08 being frustrated by arcane devices is so fun! Jul 26 00:58:42 as an ancient saying goes "deferred hope leads to frustration" , and frustration can lead to bad things (my addition). Jul 26 01:39:54 I've been sshing to my bbb through a router? Jul 26 01:40:00 er, that wasn't a question Jul 26 01:40:08 how do I connect to it directly? Jul 26 01:40:27 the website seems to say it's supposed to act as a network interface Jul 26 02:01:20 ksft do you know the BBB ip you should be directly connected to it. Jul 26 02:02:06 it does a number of things depending on what its connected *to* .. Jul 26 02:02:33 ie. device and port Jul 26 02:02:54 I've connected it to my laptop Jul 26 02:03:04 GenTooMan: I mean I don't want to go through the routr Jul 26 02:03:08 router* Jul 26 02:03:25 you'll need to set up some networking on the BBB then .. or your laptop .. Jul 26 02:03:32 that is what your router is doing Jul 26 02:06:25 the website says "If connected via USB, a network adapter should show up on your computer" Jul 26 02:06:43 I assume that means "If the BBB is connected via USB..." Jul 26 02:12:29 yes, it uses RNDIS Jul 26 02:12:34 like your cell phone Jul 26 02:12:44 (in USB tether mode) Jul 26 02:15:06 the default configuration used to be 192.168.7.1/2 Jul 26 02:15:16 but that was some time ago now **** ENDING LOGGING AT Fri Jul 26 02:59:59 2019