i get it. I’ll try to connect. Thank you very much.
After overlaying all the above process and the BONE-SPI0_0.dts file,
P9_17(header) SDA(SS) → SPI6_CS0
P9_22(header) SCK → SPI6_CLK
P9_18(header) MISO → SPI6_D1, INPUT
P9_21(header) MOSI → SPI6_D0, OUTPUT
X IRQ
P9_1(header) GND
P9_9(header) RST → RESET
P9_6(header) 3.3V → V_in
I connected the RFID RC522 module and the beaglebone ai-64 board to the above pins and tried to run it using SPI communication.
However, no communication actually took place. So I took pictures of all pins from sck with an oscilloscope to see if the signal was actually caught.
However, a signal with only noise came out, and the toggle and related signals were not caught.
Isn’t this a problem with the kernel?
do you know how to solve it?
It is unlikely to be a kernel issue, more likely a device tree issue.
Are you sure you are loading an un-modified dts file ?
When checking for signals is the RFID board connected ?
If it is, try checking again with nothing connected to the SPI bus apart from DSO
It is certainly. The BONE-SPI0_0.dts file was imported without modification.
And after building the code below without RFID connection, I checked the clock speed with only GND of P9_1 and SCK of P9_22.
#include <stdio.h>
#include <string.h>
#include <stdint.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/spi/spidev.h>
#include <linux/gpio.h>
#include <termios.h>
#include <time.h>
#define SPI_DEVICE “/dev/spidev9.0” // SPI device path (X: bus number, Y: device number)
int spi_fd; // access a specific file
// initialize SPI communication
int main() {
spi_fd = open(SPI_DEVICE, O_RDWR);
if (spi_fd < 0) {
printf(“Failed to open SPI device”);
return -1;
}
// set SPI mode
uint8_t mode = SPI_MODE_0;
if (ioctl(spi_fd, SPI_IOC_WR_MODE, &mode) == -1) {
printf(“Failed to set SPI mode”);
return -1;
}
// set the maximum baud rate (1MHz)
uint32_t speed = 1000000; // 1M or 100k and so on
if (ioctl(spi_fd, SPI_IOC_WR_MAX_SPEED_HZ, &speed) == -1) {
printf(“Failed to set SPI speed”);
return -1;
}
return 0;
}
It could be a device tree problem, so I’ll try overlaying again.
And I have one more question, there are several bus and device number files such as BONE-SPI0_0.dtbo, BONE-SPI0_1.dtbo, BONE-I2C1, I2C2, I2C3.dtbo, etc. in the overlays folder of the sd card. does it matter?
No, having extra overlay files does not matter. They are only loaded if you add them to extlinux.conf
oh! i got it.
The following is written in extlinux.conf.
label Linux microSD
kernel /Image
append console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 root=/dev/mmcblk1p2 ro rootfstype=ext4 rootwait net.ifnames=0 quiet
fdtdir /
fdtoverlays /overlays/BONE-SPI1_0.dtbo
initrd /initrd.img
When I used BONE-SPI0_0.dtbo before, the above error occurred, so I plan to use BONE-SPI1_0.dtbo.
I’ll go ahead and ask further questions. thanks.
// Check if the card exists
int PiccIsNewCardPresent() {
uint8_t tx_data = {0x52};
// Data pattern value for transmitting the corresponding function to MFRC522, 0x52 : find all the cards antenna area
uint8_t rx_data[1];
memset(rx_data, 0, sizeof(rx_data)); // Init to specific value
if (SpiTransfer(tx_data, rx_data, 1) < 0) { // To determine whether or not the card exists when SPI communication fails.
printf(“Failed to transfer data\n”);
return -1;
}
// printf(“%02X, %02X\n”,rx_data[0], rx_data[1]);
return rx_data[1];
}
// read card UID information
int PiccReadCardSerial(uint8_t* uid) {
uint8_t tx_data = {0x93};
// Data pattern value to transmit the corresponding function to MFRC522, 0x93 : election card
uint8_t rx_data[1];
memset(rx_data, 0, sizeof(rx_data));
if (SpiTransfer(tx_data, rx_data, 2) < 0) {
printf(“Failed to transfer data\n”);
return -1;
}
memcpy(uid, &rx_data[1], 4); // Copy 4 bytes from the 2nd byte to the uid array
return 0;
}
Currently, the data pattern value is used as above, but it seems to be because the Beagle Board does not provide a header file such as MFRC522.h in which the pattern value is defined.
Is there any other method other than SPI communication using these data pattern values between the RFID and the bbai-64 board??
do you know anything??
I think you have some problems there with your spi code.
In general most spi slave devices need at a minimum a command, either followed by data relevant to that command, or dummy data if the device is being read.
For example in your PiccIsNewCardPresent() function, if you want to read back 1 byte you need to transmit 2 bytes, the command, 0x52 and then a dummy byte (can be anything, but best to make it either 0x00 or 0xff) to allow the device to clock out the response for the command. The slave device cannot start to clock data out, until it has received the command byte.
If the command was going to read 100 bytes of data, you would need to shift out 101 bytes - the command, plus 100 dummy bytes to clock in the data.
If you Goolge you will find plenty of code the read an mfrc522 using SPI.
But they will probably need some modifications for the BBB though.
There is this for the Pi. https://github.com/luvbum/RPi-RFID
You will need to write an equivalent to the bcm_xxx functions to read and write data.
Or there is this https://github.com/miguelbalboa/rfid/blob/master/src/MFRC522.cpp
for the Arduino, in which case you will need to modify the read and write register functions to use spidev.
Both pretty simple to do.
In the case of Arduino URL, #include <Arduino.h> and #include “MFRC522.h” are all required. Should these also be written according to BBAI-64?
In fact, I’ve only dealt with libraries, but I haven’t written them myself. So I’m trying to use a library like iobb.h, but is it compatible with BBAI-64?
#include <stdio.h>
#include <iobb.h>
#define SPI_BUS SPI0
int
main(void)
{
int i;
int rxval;
iolib_init();
configure_spi_pins(17, 18, 21, 22); // CS, D1, D0, CLK
if (spi_enable(SPI_BUS))
{
spi_ctrl(SPI_BUS, SPI_CH0, SPI_MASTER, SPI_RX, /* use SPI_TX or SPI_RXTX depending on needs */
SPI_DIV32, SPI_CLOCKMODE3, /* 48 MHz divided by 32, SPI mode 3 */
SPI_CE_ACT_LOW, SPI_OUTIN, 16); /* D0 is output and D1 is input, 16-bit transactions */
}
else
{
printf("error, spi is not enabled\n");
iolib_free();
return(1);
}
for (i=1; i<20; i++)
{
spi_transact(SPI_BUS, SPI_CH0, 0 /*or integer to transmit data*/, &rxval);
printf("Received: 0x%04x \n", rxval&0xffff);
iolib_delay_ms(500);
}
spi_disable(SPI_BUS);
iolib_free();
return(0);
}
Prehaps you can help. I have been trying to port my 1/8 scale RC car controller from the BBB to the BBAI-64. Device trees and overlays were foreign to me with my BBB. My control system uses 3 Uart’s: for xbee interface to laptop, 1 for GPS, and the other for IMU. I used PRU0 for steering and Motor speed control. I used PRU1 for communication to the Linux environment. I want to incorporate vision control to the system of which I believed the BBAI-64 would work. To date I have the 3 UART’s working with an overlay. For the motor control I have gotten the PRU APWM to work partially. This morning I have finally got the motor’s quadrature encoder to work. I have modified the robotics cape, see atached file. What I don’t understand is why by adding the &cbass_main node why I can get the PRU to receive the EQEP0 inputs. And also why can’t I control the pinmux through the PRU’s.
MotorControl.dts (2.0 KB)
@klindsayjr, Did you ever get clarity on this issue?
@jkridner, @RobertCNelson, @nmenon, Are there any educational resources you could point us to so we can get a better understanding of how to properly construct BBAI64 devicetree overlays? Could we perhaps use a TI tool to generate the basic skeleton and then modify that into what we need for the BBAI64? We sincerely appreciate any tips or advice you can provide.
We are using EPWM from an R5 core. PWM4 only works if we include a &cbass_main node that was derived from the official beagle provided robotics cape as shown below. The comments in the snippet below from our working PWM overlay explain our specific situation:
// This alone does not make pwm4 work. For some reason EPWM seems to be depending on
// something setup in the &cbass_main section of this overlay. Without whatever magic
// from &cbass_main, an attempt to use EPWM from an R5 will crash to the DAbt handler.
&bone_pwm_4 {
status = "okay"; // EHRPWM4-B on P9-25
};
&cbass_main {
#address-cells = <2>;
#size-cells = <2>;
/* TODO: the base for this should be in the board DT */
eqep0: qep@3200000 {
compatible = "ti,am3352-eqep";
reg = <0 0x3200000 0 0x100>;
power-domains = <&k3_pds 94 TI_SCI_PD_EXCLUSIVE>;
clocks = <&k3_clks 94 0>;
clock-names = "eqep0-ficlk";
count_mode = <0>;
swap_input = <0>;
invert_qa = <1>;
invert_qb = <1>;
invert_qi = <0>;
invert_qs = <0>;
};
eqep1: qep@3210000 {
compatible = "ti,am3352-eqep";
reg = <0 0x3210000 0 0x100>;
power-domains = <&k3_pds 95 TI_SCI_PD_EXCLUSIVE>;
clocks = <&k3_clks 95 0>;
clock-names = "eqep1-ficlk";
count_mode = <0>;
swap_input = <0>;
invert_qa = <1>;
invert_qb = <1>;
invert_qi = <0>;
invert_qs = <0>;
};
};
1 Like
I just started in on the device tree(s) for a project, and my head is spinning…From what I am seeing is they are trying to make one code base work with many boards. Pretty sure that is the problem, that makes all the coding confusing and too difficult to work with.
What my next attempt will be is to try and use the Ti sysconfig and the tools they are providing so I can get a grasp of what is happening. Plan is to just start out with dtb of exactly what our system requires. When I started out with the Ai64 it was assumed the ai64 had device trees for the capes, they don’t. I most certainly see the benefits of the overlays, however when you have a pin conflict the dts must be edited. Its not good to overly abstract low level functionality like this.
@foxsquirrel, Thank you for your comment. What I am hearing is that it may be best for us to create a single custom devicetree without overlays in order to adhere to the KISS principle. Is that the correct understanding?
My philosophy thus far has been to avoid customization at all costs to ensure we can simply apt-dist-upgrade to the next big Linux release. I think I am learning that for embedded, this is not a valid philosophy.
Again, thanks for your comments. This forum and this open discussion are extremely valuable. I will be watching your new “Has anyone had any success at working with Device tree for the AI-64” thread to continue to expand my knowledge. Please post how you make out with the TI sysconfig and other tools.
1 Like
I would agree with that for a custom board. Trying to follow device tress and all of the various includes makes reading devicetrees x10 harder than it should be. If you hardware is known and fixed there is no need for overlays.
1 Like
Yes, that is 100% correct.
Problem is so much of the stuff on the internet related to the single board computers and coding in general is presented as an infomercial. You are only spoon feed enough to make the promoters intentions appear sincere, yet the motive by those providing information is to sell their own services. If you could figure it out on your own, hence no need to “buy the services offered”.
That is very correct, however the capes and overlays are a good bond. If you are testing and need something quick and simple just modifying the uEnv.txt is something any one can do. However, when you need to deviate it becomes extremely difficult.
No I didn’t.