This question is a bit vague, and I apologzie for that, but a fairly vague answer will do :)
How do people typically access memory adresses of external devices (say, connected to a PC through USB, or even just say, a multipurpose microcontroller)? I'm wondering how software is able to find address to write to registers or EEPROM space.
For example if I want to write a value to register 0x1234, does software just send this information (the register and the value to be written) to some sort of driver that "talks" to the device and takes care of the value change through hardware?
Is implementation of this functionality mostly a hardware endeavor?
Thanks!
Let's use as an example a fairly common USB peripheral controller that is based on an 8-bit 8051 microcontroller core. One side of it attaches to the USB host controller on a desktop computer. The other end goes to a USB device controller that presents itself as a FIFO endpoint to the host.
Some 8051 firmware will be required to initialize the device side. A class driver will be required on the host side. Once those are in place, the application developer will have a device name on the host side which may be opened for read/write. Sometimes a vendor will provide a library to perform device specific tasks and isolate the user from the raw device. Often a Windows DLL is available to hide the low level I/O and present device operations as function calls.
Additional 8051 firmware monitors the FIFO from device end and interprets messages sent from the host application or DLL then takes actions. These actions may be low level such as read/write from a memory location or register. They may be high level such as setting the PWM value of a programmable counter array.
So your hypothetical description of a write to register 0x1234 is not far from how it is often implemented.
Related
I have a custom ps2 keyboard(8x8 matrix) interfaced with AT89C51ED2 microcontroller, now I need to change it to USB interface. I have been studying about the basics of USB HID class communication(USB HID class specs, USB complete, Beyond logic) and have come to know little bit about the theory behind it.
But I am not able to understand the firmware part, I read a demo keypad application by Microchip which had given a sample source code, but I am not able to understand in the code how data(key pressed) is sent to the IN endpoint and how the host reads that through polling. I know that endpoint is a buffer from which data is sent to host, but Is it one of the registers of the micro-controller and how do I use it in my code?.
And I have been searching the suitable micro-controller with USB support, but no supported demo's are available, any suggestions will be helpful
The AT89C51ED2 datasheet does not mention hardware support for USB, so the answer is no: an endpoint does not correspond to a hardware register. Instead, an endpoint would refer to some software buffers in the RAM of the chip, and some data to keep track of the endpoint's state. Every bit of every USB packet must be handled by the firmware of the device, and endpoints are an abstraction that live entirely in the firmware of your device.
Note: I am assuming that the keyboard doesn't have some kind of USB interface chip, and that the data lines of the USB cable connect more-or-less directly to the microcontroller.
If you can't find the source code for the keyboard, you might look into using an open-source AVR software USB implementation. Here are some useful links:
https://www.obdev.at/products/vusb/
http://www.fischl.de/usbasp/
Please note that you are undertaking an advanced project, and if you are not familiar with AVRs, USB, microcontrollers, reverse engineering, and embedded development/debugging, it might be useful to start with something simpler first.
I am supposed to pick (and may be implement) the firmware update protocol/software/procedure for the embedded device without USB and with limited program memory size. That device will work autonomously most of the time but once in a while a technician will be coming and updating the firmware.
What would be the most common choice for the update protocol if I wanted to use RS232 or CAN?
The requirements for the update are: complete after interrupted update (boot loader will be needed, I assume), small memory footprint, merge user settings with the newly introduced user data fields (in EEPROM), backup the previous version of the firmware with the possibility to roll the update back, safely update the boot loader itself.
It would be nice if the implementation of the boot loader and update client software existed already too (at least for Windows).
And just out of curiosity - are there any good alternatives to DFU for devices with USB?
Thanks in advance
I am not sure about "most common"; I am not sure anyone could answer that authoritatively or whether the answer is even useful. However I can tell you that I have implemented XMODEM-CRC/XMODEM-1K on a number of devices (ARM 7, ARM Cortem-M, PIC24, TI C55xx for example) in less than 4Kbytes. The bootloader sends an XMODEM start request on each port that is to support update, then for each port if a response is received within a short timeout (a few tens of milliseconds), then transfer continues. If no response is received the application is started normally.
complete after interrupted update (boot loader will be needed, I assume)
The approach I have taken is to not program the start address immediatly to flash on receipt but to copy it sideways and then program it last. The bootloader checks the start address on start-up and if it is 0xFFFFFFFF (i.e. not programmed) the transfer did not complete, and the bootloader restarts continuously polling for XMODEM start.
merge user settings with the newly introduced user data fields (in EEPROM),
In my case I have used Intel HEX files, but EEPROM memory is not commonly memory mapped. You could solve that by using a proprietary data format or set the address of the HEX data to an area that is invalid on the processor which the bootloader code will recognise as data to be sent to the EEPROM instead.
backup the previous version of the firmware with the possibility to
roll the update back,
That is a function of the bootloader implementation rather than the protocol. It of course requires that you have space to store two copies of the application. The unused copy could possibly be zipped, but incorporating decompression in the bootloader will increase its size. A perhaps simpler and least costly approach would be to have the bootloader support output of the current application image via XMODEM allowing the back-up to be stored on the host. However by doing that you are potentially enabling a third party to access your code.
safely update the boot loader itself.
Again that is a function of your bootloader rather then the protocol. If the code runs from RAM (i.e. the bootloader is copied from ROM to RAM and executed, then it is straightforward. In this case it is safest if possible to load the entire bootloader data into RAM before programming flash memory in order to minimise the time the target has no bootloader and so that sucessful programming does not rely on the host connection being maintained throughout.
If however the bootloader runs from flash, replacing it from the bootloader itself is not possible. Instead you might load an application that the bootloader runs and which replaces the bootloader before loading (or reloading) the final application.
It would be nice if the implementation of the boot loader and update
client software existed already too (at least for Windows).
Any terminal emulator software such as TeraTerm, Hyperterminal, PuTTY etc. will support XMODEM transfer. Implementing your own custom XMODEM sender is relatively straightforward with XMODEM source code widely available.
And just out of curiosity - are there any good alternatives to DFU for
devices with USB?
What I have done is implement a CDC/ACM device class USB stack in the bootloader so that it appears to the host as a serial port, and then used the same XMODEM code as before to do the data transfer. This increases the size of the bootloader; in my case to about 12kbytes. It was implemented using a stack and CDC/ACM (virtual COM port) app-note provided by the chip vendor. Strictly speaking for this you will need a USB vendor-id (VID) registered to your company; you should not use just any old ID.
Does anybody know if it's possible to emulate UART (simple serial transmit and receive) over USB? How would this be accomplished?
I found this link on the Microchip website, but it's not very forthcoming.
http://www.microchip.com/forums/m522571-print.aspx
Any ideas? Thanks.
You need to implement the device stack as a CDC ACM device (also known as Virtual COM port or VCP). Most vendors of microcontrollers with USB support have example code or app notes.
Given that, your device will look like a COM port as far as Windows is concerned. At the device end, you will get raw blocks of data transferred. An appropriate abstraction layer can be implemented for both UART and USB interfaces to give then the same interface if necessary.
One gotcha is that USB devices require a Vendor ID allocated by the USB Implementer's Forum, at a $5000 fee(correct 23 JUly 2016). If you are going to release your device in the wild, you really will need one if your device is to be recognised and behave correctly with other devices. Some microcontroller vendors will allow you to use their vendor ID for a subset of product IDs for free or a smaller fee, but they might only do that if you were purchasing significant quantities of devices from them.
Another issue is that while on OSX or Linux a CDC/ACM is recognised without any additional drivers, Windows is more fussy and required an INF file to associate the specific USB Vendor and Product ID to the usbser.sys driver. Then you get into the whole world of driver signing, which is essential if using Windows Vista 64, or any version of Windows 7. A code-signing signature will also cost you money. If your vendor has provided example VCP code, they will also probably provide a signed driver. STMicroelectronios's STM32 VCP example is even WHQL certified so can be acquired automatically via Windows Update.
So the upshot is that for experimentation you can do it if your vendor already provides code and a signed driver (or you are not using Windows), but to deploy a product you will need an Vendor ID and a code-signing certificate. It is a bit of a minefield to be honest.
A simpler approach is to use an FTDI USB<->Serial chip. This is especially useful for a microcontroller without a USB controller of its own, but the data transfer rate will be limited by the micro's and/or the FTDI's UART interface rather than USB speed. An FTDI chip can be used as-is using FTDI's VID/PID or you can customise it with your own VID/PID. Customising puts you back into needing to acquire a VID and a signing certificate, but allows your device to be identified uniquely rather than as a generic serial port.
Basically you have two options to emulate UART over USB:
Use an existing product. The company FTDI provides well known and solid UART-USB bridge chips, e.g. FT230X. Pro: You don't need any detailed knowledge about USB. Cons: Expensive if used in mass production. Additional hardware, needs additional power.
Implement the USB device class "Communication Device Class" (CDC). The specification of CDC is available from the USB.org, see here. Pro: Cheap in mass production (if your Microcontroller has USB on board). Con: You need detailed knowledge about USB.
I am working on Xilinx Spartan 3E platform, using this development board:
http://www.xilinx.com/products/boards-and-kits/HW-SPAR3E-SK-US-G.htm
My program operates on certain data and then provides output. I wish to transfer the input signals externally. The input data is a stream of 8-bit signals.
So, how do I send the input signals from my laptop to the FPGA via USB? Does Xilinx support this or is there standard software to do this?
Thanks.
It sounds like you are describing a uart more than a native USB interface. You can get a USB to logic level serial adapter that will let you easily transfer data to and from a Pc at up to 921.6k baud. A uart/serial port is easy to implement in the Fpga and PCs are easy to use with serial ports.
Here is the cable:
http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm
If you have a development card it is very possible this type of interface is present.
On the software side you can use your programming language of choice as if it was interfacing with a seal port or use a terminal program like hyper terminal or Download teraterm http://ttssh2.sourceforge.jp/
Updated response:
100Hz is not a hard interface to make. At that rate you should use the serial interface if at all possible. The board you referenced has 2 full RS-232 connections. At that point you only need a way to connect that to your computer. If you have a PC with RS-232 connectors you only need a cable if you have a newer computer without you need a RS-232 to USB translator cable (like this one: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=768-1014-ND or google rs232 usb). This will give you a virtual com port on the pc to interface with the previously mentioned terminal programs or your custom software.
Update 2:
on the resource tab of the development board page you linked to there are several UART based fpga designs that you should be able to use as a starting point.
i.e. the "PicoBlaze Processor SPI Flash Programmer".
That board doesn't provide easy access to the USB interface from the FPGA as far as I can tell. It's just for configuration and debug.
Some of the newer boards and tools do allow something called hardware-in-the-loop testing where the simulator can upload data to the FPGA, wait it to calculate the results and then pull the data back. This is relatively common when using Xilinx's System Generator product as the simulations can be really long.
But I think with that board you'd be better off using the on board RS232 port to get data to and from the board. You will have to build the infrastructure to do it yourself though.
This may also give you some ideas:
http://www.1pin-interface.com/
I'm using USB for communication. Our device sends 100k/s data (ARM7, very small memory size), and the PC needs to receive and process it all.
My previous design was implemented as a mass storage device, and extended a command for the communication protocol. The PC software runs a thread with a loop to receive the data.
The issue is: sometime it loses data.
So we used another solution: usb sim com (RS232).
But I don't know whether or not the OS can contain that much data before I get it using MFC (or pyserial). How can I get/set the buffer size?
We regularly punch about 100KByte/sec through our USB CDC implementation, the PC is fast enough to receive all data. But it seems that the built-in limits are lower with usb-serial (CDC) than with mass-storage protocol (in our case ~600KB/s versus ~100KB/s CDC).
The PC receive thread should have a buffer that's "big enough".
Edit: I don't know Windows' Buffer sizes, or how to get them, though.