I am attempting to connect my Launchpad device to the Pololu MinIMU9v2 9DoF sensor via the I2C bus. I am working in a Linux environment, compiling with arm-none-eabi-gcc, and I have downloaded the sw-ek-tm4c123gxl zip file from the Texas Instruments website.
In digging through the drivers download, I identified a folder (examples/peripherals/i2c) that contains 3 demonstrations (each in a single C file) for using the I2C bus. One runs the Launchpad as a slave, the next configures it as a loopback, and finally, there is one that interfaces the Launchpad with an Atmel I2C-based memory device using what it refers to as "soft I2c".
I'm assuming that the "soft" part of this means that it's software based, utilizing interrupts and all. I'm looking for a simpler solution, preferably without interrupts. The loopback example worked like a charm, for instance, but in modifying it, I can't seem to get it to communicate with the MinIMU9, no matter what I try. The documentation for the MinIMU9 is pretty clear, but I think I'm just lacking an understanding on how to use this driver software.
Finally, I don't want to reinvent the wheel, but I can't seem to find any one else talking about I2C and the stellaris or tivac launchpads. Am I way off the mark in trying to implement this in this way? If not, is there an easier way to go about this? And, if not, where can I learn more about whatever it is that I'm missing?
I was able to figure it out after all. One thing that I hadn't noticed in the first place is that Texas Instruments provides a PDF peripherals resource that discusses the usage of their driver library. Unfortunately, this documentation is far from comprehensive, and probably would have still required someone to bury themselves in the code were it not for the examples.
Now, the peripheral examples required a bit of work to get going. To save some time and effort, I tried copying master_slave_loopback.c over the top of examples/project/project.c, modified it according to the comments within the file, and then I was able to compile the example and run it with immediate success.
Next, I attempted to convert the new project.c file into something that would allow me to communicate with the MiniIMU9v2. Everything seemed straight forward for the most part. I commented out anything that looked like it was related to loopback functionality, but when I would try to execute the program, it would hang on the following line:
while(I2CMasterBusy(I2C0_BASE)) { }
Overwhelmed with what I might have to do to begin troubleshooting this, I decided to post this question. Fortunately, the problem was a lot simpler and surprising to solve than I had suspected. A quick search revealed this page: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/316580.aspx
I changed:
GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_2 | GPIO_PIN_3);
To:
GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);
And this solved my problem.
Related
i want to create new library for my e-paper using atmega32 and eclipse enviroment. What do i have to know about it moreover how it works. I dont want to use arduino libraries, want to write it on my own. How to best start making it? I know how to use SPI, what commands do i have to send to display, but do i have to have any drivers which are necessarily? Is any possibilty to program it using only this module:
https://www.waveshare.com/1.54inch-e-paper-module-b.htm
and SPI? Or it is necessary to have some drivers to do it?
Your question a little bit strange, because "driver" is usually piece of code, written by a third person. So, answer is yes - it is always possible to do it from scratch, without using third-side software.
First what you need to know is what type of controller being used in that display, to get technical documentation (datasheet). Unfortunately, there is no such information, but there is a link to the specification document: https://www.waveshare.com/w/upload/9/9e/1.54inch-e-paper-b-specification.pdf
Read it carefully. For example at page 8 you can find the list of commands, which are used to control the display, and below the detailed description of the commands.
At pages 24, 25 you can find initialization sequence, and reference flowchart.
If any doubts, you can download and investigate how third-party libraries are done. For example here: https://github.com/waveshare/e-Paper
Does anyone know how to implement the example of TrustZone running "Secure world" and "Normal world" given on the ARM documentation website below on the ZedBoard? Any documentation on this subject (running TrustZone on the ZedBoard) would be also helpful.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15417.html
The ZedBoard has a Xilinx : Zynq® -7000 All Programmable SoC Dual ARM® Cortex™-A9 MPCore™. More information on the ZedBoard can be found here:
http://www.zedboard.org/content/overview
This is a broad topic. Hopefully some of the following information will help.
First off just to de-jargon a little, SOC == system-on-a-chip.
Digilent, the board's manufacturer, has some support files for your board if you have access to the Xilinx toolchain. So first, if you go to http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1028&Prod=ZEDBOARD , at the bottom, you will find two files named "Linux Hardware Design for ISE" <version number>.
Also assuming you are using the Xilinx development tools, if you browse to Xilinx/<Version Number>/ISE_DS/EDK/hw/XilinxProcessorIPLib/pcores/axi_interconnect_v1_06_a/doc/ds768_axi_interconnect.pdf , you will find information on the AXI interrupt controller your board uses. This includes the fact that it supports TrustZone and some information on actually using it.
Next, if you go to http://zedboard.org/content/creating-custom-peripheral, you will find some instructions on making a "peripheral" device. I put this in quotes because the device in fact exists completely within the programmable logic; it's not something you plug into the micro usb port or what you'd traditionally think of as a "peripheral".
At the end of the tutorial, there is also a link that will help you read data from your peripheral.
If you repeat all those steps with the system.xmp file included in the zip you initially downloaded, then you'll notice all the heavy lifting has been done for you. You have a plugged in and ready to go interrupt controller on the AXI bus already that works with TrustZone, just ready and waiting for you to hook a little hello world device to it.
But what are you going to do with that hello world device? If you look in the assembly for the tutorial you linked to, you'll see in the comments they talk a lot about something called the "Secure Configuration Register". If you look in your processor's documentation (in the resources section here, http://www.arm.com/products/processors/cortex-a/cortex-a9.php) and search for the term "TrustZone extensions" (currently page 34 although obviously that's subject to change), you'll find a link to another page detailing this register. This is the same register they use in the tutorial, so in theory, if you have a trusted execution environment set up, you can now make the hello world tutorial work (mostly; you're going to likely want to do what they do in assembly with either vhdl or verilog code and just expose the results somewhere easy to read in C).
Now everything I have just mentioned will merely get you access to the TrustZone data in the AXI bus. In order to do anything interesting with this, you are going to have to actually create a secure world and normal world to read from. Otherwise any demo you put together will merely print "Hello from Secure World" (or function incorrectly). So this is where unzipping that tutorial you linked to and really reading their source will pay dividends.
Although my answer up until now is also incomplete, as the Hello World tutorial you linked isn't designed to teach you how to create Normal World (and possibly Monitor World) to begin with. Which it says explicitly in the ReadMe.txt . So reading the source won't help you with that. For that, you're going to need the link http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/index.html . There's a lot of info there but it's intended as a reference and the first two chapters, in my humble opinion, are just what I like to call "skipable flavor text". Although if you do have time to waste some of it is fascinating and informative as far as security theory in general. Chapter 3 will begin to teach you how to develop for TrustZone.
But hopefully the information I provided will turn this into less of a permissions problem for you and into more of an education problem. I'm still educating myself on this stuff.
This is not a homework problem, though it is a work problem. Where months ago, I would have just written up a specification and the boss would have contracted it out, money's tight. So I'm trying to do this myself.
I'm a weak C coder, and I'm lucky if gcc spits out something that will run without segfaulting, or sometimes anything at all. Still, I manage. Libftdi is built, I've carefuly perused both its example executables/code, and the documentation. But I'm still lost.
Does anyone know of a software project that makes use of its MPSEE mode, that's hooked into an SPI device? Is anyone here slick enough to provide an example? I could really use the help. I don't need this handed to me on a silver platter, but I'm having trouble even getting started. If I could even figure out how to initialize it and send a byte to the chip on the other side of the FTDI ic, I think I might manage to muddle my way through it.
Any help appreciated.
Flashrom can use FT2232 SPI mode: http://flashrom.org/Downloads
Background:
I am developing a largish project using at Atmel AVR atmega2560. This project contains a lot of hardware based functions (7 SPI devices, 2 I2C, 2 RS485 MODBUS ports, lots of Analogue and Digital I/O). I have developed "drivers" for all of these devices which provide the main application loop with an interface to access the required data.
Question:
The project I am developing will eventually have to meet SIL standards.
I would like to be able to test the code and provide a good level of code coverage. However I am unable to find any information to get me started on how such a testing framework should be set up.
The idea is that I can have a suite of automated tests which will allow future bug fixes and feature additions to be tested to see if they break the code. The thing is I don't understand how the code can be tested on chip.
Do I require hardware to monitor the I/O on the device and emulate externally connected devices? Any pointers that could be provided would be highly appreciated.
--Steve
This is a very good question - a common concern for embedded developers. Unfortunately, most embedded developers aren't as concerned as you are and only test the code on real hardware. But as another answer pointed out, this can basically test just the nominal functionality of the code and not the corner/error cases.
There is no single and simple solution to this problem. Some guidelines and techniques exist, however, to do a relatively good job.
First, separate your code into layers. One layer should be "hardware agnostic" - i.e. function calls. Do not ask the user to write into HW registers directly. The other (lower) layer deals with the HW. This layer can be "mocked" in order to test the higher level. The lower level can not be really tested without the HW, but it's not going to change often and needs deep HW integration, so it's not an issue.
A "test harness" will be all your high-level HW agnostic code with a "fake" lower level specifically for testing. This can simulate the HW devices for correct and incorrect functionality and thus allow you to run automated tests on the PC.
Never run unit tests on or against the real hardware. Always mock your I/O interfaces. Otherwise, you can't simulate error conditions and, more importantly, you can't rely on the test to succeed.
So what you need is to split your app into various pieces that you can test independently. Simulator (or mock) all hardware that you need for those tests and run them on your development PC.
That should cover most of your code and leaves you with the drivers. Try to make as much of the driver code as possible work without the hardware. For the rest, you'll have to figure a way to make the code run on the hardware. This usually means you must create a test bed with external devices which respond to signals, etc. Since this is brittle (as in "your tests can't make this work automatically"), you must run these tests manually after preparing the hardware.
Vectorcast is a commercial tool to run unit tests on the hardware with code coverage.
Do you have a JTAG connector? You may be able to use JTAG to simulate error conditions on the chip.
I like to separate the tasks. For instance, when I made a circular buffer for my Atmel AVR I wrote it all in Code::Blocks and compiled it with the regular GCC compiler instead of the AVR GCC compiler, then I create a unit test for it. I used a special header file to provide the proper data types that I wanted to work with (uint8_t for example). I found errors with the unit tests, fixed them, then took the fixed code over to AVR Studio and integrated it. After that I used wrote support functions and ISRs to fit the buffer into useful code (ie, pop one byte off the buffer, push it into the UART data output register, append a string constant to the buffer for a printf function, etc). Then I used the AVR simulator to make sure that my ISRs and functions were being called and that the right data showed up in registers. After that I programmed it onto the chip and it worked perfectly.
I greatly prefer the debugging capabilities of Code::Blocks compared to AVR Studio so I use the above approach whenever I can. When I can't I'm usually dealing with hardware only. For instance I have a timer that automatically produces a square wave. The best I could do was see that the pin bit was being twiddled in the simulator. After that I just had to hook a scope up and make sure.
I like to use a multi-level approach when debugging problems. For instance with the clock the first layer is 'Put a probe on the clock pin and see if there's a signal there'. If not, probe out the pin on the uC and look for the signal. Then, I coded a debug interface in one of my UARTs where I can look at specific register values and make sure they are what they're supposed to be. So if it doesn't work the next step is 'call up the register value and ensure it's correct.'
Try to think ahead four steps or so whenever you're planning your debugging. There should be +5V here, but what if there isn't? Write into the debug interface a way to toggle the pin and see if that changes it. What if that doesn't work? Do something else, etc etc etc. You get to a point where you run into 'I HAVE NO IDEA WHY THIS DANG THING DOESN'T WORK!!!!' but hopefully you'll figure out the reason beforehand.
I'm trying to find a basic example, tutorial, or blog post on how to write a printer port monitor. I downloaded the Windows DDK and dug through localmon, but it appears that this sample is much more complex than just the nuts and bolts basics and from my understanding it is a bit different than an OEM port monitor because of how it handles the registry key and port enumeration. Does anyone know of a blog post, tutorial, or even book that walks the reader through the basic code to get one up and going? I've found a few links talking about the conceptual stuff, but nothing that is hands on code.
I can recomend http://www.codeproject.com/KB/printing/wpa.aspx, which describes how to write a printer driver and also has good hints about what's necessary to build a port monitor.
But my opinion is that a good tutorial in this area is not available on the Internet (I would be glad to find somebody who can show me that I'm wrong). So, when I had to deal with this task I was forced to do it the hard way: I've read carefully the MSDN explanations starting from this point: http://msdn.microsoft.com/en-us/library/ff561109.aspx. In parallel with reading MSDN I also checked the code in DDK you mentioned and try to understand it. I'm sure this solution could also work for you.
I wrote mine from the specs, there aren't really that many API's to implement.
The one thing that regularaly trips people up is EnumPorts, the spooler allocates enough memory for ALL the ports, not just yours. So you need to make sure you fill any strings from the end of the spoolers buffer, don't put them straight after your structures.
It doesn't say so in the specs but you can safely put the UI and Server functions in the same DLL.
It's also possible to create a single port monitor that supports NT and the later Windows 2000 type port monitors.
The code in RedMon is much easier to read than the localmon example, it's worth looking at before you start. It's quite nice because you can compile it in VS, you don't need to use the DDK to build it.
I have been over that exact same territory for a serial printer. About the best example I found was this article in Dr Dobbs Journal. The good part is that both a serial port driver and the user-space control program are covered and the project can also be used as an example of how to set up Visual Studio to compile a driver. This is also something a little difficult to find information about. The article discusses an old NT style driver, which worked well for me on XP.
There are quite a few good articles on CodeProject about writing drivers and programs to interact with them. They include source code and most deal with the newer WDM and WDF style drivers.
OSROnline is another good source, especially for discussion of specific issues and common mistakes. They also have some great utilities you will need.
Some of the most clearly written and understandable driver code I came across was Mark Russinovich's sample code. Although Microsoft withdrew all of the source when they purchased Sysinternals, some of the best examples can still be found cached here and there.
Drivers are pretty interesting. Whatever else you do though, do it in a virtual machine. Really.