I have a network application working on Linux. What I want to do is to make my application able to announce it's presence in LAN and then notify other applications about some changes. Because I don't know how many instances of my application already works on other hosts in LAN I cannot use SCTP, multicast communication is the only way (or maybe you know other solution?).
Structure I want to send over multicast address has fixed size (320 bytes) and contains binary data, which are in fact structure of numbers and bit flags.
I'm wondering if there are any well-know programming techniques, which can make UDP communication a bit more reliable. I only figured out two things:
I drop all packets received by recvmsg() which are smaller then 320 bytes.
I surround every packet with with well-know header and footer, and then check them each time when I receive new message, however packet still can be damaged somewhere in the middle right?
Edit:
I found a PGN protocol, but the only Linux implementation is known to work on x86. It's partial solution for me, because I want to run my program on ARM architecture too
You can try porting PGM to ARM, there are not that many requirements in OpenPGM, it already runs fine on IBM s390 mainframes for example.
Disclosure: I'm the author of OpenPGM \:D/
Related
I am a physicist, and I had a revelation a few weeks ago about how I might be able to use my personal computer to get much finer control over laboratory experiments than is typically the case. Before I ran off to try this out though, I wanted to check the feasibility with people who have more expertise than myself in such matters.
The idea is to use the i/o ports---VGA, ethernet, speaker jacks, etc.---on the computer to talk directly to the sensors and actuators in the experimental setup. E.g. cut open one side of an ethernet cable (with the other end attached to the computer) and send each line to a different device. I knew a postdoc who did something very similar using a BeagleBone. He wrote some assembly code that let him sync everything with the internal clock and used the GPIO pins to effectively give him a hybrid signal generator/scope that was completely programmable. It seems like the same thing should be possible with a laptop, and this would have the additional benefit that you can do data analysis from the same device.
The main potential difficulty that I foresee is that the hardware on a BeagleBone is designed with this sort of i/o in mind, whereas I expect the hardware on a laptop will probably be harder to control directly. I know for example (from some preliminary investigation, http://ask.metafilter.com/125812/Simple-USB-control-how-to-blink-an-LED-via-code) that USB ports will be difficult to access this way, and VGA is (according to VGA 15 pin port data read and write using Matlab) impossible. I haven't found anything about using other ports like ethernet or speaker jacks, though.
So the main question is: will this idea be feasible (without investing many months for each new variation of the hardware), and if so what type of i/o (ethernet, speaker jacks, etc.) is likely to be the best bet?
Auxiliary questions are:
Where can I find material to learn how I might go about executing this plan? I'm not even sure what keywords to plug in on Google.
Will the ease with which I can do this depend strongly on operating system or hardware brand?
The only cable I can think of for a pc that can get close to this would be a parallel printer cable which is pretty much gone away. It's a 25 wire cable that data is spread across so that it can send more data at the same time. I'm just not sure if you can target a specific line or if it's more of a left to right fill as data is sent.
To use one on a laptop today would definitely be difficult. You won't find any laptops with parallel ports. There are usb to parallel cables and serial to parallel cables but I would guess that the only control you would have it to the usb or serial interface and not the parallel.
As for Ethernet, you have 4 twisted pair with only 2 pair in use and 2 pair that are extra.
There's some hardware that available called Zwave that you might want to look into. Zwave will allow you to build a network of devices that communicate in a mesh. I'm not sure what kind of response time you need.
I actually just thought of something that might be a good solution. Check out security equipment. There's a lot of equipment available for pc's that monitor doors, windows, sensors, etc. That industry might what your looking for.
I think the easiest way would be to use the USB port as a Human Interface Device (HID) and using a custom built PIC program and a PIC that includes the USB functionality to encode the data to be sent to the computer and in that way be able to program it independently from the OS due to the fact that all mayor OS have the HID USB functionality.
Anyways if you used your MIC/VGA/HDMI whatever other port you still need a device to encode the data or transmit it, and another program inside the computer to decode that data being sent.
And remember that different hardware has different software (drivers) that might decode the raw data in other odd ways rendering your IO hardware dependent.
Hope this helps, but thats why the USB was invented in the first place to make it hardware and os independent.
I'm trying to design an efficient communication protocol between a micro-controller on one side and an ARM processor on a multi-core TI chip on the other side through SPI.
The requirements for the needed protocol:
1 - Multi-session with queuing support, as I have multiple sending/receiving threads, so it will be more than one application using this communication protocol and I need the protocol to handle queuing these requests (I will keep holding the buffer if the transmission is queue but I just need the protocol to manage scheduling the queues).
2 - Works over SPI as an underlying protocol.
3 - Simple error checking.
In this thread: "Simple serial point-to-point communication protocol", PPP was a recommended option, however I see PPP does only part of the job.
I also found Light weight IP (LwIP) project featuring PPP over serial (which I assume that I can use it over SPI), so I thought about the possibility of utilizing any of the upper layers protocols like TCP/UDP to do the rest of the required jobs. Fortunately, I found TI including LwIP as part of their ethernet SW in the starterware package, which I assume to ease porting at least on the TI chip side.
So, my questions are:
1 - Is it valid to use LwIP for this communication scheme? Won't this introduce much overhead due to IP headers which are not necessary for a point to point (on the chip level) communication and kill the throughput?
2 - Will the TCP or any similar protocol residing in LwIP handle the queuing of transmission requests, for example if I request transmission through a socket while the communication channel is busy transmitting/receiving request for another socket (session) of another thread, will this be managed by the protocol stack? If so, which protocol layer manages it?
3 - Is their a more efficient protocol stack than LwIP, that meets the above requirements?
Update 1: More points to consider
1 - SPI is the only available option, I use it with available GPIOs to indicate to the master when the slave has data to send.
2 - The current implemented (non-standard) protocol uses DMA with SPI, and a message format of《STX_MsgID_length_payload_ETX》with a fixed message fragments length, however the main drawback of the current scheme is that the master waits for a response on the message (not fragment) before sending another one, which kills the throughput and does not utilise the full duplex nature of SPI.
3- An improvement to this point was to use a kind of mailbox for receiving fragments, so a long message can be interrupted by a higher priority one so that fragments of a single message can arrive non sequentially, but the problem is that this design lead to complicating things especially that I don't have much available resources for many buffers to use the mailbox approach on the controller (master) side. So I thought that it's like I'm re-inventing the wheel by designing a protocol stack for a simple point to point link which may not be efficient.
4- What kind of higher level protocols can be normally used above SPI to establish multiple sessions and solve the queuing/scheduling of messages?
Update 2: Another useful thread "A good serial communications protocol/stack for embedded devices?"
Update 3: I had a look at Modbus protocol, it seems to specify the application layer then directly the data link layer for serial line communication, which sounds to skip the unnecessary overhead of network oriented protocols layers.
Do you think this will be a better option than LwIP for the intended purpose? Also, is there a widely used open source implementation like LwIP but for Modbus?
I think that perhaps you are expecting too much of the humble SPI.
An SPI link is little more a pair of shift registers one in each node. The master selects a single node to connect to its SPI shift register. As it shifts in its data, the slave simultaneously shifts data out. Data is not exchanged unless the master explicitly clocks the data out. Efficient protocols on SPI involve the slave having something useful to output while the master inputs. This may be difficult to arrange, so you usually need a means of indicating null data.
PPP is useful when establishing a connection between two arbitrary endpoints, when the endpoints are fixed and known a priori, PPP would serve no purpose other than to complicate things unnecessarily.
SPI is not a very sophisticated nor flexible interface and probably unsuited to heavyweight general purpose protocols such as TCP/IP. Since "addressing" on SPI is performed by physical chip-select, the addressing inherent in such protocols is meaningless.
Flow control is also a problem with SPI. The master has no way of determining that the slave has copied the data from SPI the shift register before pushing more data. If your slave SPI supports DMA you would be wise to use it.
Either way I suggest that you develop something specific to your purpose. Since SPI is not a network as such, you only need a means to address threads on the selected node. This could be as simple as STX<thread ID><length><payload>ETX.
Added 27 September 2013 in response to comments
Generally SPI as its names suggests is used to connect to peripheral devices, and in that context the protocol is defined by the peripheral. EEPROMS for example typically use a common or at least compatible command interface across vendors, and SD/MMC card SPI interface uses a standardised command test and protocol.
Between two microcontrollers, I would imagine that most implementations are proprietary and application specific. Open protocols are designed for generic interoperability and to achieve that might impose significant unnecessary overhead for a closed system, unless perhaps the nodes were running a system that already had a network stack built in.
I would suggest that if you do want to use a generic network stack that you should abstract the SPI with device drivers at each end that give the SPI a standard I/O stream interface (open(), close(), read(), write() etc.), then you can use the higher-level PPP and TCP/IP protocols (although PPP can probably be avoided since the connection is permanent). However that would only be attractive if both nodes already supported these protocols (running Linux for example), otherwise it will be significant effort and code for little benefit, and would certainly not be "efficient".
I assume you dont really want or have room for a full ip (lwip) stack on the microcontroller? This just sounds like a lot of overkill. Why not just roll your own simple packet structure to move the data items you need to move. Depending on how spi is supported on both sides you may or may not be able to use it to define the frame for your data, if not a simple start pattern, length and a trailing checksum and maybe tail pattern would suffice for finding packet boundaries in the stream (no different than a serial/uart solution). You can even use the PPP solution for that with a start pattern and I think end pattern with the payload using a two byte pattern whenever the start pattern happens to show up in the data. I dont remember all the details now.
Whatever your frame is then add a packet type and your handshakes, or if the data is going to just be microcontroller to arm then you dont even need to do that.
To get back to your direct question. Yes, I think that an ip stack (lwip or other) will introduce a lot of overhead. both bandwidth and more important the amount of code needed to support that stack will chew up rom/ram on both sides. If you ultimately need to present this data in an ip fashion (a website hosted by the embedded system) then somewhere in the path you need an ip stack, etc.
I cant imagine that lwip manages your queues for you. I assume you would need to do that yourself. the various queues might want to talk to a single driver that deals with the single spi bus (assuming there is a single spi bus with multiple chip selects). It also depends on how you are using the spi interface, if you are allowing the arm to talk to multiple microcontrollers and the packets of data are broken up into a little bit from this controller a little from that controller so that nobody has to wait to long before they get a few more bytes of data. Or will a complete frame have to move from one microcontroller before moving onto the next gpio interrupt to pull that guys data? The long and short of it is I would assume you have to manage the shared resource just like you would in any other situation where you have multiple users of a shared resource (rtos, full blown operating system, etc). I dont remember lwip that well at all but with a full blown berkeley sockets application interface the user could write separate applications where each application only cared about one TCP or UDP port and the libraries and drivers managed separating those packets out to each application as well as all of the rules for the IP stack.
If you are not already doing experiments with moving data over the spi interface(s) I would start with simple experiments first just to get the feel for how well it is or isnt going to work, the sizes of transfers you can do reliably per spi transction, etc. Your solution may naturally just fall out of those experiments.
I's using Qt to build Udp and Tcp servers/clients. Now in recent project, Qt is not allowed and i'm supposed to use Boost. Having gone through boost::asio, i feel confused since there are so many features and usages are very different from Qt. For Udp (multicast,broadcast etc) i'm more or less clear now. But for Tcp i'm having problems understanding:
(have to do all async)
TCP is stream oriented so there is no way to know the number of bytes that have arrived. So we use asio::ip::tcp::socket::async_read_some(). However in Qt we have readAll() for a socket which can be made to read all data on readyRead() signal and return a QByteArray, the size of which we needn't specify as it can grow. How do i achieve this in Boost? readyRead() signal i think would map roughly to async_read_some(), what about the rest (readAll() and "growable" buffer/array?
disconnected() signal is emitted in Qt if the TCP connection disconnects (server/client off, lan cable unplugged etc). What would be the equivalent check in Boost? Do i need a timer to periodically send and expect heartbeat messages myself?
Use some overload of async_read free function with the appropriate completion-condition.
As you see there, this function accepts asio::streambuf, which is growing automatically.
Yes, the only portable & reliable way is to send some heartbeat. I don't know how Qt does that, but try cutting the network cable and see whether you get any notification from Qt...
Further to this question, I'm looking for a device that will allow me to connect two USB hosts, while still being fully programmable. I would like something that can do the following:
Masquerade as an arbitrary USB device
Take input from a PC and do nothing but pass it on to the other host.
I've been looking for a microcontroller (preferably pre-assembled) that will allow me to do this, but have so far come up blank. Does anyone know of a controller (preferably cheap) that will allow me to do this?
Take input from a PC and do nothing but pass it on to the other host.
This is non-sensical from a USB perspective. USB is a host-based protocol: a device will never send data unless a host requests it first. Keep in mind here, 'host' and 'device' have specific meanings here within the protocol itself; you can think of a 'host' as the master and the 'device' as the slave. These roles are baked into a USB controller. There is no way to convince a standard USB controller in any given PC or peripheral to swap roles. There are add-in cards for PCs that are USB device controllers (making your PC act as a device), but 'cheap' is not a word I would use to describe them.
What you really are trying to do is create something that is a USB device to device bridge. So, alright, you need to have two USB(2.0) device controllers (maybe not that expensive, some micros already have to on-the-go controllers). Then you have to get them to pass something meaningful to each other. That's really hard because, as I mentioned above, hosts must tell a device to send data, and can send data to a device whenever it wants. Assuming a game controller shows up as a HID device (assuming the console doesn't listen for some weird, custom descriptor, and use some weird, custom protocol), interrupt pipes will be used to transfer data. This pipe is guaranteed to be polled at some minimum rate. So you have the console requesting data at some rate, which is not fixed, and a host-as-gamepad sending data at some rate. It's going to impossible for the two to sync up, so you'll need some kind of decent sized buffer on the gadget you're trying to create, which adds more $$ and more complexity.
USB is also pretty fast. In high-speed (USB2.0), frames are 125 microseconds long. That means you have to be completing requests at around 8KHz, which seems slow compared to the clock speed of a microcontoller, but keep in mind you have to be doing everything else at once. I'm not sure if there's a hobbyist-level microcontroller that's going to have everything you need, especially one for which you don't need to roll your own USB stack.
Try this chip -> FTDI 232 they are protocols chips, it will translate the data to i2c, spi, serial, whatever u want. nice, easy and cheap :) . FTDI firm, have even better ones (vinculum), with otg and everything u need but I would start with the FTDI232. U just need to use your favorite uC to do the work u want. ... on the other hand, u have to do a little board, maybe some soldering, :). good luck!
You will need $$$$ in equipment and $$$$$ in development work to achieve things the way you imagine. You should better tell us what do you want to emulate, and take a look here if someone has already done it for you. If not then use LUFA library with some bigger USB AVR that can behave as USB host and connect two of them (one as USB guest and the other as USB host) via some other protocol (I2C/SPI/UART).
In the meantime there is a great solution for this Problem. Using the FaceDancer Library together with one of the boards supported by this great piece of software (i.E. GreatFET One) you get exactly what you want:
The GreatFET One has two USB connectors: the first one is used to simulate ANY kind of USB Device, while the second one is used to forward all requests/responses received/send via the first connector.
Of course this tool requires that you know the USB protocol of the device you want to simulate. Although there are some code samples you still have to know what you are doing as soon as you customize them.
I have been doing desktop programming for a while but want to get started with interfacing with hardware. Specifically, I would like to learn how to use serial ports to take an external event and alert my application (so for example, I can turn on a camera when motion is detected by an external sensor).
Please tell me how to get started, what type of sensors, what books (or online resources) are available. I tried Bing and Google but I need more pointers.
Serial interfaces are fairly simple to work with. But they do require some sort of a decoder on the other end (such as a UART.) Another option would be using the parellel port. The advantage of using a parallel port is you start with a break out of the I/O pins. You can typically control 8 devices with a very simple to build interface.
Most platforms gave a simple way to gain access to the LPT ports without too much effort and again they are very easy to interface.
Quick results for tutorials...
Parallel Port Programming
Parallel port output circuit
A tutorial on Parallel port interfacing
LPT Port Info...
Parallel Port (PC)
LapLink Cable
Printer Cable
IEEE 1284-B
IEEE 1284-C
Centronics (36 pin)
I would recommend you the book Linux Device Drivers 3rd Edition
Although I haven't programmed any hardware interface yet, I think this book will get you ready to start hacking.
There really aren't a lot of one-size-fits-all tips for this. You're going to need to look at the documentation for your device, it should specify the protocol of what it will send over the serial port and what commands you can send in return.
Make sure you understand things like what means to have a text encoding like ASCII or UTF8. Most any device that sends and expects text will use an ASCII encoding.
I'm not sure what OS or language you're using, but be aware that you're sending raw binary data through a serial port, so for example if you're using C# you would want to wrap your serial port data stream with a StreamWriter or StreamReader with the correct text encoding.
If you can find an old modem online or craigslist that might be a good start. The serial comms specs for those are pretty well documented.
After that I would just start investigating things that you are interested in - your interest in the project will drive the learning and progress more than anything IMO.
I think this site has some fun things to try:
http://blogs.msdn.com/coding4fun/
You should get a data acquisition hardware and interface with that.
http://www.dataq.com/products/hardware/
If you just want to learn how to use the serial port, get another PC with HyperTerminal (included free with Windows), and use it to send and receive data from your development machine over the serial port. This will give you very manual control over what's sent to your development box, so you can get some confidence that what you're reading and writing is correct. Once you've got the basics of serial I/O down, you can move on to your camera/motion sensor/etc.
You don't mention what OS or development environment you're using, but in VS 2005/.NET 2.0, there is actually a SerialPort class. If you're doing raw Windows API, MSDN has an article at http://msdn.microsoft.com/en-us/library/ms810467.aspx which covers the basics. If you're using another OS, sorry I'm not that familiar (I know, boo hiss on me).
The most important thing is just remember to set your communication parameters on both sides of the connection the same. There are four parameters that govern if both sides can understand each other : baud rate, bits-per-byte (usually 8), parity bits (even parity, odd parity, none, or always 1 or 0), and stop bits. HyperTerminal also lists a "Flow Control" option, I recommend setting it to "None" until you get comfortable. Xon/Xoff flow control is a fairly common way of making the other side pause while you process a bufferfull of data.
Buy a microcontroller and build a simple robot, cnc mill or something. Atmel AVR and/or PIC is the most common from what i understand.
Also gives a lot of electronics experience