How can I configure one pin for input and another for the output?
If I am not wrong this could be done with GPIO registers that controlls device pins that are not connected to peripherical functions.
Look in UM10360.PDF, Chapter 9: GPIO. There you can find the description for the FIOxDIR direction registers, as well as the reigisters for querying, setting and clearing GPIO pins.
I also strongly recommend looking at the CMSIS Standard Peripherial Driver Library that NXP offers for 175x/176x, look in microcontroller support documents. Edit: There are lots of sample code in this Library.
https://github.com/dwelch67
I have a number of lpc based examples. You are looking for the IODIR register, depending on the port and flavor of LPC, there are now what they call fast I/O registers. a one in a bit location means that pin is an output, a zero an input.
Related
I'm setting up a Raspberry Pi 4b with a number of Adafruit chips, and thus have used their CircuitPython library to control SPI communication. They've conveniently set up a way to use any GPIO pins as chip selects, but as a result I had no idea that there are two hardware chip selects on the Raspi (CE0 and CE1 on GPIO8 and GPIO7 respectively). I have already wired these pins (GPIO7&8) with the intention of using them as GPIO outputs, but I've noticed I GPIO8/CE0 is connected to the SPI clock.
Adafruit actually mentions that the NO_CS flag doesn't work in their documentation, and I can't seem to find anything useful online.
How can I disable the hardware CS pins? I know the SPI_NO_CS flag in SPI_MODE is already a bug in the spi-bcm library, and I found this patch, but I'm not sure if it would work (I think CircuitPython utilizes a hardware CS?), let alone how to apply it.
Maybe I am asking the wrong question actually but I am just making my first steps in the embedded world. So I am sorry if the question is somehow stupid.
I am trying to program a software for 9DOF IMU in c++ and linux environment.
As far as I understood the SPI, the SS pin has to be low active in order for a transmission to occur. I have seen multiple reading or writing bytes function examples and all using the struct spi_ioc_transfer but they were all single slave examples and there is no mention about setting or configuring the SS in the code. Also When I check the structre of spi_ioc_transfer there is the cs_change however, how does it know which cs we are dealing with from the beginning ?
The chip select (CS or SS) to use is determined by which device node you open.
To talk to a SPI chip with the Linux spidev driver, you open a device such as /dev/spidev0.1. The numbers in the device node file name refer to the bus and chip select, respectively — in this example it would be the first bus (0) and the second CS (1). If you want to talk to devices on different chip-selects, you have to open different device nodes and do ioctls on the appropriate one.
I am trying to write a verilog code for FPGA which will output sound from the embedded "line out" pin. I use Quartus II and Altera DE1.
I am new to hardware programming, therefore it just takes too much time for me to catch up with basics. Apparently I need to initialize the wolfson chip and need to write something to communicate with it, as discussed here:
http://www.alteraforum.com/forum/showthread.php?t=6005
It uses wolfson WM8731 codec, manual is in here:
http://www.rockbox.org/wiki/pub/Main/DataSheets/WM8731_8731L.pdf
and an example I found but couldnt figured out how to use it is in here:
https://code.google.com/p/vector06cc/wiki/SoundCodec
I have found bunch of examples about how to generate sounds using GPIO pins, but barely anything about the usage of WM8731. I would really appreciate any guidance or experience you might share.
Assuming you're using Nios II and either SOPC Builder or Qsys, the Altera University Program offers an IP core to control the Audio CODEC on the DE-Series boards.
If you don't already have it, you can download it here (at the bottom of the page, listed as University Program Installer): https://www.altera.com/support/training/university/materials-ip-cores.html
Once you install it, check the <altera-directory>/University_Program\NiosII_Computer_Systems\DE1\DE1_Media_Computer directory. app_software and app_software_HAL both give example methods to write to the audio output (using C code running on the Nios II), and the verilog or vhdl folder show example systems on connecting the core to a NIOS II using your preferred HDL.
The core itself can be found in <altera-directory>\ip\University_Program\Audio_Video. See also ftp://ftp.altera.com/up/pub/Altera_Material/14.1/University_Program_IP_Cores/Audio_Video/Audio.pdf for some (potentially) helpful reading/reference.
Addendum:
All of the FPGA inputs and outputs use the "Digital Audio Interface" of the WM8731 chip. The pins available on the FPGA are as follows:
PIN_A6 : AUD_ADCLRCK
PIN_B6 : AUD_ADCDAT
PIN_A5 : AUD_DACLRCK
PIN_B5 : AUD_DACDAT
PIN_A4 : AUD_BCLK
PIN_B4 : AUD_XCK (MCLK on WM8731)
Output is sent to the CODEC on the AUD_DACDAT pin.
The chip is configured using the I2C_SDAT and I2C_SCLK pins on I2C address 0x34 for read, and 0x35 for write.
No other pins are available to the FPGA - some are used for external connections (like the mike or line-in), or are not connected at all.
For a full list of pin assignments for the DE1 (which can be directly imported to Quartus) see: ftp://ftp.altera.com/up/pub/Altera_Material/12.1/Boards/DE1/DE1.qsf
I'm using a Virtex 5 FPGA and want to have a few +5/0 I/O pins to communicate with a microcontroller. The only peripherials I've used on the board so far are pushbuttons and switches and no one I've asked seems to know the simplest way to do this I/O. I've looked around the board specification but haven't found any simple way of doing it. I would appreciate any advice you might have.
This is not an easy thing to do. If you don't have the schematic of the board, then you need to get volt meter with some fine pitch probes and reverse engineer the board.
It is pretty easy if you have 2 boards, with one board it can be really hard since the BGA signals may not be connected to a via and therefore not available on the bottom of the board, and even if they are, then you don't know exactly which pin they are connected to. But with some luck, you can find them since the VIA can only be connected to 4 possible pins surrounding it!
The first thing you need to do is to identify your chip, find the BGA print of the IC from Xilin'x web site.
If your board has some buttons already, then if you are lucky, those signals may be routed to the pins of the FPGA that are available on the bottom of your board. Here are the things you need to do:
Make sure you have good ESD protection to perform these test
Put your voltmeter into 'buzzer' mode
Check the pins of your connector and find out how it is connected, see if there is a pull-up and/or pull-down resistors on the board
when you find the 'active' pin of your connector, start connecting the other probe to the VIAs one by one
When you hear a buzz, make a note of the position (guess or measure the distance between the side of t he IC and the location of the via)
Identify the 4 possible pins that the signal can be connected to
Write a code to get all those 4 signals and connect them to ChipScope
In Chip Scope, capture all 4 signals and see which one is the one with the right connection!
alternative, you can create a design with inputs only, capture all the inputs and put them into a memory block and create a trigger logic to capture all the signals whenever any of the inputs changes, after lots of work and analysis, you will find the correct pins.
Anyway, these are just crazy ideas since this is a really difficult thing to do without having the PCB info of the board.
Good luck with your hacking.
I have a device that takes low current 3-12v input signal to do it's magic and I would like to interface it to my linux box. What kind of options do I have on this? It would be great to have some low-cost possibly user-space solution.
If I understand right, you need to control your box by changing 3-12v input signals to it. Here's the choices I can think of from the top of my head:-
a: Using RS232 serial handshake lines. RTS/CTS can usually controlled programatically as "on/off" signals without driver development using IOCTL calls.
b: Use a "GPI dongle" such as the Advantech ADAM range. These typically take serial or TCP/IP inputs and convert them to suitable output signals.
c: You may be able to do something with a parallel printer port if your PC stil has such a thing.
As shodanex says, be aware that RS232 levels are NOT directly compatible with TTL/CMOS inputs so you may need some minor level shifting/clamping electronics to fix this.