I think you are making this much more difficult than it needs to be.
The standard linux SPI device works fine for talking to any slave
device. What you need to do is to connect one device to CS0 and the
other device to CS1, and then tell the (one) driver to use one or the
other chip select
I have not done this with the PRU, but I work with all sorts of other
chips that have to use ring buffers. It is usually easiest to start
with head = tail = 0 as the starting (buffer empty) case. Then drop
bytes on the sender side if head++ would == tail. It gets really simple
if the head
You do need to leave the SCLK with RX_ENABLE turned on, or the receive
section of the SPI will have no SPI clock. RX_ENABLE does not make the
pin an input or output: It just enables reading the value out on the IO
pin. The use of the pin specified in the 3 MODE bits really defines if
it
I've done some work with GPIO handshaking from a user space program, and
I've watched the process with a logic analyser: I see the user space
program running about 70% of the time with several msec gaps about every
10 msec. I also see some longer gaps (up to 120 msec!) every now and
then.
It's not a quirk of the driver, that you have to set SPI_CLK as an input
even when the Sitara is master: It's the hardware. The SPI puts the
SPI_CLK out for its MOSI data, but it needs the SPI_CLK to clock in its
MISO data from the slave. The bit that you are calling input does not
make the
The SPI module gets a clock of 48 MHz from the clock tree. You might be
able to work with that frequency, but I know you can get it to work at
48/3 (16 MHz), because I do every day. I have read somewhere
experimenters could not get it to work at 48/2 (24 MHz). I set my speed
on the fly using
The easiest way is just to buy a little router that does PPPOE and NAT
to connect your internal LAN to your ISP. You go into the router setup
screen once to tell it the PPPOE password, etc. Then you tell all your
devices (ie. laptop and BBB) to use that gateway address so anything on
your
I'm memory mapping GPIO so I can run some GPIO pins MUCH faster than
doing it through the file system. (340 nsec versus 80 usec) You can
use those GPIO_CLEARDATA and GPIO_SETDATA registers to either turn on or
turn off multiple bits at once, but there are two important limitations:
1) You can
I don't think you will be able to overcome these times using the
existing SPI HW and SW. 48 MHz is the fastest the SPI hardware can run
because that is the clock signal it gets before any clock dividing.
Some things I have read say not to use it at faster than /3 (16 Mhz).
If you really
Yes, I was talking about trying to do hard real-time data collection in
a user-space program. If you look at the maximum interrupt latencies
from other stuff running on the system, then you see just why PRUs are
necessary to always meet your deadlines. Most of the time, a user-space
program
You could bit-bang SPI Master using some GPIO pins, but you can't run
the clock much faster than 1 KHz using a user-space program under
Linux. With a custom driver, you could run faster but it would still be
limited by the interrupt latency caused by other ISRs. You could do it
using a PRU
/O pins in user space.
On 5/8/2014 1:29 AM, r van dam wrote:
@Guy I have been away for a bit thus my late reaction.
Can you give me a hint how to change the pullup to pulldown at bootup?
Op maandag 21 april 2014 21:02:52 UTC+2 schreef Guy Grotke:
I would not fight the enabled pullup
Try looking at SiliconDust tuners: They have a tuner that is controlled
by and generates ethernet packets. They have online documentation that
explains the packet contents, so I don't think it would very difficult
to write your own BBB software to use them.
On 5/8/2014 11:42 AM, Ranjith
I would not fight the enabled pullup with my own pulldown: Either change
your control program and circuit to take high as inactive, or change the
boot software to program that GPIO with no pull resistor (so you can add
your own external pulldown) or program that GPIO with the internal pulldown
Is it high (IE. driven) or is it just floating? To quote the TI Technical
Reference: “At reset, all the GPIO related pins are configured as input and
output capabilities are disabled.” Unless the boot process or some program
sets your pin up as an output, then it would just float in a high
No other language squeezes into tight spots like that.
Forth comes in lots of different flavors: The tiniest one I ever used (for a
6502-based industrial air pollution monitoring device) was cross-compiled on a
minicomputer to generate 8-bit tokens for the program ROM. So each “call” of a
I am running BBB SPI as slave but using the opposite direction for the data
pins:
0x150 0x30 /* spi0_sclk.spi0_sclk, INPUT_PULLUP | MODE0 */
0x154 0x10 /* spi0_d0.spi0_d0, OUTPUT_PULLUP | MODE0 */
0x158 0x30 /* spi0_d1.spi0_d1, INPUT_PULLUP | MODE0 */
0x15c 0x30 /*
All your programmable I/O pins are going to startup in tristate mode. That
means you can just add a weak pullup or pulldown resistor (EG. 10K) to each
pin’s circuit to make your external devices behave properly until your software
programs the pins.
From: maartenrik...@gmail.com
Sent:
: Gerald Coley
Sent: Monday, April 14, 2014 11:11 AM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Setting I/O's
That is not correct. Please. Read the datasheet.
Gerald
On Mon, Apr 14, 2014 at 1:04 PM, Guy Grotke ggro...@serranosystems.com wrote:
All your programmable I/O pins
Sure, it’s very nice to have a tiny and inexpensive computer that runs Linux, a
TCP stack, etc. But you probably have your BBB connected to a PC that can do
that stuff already, much faster and with a keyboard, mass storage, and so
forth. BBB is a both an embedded Linux platform AND two very
You might try using 24 or 16 Mbps instead of 48 Mbps. The SPI clock divider
has a 48 Mhz input, so maybe it has to actually divide by more than 1.
From: Lukas Van Iseghem
Sent: Thursday, March 20, 2014 7:08 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] bare metal programming
You probably have a bone_capemgr.8 instead of a .9. Have a look. Or just try
using .8 instead.
From: woelf...@arcor.de
Sent: Monday, March 17, 2014 10:08 AM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Trying to enable UART
Hello Louis,
simply type:
echo BB-UART4
I am using the Angstrom 3.8.13 release that came with my BBB, with either the
serial gadget interface or SSH. I have tried lots of “known” methods to read
single keypress values from my console but I still am seeing local echoes of
the characters until I press the enter key. I suspect both of
I think you might have to do this in a PRU: I believe the SPI clock divider
input runs at 48 MHz, so it can divide down to 24 MHz, 16 MHz, 12 MHz, etc.
But I have also read someplace that it doesn’t work above 16 MHz. You should
also keep in mind that the SPI device driver takes the passed
Its going to be pretty difficult to get a 38,400 baud “take photo” command out
to six cameras at once when you get a signal from your accelerometer. Without
some real-time patches, Linux may have a response latency of 100 msec for a
user-space program and with them 50 usec for an
All of the LCD pins are listed in Derek Molloy’s nice
BeagleboneBlackP8HeaderTable.pdf. The high-order ones you are looking for are
on P8_11 to P8_17 + P8_19, but the order is mixed up.
Do a web search for BeagleboneBlackP8HeaderTable and
BeagleboneBlackP9HeaderTable and you will find Derek’s
I just checked my BBB again with Chrome: Works fine, always has. I guess you
could try downloading the latest image to an SDA card and reprogram the
internal flash. If that doesn’t work, then it’s time to ask your vendor about
an exchange.
From: Kelly Barker
Sent: Monday, February 17, 2014
Derek Molloy has published two very nice tables on github, with everything you
need. Just do a web search for BeagleboneBlackP9HeaderTable or ...P8... and
you will find them.
From that table, P9.17 = PIN # 87, addr = 0x44E1095C, offset = 0x15C, in mode7
= gpio[5]
cat
If your requirements are pretty relaxed (like running a touch screen), then you
could use four GPIO outputs as address inputs for a 16-to-1 analog MUX chip.
Your program would select the input you want to measure (of 16 possible), which
would connect that input to an ADC pin.
If you really
29 matches
Mail list logo
