William, yes, indeed much of my code is based on some of the approaches
of Abhiskek; he did a real nice job, and I borrowed some of his
techniques with some changes (I only go up to a maximum of 50MS/s
whereas Abhiskek goes up to 100MS/s and I don't use the new TI assembler
or the Pru-C compiler - they looked too complicated for me without
having someone around that was knowledgeable about how to use them, and
I was up and running on pasm2, also I only support up to 12 bits), but
my approach is very similar, especially in timing. My user interface is
different as my application is different (primarily intended to hook up
to buses going to sensors from my cape). I've been trying to get my cape
linked to the http://elinux.org/Beagleboard:BeagleBone_Capes site, but
have not been successful in these attempts (not sure why). Currently,
working on a second cape (first one is finished along with two sensor
interfaces - well hardware anyways, software is never finished - ) with
a LoRa transceiver (which has an SPI interface - the Semtech SX1276) and
an RTC; first PCB into debug early Jan. but have two jury rigged BBBs
talking now to get software started (have established python on arm is
plenty fast enough).
On 15-12-16 06:39 PM, William Hermans wrote:
Kenneth, Have you looked into Beaglelogic ?
https://github.com/abhishek-kakkar/BeagleLogic
On Wed, Dec 16, 2015 at 4:13 PM, Kenneth Martin
<[email protected] <mailto:[email protected]>> wrote:
John, I haven't heard of McSPI, but I'm running the SPI from a
python program on the Arm side based on some Pyside Qt
controllers, I'm using the PRU for a logic analyzer and the logic
analyzer pins are not available for the SPI, so this could be the
reason. I may also use the PRU IEP timer in the future for some
fine timing but I don't think this is relevant.
On 2015-12-16 04:53 PM, John Syne wrote:
No need to bitbang unless you want additional SPI ports
available. Simply use the McSPI port controlled from the PRU.
Regards,
John
On Dec 16, 2015, at 1:37 PM, William Hermans <[email protected]
<mailto:[email protected]>> wrote:
/Normally SPI's are good up to 100MHz, but this is seldom
needed. I normally set them up at 1MHz for initial debug
(allows for cheaper instruments) and then usually go to
10MHz which normally makes speed a non-issue and allows for
longer wires. 16MHz should be fine as well. I2C's often run
around 1MHz and are very dependent on length (i.e.
capacitance). One needs to keep I2Cs high when not used to
minimize power due to pull-ups. SPI's, once you get them
going, are generally a better choice./
SPI through the PRU seems to be limited at around 21.2Mhz. At
least an implementation I was just reading about. It seemed that
the author was bit banging however. Using the other PRU core for
the clk timer as well.
On Wed, Dec 16, 2015 at 12:49 PM, Robert Nelson
<[email protected] <mailto:[email protected]>> wrote:
> Currently I'm fighting with WiFi; I had scripts to detect
the wlanx device
> using iw dev | grep "Interface" | awk '{printf $2}' but
this is failing at
> boot; it works fine after boot. I tried hard coding the
wlanx device, but
> now it seems to change; when I specify wlan0, it comes up
as wlan1, and vice
> versa? It seems wireless networking changed somewhat from
my previous
> version, and I haven't tracked down what yet. So wireless
first, apt-gets
> second, pips third, device trees fourth, prus fifth, and
then tracking down
> why previously debugged software stopped working. It might
be interesting to
> keep track of how many issues come up.
Sounds like the wifi device has a mac that changes..
Right a udev rule to push it back to wlan0..
here's an example of a udev rule we used on teh bbb's for
the eth0:
https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Networking:UsingasharedSDcardwithMultipleBeagleBone
For example, enp2s0 on my desktop:
$ sudo udevadm info -a /sys/class/net/enp2s0
Udevadm info starts with the device specified by the devpath
and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device
'/devices/pci0000:00/0000:00:15.0/0000:02:00.0/net/enp2s0':
KERNEL=="enp2s0"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_assign_type}=="0"
ATTR{addr_len}=="6"
ATTR{address}=="bc:5f:f4:e5:9d:83"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{carrier}=="1"
ATTR{carrier_changes}=="1"
ATTR{dev_id}=="0x0"
ATTR{dev_port}=="0"
ATTR{dormant}=="0"
ATTR{duplex}=="full"
ATTR{flags}=="0x1003"
ATTR{gro_flush_timeout}=="0"
ATTR{ifalias}==""
ATTR{ifindex}=="2"
ATTR{iflink}=="2"
ATTR{link_mode}=="0"
ATTR{mtu}=="1500"
ATTR{name_assign_type}=="4"
ATTR{netdev_group}=="0"
ATTR{operstate}=="up"
ATTR{speed}=="1000"
ATTR{tx_queue_len}=="1000"
ATTR{type}=="1"
looking at parent device
'/devices/pci0000:00/0000:00:15.0/0000:02:00.0':
KERNELS=="0000:02:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="alx"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{d3cold_allowed}=="1"
ATTRS{device}=="0x10a1"
ATTRS{dma_mask_bits}=="64"
ATTRS{driver_override}=="(null)"
ATTRS{enable}=="1"
ATTRS{irq}=="38"
ATTRS{local_cpulist}=="0-3"
ATTRS{local_cpus}=="f"
ATTRS{msi_bus}=="1"
ATTRS{numa_node}=="-1"
ATTRS{subsystem_device}=="0x10a1"
ATTRS{subsystem_vendor}=="0x1849"
ATTRS{vendor}=="0x1969"
looking at parent device '/devices/pci0000:00/0000:00:15.0':
KERNELS=="0000:00:15.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{d3cold_allowed}=="0"
ATTRS{device}=="0x43a0"
ATTRS{dma_mask_bits}=="32"
ATTRS{driver_override}=="(null)"
ATTRS{enable}=="1"
ATTRS{irq}=="24"
ATTRS{local_cpulist}=="0-3"
ATTRS{local_cpus}=="f"
ATTRS{msi_bus}=="1"
ATTRS{numa_node}=="-1"
ATTRS{subsystem_device}=="0x0000"
ATTRS{subsystem_vendor}=="0x1022"
ATTRS{vendor}=="0x1022"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
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
[email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic
in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/beagleboard/tdt1TTix7aE/unsubscribe.
To unsubscribe from this group and all its topics, send an email
to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the
Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/beagleboard/tdt1TTix7aE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
