I am trying to understand how can I write tasks for VxWorks. I have VxWorks on a board that is mounted on a development board.
I can access the board through Putty and a serial terminal connected to the UART of the system. How can I write other tasks (maybe to communicate with other UARTs or other Serial Interfaces) ?
And how do I know where to find the documentation describing how I can access those serial interfaces? (for example write/read methods, which file to include etc)*
Thank you
VxWorks is cross development environment, so you need a licensed development system on Windows or Linux desktop to create applications.
Then you load the compiled code on the target reference board as process/RTP or LKM/DKM. How you get it there varies by board: FTP, TFTP, removable USB or SD card....
At the C shell on booted system you can start a task in the kernel context with any public symbol. But if your working with deployed system, it shouldn't have the C shell, that's a serious security risk :)
Try..
-> sp printf, "\nHello VxWorks World!\n"
Related
I'm using a LPC178 development board and I want to read a file present on a Windows PC. My dev board only has a RS2323 interface to communicate with.
How can I go about transferring the file from my PC to my MCU using a RS232 (serial) link? I found a reference which explains how to transfer data between a MCU and PC but it isn't about file transfers.
Afaik there is no easy solution for this like calling something like "copy" or "fopen" over RS232. I would be happy to be proven wrong here.
The fastest solution might be to write a little programm running on your Windows Host, which listens to your RS232 communication and pipes your communication into/out of the file based on your communication protocol. This can be done with standard file operations in the language of your choice, for example C, C++ or Python.
Your problem is one of the oldest in the book. How do you transfer files without fancy operating system abstractions. For RS232 (or any other serial method) there exists many file transfer protocols.
One of them is kermit. This is a protocol from 1981 and can transfer binary and text files. It is able to be embedded in a micrcontroller and there exists programs to transfer/receive using kermit.
alternative old site for reference
In the simplest case you would use a file transfer protocol such as XMODEM, YMODEM, ZMODEM or Kermit - these protocols were designed in the days before networking and the Internet were ubiquitous and deal with simple point-to-point transfers between two computers. They are supported bu most terminal emulator tools such as TeraTerm Pro or PuTTY so no specific PC software need be written, just the microcontroller end.
A more complex but flexible solution is to implement a TCP/IP stack and a PPP driver, and an FTP application layer - probabaly only practical if using a third-party TCP/IP stack and application layer. You can then use any FTP client for the PC end, so again no PC software required. While this may be overkill if all you need to do is transfer files, it has the advantage of allowing you to use the the single serial port concurrently for other data streams and application protocols such as Telnet. The disadvantage perhaps is that while Windows does support PPP it is buried within the dial-up networking and to be frank a pain to get working.
Very first step you have to do is ensure serial communication is working fine.
Send a byte continuously from mcu to PC and display it on some io console (for example: HyperTerminal, Dock light )
Receive a byte to mcu from PC and echo it back to PC.
Once you are sure that serial communication is working fine then select some file transfer protocol and implement it.
While you can select any of the available protocols or write your own protocol and implement it.
For purpose of discussion i select Xmodem protocol.
If you consider some other protocol you may stop reading answer here.
XMODEM is a simple file transfer protocol.
Refer http://web.mit.edu/6.115/www/amulet/xmodem.htm for detailed information.
You may implement Xmodem mcu side by reading protocol. Or may consider using open source also ( if available )
PC side i prefer to use HyperTerminal io console as it is compatible with Xmodem.
In HyperTerminal all that i have to do is configure settings and select file for transfer to mcu.
Now transfer any file to mcu using Xmodem protocol from PC.
What you do with received file in mcu is up to you : )
First off I have very very little experience with how USB functions let alone writing a driver; essentially trying to make this project a learning experience.
My setup consists of the SparkFun Pro Micro board and a Windows machine. I have a potentiometer wired up to the Pro Micro and my end goal is to send the value of the potentiometer to the host machine and use the value to change things like system volume etc...
The Arduino library came with a Serial library and I can send things over USB using that. I currently have a working Arduino program that sends 1 byte every 1 second, and a C program on the windows machine that "connects" to the COM port and reads the byte coming through (this part I have working fine).
The issue is that when the Pro Micro is connected to the computer it appears on a randomly selected COM port and I don't think you can tell which COM ports hold which device (not sure about this bit).
My end goal is when the Pro Micro is connected to the PC the host program should automatically recognize the Pro Micro and start processing the data that is coming from it. Setting it up as a HID device and making it appear in Device Manager as my own custom device is something I'd be interested in doing, especially for the learning experience but I feel that it might overcomplicate things.
Can anyone point me in the right direction as to what I should do/look into?
maybe use windows internal tools like the COM port database (https://msdn.microsoft.com/en-us/library/ff546481.aspx) or re-assign COM ports using windows registry, see
How does windows map the virtual com port to a device
https://superuser.com/questions/851192/change-com-port-number-programmatically
http://www.ftdichip.com/Support/Documents/AppNotes/AN_132_Re-Assigning_COM_Port_Numbers_Using_Registry.pdf
if you want to know the backgrounds: the arduino implements the USB CDC ACM class (Communication Device Class - Abstract Control Model https://en.wikipedia.org/wiki/USB_communications_device_class) and emulates a COM port. Windows recognizes this class and loads the apropriate driver which is usbser.sys (https://msdn.microsoft.com/de-de/library/windows/hardware/dn707976%28v=vs.85%29.aspx) when the driver is loaded the new (virtual) COM port is accessible
the best sources are How does windows map the virtual com port to a device, https://superuser.com/questions/851192/change-com-port-number-programmatically and http://www.ftdichip.com/Support/Documents/AppNotes/AN_132_Re-Assigning_COM_Port_Numbers_Using_Registry.pdf
I would suggest using libusbp, a C library that can be used to find the name of a COM port, given the USB vendor ID and product ID. There is even an example in the "examples" folder that does just that:
https://github.com/pololu/libusbp
I've recently programmed a client server program in C where the server was running on an embedded board that had a Linux OS and the client was running on a Linux machine. All I had to do was specify the board's IP address to the client running on the machine to establish a connection.
But now I'm doing essentially the same thing but the server is running on an embedded board that has no OS. I'm still establishing a tcp/ip connection between the server and the client, but I'm using a standard library called uIP (microIP).
I was told that the code that would run on the embedded board (the server) would be very tricky to write since it would have to be platform specific, i.e I'd be better off getting a code that was already intented for the platform. My question is though: why is it that much harder to program a C file on a board to establish a connection when the board has no OS, when it was relitavely "easy" to do so on the board with an OS. All I did for the latter was write the code on the Linux machine, then transfer the code on the OS board with scp, compile it, and execute it. Why can't the same be done for the OS'less board? I know I wouldn't be able to compile on the board, but can't I cross compile the server on a machine, and load it onto the board without having to worry about anything else? Why is this circumstance so much more complicated than if I were working with an OS board?
The uIP library most likely implements just the TCP stack. It still needs a way to talk to the hardware. This is what OS is for. Setting up DMA, managing buffers, serving interrupts (and interacting mainline code with ISRs).
With no OS you'd have to implement everything manually.
My question is going to be rather vague but I will try to explain as detailed as I can what I am trying to resolve.
Trying to learn Linux kernel USB stack I have started to think of making a simple USB driver for my Atmel evaluation board based on ARM M0+ MCU to run away from Windows tools (Visual Studio plugin).
I have spent few days learning kernel's USB API and come to conclusion of how to make this. My driver aims to make my board connected to PC through USB cable act like a simple USB flash drive. Making that I then can easily program it with a new version of firmware written by me.
I have found that I need to find out specific interface (I am talking about interface in terms of USB specification, not interface we used to use as a code abstraction) that holds an endpoint (pipe) responsible for interaction with flash memory. And then I can map it to character device and interact with it using standard I/O operations that are described in struct file_operations structure.
Simply using cat on /proc/* file descriptor that was created by USB Core subsystem I have investigated that interface responsible for interaction with flash memory holds bulk endpoint (likewise, this terms come from USB specification, CMIIAW) that act as a "descriptor". Linux kernel USB Core subsystem gives neat interfaces to talk to different kind of endpoints whether it control, interrupt, bulk or asynchronous endpoint.
Now I have come closer to my very question.
Also the main transfer unit in communication between two USB devices is abstraction called urb - you allocate it, you fill it, you send it to USB Core subsystem, you read it if it was IN type of urb and, finally, you free it. What is confusing for me and tightly related to my question is the next API include/linux/usb.h:
static inline void usb_fill_bulk_urb(struct urb *urb,
struct usb_device *dev,
unsigned int pipe,
void *transfer_buffer,
int buffer_length,
usb_complete_t complete_fn,
void *context)
Assume I have obtained an information from board's datasheet about where to write a program code. Let's say, we have 0x00100 - 0x10000 memory region. I will compile my code, obtain a binary and then using standard Linux tools or writing a simple user-space wrapper application I will use lseek to set file's offset to 0x00100 and write system call provided with a buffer (binary compiled previously) and it's length.
In kernel space, I will have to allocate urb in write system call handler, fill it with a buffer sent from user space and submit this urb to USB Core.
BUT I can not find a way how to specify an OFFSET set earlier by lseek. Do I miss something? Maybe I missed some concepts or, perhaps, I am watching in a wrong way?
When your embedded Linux device acts as a USB mass storage device, the flash as a peripheral on Linux device is unmounted, and the gadget driver is loaded. Linux then loses control to the flash, and now the PC connected to your Linux device fully controls the flash. This is because a flash as a USB device can only has one USb host.
The gadget driver works purely in kernel space. It does not receive or transmit data from/to user space. It calls vfs_read() and vfs_write() to access the files on the flash, with an field offset. The offset is got from the USB commands sent from your host - Windows PC.
There is no way to specify offset using USB subsystem's API. I misunderstood whole conception of USB as communication protocol, unwise me. You must first learn underlying protocol your device uses to communicate with others.
If your device acts as a USB HID device then learning specification of how to exchange data with USB HID device is the way to go. If there is something proprietary then you can do nothing but reverse engineer it (listening USB packets with a sniffer on system where a driver for your device exists).
As for my board it has embedded debugger that serves as a communication module besides being debugger itself. Specifically, my device is equipped with EDBG and here is a link on description of protocol it uses for communication.
I have to discuss the codeflow of the USB host controller. This USB host controller is the interface between the device and the OS. There are numerous USB devices (eg.keyboard,camera,mouse,etc).
Where will I find the code to see how the communication between the USB device and OS happens through the USB host-controller ?
Download the Linux kernel source code, and start reading the code in drivers/usb. Here an online reference, and the README about the USB-tree
I suggest you to take a look at USB host controller specifications - UHCI/OHCI/EHCI/XHCI because this knowledge will be necessary to understand whole USB stack in linux kernel.
You may also download some example sources provided by several embedded microcontroller producers (i.e. Atmel). Probably those drivers will be easier to analyse than linux sources.