ARMduino API

Background

After spending the past few years trying to figure out how to interface optical drives directly to an Arduino board, it finally hit me to use the native functions of a PC that already existed to give access to all formatted drives. From my finding, I managed to give all drives a drive letter while printing the drive types and free space left on each disk. Data transfer occurs over USB and an Arduino DUE R3 can read and write to any storage medium.

Through the current setup, a computer hosting the remote drives is kept off the internet but accessed through an arduino DUE. With USB keyboard input, commands can be entered directly into the DUE or the DUE can accept commands via UART or from the PC hosting device connections. In short, the DUE controls bidirectional access to all memory locations inside the PC. Though the PC could remain off the internet, the DUE can update or write databases or web server files by executing DOS commands or processing char-based function commands.

Interaction and communication between Intel Atom deskboards and ARM MCU's becomes possible.

The command line interface is coming together and a list of available commands can be printed out on the display giving the ability to place the board's listening mode to USB, Keyboard or UART and change any digital pins to inputs or outputs and even set their values. Will be implementing many more commands with a combination of DOS and Linux style commands.

There can be an unlimited number of Arduino DUE boards linked together through two UART ports on each board with one Arduino DUE board linking to another per computer station while each computer can be accessed individually from another. Doing this would increase available storage space exponentially if the individual computers the DUE's are connected to are of like models.

Each Arduino DUE would be running the exact same program listening for command chars and processing data the same way. It could then be theoretically possible to handle file transfer between compiters in a sort of DMA mode while the main initiating DUE among pthers in the network are free to process other commands or data. The boards would be independen but able to communicate with each other to retrieve files, other data or volume information. Where more storage space is needed, this could be a great solution and with the computers offline and accessible only through the DUE, the whole process could be password protected to prevent unauthorized access where the DUE wouldn't process any commands unless administrative privileges were given by setting an admin byte value if a correct password was entered.

Entrance into the array of boards would be through UART, possibly from an initiating Arduino acting as a main computer array controller. Each DUE board could have an input and an output serial port to ease linking up the boards together. Additionally, the DUE hardware is accessible so reading and writing to and from the digital or analog pins wouldis possible. Control individual relays and have upwards of 32 digital inputs or outputs for indicator LED's or sensor readings per board while controlling DAC output voltages.

Drives are broken up into local and remote groups. Local storage is a 32GB SD card and a 64KB ram drive while remote storage is everything from floppy disk to CD/DVD/BD-R to hard drives, ram disks and USB drives. I'll be using the floppy drive to store executable binaries that will run on the Arduino Due, booting over USB in a sense. Access to the floppy will not be possible after booting to protect the binary boot code for which a bytecode compiler will be made.

I've decided to call the command prompt environment ARMduino API since the MCU is ARM based. The image attached shows the local and remote drives, their formats and available space. Continuous programming is occurring for this project.

Additionally, the DUE has native USB support so I will be using that for data entry, but can hand the ARMduino environment an automated mode that runs through ARMduino binaries that control the DUE board and a manual data entry mode for text entry that could enable automated mode allowing users to jump or toggle between the modes.

The sky would be the limit with this project and could be useful for storing sensor readings, controlling output or analog input channels. While running a bytecode app, the Arduino DUE could possibly run some very powerful functions. Arduino DUE board data could be retrieved over the internet via ASP.net, in addition to controlling Arduino DUE board functions over the internet where each transaction would require a password for data storage or retrieval.

Another good possibility could be aiming the interoperability toward Apache Web Server, handing it databases written by the DUE to any of the PC or Local drives. It could also be possible for the DUE to write or update web server files. Alternatively, the DUE could probably store data locally in the 32GB SD card and allow access to the data over the internet with a password or sha256() datablock verification during any read/write operations to and from the DUE via ASP.net or even Perl which can catch variables and handle data operations from incoming or outgoing transactions.

Overall, this project provides a way for an Arduino DUE to access local and remote disk drives that are formatted as well as allowing requests made over the internet to read or write data to and or from the Arduino DUE board by interpreting char-based bytecode uint8_t data binaries that run predetermined functions giving access to all hardware on the Arduino DUE as well as all memory locations that have a drive letter inside a PC for read/write operations.