<mattb0ne>
they will have steps for what packages to install
<mattb0ne>
why are you putting a gui on
mattb0ne has quit [Ping timeout: 272 seconds]
thinkfat has joined #beagle
buzzmarshall has joined #beagle
dinuxbg has joined #beagle
mattb0ne has joined #beagle
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
rob_w has joined #beagle
alan_o has joined #beagle
samael has joined #beagle
ikarso has joined #beagle
Shadyman has quit [Quit: Leaving.]
starblue1 has quit [Quit: WeeChat 2.3]
pbrobinson_AFK is now known as pbrobinson
starblue has joined #beagle
johanhenselmans has quit [Quit: johanhenselmans]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #beagle
set_ has quit [Ping timeout: 252 seconds]
neophyte has joined #beagle
<neophyte>
I need advice on how to get can1 working on beaglebone black wireless
<neophyte>
thanks
neophyte has quit [Quit: Client closed]
argonautx has joined #beagle
lucascastro has joined #beagle
samael has quit [Ping timeout: 268 seconds]
buzzmarshall has joined #beagle
zjason` is now known as zjason
<veremitz>
kthnxbyeeeee
Konsgn has joined #beagle
akaWolf has quit [Ping timeout: 268 seconds]
argonautx has quit [Ping timeout: 252 seconds]
argonautx has joined #beagle
akaWolf has joined #beagle
Ramon has joined #beagle
GooberMan has quit [Quit: Connection closed for inactivity]
lucascastro has quit [Ping timeout: 272 seconds]
<Ramon>
Looking for guidance on using beaglebone Ai and RS485
<zmatt>
the short summary would be: configure pins (rx, tx, rts) to uart mode, enable rs485 mode from userspace (same as on any other linux system)
<zmatt>
(configuring pins is the usual headache on the BBAI)
<zmatt>
using the new experimental cape-universal for bbai wouldn't help here since it appears it doesn't bother to include uart rts/cts pin modes (iirc cape-universal for the beaglebone has the same shortcoming)
lucascastro has joined #beagle
<zmatt>
though I suppose it avoids the cape-pins-default headache
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #beagle
<Ramon>
I have the hardware beaglebone ai and COMCPE-BBBCAPE
<Ramon>
main goal is to read rs485 data and have the beagebone ai process it via node red
<zmatt>
if you only ever receive data then you don't even need rs485 mode, it's simply uart mode
<zmatt>
(rs485 mode is for controlling the driver-enable pin when transmitting)
<zmatt>
is this cape BBAI-compatible?
lucascastro has quit [Ping timeout: 268 seconds]
<zmatt>
it is not
<zmatt>
it mistakenly uses P9.05/06 as 5V supply (instead P9.06/07), which do not provide 5V output on the BBAI (nor on an usb-powered BBB)
<zmatt>
which means the RS485 transceiver on the cape will be unpowered
<zmatt>
though this should be fixable with a relatively simple hardware patch
<zmatt>
and then it looks like it should be BBAI-compatible
lucascastro has joined #beagle
<zmatt>
jkridner[m]: the capes repository is missing a bottom-side image of the Comms cape, the BeagleBoneCommsCapeA2_Bottom.png file in that repository is actually just a 404 html file
<jkridner>
thanks.
lucascastro has quit [Read error: Connection reset by peer]
<zmatt>
jkridner[m]: the pins matrix also lists SYS.VOUT as used by the Comms cape, but (unfortunately) this is one of those capes that erroneously use VDD_5V as their 5V supply
<zmatt>
it does not use SYS_5V for anything
<GenTooMan>
mattb0ne, a good question I suspect the person is at the "mud versus wall stage"
<zmatt>
good question indeed, why use the BeagleBone AI ?
<mattb0ne>
i would like to see the AI get to a point where it is usable by someone other than zmatt
<mattb0ne>
lol
<mattb0ne>
I have been following these guys for a while
<zmatt>
well actually I noticed that this cape doesn't have a driver-enable pin for rs485 (it uses a transceiver with some kind of magic auto-driver-enable), so if the cape didn't fuck up its power supply connection and you have the new overlays stuff for the BBAI installed (part of latest testing image I think?) then you can just use config-pin (or the appropriate overlay?) to setup the uart pins
<zmatt>
but yeah, that's still not part of the latest official image
<mattb0ne>
there are new images coming out soon?
<mattb0ne>
that will make bbai config possible?
<GenTooMan>
the op mentioned node-red... that sounds like the desire to use "easy" gui based "programming" node-red appears to have a graphical layer ontop of a javascript layer
<zmatt>
I mean, the planned release date was october 2020
<zmatt>
with the next release being planned for april 2021
<zmatt>
I have no idea what's been blocking releases since the last testing image of 2020-08-25
<Ramon>
im at the prototype stage so can modify de cape or board , the reason for the Ai is horsepower, Ill be trying to read and write data to 4000 nodes probably will split between 6 or 7 beaglebone ai
<Ramon>
node red I'll use for testing that i can read and write data to my nodes
<zmatt>
you're communicating via rs485 yet you think cpu power is the limiting factor, rather than bus speed?
<Ramon>
im just over designing it , its a legacy system that uses rs485
<Ramon>
so it will sequentially read and writ values to all those nodes
<zmatt>
I wasn't dissing the choice of rs485, I'm wondering why you think you need so much cpu power
<Ramon>
need 1/2 second updates on data going to and from the nodes. I'm a newbie on the beaglebone so went with biger is better for now,
<zmatt>
how often you want to update the data is irrelevant. unless you're going to do some kind of really cpu-intensive processing on the data, the cpu will probably be mostly idle while it's waiting for the rs485 bus
<zmatt>
I suppose it's possible that doing anything whatsoever in node-red is already very cpu-intensive, I've never used it :P
<zmatt>
what's your rs485 bus speed?
<zmatt>
also, earlier you said you only needed to receive, but it's clear now that you're going to be polling devices so you'll need both transmit and receive
<Ramon>
both tRASNMIT AND RECIVE, 9600baud
<zmatt>
lol
<Ramon>
I wanted to use the cape i dont want to use usb converter , avoid adding failure point to the system
<zmatt>
9600 baud, okay, so that's 960 bytes per second. that means on a 1 GHz cor eyou have one million cpu cycle to spend on each BYTE of data
<Ramon>
so you saying beaglebone black can handel it and use the cape ?
<zmatt>
definitely don't use usb, but for prototyping I'd suggest just hooking up an external 3.3v rs485 transceiver breakout to one of the many uarts
<zmatt>
I'm saying you have one million cpu cycles to spend on each byte of data if you use one bus at 100% utilization. that means that unless you really have that much processing to do on the data, your software will be waiting for the bus and increasing cpu power will just make it have to wait more
<zmatt>
combined with the complications of the BBAI compared to the BBB, I'd suggest the BBB
<Ramon>
ok I will step it down to a bbb
<zmatt>
and you can attach four rs485 transceivers to one BBB to handle four buses at the same time; of course then you'll have "only" 250000 cycles/byte of cpu time to keep all four buses at 100% utilization
<zmatt>
the Seeed RS485 grove module (https://www.digikey.com/short/p8hr4tbr) is a cheap MAX13487E breakout... the image seems to imply a grove cable is included, so you can just cut off the connector on one end and e.g. solder it to jumper wires to connect to the BBB for prototyping
<zmatt>
PRU could no doubt be used to control even more RS485 buses at the same time. at 9600 baud it has plenty of time to bit-bang a whole bunch of these
<Ramon>
PRU ? Know of any technotes of how to use PRu to communicate directly to a rs485 device ?
<zmatt>
(in fact so slow that the limiting factor is probably the number of gpios available, which is 57 on the BBB hence 57/2 = 28 buses when using transceiver with auto-driver-enable (like the MAX13487E) or 57/3 = 19 RS485 buses when using manual driver-enable
<zmatt>
no that would need to be custom-written
<zmatt>
(the simple way to use rs485 from PRU would be by using the PRUSS UART, but that only gives you a single RS485 bus. the PRUSS UART is mainly useful for very high speed serial communication, up to 12 Mbaud)
<zmatt>
Ramon: even for soft-uarts, an implementation for one high-speed port would be very different from an implementation for many low-speed ports
<zmatt>
oh actually TI made a driver that supports 3 UARTs per pru core (6 UARTs total) on the AM335x
<zmatt>
with a linux driver that exposes them to userspace like any other serial port
<zmatt>
I don't know if this driver is included in rcn's kernel
<zmatt>
# CONFIG_SERIAL_PRU_SUART is not set
<zmatt>
hmm
<zmatt>
rcn-ee: might be nice to include it for people who want mooooore UARTs
mattb0ne has quit [Ping timeout: 265 seconds]
<Ramon>
newbie question rcn's kernel ?
<zmatt>
Ramon: so without custom PRU programming that would bump the number of RS485 buses you can have on the BBB to 10 (note that manual driver-enable would not be supported)
<zmatt>
rcn maintains the linux kernel package for the beagleboard.org images
<zmatt>
robert c nelson
<Ramon>
ok I need to do more reading , thanks for all the input
<zmatt>
you can start with 4 buses ;)
<zmatt>
if you can keep your cpu load below 40% you'll have an easy option to increase the number of buses to 10
<zmatt>
(this makes the oversimplified assumption that cpu load is proportional to the number of buses used)
<zmatt>
and a less easy option to go beyond 10 buses... though custom PRU code could also take care of some of the lower-level processing details hence relieve some of the cpu load from the cortex-a8
<Ramon>
4 busses should do for prototype
Ramon has quit [Quit: Client closed]
<zmatt>
and don't forget to properly terminate your buses! (I just realized that doing so is extra important when using a transceiver with auto-driver-enable)
<zmatt>
no urgency, just nice to include for the next build
* GenTooMan
hands ammo out for proper bus termination.
rcn-ee has quit [Remote host closed the connection]
rcn-ee has joined #beagle
rob_w has quit [Read error: Connection reset by peer]
Konsgn has quit [Ping timeout: 268 seconds]
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
Shadyman has joined #beagle
mattb0ne has quit [Remote host closed the connection]
argonautx has quit [Quit: Leaving]
set_ has joined #beagle
<set_>
Woof, I made it!
<set_>
man...it seems there are types of jobs locally now for embedded things, i.e. mostly POS stuff. Boo!
<set_>
i want to build neat-o, van-deet-o things. Just not POS stuff.
<set_>
I mean, not neon Bells and whistles or anything but bots. I saw a fellow from ROS, a privitized co, and this fellow used ROS to build a real robotics co.
<set_>
That seems nice.
<set_>
I mean, I will most likely never be as educated in the field as you guys. But, I can try when I have time!
akaWolf has quit [Ping timeout: 272 seconds]
akaWolf has joined #beagle
mastermind has joined #beagle
mastermind is now known as mattb0ne
<mattb0ne>
is there a quick way to turn off debug prints
<zmatt>
what do you mean by "debug prints" ?
<mattb0ne>
like C i have seen like something like IF FALSE
<mattb0ne>
well to find bugs I will have print('checkpoint 1')
<zmatt>
that's not C
<mattb0ne>
and so on littered throughout my code
<mattb0ne>
i know but I know C had a quick way of having debug message take effect or not
<mattb0ne>
what would be the same for python
<zmatt>
I mean, that's not a "debug print", it's a print. there's nothing to distinguish it from a non-debug print
<mattb0ne>
like flag so I do not have to go around commenting it
<zmatt>
you could make a debug_print() function that forwards its arguments to the regular print() if some debug-flag is enabled