So I am trying to connect and then launch the SD card reader to Raspberry Pico using SPI1 and not the default pico one because the default one is taken by a LoRa module.
I am using the arduino core.
SPI1.setRX(12); // 16 12
SPI1.setTX(15); // 20 15
SPI1.setSCK(14); // 19 14
SPI1.setCS(13); // 17 13
I figured out this the way to define my SPI1 pins, but I still have no clue how to launch the SD card library on SPI1 and not the default SPI0.
I know that the defining code is right because I tested the SD card module on alternative SPI0 pins and it worked. I also asked the wise man that created the core how to do it and that's what he replied:
"There are 2 SPI port, SPI and SPI1. You can use the 2nd port, SPI1 at the same time as SPI. I don't think it's safe from the SPI protocol to change pins between transactions (glitches/etc. might upset the devices)."
But I still have no clue on how to run a SPI device on SPI1.
Related
For a fast ADC sampling USB device, I am using the USB 2.0 High Speed capable STM32F733 with the embedded USB-HS PHY. In USBView, I can see that the device is enumerated, the libusb code opens the device and claims interface, but when I try to receive data with libusb_bulk_transfer, the operation times out (return code -12). Things I have tried: I have confirmed than when I request data with libusb_bulk_transfer, the device is interrupted. Note: I have DMA enabled in my class configuration C file and it is not clear to me how that is triggered. I have verified that the transfersize and packet count registers are being set correctly by the LL library function, and that when I request data from
Any tips on debugging such problems will be much appreciated - this board is my undergrad thesis due in under two months!
Desktop sequence:
libusb_get_device_list, libusb_get_device_descriptor, libusb_open, libusb_get_string_descriptor_ascii, libusb_free_device_list, libusb_bulk_transfer(devh, fat_EPIN_ADDR, inframe, fat_EPIN_SIZE, &gotBytes, 100). Where gotBytes is integer, and inframe is a large array.
Device firmware:
MX_USB_DEVICE_Init();
uint8_t txBuffer[10*fat_EPIN_SIZE];
while (1)
{
USBD_LL_Transmit(&hUsbDeviceHS, Custom_fat_EPIN_ADDR, txBuffer, Custom_fat_EPIN_SIZE);
HAL_Delay(1);
}
Custom_fat_EPIN_SIZE is 0x200 and the endpoint address is 0x81 (EP IN 1)
Installed driver for device is WinUSB (verified in Device Manger to be winusb.sys), and I am linking libusb-1.0 into my desktop program. You can find my source code at https://gitlab.com/tywonemi-school-stuff/silicon-radar-fun, the firmware is My SW/v1 and the desktop software is a Qt Creator project in My SW/Viewer, of note is usb.cpp. You can also compare with testing project/HIDTest, which is code that I tested with STM32F303 nucleo dev board where I was able to read an array through IN bulk endpoint with the Viewer application. However, F3 has the USB peripheral, while F7 has OTG_USB, and I am now attempting USB 2.0 compliant HS so there may be more protocol-based pitfalls. You can also find the output of the device descriptor etc from USBView in my SW/USBView_broken.txt
EDIT 1: I have found finally some concrete error in the STM32 behavior. The DMAADDR is set for EPIN 0x81, and never increments, despite the DMA being enabled. I have went through literally every occurrence of the word "DMA" in the USB_OTG periphery.
I thought it might be that my linker script makes my array be stored in DTCM or similar, and the OTG DMA can't access it, but the address of txBuffer is 0x2003EBEC which is in SRAM2. The AHB matrix in the reference manual clearly shows, that the USB OTG HS DMA is master for a bus that SRAM2 is a slave of. And DTCM is connected too. I will look for application notes for USB OTG HS DMA - it just seems to be refusing to copy data!
I have fixed my issue by disabling the DMA setting. I have re-read the relevant portions of the reference manual and still don't know how exactly the values propagate into the Tx FIFOs. It is possible that DMA-less operation will be a major bottleneck in my project, I might return to this later.
I am having troubles using an I2C sensor with the Beagle Bone Black (BBB). The BBB is running a newly flashed 18.04 Ubuntu image specifically for the BBB.
I wired the sensor (VIN, GND, SCL, SDA) to the corresponding I2C2 pins (4, 2, 19, 20) on the BBB using the below pinout.
The sensor is supposed to be using address 0x40, but scanning I2C2 (using i2cdetect -r 2) does not show the sensor.
I have tested this with two separate sensors as I thought at first I may have fried the original sensor somehow, but the results are the same. In fact, running the I2C2 scan command yields the exact same results when nothing is connected at all.
I have read in many places that I2C2 may not be enabled by default, but I assume it is enabled in my case as I can scan I2C2 without getting an error. Is this assumption incorrect? Again, this is a freshly flashed BBB, and I have not enabled/disabled anything - it should be in the default state.
I have also verified the connectivity of my wires between the sensor and BBB. The voltage between VIN and GND on the chip is 3.3V, so it is definitely being powered.
Why can't I connect to my I2C sensors using the BBB?
it could be that the source you are using is outdated or not a viable entry for i2c.
Also, you could use this command to make sure i2c2 pins are available:
config-pin p9.21 i2c
config-pin p9.22 i2c
This may work, also. If this does not work, please reply with your entire source.
Seth
P.S. Also, if you have time, you may want to get an i2c library to use if your software falls short of setting up your own i2c library. They have smbus2 you can install with pip and other i2c libraries out there still.
Here are a few things you should check (in random order).
List all I2C buses wich i2cdetect -l and try them all. Depending on the platform, the i2c bus number in Linux may be different from the peripheral number used in the datasheet and pinout. E.g. "I2C2" might be bus i2c-1 or i2c-3 in Linux).
Use an oscilloscope or logical analyzer to see if the SCL and SDA lines are being driven. If they aren't check the bus number as above. If they are, then check whether the device gives an ACK; if it doesn't, anything else will never work: double-check the chip slave address. There are cheap logical analyzers that you can buy and user with pulseview.
Simply load the Linux driver for your chip (see the kernel docs on how to do it from userspace for a quick test). Then see check if the device appears or use dmesg to see any kernel error messages while probing.
I have a ADRF6720-27 EVAL Board. It connects to the host PC using CY7C68013a; the board also has a 64Kb EEPROM 24LC641; ADRF6720-27 is a RF modulator which is programmed via its SPI pins connected to pins 33, 34 and 35 of CY7C68013a.
The evaluation software runs fine. What I want to do is to load a program into the EEPROM (24LC641) such that the board generates stepped frequency from 700MHz to 2GHz.
I suppose this can be achieved if the program drives the three GPIO pins (say 33, 34, 35 in CY7C68013a) to drive the SPI slave (ADRF 6720-27) using bit-banging.
Installing the FX2LP-USB software detects the board correctly. My question is: in the IDE Keil uVision, which header files do I include while writing the program? There are many files in a demo project like bulkloop.c, which ones do I modify and which ones should be left as it is for my own purpose mentioned in the 1st and 2nd paragraph?
Thanks
I am very new to zedboard. I have a zedboard running an Ubuntu image. I am trying to write a driver to run the OLED on the board. On board start-up the OLED on the board shows some display(Xilinx logo), therefore I am assuming it already has a driver. I have the following questions:
a) How is the OLED in the zedboard internally connected, is it through SPI, GPIOs or the PL. If it's through SPI/GPIOs then which pins?
b) Any tutorial or documentation that I can follow to create userspace drivers using SPI/GPIO for the OLED in the zedboard?
c) I have a redhat desktop, is there any SDk I can use to develop userspace drivers for the zedboard from my redhat desktop.
I have seen a lot of materials on the zedboard but none of them talks about how the OLED is internally connected. In one document it shows that it's connected to the PL. If that's the case then how can I write userspace drivers using the PL on the zedboard? I will be coding using C.
Appreciate your help and thanks in advance!
a) How is the OLED in the zedboard internally connected, is it through SPI, GPIOs or the PL. If it's through SPI/GPIOs then which pins?
First or second result for the web search "zedboard oled pdf" - http://zedboard.org/sites/default/files/ZedBoard_HW_UG_v1_1.pdf
then search for "oled" in it (page numbers of the pdf file, not printed in document):
page3: 2.4.4 OLED...... ... ...... 19
page4: 128x32 OLED Display
page5: ZYNQ XC7Z020-CSG484 OLED <- bus_of_5 -> 128x32 OLED
page20: 2.4.4 OLED
An Inteltronic/Wisechip UG-2832HSWEG04 OLED Display is used on the ZedBoard. This
provides a 128x32 pixel, passive-matrix, monochrome display. The display size is 30mm x11.5mm x 1.45mm. Table 11 - OLED Connections ... Interface
oled_pin symb EPP_pin Function
9 RES# U9 Power Reset for Controller and Driver
8 CS# N/C Chip Select – Pulled Down on Board
10 D/C# U10 Data/Command Control
11 SCLK AB12 Serial Clock Input Signal
12 SDIN AA12 Serial Data Input Signal
So, we know model of OLED UG-2832HSWEG04 (datasheet http://www.adafruit.com/datasheets/UG-2832HSWEG04.pdf with low-level details on data interface) and data connection; this is OLED with 1 serial data input and 1 serial clock.
Pinout pdf is http://www.xilinx.com/support/documentation/user_guides/ug865-Zynq-7000-Pkg-Pinout.pdf (too long to read), but there is shorter version of pin list in txt format: http://www.xilinx.com/support/packagefiles/z7packages/xc7z020clg484pkg.txt
Device/Package xc7z020clg484 9/18/2012 10:07:35
Pin Pin Name Memory Byte Group Bank VCCAUX Group Super Logic Region I/O Type
AA12 IO_L7P_T1_13 1 13 NA NA HR
AB12 IO_L7N_T1_13 1 13 NA NA HR
HR means "3.3V-capable high-range (HR) banks", both data pins are from "bank 13". Pin name is IO_* so it "supports both input, as well as output functionality", and is part of "PL Pins" (PL = programmable logic = FPGA). Default Zedboard firmware of FPGA part gives access to this pin to the ARM part of chip with linux kernel (PS = processing system = ARM) by routing it to some internal processing_system GPIO pin via system.ucf file like:
NET processing_system7_0_GPIO_pin[5] LOC = AB12 | IOSTANDARD="LVCMOS25"; # "OLED-SCLK"
NET processing_system7_0_GPIO_pin[6] LOC = AA12 | IOSTANDARD="LVCMOS25"; # "OLED-SDIN"
Then the GPIO pins are registered in devicetree (dts) https://github.com/Digilent/linux-digilent/blob/master/arch/arm/boot/dts/digilent-zed.dts in zed_oled group:
zed_oled {
compatible = "dglnt,pmodoled-gpio";
/* GPIO Pins */
vbat-gpio = <&ps7_gpio_0 55 0>;
vdd-gpio = <&ps7_gpio_0 56 0>;
res-gpio = <&ps7_gpio_0 57 0>;
dc-gpio = <&ps7_gpio_0 58 0>;
/* SPI-GPIOs */
spi-bus-num = <2>;
spi-speed-hz = <4000000>;
spi-sclk-gpio = <&ps7_gpio_0 59 0>;
spi-sdin-gpio = <&ps7_gpio_0 60 0>;
};
b) Any tutorial or documentation that I can follow to create userspace drivers using SPI/GPIO for the OLED in the zedboard?
According to Avnet's Getting Started pdf, "Demo 2 – OLED Display" scetion on page 17 (web searched as "zedboard oled") http://zedboard.org/sites/default/files/documentations/GS-AES-Z7EV-7Z020-G-14.1-V6%5B1%5D.pdf#page=17 there is kernel driver pmodoled-gpio.ko (on screenshot it reported as "pmodoled-gpio-spi"), so OLED is driven with GPIO pins.
There are two helper scripts: unload_oled to remove the kernel module and load_oled to insert it into kernel. Driver will create special device file /dev/zed_oled to work with display from user-space and load_oled also displays the /root/logo.bin file using this zed_oled interface.
Typical usage of zed_oled is like cat yourfile.bin > /dev/zed_oled, for example http://people.mech.kuleuven.be/~lin.zhang/notes/emebedded-linux/zedboard-oled-display.html and better http://zedboard.org/content/zedboard-oled
The .bin file format. ... The screen is written to right to left, top to bottom with each pixel being represented by a bit within one of the bytes within the .bin file. Bits are read-in top down 8 pixels then move over 1 pixel and write the next 8 bits and continue until you are at the end of the row. Then move down 8 pixels and do this again 3 more times.
You can do writes from C application, check code from http://www.cnblogs.com/popo0904/p/3853144.html (you can use online web translation services to read the text)
Documentation on the kernel module PmodOLED used in standard zedboard demo: https://github.com/Digilent/linux-digilent/blob/master/Documentation/pmods/pmodoled.txt
The driver provides a 512 Byte display buffer for the display of PmodOLED.
The Whole screen is divided into four lines, each of them is 128 bits wide
and 8 bits high, as shown in the figure below.
+--------------------------...----------------------------+
+ Line 4 +
+--------------------------...----------------------------+
+ Line 3 +
+--------------------------...----------------------------+
+ Line 2 +
+--------------------------...----------------------------+ MSB (bit 7)
+ Line 1 +
+--------------------------...----------------------------+ LSB (bit 0)
byte 127 byte 0
Users can perform read and write functions to the device node to access the data
inside the display buffer.
And there is source code of the dirver: https://github.com/Digilent/linux-digilent/blob/06b388903e5459687ba2538ae3895ffe29e2e39e/drivers/pmods/pmodoled-gpio.c
c) I have a redhat desktop, is there any SDk I can use to develop userspace drivers for the zedboard from my redhat desktop.
The standard driver is kernel-space for this OLED on ZEDboard, you can use it from precompiled ZEDboard firmware. Or you can build the kernel according to zedboard instructions, all in-kernel drivers will be built too (if enabled in kernel configuration): http://zedboard.org/content/creating-linux-kernel-image-boot-zc702-sd-card-slot
What is the Difference between BGAPI and BGScript ?
And if we write any code for BG profile than how can we burn it in BLE 112?
The BGAPI interface defines the protocol used to talk to the module over USB or serial link.
BGScript is something which runs on the module processor itself, when the USB or serial link is not used.
I have the dongle, BLED112, which is the same thing as BLE112 with a USB connector on it, and the code is "burned" to it using standard USB DFU interface.
The downloading of the code to BLE112 can be done using several methods:
(1) Bring out the DD, DC debug interface pins from your module and use the CC-Debugger (digikey part 296-30207-ND, $55). This works every time. If you have the DKBLE112 kit, the CC-Debugger fits on the 10-pin .050 connector in lower right corner. You can "burn" any firmware and any stack this way. Works awesome.
(2) Hope that the current firmware on the CC2540 has serial bootloader, and load the new firmware (hopefully also containing serial bootloader) using UART. TI has the tools, but it sure seems quite convoluted to me, and I did not try it.