<CoffeeBreakfast>
2v as reference, they are using the opamps as comparators
<set_>
Aw. So, it is just the voltage going, if measured, at that point.
<set_>
For some reason, I was unaware of negative being 2v or 2v being a negative reference at any point.
<set_>
Hmm. Just when you think it is safe to have a negative.
<set_>
Bzzt.
<set_>
CoffeeBreakfast: Thank you.
<CoffeeBreakfast>
2v positive
<set_>
Oh. Sheesh.
<set_>
Now I am completely confused. So, 2v is positive. I understand but the opamp states it being negative.
<CoffeeBreakfast>
the " - " symbol means non-inverting input
<set_>
Oh. Okay.
<set_>
Oops.
<set_>
Is that standard for opamps?
<set_>
I mean...
<set_>
Is a non-inversion input standard for opamps?
<set_>
I thought they worked like this idea: 1) If the light is too bright or too dim, the opamp kicks on. 2) If that is opposite, then the opamp reserves its voltage.
<set_>
I might as well look it up again.
<set_>
Well, I am way off.
<set_>
I should have studied more. Argh/blah/cough.
<set_>
Now, I am wondering what piece of circuitry handles the light for turning on/off the amplitude.
<set_>
Hey, CoffeeBreakfast: Um, do you know of a _______. forget it. I will keep searching.
xet7 has quit [Remote host closed the connection]
<set_>
Argh, optocouplers.
<set_>
I am gettin' rusty and rigid.
<set_>
I was thinking optocoupler when you said opamp.
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #beagle
Konsgn has quit [Remote host closed the connection]
Shadyman has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
jer339 has joined #beagle
jer339 has quit [Client Quit]
vd has quit [Ping timeout: 256 seconds]
vagrantc has quit [Quit: leaving]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Guest55 has joined #beagle
<Guest55>
Hello! Let's say I'd want to design a beaglebone expansion cape that has additional USB ports - is that possible? I guess I need something like a SPI USB Hub? Any IC recommendations?
<zmatt>
that's not really a thing, usb is way way faster than spi can handle
<Guest55>
USB 2 would be enough for me
<Guest55>
So no chance? Only the given USB ports on the beagle are available?
<zmatt>
usb 2 is 480Mbps, half the bitrate of gigabit ethernet
<zmatt>
usb 2 requires pretty careful pcb design because of its high bandwidth, running it over expansion header pins like those on the BBB would butcher its signal integrity
<Guest55>
Ok I see
<Guest55>
You think it's possible with USB1 speeds?
<zmatt>
doesn't really matter since there's no usb port pinned out on the expansion headers... the am335x has two usb ports, both are connected directly to usb connectors (one for the mini-usb-B device port, one for the usb-A host port)
<Guest55>
Ok thanks a lot - then this is how I will do it, too
Guest55 has quit [Quit: Ping timeout (120 seconds)]
Ramesh has joined #beagle
<Ramesh>
Hello
<Ramesh>
I am trying to do PCIe communication between Beagle board x15 (which uses Sitara processor - am572x) and layer scape board (LS1043ARDB).
<Ramesh>
I configured beagle board as endpoint and layer scape board as Root complex. Can any one suggest me the driver for endpoint to be used in Root complex.
<zmatt>
Ramesh: might want to try the TI e2e forum instead
<Ramesh>
Ok
bzyx has quit [Quit: No Ping reply in 180 seconds.]
bzyx has joined #beagle
Ramesh has quit [Quit: Client closed]
Shadyman has left #beagle [#beagle]
samnob has quit [Quit: I'm not smart enuf to edit bouncer.conf]
<zmatt>
error is typed as Error | undefined, so whoever is calling it with null as first argument is committing a type error
<rcn-ee>
zmatt, didn't look to far into it.. the null actually doesn't break our image..
<zmatt>
sudoPrompt.exec()'s callback arg is typed as (error?: Error, stdout?: string | Buffer, stderr?: string | Buffer) => void
<zmatt>
so it too is claiming null is not permitted
buzzmarshall has joined #beagle
kona_ has joined #beagle
set_ has quit [Ping timeout: 256 seconds]
<jfsimon1981>
Good evening, is the default kernel of a Beagle Board -RT (preemp real time) ?
<zmatt>
no, -rt is a bad default choice
<zmatt>
but you can install an -rt kernel if you wish
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
<jfsimon1981>
ok thanks
<jfsimon1981>
trying to make an accurate delay for rts signal purpose (usleep() is not giving exactly expected delay and for this signal, it has to e within about 5us ideally).
<zmatt>
that's not going to happen to linux userspace, pru is well-suited for that sort of thing
<zmatt>
*in linux userspace
<jfsimon1981>
ok
<jfsimon1981>
doing a few tests in sw, and keep in mind the hw pru, thx for the tip
<zmatt>
jfsimon1981: iirc I had about 40-80us latency from gpio-triggered interrupt to userspace last time I tested an rt kernel (long time ago)
<jfsimon1981>
i got recently 5 us period when switching 1/0 on gpio, pretty good. Issue lies in usleep().
<zmatt>
5 us period when switching a gpio? that sounds awful
<zmatt>
no, the issue lies in trying to create accurate timing in linux userspace
<zmatt>
even if you get it working most of the time, you'll still get random delays at random moments
<rcn-ee>
jfsimon1981, switching i/o in real time... PRU?>...
<zmatt>
that's what I said, this is exactly the sort of thing pru is excellent for
<zmatt>
pru can get you 5 _nanosecond_ timing accuracy with a bit of effort. even with some lazy C code and no attention paid to efficiency you'll still get small-fraction-of-microsecond accuracy
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
<jfsimon1981>
correct
<jfsimon1981>
timing gets sometimes prempted, but I got one good candidate delay function, gets very accurate most of the time. Still conducting tests on it
<jfsimon1981>
pru is programmeble timer, i have no clue yet how to make that work
<jfsimon1981>
Yep 5 us period (4.6) is the shortest we can do with c/c++ using gpio file
<zmatt>
pru is a programmable microprocessor
<zmatt>
designed for real-time tasks, especially i/o (it has dedicated gpios wired directly into register)
<zmatt>
you can generate a 5ns pulse in software on pru
<jfsimon1981>
yes i grab it
<jfsimon1981>
as you say it's little bit more work but that sounds the right solution
<zmatt>
there's a bit of learning curve to get used to it I guess
<zmatt>
I've created a python library that can not only load code onto it but also directly inspect and poke the subsystem and the cores within it, which can useful both for learning and for practical purposes: https://github.com/mvduin/py-uio
<zmatt>
unfortunately there's not much documentation
<jfsimon1981>
dealing with libmodbus half duplex and having issue with RTS timing, which needs to be precisely switching after a calculated time eg 520 us. Though there seems to be more accurate than usleep() for delay,
xet7 has quit [Remote host closed the connection]
<jfsimon1981>
Found busySleep() which gets better, close within 0.1% or so. Though once in a while the os gets work done and the delay get 100u or even 1ms.
<jfsimon1981>
I'll conduct tests on beagle board with modified library. If that does'nt do the job then I'll try work with the PRU and thanks for sharing the py library.
<zmatt>
yeah, busywaiting wastes cpu time so linux will be more likely to interrupt you
<zmatt>
pruss also has a local high-speed uart in the subsystem (up to 12 Mbaud if I remember correctly)
<zmatt>
yeah
<jfsimon1981>
i'll probably need to check the pru and make it work, cause when the modbus line goes wrong, the client device gets confused and starts replying on older messages, until by any luck it gets working back after a while.
<jfsimon1981>
For a customer project that needs be fixed, either on BBB side or the RS 485 controller.
<zmatt>
is the bbb the master or the slave?
vd has joined #beagle
<jfsimon1981>
it's the master
<zmatt>
is the kernel's rs485 functionality (kernel-controlled driver-enable via rts) also inadequate? surely it'll have better timing than doing it in userspace
<jfsimon1981>
i see, it had the same issue
<jfsimon1981>
both of them showed a similar delay if memorry serves well
<jfsimon1981>
you mean uart with rts variant
<zmatt>
what exactly is this delay you say you need to do precisely anyway? I'd normally expect an 485 master to just need to disable DE fast enough after transmitting a request (to free up the line for the slave to reply)
<jfsimon1981>
rts release
<zmatt>
and keep appropriate minimum spacing between requests
<zmatt>
so why do you need a delay?
<zmatt>
don't you want to release it asap after the serial transmission is done?
<jfsimon1981>
it must be released as soon as transmit done, though in libmodus they calculate this delay, request uart to send data, then wait and release rts
<jfsimon1981>
the uart would be working in the background and both should get done simultanesouly
<zmatt>
that sounds like it'll always be worse than letting the kernel handle it
<jfsimon1981>
yep sounds like i remind uart-rts did'nt work, but need to do tests again. I did'nt get note of the time results.
<zmatt>
the kernel knows when the transmission is done and can immediately deassert rts, instead of guessing the timing
<zmatt>
it still won't be the sort of tight timing pru can get you, but it should be substantially better than anything you do in userspace
<jfsimon1981>
i don't remember exactly, it did'nt get exact that way too, but i need to grab a bb and the scope to measure.
<jfsimon1981>
i'll test back uart-rts on scope to make sure.
<zmatt>
make sure delay before/after send is configured to zero
<zmatt>
of course it's entirely possible the kernel driver is just shit
<zmatt>
my statement above is under the assumption the driver doesn't suck
<jfsimon1981>
right that's what i want to tackle again, i didn't test thouroughly on that one
<jfsimon1981>
Took a while to understand what was going on, the half duplex line had mixed signals for a short while. after poking for a few days i tackled to rts timing, but the work arounds really aren't good, i just added -100us in the delay which made it kind of work 70% of the time.
<zmatt>
uhh
<zmatt>
that just sounds like something is borked
<zmatt>
when the serial port is configured into rs485 mode, the kernel will assert rts prior to transmission (with configurable delay between asserting rts and starting transmittion) and deassert it once transmission is done (again with configurable delay, which you'll want to be set to zero)
<zmatt>
(polarity of rts signal is configurable)
<zmatt>
all userspace has to do is setup/enable the mode and then just write data, wait until transmit completes (with tcdrain() I think) and then wait for a response (if unicast) or wait for the minimum required delay until the next request
<zmatt>
as far as I know
<jfsimon1981>
right, once the message is sent, the client device immediately sends a reponse, and the rts gets too long to release the line, thus transmis on bbb and client device for about 100us or so. This puts the wrong response bits for maybe a few bits, and then CRC complains and the message is discarded.
<jfsimon1981>
Sot the RTS is too long to release the line by just a few us.
<zmatt>
how long does the kernel keep rts asserted after transmit?
<zmatt>
what baudrate are you using?
vagrantc has joined #beagle
<jfsimon1981>
the line is 19.2
<jfsimon1981>
kb
<jfsimon1981>
sending 8 bytes expected 520us and getting little more than that
<zmatt>
how much is "a little more" ? how long the driver remaining enabled after the last byte?
<zmatt>
*how long is
<jfsimon1981>
in the begining this was 100us
Guest41 has joined #beagle
<zmatt>
that's only 2 character times... modbus requires 3.5 character times for the bus to be considered idle (i.e. end of frame) if I understand this document correctly
Guest41 has quit [Client Quit]
<zmatt>
am I saying that right, wait no
<zmatt>
uhh
<zmatt>
19.2 kbaud means 52 μs per _bit_
<jfsimon1981>
yep i still don't understand, the timing looks like it needs be tight. You are right I missed that.
<CoffeeBreakfast>
I did an arbitrary function generator, using a combination of a rt kernel, PRU, ePWM and an external DAC. It worked reasonably well. The code was a bit messy though
<zmatt>
573us per byte
<CoffeeBreakfast>
A while ago.. zmatt helped me a lot with that
<zmatt>
jfsimon1981: so again, if I understand the spec correctly, end of packet is signalled by >=3.5 character times of bus idle, which is 2ms
<jfsimon1981>
Yet if I get the rts a little bit sooner, the client does not get all message and hangs. But there must be a 3.5 bit delay roughly 30us.
<jfsimon1981>
doesn't make sense.
<zmatt>
3.5 *byte*
<zmatt>
11 bits per byte (including start, parity, and stop)
<zmatt>
52 us per bit
<zmatt>
so you're right that something is not making sense about what you're saying
<zmatt>
you should have plenty of time
<jfsimon1981>
yep i must conduct new tests, but i take note on the stop delay which i forgot has to be present
<jfsimon1981>
it looks the client device does'nt wait for that to happen and responds anyway, but with that in mind i'll check in detail on scope what's going on
<zmatt>
how can it respond to a packet if it doesn't know the packet has ended yet?
<jfsimon1981>
let me check scop pix
<zmatt>
and maybe test with the simplest possible program rather than some library, e.g. just enable rs485 mode (https://pastebin.com/r1rJFUfr) and do a write(), tcdrain(), and optionally read the response
<zmatt>
check the timing of RTS relative to transmitted data, and if you have a third channel then record rxd as well
<zmatt>
I have no idea what I'm looking at... does this scope have only a single channel?
<jfsimon1981>
the stop time looks like 150us thereabout
<zmatt>
this is also way too zoomed in
<zmatt>
I have no idea what the timing of anything is here
<jfsimon1981>
the left signal is sent by bbb. Then there's a stop, and a response. The voltage on response lies about 200 mv below.
<zmatt>
where is this being measured?
<zmatt>
this looks inverted
<jfsimon1981>
ah it might be, that's the RS485 half duplex line
<zmatt>
does your scope have only a single channel?
<jfsimon1981>
(A-B)
<jfsimon1981>
there are 2 channels.
<zmatt>
then capture txd and rts from the beaglebone
<zmatt>
and just send a single frame, capture it in its entirety... trigger on rts is probably useful
<zmatt>
doesn't even have to be a valid frame, all we care about first is what the rts timing relative to the data looks like
<jfsimon1981>
on picture 7700 the rts signal went down on the first vertical bar, then client responded on second vertical bar
<zmatt>
these images are not useful to me, they show tiny snippets of the bus with unknown context/history
<jfsimon1981>
At the time (last month), i did'nt take the pictures with rts, but i check with rts on second channel. At the moment the lab is'nt setup to work.
<jfsimon1981>
yep
<jfsimon1981>
i can do better in a while, i was moving home recently thus the lab is'nt yet deploed to work. Will be shortly
<jfsimon1981>
will take a couple of days to be back into business
<zmatt>
the slave transmitting right when the master is making a request means either 1. the slave is broken, or 2. the master is doing nonsense (e.g. sending a request and then without waiting for the slave's reply send another one right as the slave is about to reply)
<zmatt>
based on your descriptions with weird delays, 2 sounds plausible enough to me
<zmatt>
hence my emphasis on doing a single isolated request as first test
<zmatt>
and really, first we want to see what the master does in isolation, i.e. what it's doing with txd and rxd
<zmatt>
if that's not okay, there's no point in looking at the interaction with the slave
<zmatt>
solve one problem at a time
<jfsimon1981>
We can see the issue picture 7692, the master (bb) still hold the line with rts although the uart has sent the message. Between the two vertical bars stand a short period where tx on BBB and client both are on.
<zmatt>
bbb and slave you mean?
<jfsimon1981>
I'll need more tests to get a clear understanding.
<jfsimon1981>
Slave is a client device
<zmatt>
I don't know what you mean by that
<zmatt>
anyway, like I said I can't tell anything from this image
<jfsimon1981>
bbb is the master
<zmatt>
since I don't know how much time has passed since the end of the last byte transmitted by the master
<jfsimon1981>
the client probe is the client on half duplex line
<zmatt>
???
<zmatt>
what do you mean by "client". there's a master and a slave
<jfsimon1981>
modbus host (bbb) query a client through modbus rtu
<jfsimon1981>
thus rs485 line (half duplex)
<zmatt>
okay, these are modbus terms?
<jfsimon1981>
yes i think so, little bit confusing terms somehow
<jfsimon1981>
master-slave
<zmatt>
yes the term makes no sense to me, I'd expect a client to be a piece of software running on the host
<jfsimon1981>
master is bbb
<zmatt>
(i.e. the master)
<jfsimon1981>
yes, it sends a request to a node on the bus, which responds immediately
<zmatt>
yes, that's called a slave
<zmatt>
not a client
<jfsimon1981>
right a slave
<jfsimon1981>
i mixed up with server/client, that's used with tcp
<zmatt>
anyway, like I said, capture txd + rts on separate channels, and with a simple test rather than libmodbus preferably since your description of it sounds like it's doing weird stuff
<zmatt>
focus on verifying that the master is not holding the driver enabled _excessively_ long,... though I really doubt that given that even 1.5ms is still okay
<zmatt>
it's probably much less than that
<jfsimon1981>
where does 1.5 ms come from ?
<zmatt>
if that's confirmed to be okay then try a _single_ request/response exchange with the slave
<zmatt>
zoom out to confirm there's no activity prior to the request of interest
<zmatt>
(or just trigger on rts)
<zmatt>
or on data rather, can't trigger on rts if you're going to examine txd + rxd (which is probably easier to read than scoping the bus itself)
<jfsimon1981>
why did you mention 1.5 ms, where does the value come from ?
<zmatt>
3.5 character times * 11 bits/character (including start/parity/stop) * 52 us/bit
<jfsimon1981>
right
<zmatt>
is 2 ms
<zmatt>
but you want some margin obviously
<zmatt>
also I don't think the spec was 100% clear about what they means by character time, and they suggested using 1.75ms inter-frame delay when using baudrates greater than 19.2 kbps
<zmatt>
recommended rather, not suggested
<jfsimon1981>
thanks, i need to check in detail, indeed there was no 2ms wait as far as i checked.
<zmatt>
well there doesn't need to be one as such
<zmatt>
if you're doing a request to the slave, it's the slave who has to wait that amount to determine end of transmission of your request, at which point it can send the response
<jfsimon1981>
ok i'll check with various configurations anyway
<zmatt>
so all that matters for the master is that it doesn't take _more_ than 2ms to disable its driver after the last byte
<jfsimon1981>
yep it appears it waits for 150ms instead of about 2ms. I might be wrong, have to setup the bench and to additional tests.
<zmatt>
it can spend much more time than 2ms of course if its wants
<zmatt>
up to some timeout
<jfsimon1981>
yep and 2ms does'nt need extra work, that far within the usleep() margins
<zmatt>
but it can't spend _less_ than 2ms since it can't have recognized end of transmission yet
<zmatt>
again, there's no delay here in the master
<jfsimon1981>
however the slave appears to skip the delay, but i may be in touch with the manufacturer as well to get clarificaiton on this.
<zmatt>
the master just sends data and waits for reply
<zmatt>
I'd start by making sure you're not just sending nonsense to the slave like I explained earlier
<zmatt>
your scope pics are zoomed-in close ups so we can't tell what happened earlier
<jfsimon1981>
thanks for this clarification, I totally missed this delay, I though 150us was good per spec.
<zmatt>
150us is 3 bit times... that's a normal allowable amount of delay between bytes and definitely not enough to mark end of frame
<jfsimon1981>
For instance 7697 is the zoomed out slave response
<zmatt>
it's the master I'm concerned about
<jfsimon1981>
but i can do better, once i get to dive into the matter and labo alive again
<zmatt>
again, first check the master by itself
<zmatt>
then a _single_ request/response interaction with the slave
<jfsimon1981>
sure i don't seem to have pics on th emaster
<zmatt>
I can't stress that enough since misbehaviour from the master seems the most likely explanation to me at this point
<jfsimon1981>
that one was taken from a full frame master/slave
<zmatt>
and how certain are you there's zero activity from the master prior to this bit you captured?
<zmatt>
(I can't tell if this is single acquisition or auto acquisition)
lucas_ has quit [Ping timeout: 240 seconds]
<jfsimon1981>
it's a few seconds sparse requests
<jfsimon1981>
acquisition mode
<zmatt>
the scope I mean
<jfsimon1981>
it's been working in acquisition on this picture
<zmatt>
???
<zmatt>
also, this is skipping ahead again, do step 1 first
<jfsimon1981>
this picture was taken from a single request/response between bbb and slave
<zmatt>
like, if this isn't caused by misbehaviour from the master (sending requests without waiting for the previous response) then the only other explanation is that the slave is _completely_ broken and doesn't even remotely implement modbus
<jfsimon1981>
the bbb has sent a ~ 4ms message and received a ~ 7 ms resopnse. There is no 3.5 char wait.
<zmatt>
a single request/response wasn't step 1, it was step 2
<jfsimon1981>
as I mention, those are old pictures.
<jfsimon1981>
at the moment I can't do live testing.
<zmatt>
yeah so that's not modbus since a modbus slave cannot reply until it sees the 3.5 char wait, since the packets are variable-length and the only way to know that the packet has ended (which you need to even be able to check the CRC) is by seeing the 3.5 ms idle time
<jfsimon1981>
sorry about this
<zmatt>
then you'll have you wait until you can do live testing
<zmatt>
debugging blind is useless
<zmatt>
I'm simply outlining what I recommend you test once you do have the ability again
<jfsimon1981>
but you got a right point.
<zmatt>
btw, implementing a proper spec-compliant modbus receiver (with correct error handling) is _definitely_ not possible in linux, that can only be done by pru
<zmatt>
well
<jfsimon1981>
I think I had issues with the slave reponding to older messages, so it's possible there's a coincidence the request and response are close by on this picture.
<zmatt>
it requires being able to tell the size of small gaps between characters
<zmatt>
received
<jfsimon1981>
I mean this is probably the reponse to a previous request far back in time 2ms before. That, I did'nt check.
<zmatt>
yes, that's the only thing that makes sense to me
<zmatt>
hence my stress on _single_ request/response
<jfsimon1981>
but I observed I got responses from a different request.
<jfsimon1981>
i check my source code again ...
<zmatt>
that makes sense if the slave was simply still busy processing your earlier request and preparing the response
<zmatt>
i.e. if your master code was just too impatient
<zmatt>
and you went ahead and sent the next request
<jfsimon1981>
indeed, the manual calls for 10s wait timeout, which i did'nt respect
<zmatt>
there ya go
<zmatt>
patience is a virtue
<jfsimon1981>
gosh that may be the point
<jfsimon1981>
well spotted i'll modify the code on this.