**** BEGIN LOGGING AT Mon Jan 07 02:59:56 2019 Jan 07 05:13:10 How should I use the RelayCape? Any takes on this idea? Jan 07 05:14:03 I am currently learning more about relays on Nat. Cont. Dev. LLC's site. I see I can put high loads from AC in the Replay but would this be an accurate estimation for that RelayCape. Jan 07 05:14:35 Replay = relay Jan 07 05:15:23 I see how to use the Cape w/ lights, motors, and other devices. Jan 07 05:18:14 P9_41 controls Relay1! Jan 07 05:18:21 Now, onto wiring. Jan 07 05:18:54 NO, COM, NC are like a window sensor. Cool! Jan 07 05:20:57 Do you think the motor idea on this page, https://ncd.io/relay-logic/, is relevant to the BBB and using the LoadCape? Jan 07 05:21:51 I mean, am I allowed to put two relays in a row w/ this specific Cape? Jan 07 05:22:05 Sorry. LoadCape = RelayCape. Jan 07 07:43:48 Those relay/light bulbs can be done, yes. Jan 07 07:44:10 However, I would not learn using a situation that uses 120Vac. Jan 07 07:44:48 Instead, learn using a regular LED and switch that on and off. Jan 07 09:53:51 beaglebone blue with Ada in action ... Jan 07 09:53:54 http://knaldgas.dk/~pdj/Roadrunner_At_Racetrack_20180403.mp4 Jan 07 09:54:03 http://knaldgas.dk/~pdj/Roadrunner.mp4 Jan 07 10:04:24 Hey Jan 07 10:04:58 I'll be applying for GSoC'19 Jan 07 10:05:20 see https://beagleboard.org/gsoc for gsoc-related resources Jan 07 14:46:55 With the PRU assembler, I had a question about the QBLT (quick branch if less than) command. Jan 07 14:46:57 It Jan 07 14:47:33 It's definition is QBLT LABEL, REG1, OP(255), so does this mean it can only compare REG1 to a value less than 255? Jan 07 14:48:02 For example, if REG1 and REG2 both were 1000, what would QBLT, LABEL, REG1, REG2 do? Jan 07 15:45:18 Also, does anyone know how to reset the PRU cycle counter? Jan 07 15:45:41 I read that it needs to be disabled and then re-enabled, but I couldn't get this to work. Jan 07 15:58:46 hunter: OP(255) means either a register, a register field, or an 8-bit unsigned constant Jan 07 15:58:53 so only constants are limited in range Jan 07 16:00:09 you reset the cycle counter by performing any write to it while it is disabled Jan 07 16:00:48 also beware that qblt and friends treat their argument in the opposite order of what one would expect Jan 07 16:01:07 i.e. qblt label, reg1, reg2 jumps to label if reg2 < reg1 Jan 07 16:01:59 that's why I do this: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/common.h#L10-L19 Jan 07 16:32:20 m Jan 07 17:20:39 Snert: Thank you for the ideas. I will stay away from 120VAC. Jan 07 17:58:53 Hey there! Jan 07 18:00:40 Can anyone help me find some doc on how to map your pins from config-pin into a dtbo? Jan 07 18:01:37 how to translate pins from config-pin to a dtbo****** Jan 07 18:01:48 you mean you want to switch from using cape-universal (config-pin) to using an overlay? Jan 07 18:02:18 an overlay is overall less straightforward, you will need to enable the peripherals you need in addition to configuring their pins Jan 07 18:03:43 Well I have no choice to do so, unless I can make it run on boot? Jan 07 18:04:10 sure you can make stuff run on boot Jan 07 18:04:27 note I'm not saying you should pick either option, they both have pros and cons Jan 07 18:04:30 Can I make it run from the uEnv.txt? Jan 07 18:04:56 Would you happen to have documentations on those pros and cons? :) Jan 07 18:04:58 uEnv.txt is the config file of the bootloader, it has no control over what is run by the OS at startup Jan 07 18:05:18 I would need to add it to one of my scripts then Jan 07 18:05:58 yeah, performing the pin configuration immediately before starting whatever program makes use of the functionality of those pins is a viable option Jan 07 18:07:48 Ithink I will have to do that for now. But later, I will need to go with the overlay. I am supposed to switch to Yocto at some point Jan 07 18:08:08 in that case you won't use overlays either but will probably do everything in the main dtb Jan 07 18:09:11 How may I do that :) ? Jan 07 18:09:58 you may want to check out my overlay-utils project. it allows you to write overlays with exactly the same syntax as you would use in the main dt, so you can easily port stuff between the two approaches. it also includes a bunch of examples. https://github.com/mvduin/overlay-utils Jan 07 18:10:30 beware however that some of my macros (e.g. for pinmux) differ from those available in mainline linux, although it's not too hard to adapt for the changes in either direction Jan 07 18:10:41 see spi0.dtsi for a decent example Jan 07 18:11:17 I know which pin mode to use for pins, the "P9" and "P8" tabs of my pins spreadsheet give a concise yet detailed overview: https://goo.gl/Jkcg0w Jan 07 18:11:25 cool thank you so much @zmatt Jan 07 18:11:56 I had access to those already! But it looks way more convenient on gdocs! Jan 07 18:13:25 for comparison, the spi0.dtsi in my overlay-utils project is *roughly* similar (there are differences) to this overlay: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts Jan 07 18:13:32 I think my version is more readable :) Jan 07 18:13:58 my overlay-utils uses a perl script to convert a device tree fragment into the ugly structure required for overlays Jan 07 18:16:10 to verify the current pin configuration on a running system, you may find my show-pins script useful: https://github.com/mvduin/bbb-pin-utils/#show-pins Jan 07 18:16:27 (it works regardless of how you perform pin config) Jan 07 18:16:39 wow! cool thx! Jan 07 21:54:17 I have BBB. I am trying to talk to i2c sensor. I believe I properly connected it to the board. Jan 07 21:54:41 what sensor? Jan 07 21:54:53 i2c! Jan 07 21:55:20 Give me a sec to finish :) and thank you for your support! Jan 07 21:55:49 The sensor is SHT-31-D Jan 07 21:55:59 debian@beaglebone:~$ i2cdetect -y -r 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- Jan 07 21:56:16 please don't paste multiline output into chat, use a paste service like pastebin.com Jan 07 21:56:31 Yes. you are right! Jan 07 21:57:20 https://pastebin.com/iwaKvpE6 Jan 07 21:57:47 As you can see the device responds on 0x44 Jan 07 21:59:49 I have found a C-sample online to talk to it: https://pastebin.com/EmyNzpYf Jan 07 22:00:19 But the code fails on file = open(bus, O_RDWR) Jan 07 22:01:46 Input/Output Error Jan 07 22:02:03 The serial channel is more speciffic: Jan 07 22:02:05 EIO on opening the bus? o.O Jan 07 22:02:12 not on read/write ? Jan 07 22:02:28 omap_i2c 4819c000.i2c: controller timed out Jan 07 22:02:59 Correct, on opening - nothing even to do with the sensor Jan 07 22:09:02 so, let's first add some better diagnostics: https://pastebin.com/yiFt9CDS Jan 07 22:09:12 I hope I didn't make any typo, haven't tried to compile it ;) Jan 07 22:11:24 oh lol it's missing #include Jan 07 22:13:26 I'll admit that I'm not used to using read/write on an i2c device, normally I use the ioctl interface Jan 07 22:15:07 it seems unlikely "short read" is actually a thing that can happen Jan 07 22:22:45 zmatt, my chat window has disappeared. I have tried your program. The same result. Note that during 'open' the program crashes. I do not insist on 'open' code. I just need to make it working. If you have another approach, I would love to try it Jan 07 22:22:58 what do you mean "crashes" ? Jan 07 22:23:10 and the result can't be the same since my program produces different messages Jan 07 22:23:26 and I don't know what you mean by "'open' code" Jan 07 22:24:02 btw, are you using the adafruit breakout? Jan 07 22:27:52 btw it's quite possible that using i2cdetect confuses the device into a state where it becomes unresponsive or behaves strangely. it may be a good idea to reset the sensor (by pulling the reset pin of the sensor low or by power-cycling the beaglebone+sensor) before continuing Jan 07 22:31:01 zmatt, the program crashes at line#18 Jan 07 22:31:09 int fd = open( bus, O_RDWR | O_CLOEXEC ); Jan 07 22:31:23 what do you mean "crashes" ? what happens exactly? Jan 07 22:31:27 because that doesn't make any sense Jan 07 22:31:27 no messages are printed Jan 07 22:33:00 how do you know it crashes at that line? Jan 07 22:33:58 give me a sec. It started to behave differently Jan 07 22:41:22 Hello! Jan 07 22:45:18 dreamhiker: are you using the sht31-d breakout board from adafruit ? Jan 07 22:45:37 I've also updated my paste ( https://pastebin.com/yiFt9CDS ) to improve it a bit Jan 07 23:12:02 I am not using any cape boards and connected the sensor directly to GPIO. Jan 07 23:12:31 I am getting: Read error: Remote I/O error Jan 07 23:12:43 Thank you for showing %m - was unaware Jan 07 23:13:35 do you have pull-ups on the i2c lines? decoupling capacitor on vcc (near the sensor) ? basically all the components that are on the breakout board: https://cdn-learn.adafruit.com/assets/assets/000/028/982/original/adafruit_products_schem.png Jan 07 23:14:24 pull-down on addr is also required Jan 07 23:15:35 pull-up resistors on sda and scl should be in range 1K - 10K Jan 07 23:17:18 addr can be tied to ground. reset can be tied to vdd if unused, otherwise connect to gpio and to pull-up resistor in range 1K - 10K Jan 07 23:17:26 Allow me to rewind a bit: the above read error is for Jan 07 23:17:27 char cmd[2] = { 0x24, 0x00 }; Jan 07 23:17:34 yes I understand Jan 07 23:17:42 shall I use 0x24 or ox2C Jan 07 23:17:44 ? Jan 07 23:17:45 so there's a problem with i2c communication Jan 07 23:18:10 I recommend 0x2400, but 0x2c06 should also work Jan 07 23:18:50 anyway, I'm pretty sure all versions of the code should have worked, and your problem is simply in the hardware Jan 07 23:19:10 verify the things I just mentioned Jan 07 23:22:43 BTW, 0x2C06 results in: Failed to send command: Connection timed out Jan 07 23:23:16 Let me take a look at your other suggestion Jan 07 23:23:24 what's the value of the decoupling capacitor you use on the sensor's vdd ? Jan 07 23:26:07 Sorry, I am ignorant in those things. I just connect the sensor directly to GPIO. As shown in the book ExploringBeagleBoard.pdf page#277 Jan 07 23:27:13 how exactly are you connecting it directly to gpio? surely you didn't solder wires directly to the chip? Jan 07 23:27:24 Is there a way to paste an image somewhere? Jan 07 23:28:02 learn to use google. first result on "paste image": https://pasteboard.co/ Jan 07 23:29:33 also, you're connecting it to pins, not to "gpio". gpio is a particular type of functionality of a pin (different from the i2c mode you're using) Jan 07 23:29:48 GPIO! Jan 07 23:30:07 set_, please stop randomly repeating words Jan 07 23:30:08 There are probably numerous ways to share images. I could have used google docs or google shared drive. I am just trying to follow the rules of the board :) Jan 07 23:30:14 fine. Sorry. Jan 07 23:30:43 dreamhiker: there are no rules dictating the use of particular sites Jan 07 23:31:31 p. 277, heh? I will look that up real quickly. Jan 07 23:34:29 zmatt: I will post a photo. Jan 07 23:34:36 BTW, it started to work :) Stupid me. The ground got disconnected Jan 07 23:35:36 that won't help. anyway, if you're not using a standard breakout for the sensor, be sure to follow all the requirements specified in the datasheet for reliable operation Jan 07 23:36:08 https://pasteboard.co/HVpvOhE.jpg Jan 07 23:36:35 I just thought this may present some valuable info. Jan 07 23:37:10 it doesn't, it shows the connection between a beaglebone and a breakout board of some random other chip Jan 07 23:37:21 but thanks for making the photo Jan 07 23:37:35 No issue. Jan 07 23:38:54 Oh yea. He was using the sht-xx-xx. Jan 07 23:38:57 Sorry. Jan 07 23:39:37 dreamhiker: I'm assuming you're simply confused about the question and are in fact using a breakout board, in which case proper connections for vdd, gnd, sda, and scl suffices Jan 07 23:43:26 to clarify, this is the sensor: https://media.digikey.com/Photos/Sensirion/MFG_SHTxx.jpg this is the adafruit breakout for it: https://www.kiwi-electronics.nl/image/cache/data/products/adafruit/sensor/temperature/ADA-2857-3-1000x667.jpg Jan 07 23:45:01 Oh. Jan 07 23:45:28 I think I have one of those on my Grove connector. I can test it but i am busy, I apologize. Jan 07 23:45:40 I will get to it later. Jan 07 23:45:56 set_: no need, the problem has already been identified (faulty ground connection) Jan 07 23:46:01 How is libpng12 not available for Stretch/Debian? Jan 07 23:46:01 Here is the image Jan 07 23:46:02 Oh! Jan 07 23:46:08 https://pasteboard.co/HVpzBDk.jpg Jan 07 23:46:12 GND! I thought I read that correctly. Jan 07 23:46:26 yeah, so it's a breakout Jan 07 23:47:07 You are (as always correct)! Jan 07 23:47:20 I cannot see the breakout in that photo (close up). Jan 07 23:47:37 So everything is cool then? Jan 07 23:47:53 you might want to consider getting shorter jumper wires (these things: https://static2.tme.eu//products_pics/6/c/5/6c571f6008a9d6b943f8eba0dbaac3c8/32188.jpg ) long wires clipped onto pins like this generally isn't great for reliability Jan 07 23:48:49 set_: it's a bit blurry, but it's the tiny pcb on the left with a header onto which the various wires are clipped Jan 07 23:48:57 honestly, I am waiting for our HW guy, who is on vacations :) And I agree that my connection was clumsy Jan 07 23:49:09 Oh. Jan 07 23:52:41 Should I use a rt kernel for supporting dronekit w/ the BBG or variations of the BBB? Jan 07 23:52:48 dreamhiker: keep in mind that even if the sensor seems to work, poor (i.e. somewhat resistive) ground or vdd connections can also adversely impact sensor performance Jan 07 23:53:00 ... Jan 07 23:53:22 set_: you should use an rt kernel if you're using software that specifically needs it and takes advantage of it Jan 07 23:53:30 I read somewhere that the rt (video w/ slides) patch is now going to be in mainline. Jan 07 23:53:35 Okay zmatt: Good idea. Jan 07 23:54:13 regardless of whether the rt patches are in mainline, it's still a config option at compile-time of the kernel Jan 07 23:54:24 for most general uses you don't want an rt kernel Jan 07 23:54:55 I am going to try rt. I am trying to run dronekit and coming up w/ issues. I think it is based around the real-time issue. Jan 07 23:54:57 zmatt, on a different subject. For this exercise I was using putty client to connect to BBB. There, for my convenience, I was using emacs and gdb. This is sufficient for small exercizes, but probably clumsy for larger projects. What is your suggestion? Jan 07 23:55:52 set_: define "issues". an rt kernel is meant to solve specific kinds of performance problems for software that already takes advantage of real-time process scheduling Jan 07 23:56:21 dreamhiker: sounds fine to me, except I use vim rather than emacs Jan 07 23:57:24 So no Visual Studio, nor eclipse, nor nothing? Jan 07 23:58:09 I have yet to find an IDE that I don't hate, but different people prefer different tools and workflows. just use whatever works for you Jan 07 23:59:30 The software from this github.com repo will not run. I have all the dep.s and I cannot get this "simple" software to run. Jan 07 23:59:43 if it doesn't run, the problem won't be solved by an rt kernel Jan 07 23:59:54 I have just attached a servo for now to test things. Jan 07 23:59:59 Okay. Jan 08 00:00:20 I sort of get why but I am still unclear on what may be the issue. Probably the software. Jan 08 00:00:21 ... Jan 08 00:00:39 So, the rt kernel is for faster processing of real-time communication? Jan 08 00:01:39 the telemetry device works but has not been paired yet. Oh well. zmatt: do not worry about it. Jan 08 00:01:44 note that if you actually hope for feedback, it will probably help to mention the actual project (instead of "software from this github.com repo") and error you're getting Jan 08 00:02:12 Aw! https://github.com/tizianofiorenzani/how_do_drones_work Jan 08 00:02:13 ... Jan 08 00:02:23 and no, rt kernel generally makes things slower, not faster Jan 08 00:02:28 That is it. I had to changed the software a bunch so far to get it to run. Jan 08 00:02:29 Oh. Jan 08 00:02:50 but it reduces worst-case latency Jan 08 00:02:54 But...I am stuck after I get the numpy installed and ready in my env. Jan 08 00:02:56 Aw. Jan 08 00:04:55 On the BBB, the installed files in the v-env, I have to have the specific libs-repos-installs in the env or will it work w/out installing those while env is activated? Jan 08 00:05:27 I have no idea what you're asking Jan 08 00:05:35 I have been working on figuring it out and I do not think this is the issue. I think that python2 and python3 have not become one yet. Jan 08 00:05:55 they haven't and never will Jan 08 00:06:12 There are older repos w/ py2 that droneKit relies on and dronekit it outdated. Jan 08 00:06:23 my condolences Jan 08 00:06:26 I know. Jan 08 00:06:48 They all moved to pilotbeagle or something w/ ardurover. Jan 08 00:06:55 I cannot keep up. Jan 08 00:09:12 I am going to program that Atmel on the Motor Bridge Cape and try to fix the issue. Jan 08 00:09:33 They have six or eight lines of pins for motors. Jan 08 00:09:43 I can do it. Jan 08 00:09:47 ehm Jan 08 00:09:51 What? Jan 08 00:13:25 set_, zmatt: I see your conversation about rt-kernel? What are you guys talking about? Not PRU by any chance? Jan 08 00:13:34 no Jan 08 00:14:06 using pru for real-time tasks is a much better solution whenever feasible Jan 08 00:14:31 https://www.st.com/en/microcontrollers/stm32f0-series.html?querycriteria=productId=SS1574 is the chip instead of the Atmel I mentioned. Jan 08 00:14:39 Okay. Jan 08 00:14:50 PRU is something I have not at all came close to mastering. Jan 08 00:15:00 I am still having issues w/ the compilers. Jan 08 00:15:14 That's why I reacted here. I also do need to get a us precision in controlling GPIO. I was planing on PRU Jan 08 00:15:37 Good luck. TI.com has a ton of resources if you have two years. Jan 08 00:15:51 zmatt, I would like to compliment you on your statement: "rt kernel generally makes things slower, not faster - but lower latency" Jan 08 00:15:53 They have unlimited info. that is up to date. Jan 08 00:16:18 That's the key. And PRU is slower, but it much more predictable in controlling the pins. Jan 08 00:17:23 yeah, PRU can easily achieve us precision. in fact if you use dedicated pru gpio then it can just as happily get you 10 ns accuracy (or even 5 ns in many cases) Jan 08 00:17:23 https://elinux.org/Ti_AM33XX_PRUSSv2#Available_PRU_Resources is a good set of ideas that lead to more ideas. Jan 08 00:17:48 zmatt, did you have an experience with PRU? Do the tools work? Jan 08 00:18:01 for playing with pru you can also check out my https://github.com/mvduin/py-uio project Jan 08 00:18:41 brb Jan 08 00:18:44 it can load both raw binaries produced by pasm and ELF executables produced by clpru Jan 08 00:19:10 and allows direct introspection and manipulation of the pru cores from python Jan 08 00:22:06 zmatt, yes, I read about 5ns precision - something that the main CPU cannot get even close. I would never consider the main CPU even for us precision. Jan 08 00:22:30 set_, what precision do you need? Jan 08 00:22:38 nor should you, I think interrupt latency is itself already 40-80 us or so Jan 08 00:22:51 pretty ludicrous Jan 08 00:23:16 I have no idea what linux is doing in those 40000-80000 cpu cycles Jan 08 00:24:12 I doubt it is 40-80ms. In my experience a few decades ago with Motorolla 68020, even then it was a few Jan 08 00:24:15 us. Jan 08 00:25:04 During the interrupt just some registers needs to be saved/restored plus the context switch, which was just a few machine commands Jan 08 00:25:09 note I'm not talking about the cpu itself but the time linux takes to actually deliver some irq-triggered event to userspace Jan 08 00:25:45 Actually, could be. At that time everything was in the system space :) Jan 08 00:26:30 you can still do that, even on the beaglebone Jan 08 00:26:49 what, to be constantly in the kernel space? Jan 08 00:27:09 writing baremetal code, without some bloated OS getting between you and the cpu Jan 08 00:27:57 I was thinking about it. Even installed some TI code. But something did not work for me. Jan 08 00:28:11 starterware or ti-rtos ? Jan 08 00:28:39 in fact, I am more comfortable in the baremetal space. Jan 08 00:29:23 I do not remember what I was using. Likely ti rtos, because I was getting a few hundred GB from TI Jan 08 00:29:30 oof Jan 08 00:29:56 of course ti-rtos is technically still an os, even if it's going to get less in your way than linux Jan 08 00:31:22 Actually, I think that the combination of Linux for all the services (I will need http) with PRU should be a good combination. What do you think? Jan 08 00:31:28 starterware is a collection of driver/utility/library code if you want to go entirely OS-less, but unfortunately it is a steaming pile of pig manure. I've seen examples that get compiled into a deadloop if you enable optimization, and drivers that work purely by accident if at all Jan 08 00:32:27 I was going to use PRU for rt applications but I cannot. The idea behind it is difficult to me. So, I just keep reading. Jan 08 00:32:40 yeah, if it suits the needs of your application then it's a great combination Jan 08 00:33:18 Okay. So, I have a .asm file and a .h file and a .c file. What would a good cmd line command be? Jan 08 00:33:26 I understand what you are talking about. And I do not have a desire to get into this manure space. Especially, considering that the company depends on me getting some working device-control software :) Jan 08 00:33:27 set_: banana. Jan 08 00:33:31 Oh. Jan 08 00:33:46 set_: your question makes about as much sense as my answer Jan 08 00:33:51 Oh. Jan 08 00:34:02 So, I just need a .c file w/ .h files? Jan 08 00:34:13 For instance... Jan 08 00:34:47 specific directives in the .c file in the form of header files run my software but my command line command is garbage and does not run. Jan 08 00:35:28 set_: the individual words you use have meaning, the way you combine them does not Jan 08 00:35:41 Oh. Jan 08 00:35:42 Okay. Jan 08 00:36:16 set_: if you want concrete pru examples, either in C or in assembly, maybe look at the most basic examples included with py-uio Jan 08 00:36:44 Okay. Jan 08 00:37:01 if you intend to use C programming, you may first want to get used to it on linux instead of on pru Jan 08 00:37:10 I looked over that repo. I will review it again one day. Jan 08 00:37:18 zmatt, thank you for your support. Actually, while my hw person is on vacations and (with your help) the sensor is working, it is good time to look at PRU Jan 08 00:37:51 I have run gcc and g++ on Linux w/ the BBB before. I have been unable to run clpru w/ options and .c files. Jan 08 00:38:13 For instance: Let me give you my command. Jan 08 00:38:16 ... Jan 08 00:38:17 (I'm not a fan of using C for PRU since it negates many of the advantages of PRU, but I understand there are situations where it can be convenient and still adequate) Jan 08 00:38:29 Please hold. Jan 08 00:38:34 what do you mean by: if you intend to use C programming, you may first want to get used to it on linux instead of on pru? Jan 08 00:38:44 set_: clpru requires drastically different invocation compared to gcc Jan 08 00:39:04 Yes, I do want to use c-programming. What else? do you mean assembly programming? Jan 08 00:39:28 I understand. Jan 08 00:39:48 dreamhiker: I'm fairly certain set_ isn't particularly well-versed in C programming, and it's probably easier to learn by doing linux userspace programming in C than doing pru programming in C Jan 08 00:40:09 Oh, I see Jan 08 00:40:53 dreamhiker: and yeah, PRU was designed to be programmed in assembly rather than being targeted by a C compiler (which came much later) Jan 08 00:41:37 it has a simple and elegant instruction set, and quite powerful assembler (with support for data structures and such) Jan 08 00:41:44 Oh. Jan 08 00:41:50 That is good history. Jan 08 00:42:11 Getting back to PRU, will I be able to program it in Ansi-C? Probably not C++? Hopefully not in machine code? Jan 08 00:42:20 I cannot find my damn article and software right now anyway. Forget it for now. Jan 08 00:43:15 there is a C/C++ compiler, but its output is pretty mediocre, in part because the pru instruction set wasn't designed for C Jan 08 00:43:27 using C/C++ also makes timing much harder Jan 08 00:43:57 like, you can definitely forget about the 10ns accuracy when using C ;) Jan 08 00:45:08 clpru -v taco.c -o taco <---- this is what I learned and it is not correct. Jan 08 00:45:17 set_: it most definitely isn't Jan 08 00:45:29 --run_linker is -v right Jan 08 00:45:30 set_: use an existing makefile designed for clpru, don't make shit up Jan 08 00:45:51 okay. Jan 08 00:46:18 --rom_model | --ram_model is needed or not? Jan 08 00:46:58 dreamhiker: here's an example of pru assembly that makes use of variables and data structures (which are higher-level concepts than you generally find in assembly languages): https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/stream.pasm Jan 08 00:46:59 In my experience C for friendly processors (like former 68020 or intel960) is typically mapped 1-to-1 to machine code. At the same time, a more complex machine code like Intel MMX/SSE is not mapped well. So, is your recomendation to program PRU in machine code? I do not mind, as long as it is a good machine code. Jan 08 00:47:35 it is a simple and very regular instruction set that's small enough to fit in one's head Jan 08 00:49:14 also the fact that nearly every instruction takes exactly 1 cycle to execute is very convenient for making highly accurate and deterministic timing (the major exception being memory load/store instructions, although these are typically still deterministic when accessing pruss-local resources) Jan 08 00:49:22 Oh, I see. It seems they have a quite classical machine code + some Macro Assembly support to make things more readable. Jan 08 00:49:28 Could be fun! Jan 08 00:49:39 yes, it's a simple and nice risc instruction set Jan 08 00:49:50 32-bit, lots of registers Jan 08 00:50:49 deliberately no pipelining (hence no need for branch prediction) Jan 08 00:51:07 what is code and .bss sizes? Jan 08 00:51:48 8 KB instruction ram (i.e. 2048 instructions) per core Jan 08 00:52:06 (another great reason to not use a C/C++ compiler) Jan 08 00:53:22 Yes, 8KB is small. But for my real-time of controlling pins should be sufficient Jan 08 00:53:55 I am curious what was the reason for such a small code space. Jan 08 00:54:01 there are three local data memories with deterministic low access time: 8 KB + 8 KB + 12 KB. officially it's 8KB for each core and 12KB shared, but both cores (as well as other initiators like the cortex-a8 and the DMA controller) can access all three memories Jan 08 00:55:07 probably the fact that instruction ram is very tightly coupled to the core. the lack of pipelining means there's only 5 ns to fetch the instruction from iram, decode it, and execute it (including determining the next instruction address) Jan 08 00:55:32 even an 8-bit avr has a pipeline stage Jan 08 00:55:56 running at 200 MHz without any pipelining whatsoever is pretty impressive Jan 08 00:57:06 and it's plenty of most uses Jan 08 00:57:11 Motorolla was 20MHz :) And we were able to do powerful things. Jan 08 00:59:32 pru can also efficiently write data to external (ddr3) ram as long as it doesn't exceed the (very considerable) bandwidth, since its writes to the L3 interconnect are "posted" (fire-and-forget) Jan 08 01:00:15 which enables projects like BeagleLogic (which turns a beaglebone into a 14-channel 100Msps logic analyzer) Jan 08 01:00:51 A different question. The reason I have switched to BBB from BB-X15 is the lack of the documentation. For BBB there are good books, a lot of community support, etc. But I do not see it for x15. I do realize that some Linux-savy people maybe do not need cook-books and good documentation, but for Linux-mediocre people like me it is difficult. Can you comment on this? Jan 08 01:01:20 both could use much better documentation Jan 08 01:01:27 especially uptodate documentation Jan 08 01:01:56 on the software side the differences aren't that big though, except that pin configuration is a pain in the ass on the x15 Jan 08 01:02:16 (as is connecting stuff to those pins due to its connectors) Jan 08 01:03:48 but once you have a good understanding of how to do stuff on the beaglebone, you can probably easily move to the x15 if you'd want to Jan 08 01:04:08 it's just less inviting for experimentation Jan 08 01:05:30 and being able to experiment easily makes learning so much easier Jan 08 01:06:30 Okay. What would be the type of communication that is best used to com. b/t a receiver/bbb and transmitter? Jan 08 01:07:03 There is this talk from 2012 but the person in the video at ECLE was too quiet. Jan 08 01:07:16 set_: too vague, there's no "best" in general Jan 08 01:07:21 Okay. Jan 08 01:07:37 I can use PWM b/c of my receiver but I was thinking about just uart. Jan 08 01:07:53 UART is easier for me than PWM for some reason. Jan 08 01:08:39 anyway, I have the receiver powered via sys_5v, GND, and UART_TX2. Jan 08 01:08:49 I think I need to use UART_RX2 instead. Jan 08 01:08:55 Goofin' Jan 08 01:09:04 what are you talking about? Jan 08 01:09:11 what "receiver" Jan 08 01:09:23 are you talking about the sabertooth thing or something? Jan 08 01:09:32 I have a X8R receiver w/ a transmitter. Jan 08 01:09:54 x-lite from FrSky (both are from FrSky). Jan 08 01:10:40 This sucker will not pair to the transmitter. This is not a BBB issue, I know. But my write and read examples need to work via some protocol. Jan 08 01:10:52 Should I have one in and one out? Jan 08 01:11:02 Or just power, signal, and gnd? Jan 08 01:12:40 I figured this would be okay. I put in wiring to Receiver1 for power, gnd, and signal from the BBB. Now, I put a wiring from my receiver to the servo for testing. Jan 08 01:12:41 ... Jan 08 01:13:13 what signal? Jan 08 01:13:29 oh Jan 08 01:13:30 huh Jan 08 01:13:38 hold on I'm reading the confusing datasheet Jan 08 01:13:54 I figured some odd software would work out of the box, https://github.com/tizianofiorenzani/how_do_drones_work/blob/master/libs/plane.py, so I could run off the UART. Jan 08 01:13:55 ... Jan 08 01:13:58 Okay. Jan 08 01:14:20 I fixed all of the bugs and bad code in his software. Jan 08 01:14:35 zmatt, that's what I thought. But apart of the lack of usb-3, most likely BBB with PRU will be powerful enough for my needs. Jan 08 01:14:53 set_: ??? what does this have to do with pairing these x8r devices? Jan 08 01:15:13 Nothing. Pairing is straight forward but has not worked for me. Jan 08 01:15:27 I am waiting to pair it and make the software work. Jan 08 01:15:58 I keep trying new ave. and examples. Notta, so far. Jan 08 01:16:00 if you're trying to get help with something, it really helps to not randomly insert a completely different topic Jan 08 01:16:09 Okay. Jan 08 01:16:12 No issue. Jan 08 01:16:24 unless you're explicitly trying to make people confused and frustrated Jan 08 01:16:51 Well, I did chat about it previously for a short bit but I understand. Jan 08 01:16:56 We were on PRU stuff. Jan 08 01:16:59 My bad. Jan 08 01:17:54 no you were asking about this x8r receiver, both pairing it to the transmitter and interfacing it to the beaglebone, as far as I could tell (I'm not really sure) Jan 08 01:18:06 That is all. Jan 08 01:18:33 I was just wondering if you or anyone else was using receivers w/ specific communication to advance learning w/ the BBB. Jan 08 01:18:52 I have one particular one but general ideas is good too. Jan 08 01:19:31 is there a particular reason to use this thing to send signals to the beaglebone? it seems extremely inconvenient for the application Jan 08 01:19:50 Not really. I just had it and wanted to interface w/ it. Jan 08 01:19:52 not impossible mind you, but not simple either Jan 08 01:20:01 I understand. Jan 08 01:20:10 (unless its "s-bus" output is convenient serial data, but I can't find any real documentation about it) Jan 08 01:20:47 s-bus is a "new" protocol for wiring. It is only a servo wiring set up. Jan 08 01:20:59 I do not know why they sold the idea of Sbus. Jan 08 01:21:16 I can use 16 CH b/c of Sbus. Jan 08 01:22:06 it does seem sbus uses an uart protocol Jan 08 01:22:28 Okay. Jan 08 01:22:38 I am about to add the uart section in the software. Jan 08 01:22:44 ? Jan 08 01:22:52 Serious. I have not added it yet. Jan 08 01:22:59 I have no idea what you mean by that Jan 08 01:23:01 "the uart section" Jan 08 01:23:12 I have not typed up the uart portion to the software in the "example." Jan 08 01:23:18 what "uart portion" Jan 08 01:23:27 that's about as vague as "the thing that does things with pins" Jan 08 01:23:34 Ha. Jan 08 01:23:44 Hold on. I will make sense. Please hold. Jan 08 01:24:42 I have to import "dronekit" as "whatever" and then I was just going to use Adafruit_BBIO.UART as UART and then call blah = (uart2) Jan 08 01:24:57 Let me get the real example. Jan 08 01:25:00 Please hold. Jan 08 01:25:40 for what purpose? Jan 08 01:26:24 https://pastebin.com/uZnKjAmK is the software I am rearranging. Jan 08 01:26:35 to suit my needs. Jan 08 01:26:36 if you mean for sbus, you'll still need some logic to interface it electrically (it is inverted, and quite possibly 5V) Jan 08 01:26:48 I, oh. Jan 08 01:26:54 I just understood what happened. Jan 08 01:27:10 I have it powered via 5v but the bbb gives 3.3v logic? Jan 08 01:27:19 what are you talking about? Jan 08 01:27:50 The receiver needs to be powered via 4.0v to over 5.0v (some voltage). Jan 08 01:28:04 okay, so we're still talking about the x8r receiver Jan 08 01:28:13 RIght now, yes sir. Jan 08 01:28:51 are you trying to connect its sbus output to the beaglebone? because it so, connecting it directly 1. will definitely not work 2. has a decent chance of damaging the beaglebone Jan 08 01:28:54 I am working on a project w/ a receiver, transmitter, and the BBB. Jan 08 01:28:57 *if so Jan 08 01:29:41 I have one TX(UART) pin coming from the BBB to the Receiver. I am powering the Receiver via 5v from the BBB. Jan 08 01:29:49 that makes no sense Jan 08 01:30:00 the receiver would provide data to the beaglebone, not the other way around Jan 08 01:30:08 Oh. Jan 08 01:30:19 since it's... a receiver Jan 08 01:30:28 which, you know, receives... stuff... Jan 08 01:30:44 okay I guess that can be interpreted two ways, and I'm being silly Jan 08 01:30:46 So, I need the UART RX to work w/ the Receiver. Jan 08 01:30:47 Okay. Jan 08 01:30:54 yes, but again do _not_ connect that directly Jan 08 01:30:58 Okay. Jan 08 01:31:04 I will not connect them directly. Jan 08 01:31:14 Should I use a voltage divider? Jan 08 01:31:19 according to the interwebs you need an interter Jan 08 01:31:24 *inverter Jan 08 01:31:26 Oh. Jan 08 01:31:27 Okay. Jan 08 01:31:30 inverter. Jan 08 01:31:38 Where did you find that info? Jan 08 01:31:50 I also have no idea what voltage s.bus uses, I've not found any specification of it, or even an informal mention Jan 08 01:32:05 (as typical for all rc stuff I've tried to briefly look into) Jan 08 01:32:11 It is a RC thing. Jan 08 01:32:25 right. I just wanted to try rc w/ the BBB for a different view on life. Jan 08 01:32:32 yes, apparently everybody makes compatible stuff but nobody actually writes specs Jan 08 01:32:42 I hate that. Jan 08 01:33:34 do you think a switching regulator would work? Jan 08 01:33:50 I am asking b/c I actually have one on my desk. Jan 08 01:33:59 you can try using the transistor + pull-up trick you can find floating on the internet: https://dev.px4.io/assets/driver_sbus_signal_inverter_circuit_diagram.png Jan 08 01:34:12 ehm, it'll work about as well as a banana Jan 08 01:34:38 Okay. PLugging in banana now. Just kidding. Jan 08 01:35:24 My uart signal from the Receiver is at what voltage? Jan 08 01:35:25 instead of the transistor construction you can also just use a proper inverter, 3.3v-powered but with 5v-tolerant input Jan 08 01:35:35 See. Jan 08 01:35:49 the s.bus (inverted uart) signal from the receiver has unknown and undocumented electrical specs Jan 08 01:36:01 Hhahahahaha. Odd days. Jan 08 01:36:18 I will look online soon or contact those people who mfg. it. Jan 08 01:36:26 This is good insight. Jan 08 01:37:31 so I'd personally prefer some inverter with a robust and high-impedance input to maximize compatibility. however, apparently people have success with the schematic I linked earlier, so if you happen to have an NPN transistor, 1K resistor, and 10K resistor, you could give it a try Jan 08 01:37:49 see https://dev.px4.io/en/tutorials/linux_sbus.html for more details on the circuit Jan 08 01:39:13 Okay. I have the resistors and some sort of transistor. I will have to research the type of transistor I have. Jan 08 01:40:00 yeah the webpage says any NPN transistor should do Jan 08 01:40:31 NPN, got it. I will have to look around. Jan 08 01:42:57 I fn got it. Jan 08 01:43:09 NPN~ Jan 08 01:44:28 and, bizarre as it seems, apparently you bind the receiver to the transmitter by connecting "battery" (i.e. 5V) to one of the receiver's eight output channels while the receiver is powered and you're holding the F/S button Jan 08 01:44:45 (while the transmitter is also in bind mode) Jan 08 01:47:41 I can't imagine what could possibly have made them think this is a sane thing to do, instead of having a dedicated button or signal input for binding Jan 08 01:48:12 Right. I tried that. I have been unsuccessful so far. Jan 08 01:49:27 What I read was this, "turn on the tx while holding the f/s button on the rx." Jan 08 01:49:44 "after the power had been applied to the rx." Jan 08 01:49:59 that's not what the x8r documentation says Jan 08 01:50:34 I might have an older model of the docs. in my hands. Jan 08 01:50:39 I will go online and look. Jan 08 01:51:06 https://www.frsky-rc.com/wp-content/uploads/2017/07/Manual/X8R.pdf Jan 08 01:51:33 I see that now for mode1. Jan 08 01:51:42 for any mode Jan 08 01:51:47 the default (mode 5) seems fine to me Jan 08 01:52:14 s.bus is not supported in mode 1 apparently Jan 08 01:52:21 Okay. I am going to try it again. Jan 08 01:52:41 Wait for fireworks! Jan 08 01:52:45 anyway, I'm gonna do other stuff Jan 08 01:52:56 Okay. Thank you for being here still. Jan 08 01:53:02 Numero uno! Jan 08 01:53:43 zmatt hates rc!@ Jan 08 01:53:47 Ha. **** ENDING LOGGING AT Tue Jan 08 02:59:57 2019