**** BEGIN LOGGING AT Tue Feb 11 02:59:58 2020 Feb 11 03:04:44 This is a neat cape and neat chip. You can add and configure all sorts of external connections w/ just MOSFETS and resistors. Feb 11 03:05:21 no code available for testing unfortunately. So you are on your own. Feb 11 03:05:32 No issue. I can configure something. Feb 11 03:06:16 First, I got to figure out how to handle this i2c, pwm, and power concern. Then, off to programming land. Feb 11 03:09:11 right just remember these numbers 1 = min 1.5 = 90 degree 2 = max on servo. that's in milliseconds. figure you numbers from that and the documentation. Feb 11 03:16:21 Okay. So: 1 = min && 1.5 = 90 degrees && 2 = max. But, how do you know this already? Feb 11 03:34:32 milliseconds, it's the definition of the servo control read wikipedia. Feb 11 03:40:59 Okay. I will check that out. I am on page 16 and reading the datasheet to get used to it. Feb 11 03:44:05 I need some catching up time. It is register refresher time for me. Feb 11 04:28:22 I am stuck in Python.org looking to access registers. I found out how in asm files but not w/ Python. Feb 11 04:28:23 Blah. Feb 11 04:55:22 Do I have glibc access w/ ctypes in Python on the BBB? Feb 11 05:17:26 I'm using Putty terminal to send strings of data to BBB UART4. I always receiving echo the same message i sent Feb 11 05:17:33 does anyone know how to disable it ? Feb 11 05:20:19 I can replicate what you are doing and maybe be able to help but do not rely on me. Feb 11 05:26:36 HCL47: probably the uart's termios hasn't been configured right Feb 11 05:26:55 unless you're talking about local echo by putty Feb 11 05:27:09 in which case it'll be putty's settings Feb 11 05:28:09 i even try out TeraTerminal , Hercules and Putty terminal. All will receiving echo when i press sending the message to BBB Feb 11 05:28:42 you have software running on the BBB that is supposed to receive the message? Feb 11 05:29:17 it should ensure the serial port is configured to raw mode Feb 11 05:29:30 yes my python program in BBB did receive the message. But my program didn't write any message back. Feb 11 05:30:27 I would kinda assume pyserial configured the port to raw mode by default Feb 11 05:30:47 i only configure my bbb using config-pin P9.11 uart Feb 11 05:30:52 and config-pin P9.13 uart Feb 11 05:31:10 that's just pin configuration Feb 11 05:31:29 your python program uses pyserial I assume? Feb 11 05:31:34 ser = serial.Serial('/dev/ttyS4', 38400, timeout=0.050) Feb 11 05:31:41 my python serial configuration as above Feb 11 05:33:17 ok, I just checked, pyserial absolutely does configure the port to raw mode, no echo Feb 11 05:33:33 so what you're seeing is just your terminal program showing you what you're typing, it's not data coming in via the serial port Feb 11 05:34:12 for example, in putty this can be disabled here: https://i.stack.imgur.com/cs4Kx.png Feb 11 05:34:29 (set to Force off) Feb 11 05:36:27 that's my guess anyway, since I don't see any reason the BBB would echo data when pyserial configures it to raw Feb 11 05:38:33 still receiving message from BBB even i set it to Force Off Feb 11 05:38:40 ehh Feb 11 05:38:48 import time Feb 11 05:38:57 simple program like this will have such error as well Feb 11 05:39:05 use BBB to run such python program Feb 11 05:39:22 then i use putty terminal to send string to BBB, i will receive the message Feb 11 05:39:49 I don't know if you just tried to paste multiline code into chat (it just showed "import time"), but if you so... don't. use a paste service such as pastebin.com to share code Feb 11 05:41:02 Hey, what are you guys discussing? Feb 11 05:41:43 set_: ehm, the entire page of text is presumably still on your screen? Feb 11 05:41:58 Right, it is. Just curious. You know me, lazy eyes. Feb 11 05:42:08 I will read it again. Feb 11 05:42:48 https://pastebin.com/fH8xUw3v Feb 11 05:46:44 lemme see if I can test this here Feb 11 05:50:07 https://ibb.co/SXDm5pN Feb 11 05:50:20 i uploaded the pictures of message i received Feb 11 05:51:59 but that's not actual echoing, it's heavily corrupted Feb 11 05:52:14 the pink one is message i send Feb 11 05:52:20 could this be a hardware issue? like cross-talk? Feb 11 05:52:21 the black one is message i received. Feb 11 05:52:36 although I can't imagine how that could be so severe Feb 11 05:52:40 it shouldn't be receiving this message Feb 11 05:54:22 this is really starting to look like a hardware issue to me, both because there's no plausible reason for the echoing and because the echoed version clearly has many many bit-errors Feb 11 05:54:52 even if the BBB were echoing for some inexplicable reason, that would still leave the question of why it's so corrupted Feb 11 05:56:50 https://ibb.co/tmCr5mG Feb 11 05:56:55 my hardware setup Feb 11 05:57:01 shouldn't be hardware ? Feb 11 05:57:26 as both UART2 and UART4 will have such issue Feb 11 05:58:43 hmm, why is the 3.3v supply from the beaglebone going to the usb-serial converter? Feb 11 05:59:20 to power up the RS232-TTL Feb 11 05:59:52 i'm having a RS232-TTL in between the BBB and (RS232-USB) Feb 11 05:59:58 have a link to a datasheet or product page for that usb-serial converter? Feb 11 06:04:48 i try to use another USB-serial and check it out Feb 11 06:05:05 I have used serial ports before on the BBB without any problems like these. I've also never seen data corruption on BBB serial ports, not even at 4.608 Mbaud Feb 11 06:05:53 unless some other software on the BBB is hijacking the port while your software is running and causing it to echo (either by echoing itself or by reconfiguring the port to echo), the BBB won't echo data Feb 11 06:08:05 make sure the ground connection isn't loose or something Feb 11 06:10:05 and I'm still curious about your connection from the 3.3V of the BBB to the usb serial converter... I've never seen an usb serial converter that needs to be powered from the target side (though it would certainly be useful, to make it voltage-adaptive) Feb 11 06:11:55 an easy way to avoid any issues from usb-serial converters is to just configure two uarts on the same BBB and cross-connect them Feb 11 06:12:09 and confirm they can communicate with each other without problems Feb 11 06:27:42 thanks zmatt Feb 11 06:27:50 is hardware issue on my USB-RS232 cable Feb 11 06:28:09 i use another type converter and this issue resolve Feb 11 06:28:24 The BBB lives! Feb 11 06:29:26 zmatt , you may see the device like this Feb 11 06:29:27 https://sg.rs-online.com/web/p/processor-microcontroller-development-kits/8829042?cm_mmc=SG-PLA-DS3A-_-google-_-PLA_SG_EN_Semiconductors-_-Semiconductor_Development_Kits%7CProcessor_And_Microcontroller_Development_Kits-_-PRODUCT_GROUP&matchtype=&pla-393439849165&gclid=Cj0KCQiAm4TyBRDgARIsAOU75srRf6wZ52-Z3IDEL6r1XpD5vpTtu06zbBFb3kP0wQ-tmxbr9nZ-ocUaA Feb 11 06:29:27 nxLEALw_wcB&gclsrc=aw.ds Feb 11 06:29:39 usually it will need external power to power up. It can be 3.3v or 5v Feb 11 06:33:48 oh I only now just realized you're not using an usb to ttl serial converter but an rs232 driver attached to the bbb... jeez i'm blind Feb 11 06:34:59 normally i use another one...because that one is too short so i swap to a new converter . ended up new issues Feb 11 06:35:08 thanks for pointing out Feb 11 06:35:40 it does seem like this should work.. although this link doesn't look like the one you used in your photo Feb 11 06:36:10 perhaps you used one that doesn't work on 3.3v ? Feb 11 06:49:25 3.3v is working fine. Is from laptop->USB-RS232 converter that giving issue. That RS232-TTL is working fine at 3.3V Feb 11 08:30:49 Guys need some help....I have recently updated my BBB Rec C to Debian 9...from Debian 7 via reflashing...now in CCS I am uabe to access the RAM when connected over JTAG where I could on Debian 7 Feb 11 08:41:41 Robert58: what is "unable to access the RAM" exactly? Feb 11 08:48:19 Robert58: as in "cannot set breakpoints in kernel"? Feb 11 08:58:53 thinkfat_: those are two rather different things Feb 11 08:59:06 Robert58: maybe the old kernel didn't disable the debugss clock Feb 11 08:59:24 In Debian 7 I could setup a debug session in CCS8, and connect the DebugSS and view teh RAM in memory browers, when I do the same in Debian 8 all I see is . . . . . . for the memory locations Feb 11 08:59:51 in theory you should be able to use an overlay to force-enable the debugss clock, but last time I tried that it didn't work, however manually enabling it did work Feb 11 09:00:03 lemme search irc history for the command Feb 11 09:01:16 Robert58: try: sudo omapconf write 0x44e00414 0x12550002 Feb 11 09:04:32 normally the debugger is supposed to be able to override power, reset, and clock controls via jtag (via ICEPick debug tap access registers) but TI failed to do proper ICEPick<->PRCM integration on the AM335x so the debug subsystem has to be kept enabled by software to allow the debugger to work properly (and the kernel by default will disable "unused" modules) Feb 11 09:05:25 (though in theory the debugger could attach to the wakeup-M3 DAP and use that to enable the main debugss in PRCM) Feb 11 09:05:43 Cheers...let me give that a try and see where I get...many thanks! Feb 11 09:35:20 zmatt: yet its a typical stumbling block when moving to a more recent linux kernel ;) Feb 11 09:35:53 zmatt: but yes, sometimes I take the second step before the first. And sometimes it works and sometimes it doesn't ;) Feb 11 09:37:04 I don't really know anything about kernel debugging via jtag, and wouldn't assume that's what someone is trying to do when they're just mentioning viewing RAM via a memory browser Feb 11 09:40:30 zmatt: because that's what you typically do with a linux platform when you hook up JTAG ;) Feb 11 09:40:45 zmatt: of course, why would you use CCS for that... Feb 11 09:41:46 exactly. pru stuff seems more likely (although there's not really a fundemantal reason to use jtag for that, but I think that's the only way to debug PRU C applications currently) Feb 11 09:55:04 zmatt: well kernel debugging with jtag is just the same as debugging any bare metal program. you hook up your jtag, point your debugger to the elf file and off you go. Feb 11 11:21:57 Hi, all Feb 11 14:04:59 zenmap is cool ... heh :D Feb 11 15:40:12 Hello guys! Feb 11 15:40:28 I have a question: Feb 11 15:41:07 How can I format eMMC on beaglebone black? Feb 11 15:54:00 Anyone? Feb 11 16:12:05 impatience... Feb 11 16:16:48 zmatt: consider it a pre-filter :D Feb 11 18:40:49 Well that was stirring slowly. Feb 11 18:44:38 GenTooMan: Hello! What are you concocting these days? Feb 11 18:45:00 "Testing w/ the best?" Feb 11 19:14:19 set_ waiting for a relativistic phone call and assessing config-pin script to see what would make sense to implement in python Feb 11 19:16:12 in python you can reconfigure a pin with a one-liner Feb 11 19:17:23 config-pin is ultimately just a big wrapper around reading/writing some sysfs attributes Feb 11 19:21:40 zmatt exactly why I was thinking that, It's clunky to set things then run my python script, it makes more sense to set things up in python too me at least. Feb 11 19:23:54 zmatt still it's pretty "complex" just to look at this "thing" LOL Feb 11 19:31:39 GenTooMan: https://pastebin.com/MKtWJ8G8 Feb 11 19:32:10 instead of a one-liner I made it a nicer wrapper with more sensible interface ;) Feb 11 19:33:02 ah wait, re-raising in python is just "raise" Feb 11 19:33:17 fixed Feb 11 19:35:17 same paste I presume? Feb 11 19:35:23 yes Feb 11 19:37:30 not quite as fancy as I had envisioned but I tend to overdo things. A good example is my "test" for the SPI port which is 724 lines .. heh. Feb 11 19:37:55 not sure how I'd make this fancier Feb 11 19:41:33 Oh I can overcomplicate anything practically. :D Feb 11 19:42:29 That is my job! Feb 11 19:43:01 To turn simplistic into heart wrenching is my shtick. Feb 11 19:43:55 simplicity takes work complexity is the result of doing something other than what you should do. Feb 11 19:44:19 Right. My J-O-B! Feb 11 19:45:06 I am dealing w/ the mfg. now in regards to the Cape. I am learning how to use this thing. Feb 11 19:45:25 I have the datasheet open but registers mean nothing to me as of now. Feb 11 19:46:29 I need to keep reading. The Python3 venture I went on last night tended to lend itself to ioctl and fcntl. Feb 11 19:46:42 I learned about wrappers and how to use ctypes. Feb 11 19:47:11 Not so easy but doable. I will keep trying. Feb 11 19:49:46 I am reading too much. I am going googlie eyed. Feb 11 19:51:32 I suggest writting down a plan of action even if it's wrong it's better than random bits in your brain firing off. Feb 11 19:54:46 Okay. Plans: Make this Cape work, Danny. Feb 11 19:55:01 . = ! Feb 11 19:56:52 so define what work means. Feb 11 19:56:57 :D Feb 11 20:00:01 Okay. I have to read about registers, Python3, and calling in Python3 scripts. Feb 11 20:00:11 I think that should sum up what needs to happen on my end. Feb 11 20:01:33 that sounds too vague to be meaningful Feb 11 20:01:44 what kind of registers are you talking about? Feb 11 20:03:21 unstructured. You need to define some steps of what you are trying to do. IE I need to set the pulse width to X and it needs to repeat with a period of y. How to set y and x comes after defining the former. Feb 11 20:04:03 Oh. Feb 11 20:04:37 ah registers of the pwm controller, i.e. you're either trying to learn about i2c transfers in python and/or setting the pwm controller's registers via i2c (those are two fairly independent things to learn) Feb 11 20:05:58 Okay. See, I just asked the mfg. if I needed to see if I needed to read about i2c for controlling the Cape. Feb 11 20:06:23 I guess that is a big YES on this one. Feb 11 20:06:57 unless the cape has an overlay that configures a kernel driver for it Feb 11 20:07:19 I do not think it does but I will look. Feb 11 20:07:54 yeah doesn't look like there is one Feb 11 20:08:23 Oh. Feb 11 20:08:24 Okay. Feb 11 20:21:26 What is the i2c module in Python3? Feb 11 20:22:59 I guess I will need to find a wrapper instead. Blah. Feb 11 20:23:01 Forget it. Feb 11 20:23:23 smbus2 Feb 11 20:23:50 Oh. Okay. Feb 11 20:24:05 I guess i can use this one again for this particular Cape. Feb 11 20:24:19 for any i2c communication Feb 11 20:24:31 I was searching the Python3 docs. and found nothing. Feb 11 20:24:34 Is that normal? Feb 11 20:25:17 if you were searching literally the documentation of python3 itself, then yes Feb 11 20:25:23 Oh. Feb 11 20:25:24 Okay. Feb 11 20:25:42 I thought since they had other modules, i2c modules would be available too. Feb 11 20:26:46 python comes with a "standard library" of a select few modules Feb 11 20:27:07 most modules are not part of this standard library Feb 11 20:27:47 Oh. Feb 11 20:27:48 Okay. Feb 11 20:28:51 when you state "standard library" in your last sentence, are you discussing the libc.so.6 std? Feb 11 20:28:56 no Feb 11 20:29:00 Okay. Feb 11 20:29:16 that's the C standard library and has nothing to do whatsoever with the python standard library Feb 11 20:30:10 Okay. Feb 11 20:30:50 But, wrappers can be made from std to the Python calls that can be made, right? Feb 11 20:31:50 So, for instance, if I wanted to use a c library in Python, ctypes would work. Feb 11 20:32:07 Mostly...I am sure there are drawbacks. Feb 11 20:33:11 how is this relevant for your current goal of configuring the pwm controller on the servo cape? Feb 11 20:33:28 why do you even have this servo cape? you already had the motor bridge cape Feb 11 20:34:15 and working python code for it Feb 11 20:34:23 this whole servo cape just seems like a distraction Feb 11 20:34:23 Oh. Feb 11 20:34:39 a way to *yet again* be back to square 1 Feb 11 20:34:47 It is a distraction. Not only do I make things complicated, distraction is my middle name. Feb 11 20:34:50 Right, right. Feb 11 20:35:05 No offense but I need to do learn things and do stuff. Feb 11 20:35:30 I cannot always just promote more findings geared towards the same chips and Capes. Feb 11 20:35:54 But. I get what you are saying. I am starting something new instead of advancing in older ideas. Feb 11 20:36:54 https://github.com/torvalds/linux/blob/master/sound/i2c/i2c.c Feb 11 20:36:57 Look what I found. Feb 11 20:37:15 is this i2c.c file on the BBBW? Feb 11 20:37:32 that file has absolutely _nothing_ to do with _anything_ you are doing Feb 11 20:37:38 Okay. Feb 11 20:37:39 Fine. Feb 11 20:38:07 _nothing_? _anything_? What about ctypes and making the Cape work? Feb 11 20:38:29 it has nothing to do with anything you've done in the past year Feb 11 20:38:34 Fine. Feb 11 20:38:35 or tried to do Feb 11 20:38:36 Okay. Feb 11 20:38:49 ctypes is also of no relevance to making the cape work Feb 11 20:39:11 Oh. Feb 11 20:39:20 just distraction upon distraction upon distraction Feb 11 20:40:09 @zmatt: Calm down, mate. I finally put things together in the end but "in the end" is the end. I have to move on to new "horizons." Feb 11 20:41:05 My bot is put together and working. Do you expect me to learn more about that ST chip onboard the Motor Bridge Cape? Feb 11 20:41:23 I have some "nice" plans. Feb 11 20:41:43 Ideas a-plenty! Feb 11 20:46:23 argh. Feb 11 21:31:49 set_ the motor bridge cape is simpler than the servo cape. Namely because you have SW for it already. Feb 11 23:06:17 set_ the motor bridge cape is simpler than the servo cape. Namely because you have SW for it already. Feb 11 23:06:47 set_ also keep things simple until you have proven them to work... always a good axiom ... although I seldom actually follow that :D Feb 11 23:54:56 Yep. This is going to be a long journey. Feb 12 00:00:26 Hi i have question Feb 12 00:01:05 do you know beagle Bone AI Feb 12 00:01:37 i want connect debugger Feb 12 00:02:07 but they not supply to Target Feb 12 00:02:31 so who knows this problem? Feb 12 00:15:46 you may wish to check the reference manual it gives some information about debug connections search for Debug and JTAG https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual Feb 12 00:25:45 JI: You have to purchase one instead of it being supplied when the board is purchased. Feb 12 01:42:15 I finally found some info. on the PCA9685. Feb 12 01:42:29 And oddly enough, not from the mfg. Feb 12 01:44:36 I found that in linux 5.3.x, there is a driver for this chip. Feb 12 01:45:02 Baby steps...baby steps. Feb 12 01:50:05 One must wait, I guess. **** ENDING LOGGING AT Wed Feb 12 03:00:33 2020