**** BEGIN LOGGING AT Thu Dec 19 03:00:12 2019 Dec 19 03:20:47 I made some udev rules. Dec 19 03:20:49 Yea boy! Dec 19 03:25:42 I got the bypass of smbus to understand its belonging to the i2c group. Yea! Dec 19 03:26:17 Now...I need to figure out what exactly was meant by MotorBridge.writeByte(xxx, xxx). Dang. Dec 19 03:26:33 writeByte in smbus2 is labeled differently. Dec 19 03:29:15 Sorry. Not writeByte! It is writeList Dec 19 04:03:50 it was write_quick for the smbus2 library. Dec 19 04:03:56 Yea boy! Dec 19 04:04:06 Now. Onto testing again! Dec 19 05:15:50 is there a way to get access to /dev/i2c-0 or i2c-1 or i2c-2 w/out complication? Dec 19 05:16:21 my udev rule is too weak or something. Dec 19 06:07:11 Otay! I got it. Dec 19 06:09:12 really? Help me Dec 19 06:10:32 victor96: ? Dec 19 06:11:56 set_: it is very unlikely that you want write_quick for anything Dec 19 06:13:23 set_: permission denied is odd, the debian user should normally have suitable rights to access i2c devices Dec 19 06:14:05 I was looking for the part number of a TVS that can help prevent lightning zapping my BBB because I use my BBB to act like a home security system where I connect magnetic door/window sensor through a long wire in the attic to the GPIB 3.3V input line Dec 19 06:15:10 no, this is a simple magnetic contact sensor that you mount in the window / door Dec 19 06:15:39 it is just open/close contact so no need to mess with I2C Dec 19 06:17:32 victor96: uhh, is that in reply to someone? I feel like I'm reading half a conversation or something Dec 19 06:18:13 no, I originated this question like a week ago Dec 19 06:18:50 yes I remember, it's a rather niche question and also sounds like "can anyone please search a parts catalog for me? I'm too lazy" Dec 19 06:19:03 :P Dec 19 06:19:39 I'm just not sure why you brought up i2c Dec 19 06:20:00 I wrote all the scripts to make a BBB into a home security system but my problem is that lightning had zapped my previous 2 BBB. Right now I am using opto couple to isolate the lightning from the BBB but still got zapped Dec 19 06:21:31 No, it's not the matter of lazy but I just lack of the knowledge to spec out a correct one. Dec 19 06:21:43 maybe it's hitting your BBB via a different route than you're expecting Dec 19 06:24:00 well! where could the lightning be coming in? the network cable is short and next to the network switch and the network switch should have lightning protection, the power support is on a surge protection strip. The only thing not protected and with long wire up in the attic is the one asking for lightning to strike Dec 19 06:24:12 wait, if you're using opto-couplers, and your sensors are simple magnetic contacts, what is providing power on the sensor-side of the opto-coupler? Dec 19 06:24:52 power support = power supply Dec 19 06:25:06 a completely separate one? Dec 19 06:25:41 not a power output of the BBB itself I'd hope Dec 19 06:26:09 the opto coupler is using 5V which is tapped out at the BBB's power input Dec 19 06:26:31 lol, so you've connected your giant lightning-antenna straight into a power supply of the beaglebone? :P Dec 19 06:27:02 you got a point Dec 19 06:28:29 I was thinking the primary circuit and the secondary circuit are within the chip so they have no physical distance to isolate the lightning energyopto coupler Dec 19 06:28:57 besides that, I believe the right thing to do is to use TVS Dec 19 06:29:23 and hoping someone has that expertise to show me the way Dec 19 06:29:35 i2c! Dec 19 06:29:47 I don't exclude the possibility someone here might have that expertise, I'm not really one of them though Dec 19 06:30:20 I got the Motor Bridge Cape working again w/ write_quick. So far, it is the only one I can configure to work w/ the MotorBridge Cape. Dec 19 06:30:37 but like I said earlier, this sounds like a question where you might be able to get fruitful feedback on some electronics forum or stackoverflow or something Dec 19 06:30:45 since it's not really beaglebone-specific Dec 19 06:31:17 Thanks for trying. I probably need to go back to dig the great minds of engineering at Little Fuse. Just have to find some way to hook up with them Dec 19 06:32:41 I thought Stackoverflow are discussion in software than hardware Dec 19 06:33:07 victor96: I meant https://electronics.stackexchange.com/ Dec 19 06:33:37 Thanks zmatt. I will try them Dec 19 06:33:53 set_: the smbus2 equivalent of adafruit i2c's writeList and readList are write_i2c_block_data and read_i2c_block_data Dec 19 06:34:43 Dang. I tried those functions and the functions call for more expressions. Dec 19 06:35:13 I have no clue as to what expressions to put in place of what is already offered in the script. Dec 19 06:35:16 they both take 3 arguments Dec 19 06:35:36 slave address, offset, and length (for read) or data (for write) Dec 19 06:35:42 I know but in the MotorBridge.py file, they only had two expressions. Dec 19 06:35:43 Okay. Dec 19 06:35:53 Hmm. Dec 19 06:36:03 because the adafruit thingy already contained the address Dec 19 06:36:13 Oh! Dec 19 06:36:30 So, would I just put in /dev/i2c-1 or whatever? Dec 19 06:36:45 that's the bus Dec 19 06:36:48 Dang it. Dec 19 06:37:01 So, I would need to find the address. Dec 19 06:37:06 Okay. Dec 19 06:37:11 0x4b Dec 19 06:37:16 https://github.com/mvduin/MotorBridgeCapeforBBG_BBB/blob/master/BBG_MotorBridgeCape/MotorBridge.py#L41 Dec 19 06:37:18 How did you know that? Dec 19 06:37:19 Oh. Dec 19 06:37:35 Oh, right. Dec 19 06:37:38 I forgot. Dec 19 06:38:01 Sheesh. Sometimes, you make extremely time consuming things simple. Dec 19 06:38:40 when you create an adafruit I2C device you pass the slave address and bus (number) Dec 19 06:38:53 Okay. Dec 19 06:39:08 when you create an SMBus instance you just pass the bus (path), while the slave address is passed to the read/write functions Dec 19 06:39:25 Aw. Now, I understand w/ ease. Okay. Dec 19 06:40:43 so MotorBridge.writeList(WriteMode,data) would become bus.write_i2c_block_data(0x4b,WriteMode,data) where bus is the SMBus interface Dec 19 06:41:01 So, instead of "MotorBridge.write_quick(WriteMode,data)," I would use right. Dec 19 06:41:04 ah, SMBus is actually also instantiated with a bus number Dec 19 06:41:06 I got it. Dec 19 06:41:15 Ut oh. Dec 19 06:41:40 I assumed it used a path since you mentioned that, I should have looked at the docs instead :P Dec 19 06:41:58 Of course. Neve rely on me. You know this, man. Dec 19 06:43:01 So, MotorBridge.write_i2c_block_data(0x4b, WriteMode, data) is correct or... Dec 19 06:43:05 ah it accepts either Dec 19 06:43:10 Right! Dec 19 06:43:29 Dang it. Dec 19 06:43:45 so bus = SMBus(1) or bus = SMBus("/dev/i2c-1") is just the same thing Dec 19 06:43:53 Okay. Dec 19 06:44:41 SMBus(1).write_i2c_block_data(0x4b, WriteMode, data)? Dec 19 06:44:46 no Dec 19 06:44:49 Oh. Dec 19 06:45:08 create the bus instance once at the top of the module Dec 19 06:45:11 Oh. You mean for MotorBridge = SMBus Dec 19 06:45:13 Right. Dec 19 06:45:20 I wouldn't call it that, just call it bus Dec 19 06:45:27 Okay. I called it SMBus. Dec 19 06:45:32 just bus. Dec 19 06:45:34 Got it. Dec 19 06:45:38 SMBus is the name of the class Dec 19 06:46:01 Right. No confusion... Dec 19 06:47:40 https://pastebin.com/dWrDj40P is what I had to begin w/. I will change it now. Dec 19 06:51:09 bus.write_i2c_block_data(WriteMode,data) && bus = (1)? Dec 19 06:51:53 So, in the functions of the MotorBridge.py file, it would be bus.write_i2c_block_data. Dec 19 06:51:55 And... Dec 19 06:52:03 ???!?? Dec 19 06:52:13 ? Dec 19 06:52:15 What? Dec 19 06:52:30 Well, not the actual "&&" being used. Dec 19 06:52:48 bus = (1) would be instead of MotorBrige = bus(1)? Dec 19 06:53:50 I literally gave you the declaration earlier Dec 19 06:54:00 Oh. Dec 19 06:54:02 Got you. Dec 19 06:54:04 Okay. Dec 19 06:54:05 bus = SMBus(1) Dec 19 06:54:14 I thought that was you guessing. Dec 19 06:54:19 Sorry. Dec 19 06:54:22 where SMBus is imported from smbus2 Dec 19 06:58:21 Okay, Okay. I think I got it. Dec 19 06:59:23 So, bus = SMBus(1) goes where MotorBridge = whateverWasHere(0x4b, 2) was located, right? Dec 19 06:59:30 yep Dec 19 06:59:35 Okay. Dec 19 06:59:56 and I also gave the correct invocation for the write (which is not what you just typed) Dec 19 07:00:43 I got that too and I got the bus.write_i2c_block_data(1, WriteMode, Data)? Dec 19 07:01:02 Or instead of 1, it has to 0x4b? Dec 19 07:01:57 why did you feel the need to take something I provided as being correct and make completely random substitutions that make no sense? Dec 19 07:02:28 I thought you said something in the chat earlier about it accepts "ethier one." Dec 19 07:02:30 bus.write_i2c_block_data(0x4b,WriteMode,data) Dec 19 07:02:34 Okay. Okaqy. Dec 19 07:03:40 I misunderstood you as usual. Sorry. Dec 19 07:04:44 I guess you were discussing the bus = SMBus(1) or bus = SMBus(/dev/i2c-1) Dec 19 07:06:04 Anyway. Thank you as usual. bbl! Dec 19 07:06:15 Tiredness is beating me! Dec 19 07:34:08 Dear Sirs, I have a BBB board, where could I get the chip specification? I want to know the memory-map for this chip (am335x). Thanks. Dec 19 08:15:42 google must be down or something :P Dec 19 15:58:47 zmat: I have tried the command it works fine and disable everything, unfortunately the driver m trying to use need ethernet gadget enable on usb port to work. DO you have any solution which can disable rest except ethernet gadget on usb Beaglebone black Dec 19 16:04:39 uhh that doesn't make sense, I remember you were trying to use a particular gadget driver, and you can't use two gadget drivers at the same time on the same usb port... that would result in exactly the error you got before Dec 19 16:05:32 (the generic-board-startup service specifically uses the libcomposite driver to create a composite usb device with four interfaces) Dec 19 16:07:23 How to make read only partition so the debian system will work in RAM space only with no SD card files writing (PocketBeagle board)? Dec 19 16:10:02 ai1: if you want to have a composite usb driver consisting of both an ethernet interface and whatever you were trying to use, you'd similarly need to use the libcomposite gadget (which is quite complicated to set up) with the desired interfaces Dec 19 16:10:32 (which is only possible if your gadget is available as a libcomposite function and not just as a standalone gadget driver) Dec 19 16:15:13 zmatt: yes it is (ubq_core.ko is dependent on libcomposite module) Dec 19 16:15:43 I have install it with sudo modprobe libcomposite Dec 19 16:19:24 uhh no Dec 19 16:19:49 I just looked it up, udq_core is a standalone gadget driver and can't possibly be used in a composite device Dec 19 16:22:01 I think Dec 19 16:22:33 https://github.com/airbus-seclab/usbq_core , I am trying to use this driver Dec 19 16:23:56 yes I found that already Dec 19 16:26:48 and based on 1. its intended purpose 2. the driver source code it's quite evident that it's a standalone gadget driver, not a libcomposite function, and therefore it cannot be combined with any other gadget driver on the same port Dec 19 16:28:03 so your claim that it "need ethernet gadget enable on usb port to work" is definitely incorrect Dec 19 16:33:00 zmatt: oh m sorry, actually when I tried to load the driver with insmod it starts giving error and not load after disabling the port without disabling it is loading fine. Dec 19 16:34:11 disabling means with the command sudo systemctl disable generic-board-startup Dec 19 16:34:33 sorry I have no idea what you're trying to say Dec 19 16:45:11 m sorry for confusion. Actualy I am a student and new in it. I have a project to use this driver and mount usb drive on Laptop from beaglebone(host port to device port) as USBproxy device with MITM driver that is usbq_core and works with usbq_userland https://github.com/airbus-seclab/usbq_userland/tree/master/usbmitm Dec 19 16:51:21 not the newer framework from usbq.org ? Dec 19 16:52:01 ( https://github.com/carvesystems/usbq ) Dec 19 16:54:52 it was the first thing I found when trying to google this Dec 19 16:55:52 Yes I tried it also it runs fine but does not mounting usb on host pc, and throwing the error on beagle bone [ 1099.412400] udc-core: couldn't find an available UDC - added [ubq_gadget] to list of pending drivers Dec 19 16:56:28 ... which should be solved by disabling the generic-board-startup service Dec 19 16:56:59 it's the error indicating you're trying to use two gadget drivers at the same time Dec 19 16:58:05 thanks a lot, will try this again Dec 19 16:58:26 and it's a problem that's the same for both, since they use the exact same kernel driver, only the userspace python code was rewritten Dec 19 17:22:55 Anybody made overlayroot on pocketbeagle? Dec 19 18:40:22 zmatt: thanks alot it resolve the issue Dec 19 18:47:56 unfortunately its not mounting usb on host pc but I am not getting any error in dmesg **** ENDING LOGGING AT Thu Dec 19 21:08:38 2019 **** BEGIN LOGGING AT Thu Dec 19 23:02:59 2019 Dec 20 02:58:58 @zmatt: Hello! I know we briefly discussed the MotorBridge Cape and the source from a long time ago. Thank you. Dec 20 02:58:58 ... Dec 20 03:00:03 I have some older source I am trying to make work. Do you have any pointers as to which source might work? I will get a paste real quick of some older source that has nothing to do w/ anything except that it used to work. Please hold. **** ENDING LOGGING AT Fri Dec 20 03:00:11 2019