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]> 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 > > <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/ <https://rcn-ee.com/> > > -- > For more options, visit http://beagleboard.org/discuss > <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:beagleboard%[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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 > <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.
