I wish to read the EUI64 address from an AT24MAC602 memory chip interfaced to an Atmega128rfa1 MCU over the Two wire interface. I tried to modify the I2C master drivers which are available for other platforms to suit my need. However, I wasn't able to carry out these modifications successfully as the program stopped responding as soon as the slave address was written to the twi bus with Write flag set. I failed to uncover the underlying reasons for the same.
As Contiki OS is quite popular, i thought someone might have already come up with contiki specific libraries for reading writing over TWI interface for Atmega128rfa1 MCU. If so, please provide pointers to the twi drivers or documentation for the same, or suggest factors that should be considered for developing such drivers. Thank you.
If you don't have any luck finding/creating a driver for the TWI peripheral, you might consider emulating it by configuring the SDA/SCL pins as general I/O and then implementing the TWI protocol yourself. If you're just doing a one-time read of a chip ID then speed probably isn't a big concern, so this could work if you get desperate. Google should throw up a few examples of emulated TWI.
Related
I need to develop device libraries like uBlox, IMUs, BLE, ecc.. from scratch (almost). Is there any doc or tutorial that can help me?
Question is, how to write a device library using C/C++ (Arduino style if you want) given a datasheet and a platform like STM32 or other ARMs?
Thanks so much
I've tried to read device libraries from Arduino library and various Github, but I would like to have a guide/template to follow (general rules) to write proper device libraries from a given datasheet.
I'm not asking a full definitive guide, just where to start, docs, methods approach.
I've found this one below, but is very basic and quite lite for my targets.
http://blog.atollic.com/device-driver-development-the-ultimate-guide-for-embedded-system-developers
I don't think that you can actually write libraries for STM32 in Arduino style. Most Arduino libraries you can find in the wild promote ease of usage rather than performance. For example, a simple library designed for a specific sensor works well if reading the sensor and reporting the results via serial port is the only thing that firmware must do. When you work on more complex projects where uC has lots to do and satisfy some real time constraints, the general Arduino approach doesn't solve your problems.
The problem with STM32 library development is the complex connection between peripherals, DMA and interrupts. I code them in register level without using the Cube framework and I often find myself digging the reference manual for tables that shows the connections between DMA channels or things like timer master-slave relations. Some peripherals (timers mostly) work similar but each one of them has small differences. It makes development of a hardware library that fits all scenarios practically impossible.
The tasks you need to accomplish are also more complex in STM32 projects. For example, in one of my projects, I fool SPI with a dummy/fake DMA transfer triggered by a timer, so that it can generate periodic 8-pulse trains from its clock pin (data pins are unused). No library can provide you this kind of flexibility.
Still, I believe not all is lost. I think it may be possible to build an hardware abstraction layer (HAL, but not The HAL by ST). So, it's possible to create useful libraries if you can abstract them from the hardware. A USB library can be a good example for this approach, as the STM32 devices have ~3 different USB peripheral hardware variations and it makes sense to write a separate HAL for each one of them. The upper application layer however can be the same.
Maybe that was the reason why ST created Cube framework. But as you know, Cube relies on external code generation tools which are aware of the hardware of each device. So, some of the work can be avoided in runtime. You can't achieve the same result when you write your own libraries unless you also design a similar external code generation tool. And also, the code Cube generates is bloated in most cases. You trade development time for runtime performance and code space.
I assume you will be using a cross toolchain on some platform like Linux, and that the cross toolchain is compatible with some method to load object code on the target CPU. I also assume that you already have a working STM32 board that is documented well enough to figure out how the sensors will connect to the board or to the CPU.
First, you should define what your library is supposed to provide. This part is usually surprisingly difficult. It’s a bit hard to know what it can provide, without knowing a bit about what the hardware sensors are capable of providing. Some iteration on the requirements is expected.
You will need to have access to the documentation for the sensors, usually in the form of the manufacturer’s data sheets. Using the datasheet, and knowing how the device is connected to the target CPU/board, you will need to access the STM32 peripherals that comprise the interface to the sensors. Back to the datasheets, this time for the STM32, to see how to access its peripheral interfaces. That might be simple GPIO bits and bytes, or might be how to use built-in peripherals such as SPI or I2C.
The datasheets for the sensors will detail a bunch of registers, describing the meaning of each, including the meanings of each bit, or group of bits, in certain registers. You will write code in C that accesses the STM32 peripherals, and those peripherals will access the sensors across the electrical interface that is part of the STM32 board.
The workflow usually starts out by writing to a register or three to see if there is some identifiable effect. For example, if you are exercising a digital IO port, you might wire up an LED to see if you can turn it on or off, or a switch to see if you can correctly read its state. This establishes that your code can poke or peek at IO using register level access. There may be existing helper functions to do this work as part of the cross toolchain. Or you might have to develop your own, using pointer indirection to access memory mapped IO. Or there might be specially instructions needed that can only be accessed from inline assembler code. This answer is generic as I don’t know the specifics of the STM32 processor or its typical ecosystem.
Then you move on to more complex operations that might involve sequences of operations, like cycling a bit or two to effect some communication with the device. Or it might be as simple as finding the proper sequence of registers to access for operation of a SPI interface. Often, you will find small chunks of code are complete enough to be re-used by your driver; like how to read or write an individual byte. You can then make that a reusable function to simplify the rest of the work, like accessing certain registers in sequence and printing the contents of register that you read to see if they make sense. Ultimately, you will have two important pieces of information: and understanding of the low-level register accesses needed to create a formal driver, and an understanding of what components and capabilities make up the hardware (ie, you know how the device(s) work).
Now, throw away most of what you’ve done, and develop a formal spec. Use what you now know to include everything that can be useful. Use what you now know to develop a spec that includes an appropriate interface API that your application code can use. Rewrite the driver, armed with the knowledge of how are the pieces work, and taking advantage of the blank canvas afforded you by the fresh rewrite of the spec. Only reuse code that you are completely confident is optimal and appropriate to the format dictated by the spec. Write test code for all of the modules, and use the test code to actually test that the code works and that it conforms to the spec. Re-use the test code every time you modify anything it tests.
I have bought a Gigabyte g1.guerilla motherboard and the NIC is a dedicated freescale chip on the motherboard. It is connected to the PCI bus.
I am running Linux and unfortunately there is no driver for it. I am working to write one, however I am hitting a basic problem: How to communicate and upload code to its dedicated CPU-RAM?
Much help appreciated.
I am running on ubuntu and the chip is a mpc8308vmagd PowerQuicc II pro
I don't know anything about your specific motherboard or the processor, but are you totally sure you need to upload any code to the processor?
Usually, if a peripheral needs any code (firmware), it's already present on a ROM or a flash chip and you only need to touch it if you specifically want to write your own firmware for it. AFAIK the way it usually works is that the peripheral exposes a set of registers on the PCI bus and you interact with it by poking the registers (usually with MMIO). That is, you don't write code for the peripheral, but you write a kernel driver that pokes the registers (ie. the API for the peripheral) when it wants the device to do something.
Now, in general the register descriptions aren't often freely available, which can make writing drivers really hard.
If you really want/need to write your own firmware for the thing, it probably depends on where the code is stored. If it sits in ROM or in an inaccessible flash, you'll probably need to do some soldering. If the firmware is updatable, I'd probably try to reverse-engineer the software they provide for updating the firmware, if one is available. (Unless it allows uploading arbitrary files already, of course)
I'm going to write an SPI driver for an ARM devlopment board. It is not used with Linux.
Yesterday, I read the QSPI driver that Xilinx provided and I tried it successfully. However, I would really like to write my own SPI driver.
Here are my questions:
What is the difference between QSPI and SPI on usage?
If I write a driver based on QSPI, will it work?
If I write a driver from scratch, what is the basic procedure (READ / WRITE / INITIALIZE)?
And finally, why must SPI send and receive at the same time?
Thanks everybody.
I think it may be easier to start with your last question first.
Why must SPI send and receive at the same time?
The easy answer is that it is part of the protocol. As data is shifted out on the MOSI line from the Master to the Slave, the data in the Slave's buffer is shifted to the Master on the MISO line. This allows the hardware to use a single register in each device for both the data being sent and the data being received. There is a good diagram of the process here:
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
The not so easy answer is that SPI is not a well defined standard. There are different types of implementation depending on the devices you are using. There is even a variant where the MOSI and MISO lines are combined and used in a bi-directional manner (3-wire SPI). However, most of the implementations I have dealt with send and receive over two different lines and that tends to be the standard methodology.
What is the difference between QSPI and SPI on usage?
QSPI or Quad SPI actually does not adhere to the standard methodology and breaks the concept of sending and receiving at the same time. It utilizes four bi-directional I/O lines to send and receive data and is often used for memory applications (because it is faster than SPI). With QSPI you are not sending and receiving at the same time.
If I write a driver based on QSPI, will it work?
Certainly! You just have to familiarize yourself with the hardware that you are using. Again, SPI is very different from Quad SPI and you can often find hardware implementations that make it very easy to use QSPI. For example, your Zynq 7000 has a QSPI Controller that has a lot of features to simplify the coding process. It will also operate in a "legacy mode" that acts as a normal SPI controller. On top of that, the Zynq 7000 has two other standard SPI controllers that are not setup for QSPI. I would highly encourage you to read the technical documentation here:
http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
If I write a driver from scratch, what is the basic procedure?
That is very hardware dependent. I did a quick overview of your hardware, but detailing the steps here would take far too long. However, the technical manual for your device appears to have great step-by-step instructions for configuring and using both the QSPI and SPI controllers. Here is an example from the SPI section:
17.3.1 Start-up Sequence
Example: Start-up Sequence
Reset controller: Assert and de-assert the Ref and CPU_1x resets, refer to section 17.4.1 Resets.
Program clocks: Program the SPI_Ref_Clk, refer to section 17.4.2 Clocks.
Tx/Rx signal routing: Refer to section 17.5 I/O Interfaces.
Controller configuration: Refer to section 17.3.2 Controller Configuration.
Interrupt configuration: Configure the ISR to handle the interrupt conditions. The simplest ISR
reads data from the RxFIFO and writes content to the TxFIFO. The PS interrupt controller is
described in Chapter 7, Interrupts. The interrupt mechanism for the SPI controller is described in
section 17.3.5 Interrupt Service Routine.
Start data transfers:
Master Mode operation select: Manual/Auto start and SS, refer to section 17.3.3 Master Mode Data Transfer.
Slave Mode operation, refer to section 17.3.4 Slave Mode Data Transfer.
I hope that helps!
I have project to do. Which requires that I use FPGA. The theme is, that I need to create a circuit in FPGA using VHDL which would perform some task like multiplication or division. And then I need to send the input data from PowerPC(Built in Microcontroller in Virtex 4) to that circuit and then collect the data from output of FPGA circuit using PowerPC. I have tried looking at the manuals but failed to understand the communication between FPGA circuit and Microcontroller.
Google didn't help too..
Please let me know, if there is a book or a better tutorial which can help me in this project. Thanks in advance for your concern.
Note: I am using Virtex-4 ml403 FPGA board.
Thanks Again.
Take a look at Xapp717 from Xilinx.
http://www.xilinx.com/support/documentation/application_notes/xapp717.pdf
In the introduction it specifically mentions what you are trying to do. The APU in this context refers to the PowerPC.
This application note introduces the APU and describes the main features of an APU-enhanced
system. Included examples illustrate how the APU transfers data between the processor and
the FPGA. The two examples are:
• A simple system that moves data from memory through the processor and APU, into
registers in the FPGA, and back into memory
Source code is included (Xilinx login required)
http://www.xilinx.com/bvdocs/appnotes/xapp717.zip
Our software Impulse C will automatically make the bus connection to the PPC. You're welcome to try it for free. If you are interested send your Ethernet MAC to me or to info at ImpulseC and we'll get you started.
Best,
Brian
Do you need to implement a multiplier/divider to accelerate computing using FPGA? If so, you should design a multiplier/divider with VHDL code. Maybe using Xilinx IP core is the most convenient way. All you need to do is specify the parameter you want (e.g. input numbers are 32-bit). Synthesize your design and assign input/output pins. Then you can transfer data between PowerPC and FPGA through these pins.
I am doing IO programming in C in Ubuntu. And I need the base address of the port to write data.
My laptop dont have a parallel port. So I bought a USB to Parallel port connector. I plugged in the device and its getting detected in /dev/usb/lp0
I ran "lsusb" to see the list of devices and I can see the ID also. But how can I get the base address ? For the usual hardware parallel devices, the base address is 0x0378. this address is not getting detected while using USB to Parallel device.
Please help.
A USB parallel port doesn't have a base address - it's not a meaningful concept for USB. I'm afraid the days of doing I/O on PC hardware via in and out instructions ended a few years ago, though lots of old tutorials still survive on the web.
You can write bytes to the parallel port as a character device, and these will appear on the printer port pins. The USB adapter will expect the other end to handshake data exactly like a printer. If you want to do general I/O prototyping, you're probably better off with a simple USB microcontroller like an Arduino.
Further discussion here.
If you are still interested to use this USB-to-parallel-printer device for your own bit-banging, it's important to know that their built-in firmware always allows controlling of D0..D7, INIT (as outputs), /ERR, ONL, PE (as inputs), but never for /ACK, BUSY (inputs), /STB, /AF, /SEL (outputs) pins.
And you need an 8-bit latch (e.g. 74HCT574) for catching data while strobing.
See here (https://www-user.tu-chemnitz.de/~ygu/bastelecke/PC/USB2LPT/faq#DIY)
especially for possible data rates.
Accessing from software side is a bit complicated but possible, and you may have to re-structure your software and hardware for making such adapters useable. I don't know for Linux case how to access, but IMHO you don't need to write a kernel-mode driver.