**** BEGIN LOGGING AT Tue Jan 19 03:00:19 2021 Jan 19 03:39:28 Does the use of two, separate servers on the BBB making one page online create issues? Jan 19 14:04:49 is there a way to compact regmap reads? say i have 8 bits declared in a register, each read gets all 8 bits, but the driver is still reading 8 times rather than just updating all of them. Jan 19 16:59:02 -j #audacity Jan 19 16:59:08 eff sorry lol Jan 19 20:58:26 if a pin is configured as SPI0_D0 (using pinmux), where can the received spi data for that pin be accessed? Jan 19 21:00:37 eh, spi uses 4 pins generally (sclk, miso, mosi, and cs) and you use it via spidev (or, if you want to use an spi device with a kernel driver for that device, you'd need to declare it using a DT overlay) Jan 19 21:02:05 is there a documentation for spidev? I looked at it in the /dev directory but I can't get any info from it Jan 19 21:02:22 spi0 cs0 would be /dev/spi/0.0 (which is /dev/spidev0.0 on recent kernels and /dev/spidev1.0 on older kernels, which is why the symlink exists) Jan 19 21:02:57 spidev is a linux api, not beaglebone specific... it shouldn't be hard to find documentation for it, as well as libraries for most programming languages Jan 19 21:05:20 I knew I had some notes: https://pastebin.com/nS6FELGH Jan 19 21:07:56 in C/C++ it's not hard to use the kernel api directly Jan 19 21:08:45 (nitpick: it's easy to use the libc wrappers for the kernel syscalls) Jan 19 21:08:55 nobody wants to make syscalls directly Jan 19 21:08:59 spidev doesn't have dedicated syscalls, it uses ioctl Jan 19 21:09:12 ioctl is a syscall with a libc wrapper Jan 19 21:10:32 I mean, yes. I'm not sure why you're sharing this, I don't think anyone was considering doing syscalls with inline assembly here Jan 19 21:10:59 with "the kernel api" I mean the raw ioctl()s, as opposed to some wrapper library Jan 19 22:36:14 how fast is ssh communication Jan 19 22:37:59 i think I need to move the gui off the beagle and just use it like a microcontroller Jan 19 22:38:47 I want to include this vision piece but given I am struggling in moving files let alone do the vision portion I am resource limited Jan 19 22:39:33 so I would have the main program on the laptop and send infor from the processed images as a data stream Jan 19 22:43:28 what is the best way to connect to the beagle bone to do that where i am using it to stream data and start and stop PRUs Jan 20 01:17:04 Has anyone used spi to receive communications from other microcontroller? Stm32 for example Jan 20 01:20:48 I mean, spi doesn't care what kind of device is on the other end :P Jan 20 01:21:52 Well yes, but for some reason the spi device always reads 0 even though I'm sending data from the other device Jan 20 01:21:59 though using spi for that purpose will make things harder on the microcontroller (compared to using uart or i2c) since the microcontroller will have to be able to handle the spi requests with very strict timing (since the microcontroller has no influence over the bus timing) Jan 20 01:22:38 I'm just filling the spi data register on the microcontroller Jan 20 01:22:55 so, I'd first double-check that your pins are configured right by doing a loopback test: i.e. connect the beaglebone's mosi to its own miso, to confirm that you're receiving back whatever you send Jan 20 01:23:02 But how am I supposed to signal to receive on the beaglebonw? There's no function for clock signal initiation Jan 20 01:23:40 spi is completely controlled by the master, the slave has no influence or when the master performs a transfer, how many bits it transfers, or how fast Jan 20 01:23:49 *influence over Jan 20 01:24:04 if that doesn't suit the purpose, then spi is the wrong protocol to use Jan 20 01:24:41 if you just want to offload data from the microcontroller to the beaglebone, using an uart is probably more suitable Jan 20 01:24:48 Yes! Jan 20 01:24:49 *a uart Jan 20 01:27:27 UART! Now, if you guys are thinking, "What is this person up to today?" You would be a nice person. If nice people are present, will you please tell me how to make this darn webcam work w/ the BeagleBone Green Wireless. The thing has four USB ports and I cannot get any of them to run the source mjpg-streamer in a .sh file. Jan 20 01:27:28 ... Jan 20 01:27:32 Just asking here... Jan 20 01:27:45 Yeah, I had the microcontroller configured as slave, but I don't know how to tell the microcontroller to start sending data Jan 20 01:28:00 Is it me? No. Jan 20 01:28:32 Not this time, chummy, ole pal. It is the something or other that is vacant at some point in the kernel. I cannot put my finger on it yet. Jan 20 01:28:39 Zalymo: I'm not sure what you mean Jan 20 01:30:57 Zalymo: data transfer is initiated by the master, i.e. the beaglebone. if you want to transfer data (spi always simultaneously transfers data in both directions) then you need to perform a data transfer (via the spidev api) Jan 20 01:31:54 the details of how this works on the slave side will vary depending on how the spi peripheral on that microcontroller works Jan 20 01:32:45 The manual of the microcontroller says that the transmission sequence begins when the "clock signal is received". But how do I send a clock signal from the beaglebone? Jan 20 01:33:02 by performing a transfer, via the spidev api Jan 20 01:33:08 I feel like I'm repeating myself... probably because I am Jan 20 01:33:56 I've linked to a python example Jan 20 01:34:23 So I need to connect another wire to the microcontroller and configure it as MOSI to send the clock signal? Jan 20 01:34:31 ???!? Jan 20 01:34:49 I have the python example, have been studying it Jan 20 01:34:50 like I already said, spi normally needs 4 wires: sclk, mosi, miso, cs Jan 20 01:35:16 if don't need beaglebone->microcontroller data transfer then you can omit mosi Jan 20 01:35:29 I only have 3 wires because I thought since only the microcontroller was sending data, then I wouldn't need a MOSI wire Jan 20 01:35:56 correct Jan 20 01:36:21 But then if I omit the MOSI wire then how would I send a clock signal? Could the MISO wire receive data on the microcontroller? Jan 20 01:36:32 what Jan 20 01:36:56 I feel like you haven't read anything I've said the past 15 minutes Jan 20 01:37:04 I have Jan 20 01:37:32 You said that in order to send a clock signal, the bone needs to send data Jan 20 01:37:43 no, I said you need to perform a transfer Jan 20 01:38:01 But if I have a 3 wire configuration, which wire receives the clock signal Jan 20 01:38:02 spi transfer inherently always transfers data in both directions, though you can choose to ignore one of those if you don't need it Jan 20 01:38:16 the beaglebone transmits the clock on the sclk signal Jan 20 01:39:19 So to perform a transfer, I'd do spi.xfer( [1] )? Jan 20 01:40:26 that would transmit the byte 0x01 (which would be discarded since mosi is not connected) and simultaneously receive one byte Jan 20 01:40:57 since you don't care about the data being transmitted I'm pretty sure there's also a convenience function that lets you simply specify the number of bytes to transfer (which will just send that number of zeros) Jan 20 01:41:29 So then how would I initiate a transfer (of a clock signal) from the beaglebone? Jan 20 01:41:58 ... with xfer? like just discussed? Jan 20 01:43:11 You said it would be discarded without a MOSI line. But then it still gets received? Jan 20 01:43:34 output data gets discarded since you didn't connect mosi since you don't need it Jan 20 01:43:48 which is fine... since you didn't need it Jan 20 01:49:32 How would you flush the Rx buffee? Jan 20 01:49:39 and like I said since you don't care about the transmitted there are also convenience wrappers that don't require you to specify it explicitly. e.g. to transfer 5 bytes, instead of writing spi.xfer([0, 0, 0, 0, 0]) you can write spi.read(3) if using Adafruit_BBIO.SPI or spi.readbytes(3) if using py-spidev Jan 20 01:49:40 Buffer* Jan 20 01:50:00 whose rx buffer, what do you mean by "flush" it? Jan 20 01:50:34 I am receiving the data from the microcontroller (I think), but I'm only getting 255, which was the old number Jan 20 01:51:20 255 does not sound like you're receiving any data Jan 20 01:51:26 since that's just the line being high Jan 20 01:51:54 That's what I get from readbytes(1) Jan 20 01:52:21 but there's no "buffer" on the beaglebone side, xfer() or readbytes() simply returns the data receiving during that specific transfer Jan 20 01:52:28 *received Jan 20 01:53:15 if you perform a transfer with nothing connected (but pins configured correctly) then you'll receive all-ones, i.e. 255 Jan 20 01:53:49 since miso (P0.21) is pulled up by default if not externally driven Jan 20 01:54:49 How come if I set spi.threewire = True, then spi.readbytes() throws an error? Jan 20 01:54:56 not supported Jan 20 01:55:19 So I have to have MOSI connected to the microcontroller? Jan 20 01:55:23 "threewire" means mosi/miso are combined into a single wire that changes direction during the transfer Jan 20 01:55:57 you don't need data output at all so "threewire" would not be useful to you Jan 20 01:56:12 (or rather, or would have no impact in your use-case) Jan 20 01:56:19 *it would Jan 20 01:58:19 Miso is p9.18? Jan 20 01:58:30 I think you don't quite grasp yet how simple and dumb spi is. neither master nor slave has any way of knowing whether or not mosi or miso is connected. Jan 20 01:58:37 P9.18 is mosi, P9.21 is miso Jan 20 01:59:40 So SPIO_D1 is mosi? Jan 20 02:00:27 which pin is what is actually at the top of my pastebin snippet: https://pastebin.com/nS6FELGH Jan 20 02:01:38 Weird, I'm still getting 255 even though the microcontroller should be sending data Jan 20 02:03:02 have you tried a simple loopback test first? i.e. connect P9.18 to P9.21 (and leave P9.22 and P9.17 unconnected) and run one of the examples to confirm it receives what it sent? Jan 20 02:03:35 just to confirm pins are configured right Jan 20 02:04:21 Yeah, I did and it gave me the correct output Jan 20 02:04:34 okay, well then your microcontroller simply isn't sending data Jan 20 02:05:01 may I ask, why are you using spi for this? of all commonly used serial interfaces, it is probably the least convenient to use Jan 20 02:06:35 I bet speed! Jan 20 02:06:54 nah, speed to high will result in corrupted data, but you'd still see _something_ Jan 20 02:07:16 oh. Jan 20 02:07:42 I figured out my issue. It is not the BBGW. Jan 20 02:07:50 It is the source and the kernel colliding. Jan 20 02:07:51 receiving nothing but 255 suggests nothing is being sent by the microcontroller, or it's hooked up to the wrong pin of the microcontroller or something Jan 20 02:08:13 I just want to learn all 3 of the basic communication protocols, and SPI appears to be simpler than I2C so I'm learning it first Jan 20 02:09:05 tcp connection Jan 20 02:09:11 that is where I landed on what I need Jan 20 02:09:22 Zalymo: it may help to first study how spi works at a hardware level, since I get the impression you don't Jan 20 02:09:39 bbai let me down Jan 20 02:10:36 Zalymo: since spi is pretty much the dumbest form of synchronous serial communication... it barely deserves to be called a protocol Jan 20 02:11:30 and how it has to be used is a direct consequence of that Jan 20 02:11:39 zmatt Jan 20 02:11:58 mattb000ne Jan 20 02:12:00 did you see my question for having fast two way streaming of info between a black and a laptop Jan 20 02:12:12 is tcp the best way to do that Jan 20 02:12:17 Yeah, I had watched several videos on how it works and started struggling trying to apply it Jan 20 02:12:19 yeah, question too vague and broad-scoped to have a meaningful answer. Jan 20 02:12:33 like, transfer data whatever way is convenient for you Jan 20 02:12:50 well what I am attempting to do is have the laptop get data streamed from beaglebone Jan 20 02:12:57 basically move the gui to the laptop Jan 20 02:13:01 Quick question though, if I connect 3.3v to the MISO pin on the beaglebone, will it damage anything? Or is it still 3.3v tolerant in spite mode? Jan 20 02:13:21 Spi* Jan 20 02:13:32 the pins are sensitive Jan 20 02:13:34 Zalymo: miso is an input, hence it's actually *supposed* to be driven externally Jan 20 02:14:17 Yes, but the alternate pin functions on my microcontroller drive a low voltage, way lower than 3.3v Jan 20 02:14:33 so I would want to transfer data faster than ssh Jan 20 02:14:34 speeds Jan 20 02:14:42 back and forth Jan 20 02:14:59 Zalymo: if the microcontroller doesn't use the same I/O voltage as the beaglebone then you can't connect them together Jan 20 02:15:16 It does, it is 3.3v logic high Jan 20 02:15:34 But I wanted to know if connecting that is safe in spi mode Jan 20 02:15:36 so what did you mean by "drive a low voltage, way lower than 3.3v" ? Jan 20 02:15:58 a logic signal should either be close to 3.3V (if high) or close to 0V (if low) Jan 20 02:16:05 When a pin is in an alternate function on the microcontroller, it is at a low voltage, like 80-90 mV Jan 20 02:16:23 I mean, I don't know what you mean by "an alternate function" Jan 20 02:16:39 Basically alternate pin modes (like pinmux) Jan 20 02:17:09 yes but what the pin will do will obviously depend on *what* alternate mode, and if configured to a peripheral it will depend on what that peripheral is doing Jan 20 02:18:26 if configured as spi slave data output (miso) then it _should_ not drive the pin unless CS is asserted Jan 20 02:18:37 So then sinking in 3.3v to a spi pin is safe? Jan 20 02:18:48 I don't understand what you mean by that Jan 20 02:19:14 A wire from the microcontroller (Tx) wire is high at 3.3v Jan 20 02:19:39 So if I put it in p9.21, will it damage? Jan 20 02:20:23 03:13 <@zmatt> Zalymo: miso is an input, hence it's actually *supposed* to be driven externally Jan 20 02:20:51 i.e. driven to (approximately) 3.3V if high or approximately 0V if low Jan 20 02:20:58 So there is no tolerance when it is driven externally? Jan 20 02:21:05 ??? Jan 20 02:21:06 what? Jan 20 02:21:16 Voltage tolerance Jan 20 02:21:27 Since gpio pins are 3.3v tolerant Jan 20 02:21:40 I mean, 3.3V is the I/O voltage of the beaglebone Jan 20 02:22:07 it doesn't make any sense to not be tolerant to the actual I/O voltage... how would you be able to use the pins for anything? :P Jan 20 02:22:35 the word " tolerant" is normally only used when that is outside the normal range Jan 20 02:23:43 So then it should be safe to insert a 3.3v Tx wire into the p9.21 MISO pin? Jan 20 02:24:43 it is safe to connect an input to either 0V or 3.3V... since otherwise there'd be no way to use the pin Jan 20 02:25:34 (a gpio in output mode is, essentially, equivalent to being connected to 3.3V (when high) or 0V (when low) ) Jan 20 02:28:26 I appreciate the help Jan 20 02:28:28 simple rules to not fry hardware: 1. don't expose an input to voltages below 0V or above the I/O supply voltage (which for the beaglebone is 3.3V when powered on, 0V when powered off) 3. never connect two outputs 4. when interconnecting devices make sure you have a good ground connection before anything else Jan 20 02:28:55 Now that I know the beaglebone is configured properly, I'll have to take a look at the microcontroller configuration and try and sort that out Jan 20 02:29:23 sooo zmatt tcp vs ssh Jan 20 02:29:38 i need fast transfer for streaming data Jan 20 02:29:44 ssh is a complicated protocol layered on top of tcp Jan 20 02:29:52 ok Jan 20 02:30:04 (that performs authentication, encryption, and a bunch more stuff) Jan 20 02:30:13 what would be my top speed of a tcp connection Jan 20 02:30:40 on a bbai? dunno, benchmark it Jan 20 02:30:44 black Jan 20 02:30:50 bbai is going in the closet for now Jan 20 02:30:57 fun is over semester has started Jan 20 02:31:03 No! Jan 20 02:31:14 all over set all over Jan 20 02:31:18 Dang. Jan 20 02:31:54 My lucid colors of imagery are now bleak. Jan 20 02:32:30 They have school now, i.e. even in COVID season? Jan 20 02:33:59 I am not looking up how to spell bleak/bleek. Jan 20 02:34:06 bzzt! Jan 20 02:34:44 Anyway, good luck! Jan 20 02:35:07 mattb000ne: about 10 MB/s Jan 20 02:35:30 So, RISC-V has multithreading capabilities. That is nice. Jan 20 02:35:46 Servers galore! Jan 20 02:35:48 any processor can multithread Jan 20 02:35:53 Oh. Jan 20 02:35:56 depending on what you mean by it Jan 20 02:36:25 mattb000ne: slightly more actually, 11-12 MB/s Jan 20 02:36:45 which matches what I'd expect Jan 20 02:36:48 I do not mean anything. I must think that threads for server workers and instances are what multithreading is all about... Jan 20 02:37:20 set_: yeah I can confirm it not meaning anything :P Jan 20 02:37:56 Ha. Jan 20 02:38:08 Okay. Jan 20 02:38:17 It is hard to throw one by you, matey. Jan 20 02:40:20 I wonder now. Jan 20 02:40:59 How can one adapt a cross-comp. to the BeagleV w/ linux Debian? Would I need the 32-bit debian on the dev. desktop? Jan 20 02:42:04 Not that I am a mainstream user of RISC-V. I am just reading the application notes they provide on their website. Jan 20 02:43:01 man I got to setup a whole server for tcp communication Jan 20 02:43:03 do Jan 20 02:43:05 doh Jan 20 02:43:33 and can is beaglebone.local considered a static ip Jan 20 02:44:22 it's a hostname, not an ip :P Jan 20 02:47:27 whats the max baudrate for a beaglebone tcp connection Jan 20 02:47:38 i just learned baud and bit rates are not the same Jan 20 02:47:57 use bind9! Jan 20 02:47:58 "baudrate" doesn't make sense for that question Jan 20 02:48:11 as far data transfer rate I literally just answered that 1 minutes ago Jan 20 02:48:11 dont I need to know the bandwidth? Jan 20 02:48:27 10 mintues Jan 20 02:48:42 i got that but my em100 does a certain baudrate and I want to know if the tcp could keep up Jan 20 02:48:52 if we take baud to mean symbols per second, 1000BASE-T Ethernet is 125 Mbaud Jan 20 02:48:52 @zmatt just typed and I quote, "1 minutes ago." Jan 20 02:48:56 Ha. Jan 20 02:49:28 mru: this is 100BASE-TX, and the technically correct answer isn't the useful answer here :P Jan 20 02:50:01 mattb000ne: your EM100 produces a negligible amount of data Jan 20 02:50:24 you could pretty much use a carrier pigeon to transport it Jan 20 02:50:31 lol Jan 20 02:50:34 rfc1149 Jan 20 02:51:20 it supports max 1200 measurements per second and produces a few bytes of data per measurement Jan 20 02:51:53 so you're looking at a few KB/s max Jan 20 02:52:07 mru: very funny Jan 20 02:53:52 which rfc is it that specifies the "evil bit" in the IP header? Jan 20 02:54:09 I know which one you mean but dunno :P Jan 20 02:54:35 has anyone made a nice little tutorial for tcp on the bbb Jan 20 02:55:06 https://tools.ietf.org/html/rfc3514 Jan 20 02:55:26 mattb000ne: tcp doesn't work any different on the bbb than on any other device Jan 20 02:55:44 so there's no reason for an exmaple that specific to exist Jan 20 02:56:03 ok **** ENDING LOGGING AT Wed Jan 20 02:59:57 2021