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 wh
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 and
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 will
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. Do
I do this in my c programs all the time. The SPI driver has a bunch of
ioctl() calls to change anything. If Python can't make those ioctl()
calls but supports functions for reading and writing a hardware
register, you might be able to open the SPI device and then call the
register access fun
Yes, I can help you! I am talking to the SPI0 hardware directly so I
can use it in slave mode. Since you are not using the driver, you need
to enable the clock to the SPI module or else register accesses fail. I
do it like this:
// map a pointer to the clock control block:
pClockCon
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
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 th
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 need
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
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 LAN
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 r
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 to
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 Para
the I/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
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 imp
>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
F
From: 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 wrote:
All your programmable I/O pins are going to
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: Monday,
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 /* s
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 fa
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 (start
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 > /sys/devic
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 key. I suspect both of these
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 sp
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 interrupt-driv
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
They probably have a collision on one or more pins. Have you looked at their
respective .dts files to see if there is a conflict? Try assigning pins to one
or the other.
My (very limited) experience with the cape manager leads me to believe it is
not very good about giving you informative mess
Deriving the regulated 5 VDC supply from 24 VDC can be a simple as a single
pass-regulator with a couple of capacitors. Or you can make it more efficient
by using a little switching-regulator chip. 0-24 volt DC inputs just take a
resistor divider (two resistors) to scale the input range down t
Try using an mmap() pointer to read the registers themselves: It is much, much
faster. Of course, then you will be responsible for setting the right register
bits to start conversions, wait until they are done, etc. You still may want
to open the device driver so the power and clock is turned
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
Hi matt,
You are calculating the wrong addresses when you add the offsets to reg_base.
Instead of reg_base + 0x134 it does reg_base + (0x134 * 4). The compiler is
being “helpful” by converting your integer offset into a unsigned int[index]!
You could define the address pointers as unsigned in
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 /sys/kernel/debug/
Most DHCP servers will record the ethernet MAC address of each IP number
assignment and try to assign the same IP when they see that MAC address again.
That lets node users determine their DHCP-assigned IP address once and assume
they will get that same IP address when they attach to the networ
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 nee
36 matches
Mail list logo