I would like to have some kind of mechanism to somehow load the RAM on the Raspberry Pi programmatically from a controller computer (I assume through the SD interface) and then let the Raspberry Pi's CPU execute. Is there some kind of device that does this? And what is it programmed in?
It would also be great if there's a way to interrupt the whole thing from the controlling computer if needed.
SD is a fairly poor choice for an interface to try to push data into from an external source; generally the computer hosting the SD device wants to be the master of operations.
But the Raspberry pi has both uart serial ports and (on the model B) an ethernet interface. Downloading code through either is quite normal.
You haven't mentioned if you want to run an application atop a typical linux installation, or if you want to do bare metal programming. In the first case you would typically transfer the program to the file system (either ramdisk or the SD card) and then execute it.
In the second case, you would need a stub of code already on the device (which is to say, the boot partition of an sdcard) which knows how to configure peripherals sufficiently to enable reception of code via serial or ethernet (the latter complicated by needing a USB host stack), and then jump into it.
Related
I have a device connected to a USB and it periodically sends data to my PC. During the time it is not sending data, the USB cable needs to be removed, else, the device won't work (a fail-safe feature, if the USB cable is connected and attached to pc, the device is in communication mode, if the USB cable is disconnected from pc, it is in stand-alone operation mode).
I was thinking to use the Devcon so I font has to use another hardware, I'll just disable the USB port during an operation mode, then enable it during communication mode. However, the periodic transfer of data can be set to every 5,10,15,30 minutes depending on the settings.
My question is, will it be okay to disable/enable the USB port periodically? Say every 5 minutes? Won't it cause any problem in the long run? Or would it be more efficient for me to use external hardware, a switch to connect/disconnect the USB? Appreciate any advice or thoughts.
If devcon works for you, I don't see why it would cause any problems in the long run. There is no inherent reason why the hardware should get damaged when you run some commands in your software to disable a USB port.
Using external hardware to accomplish the same thing would not be more efficient because you'd have to pay for the hardware and maintain it.
I have an STM32-discovery board and I am trying to program it with not using any cables.In the place where I am doing my internship, they first wanted me to program STM32-discovery with UART. I was able to do this by making the necessary connections and using the Flash loader demo. Now my next task is to add an ESP-07 wifi module on the STM32-discovery board, connect this module to the same network as my computer, and wirelessly program it from my computer. No other device is wanted in between (like Raspberry). I did some research on this topic but couldn't come to a conclusion. What I found; I can remote program by connecting the card to a Raspberry or a device called Codegrip. Is it possible to do this with only an ESP-07 without these devices? I will be glad if you just tell me what should I look for.
Yes, it's possible to reprogram the STM32 flash wirelessly if the STM32 is running a program that supports this capability. When you programmed the STM32 via the UART there was a program running on the STM32 that:
opened the UART port,
received the new program data via the UART (using some protocol),
and then programmed that new data onto the flash.
To do likewise wirelessly, the STM32 will need to be running a program that:
opens the Wi-Fi port,
receives the new program data via Wi-Fi (using some protocol),
and then programs that new data onto the flash.
You may have used the STM32 internal ROM bootloader to reprogram via the UART. And if so then you used the protocol required by that ROM bootloader. But the ROM bootloader probably does not support Wi-Fi. So you'll probably be creating your own bootloader program that can communicate over Wi-Fi. And you might be defining your own protocol for transferring the program data over Wi-Fi. Or maybe you can apply some established protocol such as FTP. Search for examples of bootloaders that support OTA (over the air) firmware updates.
There are two possible solutions.
Write a custom bootloader for the STM32 - the flash is organised with smaller blocks at the start to support that, so you would move your application to higher memory and have the bootloader either jump to the application to load a new application. The bootloader can then access the Wi-Fi module (and other interfaces) to get updates.
Write custom firmware for the ESP0-07 so that it receives and stores the STM32 image, then transfers it to the STM32 using the existing ROM serial bootloader. In this case you need the details of the bootloader protocol, and it would be useful if the ESP-07 had a GPIO connection to the STM32 reset line so that it can invoke the bootloader without a manual reset.
Either way, you need to write software for one or other of the devices.
You can use any standard bootloader and connect the Wireless module like ESP32 (Bluetooth and Wifi), ESP8266 (Bluetooth and Wifi), BT-05 (Bluetooth), HM-10 (Bluetooth), etc.
Then create the android application or web application and update the Firmware or application.
If you don't want to use the Standard Bootloader, you can implement your own bootloader and add this OTA feature to that.
We have added the Tutorials step by step. Please refer to this if you get time. There we have developed the custom bootloader and updated the Firmware.
How is it possible to determine the commands to operate a usb device, if that device comes from another operating system and traffic monitoring software cannot be installed on that OS. The only method i can think of is sending random commands to the device, until the device responds, but this seems implausible for more complex commands, and potentially dangerous. For example, consider the DualShock 4 controller. Sony has not made an official driver for this device, so what method can i use to create a linux driver for it?
Get a hardware protocol analyzer. Then you won't need to install any software on the host or device under test. Here is one that I have used:
http://www.totalphase.com/products/beagle-usb12/
I'm writing a small OS for a ARM board, and I'm a bit tired of the usual "remove SD card, copy kernel, insert SD card, switch on" pattern, so I started to look towards u-boot, and now I'm able to load the kernel via serial port using u-boot and kermit: I don't have to remove/insert the SD card anymore.
However this is painfully slow (~5min for 2.5 Mo), and I wonder if I could do the same using the usb port of the board (I know u-boot support tftpt booting method, but I didn't managed to setup the network correctly so far).
Best,
V.
I have been tasked with writing a USB driver for our embedded software to send raw data to Host. This will be used to send some logging data to host. We are using iMX31 litekit for development.
From the documents that I have read on USB, my understanding is that the embedded device will be in device mode only. Also it will only be communicating with host machine.
So can any one guide me here? Any article, reference or code is welcome.
Some things to consider:
Is this a high bandwidth device like a camera or data recorder, or a low bandwidth device?
For low bandwidth, I would strongly consider making your device act as a USB HID class. This is the device class that supports keyboards, mice, joysticks, gamepads, and the like. It is relatively easy to send data to nearly any application, and it generally doesn't require that you write a custom device driver on the host side. That latter feature alone is often worth the cost of lightly contorting your data into the shape assumed by the HID class. All the desktop operating systems that do USB can use HID devices, so you get broad compatibility fairly easily.
For high bandwidth, you would still be better served if your device fits one of the well established device classes, where a stock device driver on the host end of the wire can be used. One approach that often works is to use the Mass Storage class, and emulate a disk drive containing one file. Then, your device simply mounts on the host as if it were a disk, and you communicate by reading and writing to one (or a few) file.
I would expect there to be a fair amount of sample code out there for any serious USB device chipset that implements either or both of HID and Mass Storage.
If you really must wander into fully custom device territory, then you will need to be building device drivers for each host platform. The open source libusb library can be of some help, if its license is compatible with your project. There are also ways in newer versions of Windows to develop USB drivers that run in user mode using the User Mode Driver Framework that have many of the same advantages of libusb, but are not portable off the Windows platform.
The last custom device I worked on was based on a Cypress device, and we were able to ship their driver and an associated DLL to make our application code easier to build. I don't know off the cuff if there is any equivalent available for your device.
For a really good overview, I recommend the USB FAQ, and the latest edition of Jan's book, USB Complete.