<zmatt>
you'll obviously also need to fix your lcd_ctrl_pins ... hopefully from this example it should be clear to do so, just look up the pin names in the spreadsheet I linked
<metgros>
yes i will
<zmatt>
also, remove that master@0 block in your &i2c1, it is complete nonsense
<zmatt>
nothing about that declaration makes sense
<metgros>
do you have a good documentation on the syntax of DTS please ?
<set_>
In that file, the octal is not compiling while the dual is compiling.
<zmatt>
what do you even mean by that?
<set_>
What does this mean?
<set_>
Okay. Let me show you.
<zmatt>
this is a single program, it either compiles or it doesn't
<set_>
I changed the source to handle what compiles due to what is on the BBAI.
<zmatt>
oh I see, the SPI_TX_OCTAL and SPI_RX_OCTAL are fairly new and not in the older headers installed on the current image
<set_>
if (mode & SPI_TX_QUAD) is a line to handles modes. But, when I installed the source on the BBAI, it seemed that the, right.
<set_>
Right.
<set_>
Okay.
<set_>
So, SPI_TX_OCTAL was not working b/c of some header files that are "out-dated".
<zmatt>
well the mode itself won't work regardless since it's not supported, but to get the code to compile you'd need a small fix of the source code to provide those constants if missing from the header
<set_>
Right.
<set_>
That is all I did.
<set_>
So, I was moving back in time when I thought I was moving forward. Ha.
<set_>
I am trying to help this person handle their /dev/spidevX.X peripherals on their BBAI but it seems hopeless right now.
<set_>
Mine works but this person keeps trying to use two peripherals that cannot work for his/her /dev/spidevX.X instances.
<zmatt>
set_, I'm not going to try to debug a vague issue by someone else that's being paraphrased confusingly by you
<set_>
I know.
<set_>
I just wanted to discuss it. No issue.
<set_>
Off to try to debug someone else's issue(s).
vagrantc has joined #beagle
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #beagle
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 260 seconds]
lucascastro has joined #beagle
lucascastro has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
ikarso has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
<set_>
Otay...I got the BBBlue on but the pru needs to be attached or not to the receiver?
<set_>
I am using librobotcontrol.
<set_>
I am trying DSM2 RX on the BBBlue and a DSM2 TX to control it.
<set_>
Anyway, when people wake up, please say something.
nparafe has quit [Ping timeout: 256 seconds]
nparafe has joined #beagle
nparafe has quit [Ping timeout: 256 seconds]
nparafe_ has joined #beagle
vd has quit [Ping timeout: 256 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
otisolsen70 has joined #beagle
set_ has quit [Remote host closed the connection]
Shadyman has quit [Remote host closed the connection]
lucascastro has joined #beagle
lucascastro has quit [Ping timeout: 252 seconds]
lucascastro has joined #beagle
lucascastro has quit [Remote host closed the connection]
mattb0ne has joined #beagle
<mattb0ne>
zmatt: my ring buffer keeps overflowing!!!!
<mattb0ne>
i tried option 1 of the two pastebins and just changed the data emmitter to just a write of the string with no delays and stuff. I can run for about 2 minutes before the ring buffer causes the PRU to abort
<mattb0ne>
if I run without sending data over the TCP it runs fine. The key from my testing is that widx updates properly. when I do not send data widx updates with the same frequency as ridx and I never have a problem with the buffer spilling over
meta has joined #beagle
meta is now known as Guest1268
<mattb0ne>
when it crashes I notice that widx updates less and less frequently and eventually ridx == widx and the code blows up. I am not sure what causees widx to slow down that is controlled by the PRU right?
<mattb0ne>
when just deleting msg from the buffer ridx and widx run in lock step. When it is going to blow up the jumps in the widx counter increases in increments of a few 100 to 8000 or so over the course of 2 minutes before crashing. How can I avoid this ?
<Guest1268>
Hello, i'm trying to connect a TFT ili 9341 to my BBB i ve modified the device tree as bellow and added the PWM backlight and the ili9341 drivers
<zmatt>
mattb0ne: I guess I underestimated how much data is being buffered by the kernel, so the write() calls never end up doing buffering in python but instead pass the data to the OS every time (which is slow)... solution is to do batching in the writer, like I showed in another pastebin
<mattb0ne>
ok
<mattb0ne>
will try that
mattb0ne has quit [Ping timeout: 256 seconds]
lucascastro has joined #beagle
xet7 has quit [Ping timeout: 250 seconds]
xet7 has joined #beagle
otisolsen70 has quit [Quit: Leaving]
ikarso has joined #beagle
mattb0ne has joined #beagle
<mattb0ne>
zmatt: I do not understand how the batch code works
<mattb0ne>
how does it even interface with the ring buffer
<zmatt>
what do you mean? that part hasn't changed at all
<mattb0ne>
oh
<zmatt>
note that to keep things as simple as possible I also changed the message format slightly
<zmatt>
but I also provided matching client code
<mattb0ne>
i guess how the write from recv_messages connect to the other code
Guest6 has joined #beagle
<zmatt>
instead of doing a .write() per message I just gather the data to be written into one big string and write that
<zmatt>
I also save time by not updating the user interface for each message but only once per batch
<zmatt>
that way make the update rate adaptive: the more time the user interface update takes, the larger the next batch will be
<mattb0ne>
ok that makes sense since I do not need that resolution anyway
<mattb0ne>
ok I think i get it
<mattb0ne>
what was throwing me off was that it was split as two separate pastebins
<mattb0ne>
but they are meant to go together
<zmatt>
one for the server and one for the client you mean?
<zmatt>
I mean, you can batch on either side independently of the other side
<mattb0ne>
yeah thoes last two pastes
<zmatt>
the only sense in which they "go together" is that both of them use the same message format "timestamp_cycles,force,angle\n"
<zmatt>
while you previously used "time,timestamp_label,force_angle\r"
<zmatt>
but the choice to batch or not is an implementation detail, the client doesn't know or care whether the server uses batching, the server doesn't know or care whether the client uses batching
<zmatt>
it's just done to improve performance
Shadyman has joined #beagle
<Guest1268>
Can anyone relate on my thread please ?
<Guest1268>
in fact i'm trying to use a ili9341 TFT display with BBB
<zmatt>
Guest1268: first of all, when I said to remove the master@0 node in &i2c I mean the entire node including contents, not move its nonsensical properties to the parent node
<zmatt>
and it looks like your gpio controllers are failing to register for some reason
<zmatt>
so something is very broken
<zmatt>
hmm, it's getting EPROBE_DEFER
<zmatt>
hmm okay it looks like they do eventually get registered, but... ugh what a mess
russ has quit [Ping timeout: 250 seconds]
<Guest1268>
:/
<zmatt>
yeah dunno what's going on here, probably something particular to these 5.x kernels, I haven't yet tried to run one on a beaglebone yet
<zmatt>
all these parse errors suggest to me maybe the format for gpio references has also changed, which would be incredibly rude but they already broke backwards compatibility in other ways so who knows
<Guest1268>
hummm okay
<zmatt>
it used to be policy to maintain backwards compatibility, but I guess they stopped caring
<Guest1268>
what kernel shall i use ?
<zmatt>
I mean, that's up to you. the kernel series used on current beagleboard.org images is the 4.19-ti series
<Guest1268>
okay
<zmatt>
why are there #address-cells and #size-cells properties in your lcd node? that doesn't make sense, an lcd panel is not a bus
<zmatt>
Guest1268: I have no idea what your problems are, but there's clearly issues with your dts and the errors seem to imply there's a problem with your gpio declarations (even though they look fine to me), so my wild guess is that maybe they changed the structure of gpio references
<zmatt>
hmm, the gpio controllers still have #gpio-cells=<2> so maybe that's not it
<zmatt>
then I have no idea what's going on
<Guest1268>
:/ i will check the driver of ili9431 too
<Guest1268>
thanks anyways :D
<zmatt>
it looks like most if not all of these errors are temporary ones though