I would be stunned if the GPIOs don't have synchronizer flip-flops as they
are sampling a signal asynchronous to the 200MHz clock. That would account
for 2 clocks. You probably need one extra to clock data into R31. And
then one clock to read R31.
50MHz is a pretty smoking speed for
support
the fix from the user side as I can't query the size and depths of the
buffers. This needs to get fixed in the PRU rpmsg kernel subsystem.
Thanks.
On Tuesday, June 30, 2020 at 3:43:01 AM UTC-7 Andrew P. Lentvorski wrote:
> So, we're still back at the original question of "Where d
MHz bursts instead of continuous
> 100MHz sampling. Difference with above single-PRU example is that you would
> use PRU register banks for buffering, which would decouple sampling from
> SBBO bus operations.
>
> Regards,
> Dimitar
>
> On Sunday, October 18, 2020 at 10:16:4
Hi, folks,
I'm trying to dump R31 over and over into either RAM0 or Shared DRAM (Data
RAM).
So, basically it looks like I have to do:
Store R31 to address in register
Increment address in register
(Lather rinse repeat)
As that stands, that's a 100MHz sample of R31. Is there anyway to do the
So, we're still back at the original question of "Where do I file this bug
so that it gets tracked?"
I see some recent work on rpmsg bugs at
https://github.com/beagleboard/linux/issues, so I'll file a bug there.
But, is there somewhere else I should file it?
Thanks.
--
For more options,
Sure. Right now, I just keep track of how many messages are in flight and
I don't allow it to queue too many.
That's useful once you know what the bug is. Fortunately, I hit this bug
before I had two threads (one receiving USB and one receiving ethernet)
which would have made hunting it down
Urk, sorry I didn't quite get the implications of this statement:
The kfifo is used only on the receive path because of the asynchronous
> callbacks. The
> Tx-path is synchronous, the copy is attempted directly on the vring buffers
>
That means that kfifo doesn't exist on send so the only
Hi, folks,
The issue is that requests cause the rpmsg channels to the PRU to fill.
Which is actually fine, the PRU in this case is servicing slow requests and
the rpmsg being full should exert backpressure.
The problem is that the rpmsg system *HANGS* several second before timing
out and
TC+2 schrieb Andrew P. Lentvorski:
>>
>> Neither userspace nor PRU can change a pinmux.
>>
>
> Not correct. In a libpruio configuration all members of system-group
> 'pruio' can pinmux from user space. That's why libpruio development is as
> easy as Arduino development
Nobody knows where I should file this bug?
On Saturday, June 6, 2020 at 6:34:26 PM UTC-7, Andrew P. Lentvorski wrote:
>
> It appears that the problem is in rpmsg_pru.c.
>
> rpmsg_pru_read has the following code:
>
> if (kfifo_is_empty(>msg_fifo) &&
On Thursday, June 18, 2020 at 10:11:20 AM UTC-7, Dennis Bieber wrote:
>
>
> OTOH -- if the author could get it to work on a
> BB AI (which has two /pairs/ of PRUs, and currently has nothing for
> run-time pin-muxing -- requiring device tree edits for any thing that is
> not a default)...
>
As
On Sunday, June 21, 2020 at 10:45:44 PM UTC-7, Andrew P. Lentvorski wrote:
>
>
> If you must have a pin that changes direction and you need to control it
> from the PRU, you can use the digital I/O's on the IEP (industrial ethernet
> peripheral). I can confirm that this works
On Thursday, June 18, 2020 at 1:50:03 PM UTC-7, Dennis Bieber wrote:
>
> I can only state then, that a quick perusal of the online
> documentation
> (in particular, the github readme) gives this one the impression that the
> package provides a specific program running on a PRU which
It appears that the problem is in rpmsg_pru.c.
rpmsg_pru_read has the following code:
if (kfifo_is_empty(>msg_fifo) &&
(filp->f_flags & O_NONBLOCK))
return -EAGAIN;
rpmsg_pru_write presumably needs a similar piece of code with
kfifo_is_full() or it needs
I was getting some strange bugs from some remoteproc stuff I was doing on a
BBB, and eventually I tracked it down to the overunning the rpmsg system
which can block for several seconds on a write.
Okay, fine. No big deal. This is what poll() was made for--flip
"/dev/rpmsg_pru30" to
Agreed. 3G modems can pull a remarkable amount of power (up to 2A!) under
certain circumstances.
That's going to tax the power systems of the PocketBeagle pretty heavily.
You need to have something which you can use to turn on/off the power to
the modem which bypasses the PocketBeagle power
You can certainly persist, but I'm going to point out the existence of
chips like the AWR1843--"Single-chip 76-GHz to 81-GHz automotive radar
sensor integrating DSP, MCU and radar accelerator":
https://www.ti.com/product/AWR1843
This is about $30, and does all the RF-y things while sending your
What are you actually trying to do? That's a 50Mbit sustained transfer
rate if bit time is 20ns. 100Mbit if 10ns. And 4 channels. That's
200-400Mbps. You're moving a *TON* of data even at slower clock
rates--there is no resource on the BBB that can keep that up very long.
This seems quite
Is there some sort of event or flag for pinmux completion?
It seems that an overlay can take up to about 10-15 seconds after login is
enabled before the pin muxes actually land in the expected state.
Thanks.
--
For more options, visit http://beagleboard.org/discuss
---
You received this
Thanks, Robert. Then I'll still install an EEPROM on my boards since there
is still usefulness.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop
Given that overlays have to be loaded at bootanyway, does it even make any
sense to keep adding EEPROM for identification?
Thanks.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To
09 AM UTC-7, William Hermans wrote:
>
> https://www.kernel.org/doc/Documentation/usb/gadget_multi.rst
>
> On Thu, May 7, 2020 at 1:48 AM Andrew P. Lentvorski > wrote:
>
>> Is there a way to configure extra USB gadget endpoints in addition to the
>> BBB default ones
Is there a way to configure extra USB gadget endpoints in addition to the
BBB default ones or do I just have to go in and edit the am335x_evm.sh
script?
Thanks.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google
-header
Sorry to bother everybody.
On Monday, March 9, 2020 at 2:23:40 AM UTC-7, Andrew P. Lentvorski wrote:
>
> Is there a full pinmux table for the Pocketbeagle headers somewhere?
>
> I'm specifically looking to see if any of the PRU Ethernet Peripheral
> digital I/O (pr
Is there a full pinmux table for the Pocketbeagle headers somewhere?
I'm specifically looking to see if any of the PRU Ethernet Peripheral
digital I/O (pr1_edio_data_out/pr1_edio_data_in) pins are mapped to
anything.
Thanks.
--
For more options, visit http://beagleboard.org/discuss
---
You
I seem to be missing something obvious: Where do I get the values for src
and dst in the pru_rpmsg_send() function?
The TI examples do a pru_rpmsg_receive() first and then echo back to the
same src and dst. That seems ... odd. What's the point of having a
variable src and dst if they are
Much appreciated, Robert. I updated to the PRUCAPE file and tore out a
bunch of stuff I didn't need and that seems to be setting the pinmux
correctly.
Is there anything else in this file that can be removed?
Thanks.
// Code shamelessly copied from AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dts
Am I doing something wrong or are my expectations incorrect?
I created an overlay file BB-PRUDAP-00A0 to take over P9_17 and P9_18 and
set them to the IEP.
I added it to uEnv.txt and apparently it loaded:
root@beaglebone:~/prudap/lkm/prudap_lkm# ls -al
/proc/device-tree/chosen/overlays/
Thank you.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
Okay, then I'm just missing something obvious. What is a GPIO-SS? What
unit and what register address? I see no mention of "GPIO-SS" anywhere in
the AM335x Technical Reference Manual.
Normally, I associate SS with "slave select" which means SPI. I see that
you *can* turn around the CS
Well, sort of, except you omit the *EXTREMELY* important point that you
install a custom kernel module in order to expose the clock activation and
pinmux system to all users.
Okay, yes, if I build a kernel module I now have full access to all
registers on the system with no restrictions.
As far as I can tell, the old mmap() method fails. What's my next step?
#include
#include
#include
#include
#include
#include
#include
#include
#define CONTROL_MODULE_START ((uint32_t)0x44E1)
#define CONTROL_MODULE_END((uint32_t)0x44E11FFF)
#define CONTROL_MODULE_LENGTH
Is there a way to set the pinmux for a pin to the PRU Industrial Ethernet
Peripheral from Linux (for example: set pin P9_17 to pr1_edio_data_out0)?
If not, what would be the recommended way to do so?
Thanks.
--
For more options, visit http://beagleboard.org/discuss
---
You received this
On Thursday, January 16, 2020 at 8:39:20 AM UTC-8, TJF wrote:
>
>
> In order to change direction for a pin on a GPIO-SS, it needs a write
> access to its OE register. The PRU can do that.
>
Let me see if I have this straight, I need access to an output enable from
the PRU. The only output
On Thursday, January 16, 2020 at 9:58:39 AM UTC-8, Jason Kridner wrote:
>
>
>
> On Thu, Jan 16, 2020 at 3:39 AM Andrew P. Lentvorski > wrote:
> >
> > I've got to be missing something obvious, but I even after several
> rounds of RTFM, I can't seem to figure ou
I've got to be missing something obvious, but I even after several rounds
of RTFM, I can't seem to figure out how to get the PRU to change the
direction of a pin or, at the very least, to let it go to a tri-state value.
I would go out over the L3/L4 (although that kinda smashes the whole
I haven't checked the Bill of Materials, but if U22 (the TUSB322IRWBR USB-C
control chip) is populated along with R533 and R534, then the board is out
of spec for USB-C on the CC lines.
On Thursday, November 7, 2019 at 7:15:01 AM UTC-8, nick.g...@gmail.com
wrote:
>
>
> Hello,
>
> I have
Well, if the SMBus Specification Version 2.0 Section "5.5.7 Block
write/read" is goofy then, um, okay ...
However, since this appears to be a standard part of SMBus, now I really do
wish to ask "How do I do this with the Linux I2C drivers?"
--
For more options, visit
Looking at the driver
at:
https://github.com/torvalds/linux/blob/master/drivers/i2c/busses/i2c-davinci.c
It looks like i2c_davinci_isr() only terminates a read via terminate_read()
which doesn't seem to have an exit path for completion without STOP.
It would be nice if somebody with more
3 PM, Andrew P. Lentvorski wrote:
>
> I'm trying to communicate with an I2C chip which returns the length of the
> bytes to be read in the first byte of the transaction. This is fairly
> straightforward on most primitive microcontrollers.
>
> But for the life of me,
Under NDA. So, not in linux database.
On Monday, February 12, 2018 at 5:07:37 PM UTC-8, Wulf Man wrote:
>
> what part
>
> On 2/12/2018 6:03 PM, Andrew P. Lentvorski wrote:
>
> I'm trying to communicate with an I2C chip which returns the length of the
> bytes to be r
I'm trying to communicate with an I2C chip which returns the length of the
bytes to be read in the first byte of the transaction. This is fairly
straightforward on most primitive microcontrollers.
But for the life of me, I cannot figure out how to do this on Linux. A
"read" always wants to
Did you ever get an answer for this. I followed the directions at:
https://wiki.tizen.org/USB/Linux_USB_Layers/Configfs_Composite_Gadget/Usage_eq._to_g_hid.ko
And am now bumping into the same problem:
root@beaglebone:/home/debian/cfg/usb_gadget/g1# pwd
/home/debian/cfg/usb_gadget/g1
Thanks to zmatt on the IRC channel this got resolved.
The problem is that the am335x-boneblack-overlay.dtb does not define the
symbol "clk_mcasp0".
So, I had to use the am335x-boneblack-audio.dtb overlay instead.
On Monday, June 26, 2017 at 1:31:27 AM UTC-7, Andrew P. Lentvo
I'm trying to get my own audio cape to load so I thought I would start by
loading the built-in audio cape configuration and then copy that to make my
own. However, I can't seem to beat the cape manager into submission. I
can load the BB-UART1-00A0 overlay, but I can't load the
Thank you, Robert.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
If I'm using Robert C. Nelson's build scripts: (ie: git clone
https://github.com/RobertCNelson/ti-linux-kernel-dev.git, git checkout
tags/4.4.54-ti-r93 and then build_kernel.sh), what is the appropriate
file/place/repository to inject patches to be picked up.
Do I modify the repo in /ignore?
I've build a codec cape based around the Analog Devices ADAU1372.
At this point, I can communicate with the device over I2C using i2cset/get
and I can see audio data on the wire using my oscilloscope when I manually
configure it. i2cdetect happily sees both my (as yet unconfigured) EEPROM
at
I've build a codec cape based around the Analog Devices ADAU1372.
At this point, I can communicate with the device over I2C using i2cset/get
and I can see audio data on the wire using my oscilloscope when I manually
configure it. i2cdetect happily sees both my (as yet unconfigured) EEPROM
In the comments from the linked article you have this message:
which cape is this tutorial for? I also have several TowerTech Can capes.
> http://circuitco.com/support/index.php?title=TT3201_CAN_Cape
>
To which the original author responds:
I did not use any cape when making this tutorial, I
Huh? CANOpen/SocketCAN SDO transactions can have almost indefinite extent,
have toggle bits that persist across frames, and CRC's that span the whole
transaction.
If you can eyeball that, you are way smarter than me.
I think you may only be considering PDO transactions which are only ever 8
I feel really stupid asking this on the forum, but I can't seem to find the
setting that would sort the threads by the latest post. Is this a group
administrator setting rather than an individual setting?
A quick Google search for variants on google groups sort thread by recent
post -gmail
for your suggestion.But i don't want to use any extra
hardware.I want to use direct BBB.Wonder if i couldn't find Can Bus
driver for BBB ?
28 Ağustos 2015 Cuma 16:53:08 UTC+3 tarihinde Andrew P. Lentvorski yazdı:
Well, you need a CAN cape of some form to provide a CAN transceiver.
Something
I can confirm this with a scope. After porting the kernel module from this
topic:
https://groups.google.com/forum/#!topic/beagleboard/dyuax5415dc
I measured exactly 12.5MHz. Apparently mmap is doing something stupid that
slows down the access from user space.
On Monday, August 24, 2015 at
I tried a couple of different ways to build the hello world kernel
module, but I seem to be lacking the proper build to use in my makefiles.
So, I installed the linux headers, but I seem to be missing a classmap.h
file.
I also managed to get past git crashing by downloading the repo and then
Well, you need a CAN cape of some form to provide a CAN transceiver.
Something like this:
http://www.logicsupply.com/cbb-serial/
After that, follow the directions that the manufacturer provides.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because
On Friday, August 28, 2015 at 2:11:43 PM UTC-7, RobertCNelson wrote:
bb-kernel repo has w.x.y-bonez kernel names...
https://github.com/RobertCNelson/ti-linux-kernel-dev
has what your are looking for kernel source...
Aha!
Thank you. That was the piece I was missing.
--
For more
After I clean up my own two *very* stupid errors of not capitalizing the
name of the Makefile and installing the *r12* headers (I had r11), it
compiles and inserts.
During my experiments, though, I came across something odd. As the missing
piece appeared to be this symlink:
While on my BBB, I tried to follow the directions for building a kernel
from here:
https://eewiki.net/display/linuxonarm/BeagleBone+Black
Unfortunately, when I try to do ./build-kernel.sh to populate everything to
deploy, git dies with error: index-pack died of signal 9555. Presumably,
it
Well, I still don't know why the overlays aren't working, but I seem to
have gotten the clocks toggled correctly to avoid a SIGBUS Bus Error.
This code turns on the clocks and waits for them to become stable. Then it
reads the SPI0 version register for confirmation.
#include stdint.h
I followed the directions here (as best I could given that device tree
filenames have changed position again ...
sigh): http://elinux.org/BeagleBone_Black_Enable_SPIDEV
Something seems wrong as I'm picking up /dev/spidev1.0 instead of
/dev/spidev0.0
And when I try to mmap the SPI region and
Hi, folks,
I have been trying to bit bang an interface on the GPIO pins. I looked at
a bunch of the tutorials on the web and managed to build something that
worked. However, the speed seems to be a bit slower than I would expect.
My scope shows that I am running at about 2.95MHz (It also
Hi, folks,
I've been poking around to get GPIO to work via /dev/mem and mmap. After
finally pushing a lot of things around, I finally managed to pull the
various flavors of tutorials together into something I now understand
(mostly).
However, what I *don't* understand is that when I put my
On Monday, August 24, 2015 at 7:27:35 AM UTC-7, Charles Steinkuehler wrote:
Optimal would be a sequence of successive stores to the set and clear
register, with the addresses pre-calculated and sitting in registers
(or with a base address and use the str instruction with an immediate
I've been trying to hunt down the maximum frequency on the BeagleBone Black
GPIO pins.
This *seems* to be dominated by the transaction latency across the L3/L4
interconnect. Fair enough. So ...
What's the latency number?
I've *measured* about 166ns per transaction (I can create a roughly
On Monday, August 24, 2015 at 5:10:11 PM UTC-7, William Hermans wrote:
I think the actual scope matters more. e.g. global versus local scope. But
maybe I'm remembering wrongly as I recall reading something to this effect
years ago. Anyway, I find this link the best single resource for
On Monday, August 24, 2015 at 5:39:54 PM UTC-7, Charles Steinkuehler wrote:
On 8/24/2015 6:12 PM, Andrew P. Lentvorski wrote:
I've been trying to hunt down the maximum frequency on the BeagleBone
Black
GPIO pins.
This *seems* to be dominated by the transaction latency across the L3
Thanks for this. I'll pull this into a separate thread as we're drifting
way off-topic now ...
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
BeagleBoard group.
To unsubscribe from this group and stop
:
On Tue, Feb 24, 2015 at 8:00 PM, Andrew P. Lentvorski bsd...@gmail.com
javascript: wrote:
To be fair, ranting at least got him a response.
Lots of people seem to be asking questions and I see like single digit
views
and no responses.
It feels like a ghost town in here
To be fair, ranting at least got him a response.
Lots of people seem to be asking questions and I see like single digit
views and no responses.
It feels like a ghost town in here.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are
Anyway ... tl;dr I can verify that 2 of the 3 CANBUS interfaces on the
TT3201 work. The third looks like it should work, but I didn't verify it.
For those who would like to actually use the thing, here's the notes I was
taking as I was going along in case I need to repeat this:
Dealing with
to
transciever with scope ??. I'd bet the IO is not configured properly for
that cape
--
*From:* Andrew P. Lentvorski bsd...@gmail.com javascript:
*To:* beagl...@googlegroups.com javascript:
*Sent:* Thursday, February 12, 2015 8:12 PM
*Subject:* [beagleboard
Beaglebone black newb here. I've been fighting with various problems with
getting CAN to work and not really getting anywhere. Does anybody have a
detailed set of instructions for the TT3201?
I'm trying to use the onboard Beaglebone Black CAN which is routed directly
to a transceiver to
73 matches
Mail list logo
