I am learning about the Microblaze processors and i don't really understand that while using the gpio functions.
This simply means that you have a second, independent GPIO on the same peripheral.
It's like having 2 different GPIO peripherals, but without the burden of allocating another one (with associated bus attachment logic duplication, etc..)
The Xilinx GPIO peripherals have always been like this, back from the OPB bus ones, to the PLB bus, and then, now, with the newest AXI bus peripherals.
You would have answered yourself by reading the peripheral documentation. (Hint: on Chapter "Register Space", page 10, you see a second set of registers, named "GPIO2_*", which are available only when "dual channel" is enabled)
Related
While I'm not new to embedded programming, I'm new to the Atmel SAM3X microcontroller. I'm trying to figure out if it's possible to use DMA to read a value from a memory-mapped register (a GPIO port, in this case) into a buffer periodically at say 1/4 the clock rate (faster than can be accomplished by software copying or software triggering of DMA), then turn the buffer over to the USB DMA to send it out the USB cable.
I see that PWM is one of the peripherals that can perform DMAC "transmissions", and I also see that the DMA channel registers have separate spots for source address and source peripheral identifier. Are the address and peripheral identifier independent and potentially co-operational? Could you use PWM as the source peripheral as a clock divider but then copy from the port data address? If so, how might this be accomplished in terms of register writes (I ask to try to circumvent the need for trial and error); if not, is there any other way of sampling a memory location at regular high but sub-clock speeds?
There are limitations in the ESP SDK libraries (which are not public) like for example the length of the packet recv (112bytes max) when in promisc mode.
I tried reaching them to get some input and directions - but they seem to be replying nonsense.
Is it possible to program the chip without the SDK - thus make my own SDK and forget their limitations?
The processor-core on the esp8266 is an 'xtensa'. The processor-core, or let's just call it the processor, is what we program with C or C++ or assembler. The processor's instruction set is made public by the company (which is Tensilica .. or Cadence??) and once you have the instruction set, you can program directly or make a compiler and have complete freedom with the processor.
The processor-core is not the complete product and for us end-consumers, and companies, like Espressif, buy the Intellectual Property rights to a processor-core's design and build an end-product by putting peripherals like SPI, I2C, UART and in the esp8266's case, the wifi-tranceiver, around the processor-core.
These peripherals are controlled digitally, and output to the processor digitally, so the processor can interface with them - but their action can be either digital or analog. For UART, SPI, I2C etc, espressif has provided us with the datasheet that informs of all the registers that can be used to control that peripheral. It's something like write to this X memory address what you want to transfer and then set the bit Y on the Z memory address to begin the transfer. For SPI for example, there are registers to control speed, polarity, phase etc for a transfer. Once you know how to control a peripheral at the lower level, you can write high level drivers, which espressif does provide too, but you can write your own.
For Wifi, espressif hasn't released how the peripheral can be interfaced with, so we have to depend upon the compiled binaries that espressif sends us. You can use 'objdump -t' on the 'lib/lib80211.a' to get atleast the names of the routines that the Wifi driver provides. You can call these routines from C or assembler code and go a little bit lower than espressif intended but to go any lower would require 'Reverse Engineering' by manually understanding the low level code in the compiled Driver and nobody's gonna take that risk and time-drain.
I have a DE1-SoC Board and would like to experiment with it.
(Board description:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=836&PartNo=1)
My wish is to incorporate non-volatile storage.
As for a start, implementing the following exercise would make me happy:
When the board is turned on, the integer stored in memory should appear in
readable format on HEX LEDS.
So far I have implemented the "ability" to change the value of HEX LEDS using extra buttons connected to board. However, if the board is turned off, the whole "ability" is gone. I then need to reconnect the board to my PC and re-download the binary code to FPGA. In addition to that, the value stored in LEDS is also reset to default. I would like to avoid having reconnect my FPGA to computer.
How to start working on this?
Looking at board documentation for memory:
64MB (32Mx16) SDRAM on FPGA
1GB (2x256Mx16) DDR3 SDRAM on HPS
Micro SD Card Socket on HPS
Does it mean that DE1-SoC has no non-volatile storage incorporated? If it does, how to access it?
I also have all pin assignments of the board in a single file "de1soc_pin_assignments.qsf"
Can I connect external SD card to "Micro SD Card Socket" and use it as a flash? Is it possible to "boot" the binary code from SD card to FPGA (as well as the integer number to LEDS)? If yes, which pin should I use for that?
Thanks a lot for your help in advance
The DE1-SOC includes an EPCS128 configuration flash, which can be used to store the bitstream for your design. See page 105 of the DE1-SOC user manual ("Programming the EPCS Device") for details on how to convert a bitstream to the appropriate format and store it on the flash chip. Once you've done so, the FPGA will "boot" into that bitstream when powered on, without needing to be plugged into a computer.
The configuration flash cannot easily be used to store other data, such as the state of your LEDs. It might be possible to store this data on an SD card, but doing so will not be an easy task, as SD cards require a complex initialization process before they can be accessed.
I'm using an ARM Cortex M4 and I want to ask if it's possible to unload main routine form communication tasks and let them run in background.
For example I'm using on ARM MCU this peripherals:
ADC
I2C
UART
SPI
When adc_start(ADC); is called, ADC start conversion in background so I don't need to wait until ADC has finished conversion and I can go to the next istruction and later read the ADC result.
I want to ask if it's possible to do the same with communication periphericals. I2C and SPI can be fast, but since this MCU types can reach 50Mhz and more, it's a waste of MCU speed if I need to wait until I2C have finished to trasmit at 400kHz or SPI at 20Mhz or worst with UART. Also, if I perform some tasks and I don't want to interrupt them, I need to be able to unload MCU from any interrupts from peripherals and let them recive packets, buffer them and when I need to read them.
Something like this is possible?
If I've understood the question correctly, you're looking for automatic interrupt based handling of fast communication peripherals such as the I2C and SPI. As far as I know, YES! its achievable, at least on the Texas Instruments TIVA based ARM CORTEX M4 series MCUs. It's quite a nifty little feature to have around when you're working on computationally intensive algorithms and not have the CPU bogged down on waiting for the SPI to finish its task.
For a good reference on programming the CORTEX M4 peripherals, I recommend keeping this book handy:
http://www.amazon.com/TI-ARM-Peripherals-Programming-Interfacing-ebook/dp/B00L9DRAI2
Table 6-7 in chapter 6 of the book details the interrupt vector table on the TM4C123G MCU (the one shipped with the TIVA launchpad). Interrupts 50 and 53 are assignments for the SSI/SPI and I2C peripherals respectively. Process should be fairly straight forward once you unmask the right interrupts.
Is it possible to do DMA transferts with the IP core «Cyclone V Avalon-MM for PCIe» provided by altera in Qsys (quartus 14.0) ?
Altera provide an ip-core named «Cyclone V Avalon-MM DMA for PCIe» to do dma transfert. But this ip-core does not support PCIe Gen1 with 1x lane.
The demo (ep_g1x1) design for «Cyclone V Avalon-MM for PCIe» include a DMA block that is connected on Avalon-mm TX bus of PCIe ip-core.
Then I'm wondering if it's possible to write data from this DMA block to the root-complex (host) ? Because I can't find how to do that.
From my brief skim of the material, it should be possible to issue DMA reads or writes from an RC to your Cyclone V (EP) using the IP core you're interested in.
I've done DMA reads and writes on a Stratix V, however it was in a non-Qsys design just using the PCIe core HIP block (custom TLP encoding and decoding logic). This block just seems to be a wrapper around their PCIe HIP block that also handles the transaction layer for you.
The first step will be to get your RC to issue PCIe DMA read or writes requests. In the case of a read request, you'll want to send a memory read complete with data (CplD) request with a length greater than 1 DWORD. I would suggest dedicating an entire BAR to map the memory space you want to DMA from on the FPGA to keep your address targeting simple.
On the FPGA side, I would suggest using Signal Tap and probing the Rxm* interface signals on the core. This way you can see the exact timing of the DMA read request that comes out of the core. My guess is that the RXMRead_<n>_o signal will go high indicating the start of the request. At which point you'll have to decode and pass the RxmAddress_<n>_o and RXMBurstCount_<n>_o to some glue logic that will fetch the requested data from the FPGA's memory. Once you're ready to send back the data, assert the RXMReadDataValid_<n>_i for each valid word being sent.
I'm guessing that the «Cyclone V Avalon-MM DMA for PCIe» core that you referenced takes care of that 'glue' logic I mentioned for you, and allows you to connect straight to a SDRAM controller on your Qsys bus. Altera doesn't usually encrypt their megafuction code, so if your system verilog is strong, it might be worth digging through their generated files and seeing if you can reuse that bit of code in some way.
As for core settings, the only thing that I saw that you need to look out for is making sure the Single DW Completer setting is turned OFF. Otherwise the core will abort any requests it receives with a length greater than 1 DWORD.
Hope that helped somewhat.
I finally managed to make DMA request with the «Cyclone V Avalon-MM for PCIe» altera core-ip. Then yes it's possible.
On my Linux system, rootcomplex (RC) is included under i.MX6 with Linux operating system. Then most of the tricks are on the Linux side in fact.
Under the Linux driver a PAGE must be requested with dma_alloc_coherent() call and the address of this page must be written on the CRA register named ADDR_MAP_LO0 and ADDR_MAP_HI0.
On my system, memory pages are 4k sized, then I had to configure the «address translation settings» of the PCIe hard ip with pages of 4k to be coherent.
Once that done, I simply connected the DMA controller provided by Qsys on the TX avalon-MM slave port of PCIe IP.
Telling the DMA to write data on this port will automatically generate TLPs from the FPGA to write on i.MX6 ram.