So i'm working on a program, wich is vaguely going to resemble
Br#y's Terminal, but running from the commandline in linux
It will do asynchronous transmission, out the serial (Com) port.
Now i think the Header/library i need for this is the termios.h
Now i've only used posix a little before and i;m finding it rather heavy going digging though manpages/specifactions
http://www.opengroup.org/onlinepubs/007908799/xsh/termios.h.html\
Does anyone know of any good guides to termios?
I would google it myself (i've tired) but i don't understand the content enough to know if a guide is good.
Am i using the right library,even?
There's a wiki book available that covers termios. Yes you are using the right library. It's the only way to manipulate the device to talk over the serial line as it controls it. There is a brief introduction to termios in this blog. Here is another wiki book on serial programming under Linux.
Hope this helps,
Best regards,
Tom.
Related
I have an obsolete hardware level/pressure transmitter that communicate with mcu using custom protocol (it appear to be similar to modbus RTU), that hardware comes along with an old commissioning software that works perfectly fine under latest windows, that software contain all communication protocol components that I try to extract and use in something like Arduino to pull data out of transmitter, anyone can help out?
Update - Didn't mentioned above that form of communication here is half-duplex serial communication where master hardware/software query slave transmitter.
Now mentioned to program Arduino mcu to pool data out of transmitter.
What best way of getting readable data out of it?
Again many thanks for all your comments and help!
What you need is called a sniffer. Use that as a keyword and you should be able to find plenty of info here at SO and around the web.
To set the record straight it is actually possible to use Wireshark to sniff on Modbus RTU over serial, see my answer here. If your protocol is similar to Modbus I would start with SerialPCAP.
If you prefer more Windows-friendly solutions you can check these out: 1, 2.
Since Modbus is pretty simple I would say reverse engineering a similar protocol should be, maybe not a piece of cake but just manageable, even if you are not very experienced.
These days when almost everyone is a maker or at least a wannabe, you might want to first take a good look around, maybe somebody else already reverse-engineered that protocol and published it somewhere.
The best tool to analyze a protocol is Wireshark. Run it on the communication link between the Windows machine and the radar. First possibility: the protocol is actually something that Wireshark knows (some trials and errors with the "Decode as" menu may be necessary.) Second possibility, less funny: the protocol is indeed completely proprietary and unknown to Wireshark. At least, Wireshark will make it easier to examine the binary data.
I am trying to get a CC2650 module to talk to an XBee S2c RF board. I have updated the XBee with the 802.15.4 driver. On the CC2650 end, I am using Contiki. Even as I was considering implementing the Rime stack, I am suspecting if the idea would even take off because XBee may not understand Rime. After all, the CC2650 is bei9ng flashed with a Contiki-based code, while XBee has its own internal firmware, which may not have been programmed to respond. Can somebody please correct me if I am wrong?
Also, kindly help me with answers to the Q's below:
Does the XBee use the Proprietary 802.15.4 protocol, which the CC2650RF layer is set to by Contiki?
I was looking at Contiki so that I need not have to change my code much if I migrated to another MuC. Contiki'platform layers take care of converting the common Contiki mechanisms to the underlying API. Is this assumption about Contiki being a generic layer correct?
Is there any communication method (runicast,broadcast et al supported by Contiki out of the box), to directly talk to the XBee?
Is there a single place where all protocolsof Contiki have been clearly explained? Iam having a hard timegoing thru the code alone and trying to make out the exact nature of each of these methods. I already went thru the Contiki wiki and a couple of other resources
Please help.
Can somebody kindly also tag this question with CC2650. It appears I am under-qualified to do that.
Thank you in advance,
Rahul
Ok. I should have done this before I posted the question. The answers lay in slightly more experimentation that I did after stumbling across this link:
http://knowledge.digi.com/articles/Knowledge_Base_Article/XBee-802-15-4-Addressing
Answer to Q1: Yes. It appears they both are talking of the same protocol
Answer to Q2: Yet to prove myself right. Opinions on this one are welcome.
Answer to Q3: This is slightly long.
Adam Dunkel's research paper on the Rime protocol presents the RIme as a way to minimize Code. Not as a new way of fiddling with the PHY or MAC layers of the 802.15.4. Therefore, my fears that the Rime protocol changes the way messages are transmitted is misplaced. Now for the actual paper, it can be easily found with some googling. But here is the easier click. So regardless of what part of the stack is used, an XBee would be able to receive it as long as it is configured following the first of the above two links.
Q4: The Adam Dunkels' Rime link is the one I was referring to in my initial question. It possibly takes some very detailed code inspection to interpret the Figure 1 of the RIme paper itself.
I want to get in the middle of packet forwarding (Not routing). For example, the system is a layer 2 bridge between hosts and their gateway. I want to check the layer 7 for string or whatever "foo" and forward/drop/delay the packet based on the result. What I am having trouble with is intercepting the packet.
What I have read so far:
I know I can get the copy of packet from BPF device (Usenix paper by Steven McCanne and Van Jacobson http://www.tcpdump.org/papers/bpf-usenix93.pdf ). that's good for sniffing but not for me.
I can access the PF device and set the filtering rules which is good for forwarding or dropping decisions, but not for inspection. man pf (4)
I can get packets into the ALTQ queues, BUT I do not know how to access the individual packets located in the queue. man altq(9)
I have also looking into the source code for PF(/usr/src/sys/contrib/pf/net ), PFCTL (/usr/src/contrib/pf/pfctl) and ALTQ(/usr/src/sys/contrib/altq/altq).
On FreeBSD 9.1 machine
I am not C expert, but I am good with it.
Maybe I am getting tired today with all the reading and missed something trivial. Please forgive me if so. Plus, this will be a very good find fro those looking into the subject.
P.S. There is a way of controlling the flow of "foo", by detecting "foo" in packet and denying the answer to that from coming back by setting up the filter for answer to that request. This is NOT what I am trying to achieve. I do not want the packet to leave the system if it should not.
EDIT 2 P.S. There is a great way of doing this on Linux. I can achieve everything I mentioned here on Linux with libnetfilter_queue. I will not bother posting solution here because there are many many many tutorials on how to do it on Linux.
In conclusion, I am still looking for answer on how to do this on BSD. As far as I can understand, I need to write a wrapper/library based on pf (because there is no such thing on the net - otherwise I should have found it already), that does the same thing as libnetfilter with it's libnetfilter_queue library. Or I could somehow dig into libnetfilter and port it to FreeBSD, but since it is based on iptables, only thing I can get from digging into libnetfilter library is logic and algorithms not the actual code itself, which by itself could prove to be of no use to me.
FreeBSD 9.1 has an userspace framework for packet access called netmap. It was recently introduced and has an amazing performance scale. It does very simple but powerful thing - just mmaps the NIC buffers to userspace portion of memory and detaches the packet processing from host stack, this was exactly what I needed the rest is on me.
If anyone needs any goods reference for this, please refer to man netmap (4)
Have a look at OpenDPI or nDPI.
Check out the "Divert Sockets" in BSD implementation as well. Unlike Netmap, it is not zero-copy (IMHO) however it can work with ipfw in order to implement the necessary filters in order to filter packages you want to process.
So I may have done something VERY foolish
I've agreed to a project where a Roomba is controlled via bluetooth. I thought everything was fine and dandy, BUT, I'm not allowed a computer for the end system.
Instead, I'm allowed a Xilinx Virtex II Pro board.
My plan is to buy a bluetooth serial adapter, and buy the iRobot accessory to foster the communication. My hope is that it'll be about as hard as sending messages over a serial port (and I won't have to deal with too much low level socket programming, but if I have to I have to).
My question is, has anyone done something similar to this? Can anyone recommend a tutorial, or a website or a specific product?
I'm aiming to buy these:
http://store.irobot.com/product/index.jsp?productId=2649971
http://overlandresource.com/wp-content/gallery/images/bluetooth-serialconverter.png
Can anyone recommend something better? Can anyone tell me what trouble I'm in for? Really, ANY advice would be nice.
To clarify this project has to be in C and VHDL as C.
You can pretty much just plug and play a Bluetooth module that will do Serial Port Profile e.g. it looks and works like a serial port, even down to RS-232 type connections to the module.
For example, I've played with an RN-42 module by RoHS and it works pretty well. I am pretty sure there are others out there as well.
However, you will have to somehow pair the two ends of the Bluetooth connection. Might involve one end knowing the fixed pin number of the other end. That's going to be down to the modules you end up using.
Don't expect high baud rates either.
So I hope my response isn't too late, but a great tutorial that covers EXACTLY what you are looking for is here:
http://www.robotappstore.com/Knowledge-Base/1-Introduction-to-Roomba-Programming/15.html
It goes over the setup, communication, and basic use of the roomba SCI commands. What's great about the roomba is that you can use any sorta of lanugage you wish to actually handle all your complicated computing, and then just send down your motion commands to the roomba.
Controlling the roomba is pretty easy, just the setup is the most difficult part. The other annoying thing is that the roomba's commands are not in plain ASCII chars, but rather sent in byte form. Once you get over that, its a breeze though.
Hope this helps!
I'm going to graduate soon in electronics and tlc engineering and I have some decent OO programming experience with PHP and Java.
Now I would like to try starting a career as a C programmer.
I'm interested in C since this is, I think, the most suited language, without considering Assembly, to develop device drivers, firmwares and other low-level softwares in.
In particular I hope to be able to work on network related topics.
I want to work quite close to the hardware since I suppose this is the only way I'll be able to fruitfully spend my degree while at the same time finding gratification in being a programmer.
So I'd like to ask what you think I should read considering that I can already write something in C, nothing fancy though, and that I've read a couple of times the K&R.
If you know of any tools or libraries (like libevent and libev) that are de facto standards in the field of low-level, network related, C programming that would be nice to know as well.
In no particular order:
Unix Network Programming
The Standard C Library
Beginning Linux Programming
Professional Linux Programming
Linux Device Drivers
Must read books:
TCP/IP Illustrated, Stevens
UNIX Network Programming, Stevens, et al
For system-level networking code (you expressed an interest in drivers, etc) see OpenBSD sources since it's tight, clean, and the standard networking APIs are based almost completely on BSD.
Depending on how low level you want to go. There is a small stack called uIP
which is a good read, its well documented and has a few papers written about it. Its a lot closer to the hardware then any of linux socket/io programming since there is no kernel to get in the way.
You may want to also take a look at tcpdump, its a nice cli based sniffer, (written in c) so you can use it as well as take it apart!
Beej's guide to Network Programming is a good place to get started. If you want to go down the rabbit hole then as many others have recommended take a look at Unix Network Programming, volumes 1-2 by W. Richard Stevens.
How about the libcurl source? Take a look here.
I've used this "Linux I/O port programming mini-HOWTO" a number of times. This is C code.
There are also a number of C code samples for serial I/O.
Not exactly C specific but packet sniffers like Wireshark can be really useful for testing & debugging network related programs.