I'm working on code that communicates via serial port between different languages and different platforms, and I'd like a single test mechanism I can use that'll hook up to a serial port and then run a series of scripted conversations (send "this", wait for "that", pause 2s, wait for "that" again etc). Messages are binary. I could write something, but there must already be something out there for this that's had decades to mature, so not only would I be re-inventing the wheel but I'd probably be making it triangular. Does anyone know of such a thing? Can be either Windows or Linux.
I´m not sure to understand your question... If what you are developing is a propietary (your own) serial protocol to execute some tasks from different platforms (with different programming languages), all talking your protocol, and what you want to do is to plug a serial cable from/to PC-device and send from the PC serial commands of your protocol to the device (could be another PC) to test your software, yes, there are plenty of software to send serial data:
With some limitations on the free versión:
http://www.commfront.com/commfront-downloads.htm
A full free software from Extron (you can send a script file):
http://www.extron.com/product/software.aspx?id=dataviewer&s=5
There are many more, specially if want to waste your money, but those are the ones i´ve worked with for some years and works great.
Related
I am involved in a project where we have some kind of IoT device. An nxp processor with an LTE modem on a PCB. The software running on it connects to the modem over a single uart interface. It will initialize the modem through AT commands, and finally made a data call to the provider (PPP).
Then, it uses lwIP (light weight IP) to open some mqtt subscriptions, and allow user code to make http get/post requests to our servers.
Every 15 minutes we want to retrieve signal strength from the modem and report this back to the server. What I do now, is put the modem back in command mode, retrieve the signal strength info, go back to data mode, and resume normal operation.
The round trip from data mode, to commando mode, and back to data mode takes several seconds (4-5 ish). This is annoying, because during that time we are not receptive for commands.
I've read about gsm mux 07.10. By following some defined protocol it allows to create virtual serial ports, over one physical uart. That sounds nice, although I realize this will go at the cost of performance (bytes will be added to each frame we send to either command mode / data mode).
The gsm mux 07.10 spec dates from 1999. I am far from an expert in mobile solutions. I was wondering: is muxing still the way to go? How does a typical smart phone deals with this for example? Do they include modems with more than one uart to have parallel access to AT commands and a live internet connection? Or do they in fact still rely on gsm mux?
If somebody would be so kind to give some insights. Also on potential C libraries that are available that implement gsm mux 07.10? It seems that TinyGSM implements it (although I can't seem to find where), and I also can find the linux kernel driver that implements gsm mux 07.10. But that driver is written on top the tty interfaces in linux, so that would mean I would have to reverse engineer the kernel driver and strip out the tty stuff and replace it with my own uart implementation.
First of all, the spec numbering is the old GSM specification numbering, so those old specs will never be updated, the new specifications with new numbering scheme will. I do not remember when the switch was made, but I do remember someone at work giving a presentation on 07.10 probably around 1998/1999, so probably a few years after that or around that time (and definitely before 2009).
The newer spec numbering scheme uses three digits for the first part.
So for instance the old AT command spec 07.07 is now 27.007, and the current 07.10 multiplex specification is 27.010.
The following is what I remember of 07.10.
The motivations for developing 07.10 was to exactly support the kind of scenario that you describe. Remember back in the mid 90's, if mobile phones had a serial interface then that was RS-232 though each manufacturer's proprietary connector at the bottom of the phone. One single serial interface.
However, in order to use 07.10 mux in serial communication you needed to install some specific serial drivers in Windows with support for 07.10 (and I think maybe there was some reliability issue with them?), and for that reason 07.10 never took of and became anything more than an rarely used solution.
Also by the end of the 90's additional serial interfaces like Bluetooth and IrDA became available on many phones, and later USB as well, which both added additional physical interfaces as well as natively multiplexing within each protocol.
So the need for multiplexing over physical RS-232 became less of an issue, and whatever little popularity 07.10 ever had dwindled down to virtual nothing.
Fast forward a couple of decades and suddenly someone asks about it on stackoverflow. Good on you :) As far as I can tell I cannot see any fundamental problems with using it for the purpose you present.
Modern smart phones that support AT commands will most likely have a code base for the AT command parsing with roots in the 90's, which most likely include the AT+CMUX command. Of course manufacturers today have zero explicit wish for supporting it, but when it is already present it will just come along with the collection of all other legacy AT commands that they support.
So if the modem supports AT+CMUX you should be good to go. I have no experience or recommendation with regards to client protocol libraries.
I am working on a project which requires data to be sent FROM PC TO FPGA,which processes the data and sends it BACK TO PC.
The board I am using is Atlys™ Spartan-6 FPGA Development Board.
The data is to be sent as 1 byte , because 1 byte is processed at each rising edge of the clock.
Could you please suggest me ways of sending data to FPGA ?
Thanks
Pick some method of communication that you have access to IP (intellectual property) cores for. For example, if you can readily access a UDP/IP core for your FPGA, then use that. If you have to develop the HDL yourself, serial protocols (UART, I2C, etc) will be simpler blocks to write. In general, HDL takes longer to develop, debug, and test.
UDP has some advantage because you can use tools like Wireshark to capture packets on the PC (once you get past the initial hurdle of actually getting packets to/from the FPGA). Plus, many people are familiar with UDP in various programming languages (C, C++).
In any case, you'll probably spend time with an oscilloscope and logic analyzer checking out signal levels and timing when data is sent to/from the FPGA.
There's a old piece of software we run in our company that manages RFID cards tapping in/out to open doors.
We want to create an app who identifies who just touched in on a specific place (we have the id for that) and grab their 1st name, to say "Hi [NAME]" on a screen.
As I mentioned, the software is quite old and there are no APIs. It communicates with the RFID hardware via a serial port (COM1).
I was wondering if the best way to get the data I need is to somehow intercept the COM1 traffic and extract/look for the data I want.
Does this sound like the best way to go about it? Would it work, or would it be impossible to get names and numbers from the data being transferred?
Cheers,
Andre
Can you configure the software to use a port other than COM1, or configure the hardware so it's physical serial port is assigned to a different COM port?
If so, take a look at com0com. It's a Windows driver that creates two COM ports on your PC with a virtual NULL modem between them. Data going in on one side comes out on the other.
Here's how you'll set things up:
RFID Reader connected to physical COM port (COMx)
your program bridging COMx to COMy and sniffing the traffic
com0com linking COMy (for your program) to virtual COM1 (for the legacy software)
legacy software
You'll need to write a program to pass data between COMx and COMy while monitoring it for the information you're looking for. Make it simple yet robust, since if it goes down you're reader will stop working.
A Simpler Solution
If you only need to monitor one side of the communications, create a cable that connects the GND and RX pin of COM1 to another COM port. Now your program can monitor that side of the conversation, without interfering with the legacy software.
Well, generally, you can look at RS232 signals, if that's the way you want to do it. It's tricky because you need to "sniff" the signals, which means buying or making a rig that allows the original signals to go through, and then gives you a way to attach to them as well. And, you need to send the transmit and the receive signals to TWO serial ports (on the RX lines). Then you'll probably want to get some "sniffing" software that allows you to look at what you're getting in time sequence (ideally, with time-stamps). Some cutesy protocols also will use modem lines, so you may need to monitor those as well.
Or, try searching for "free serial port monitor" or "serial sniffer".
Good luck!
I have a project which the information from the microcontroller (drop rate changes of dextrose like sending notification "nearly empty" or "Sudden change of drop rate. Drop rate of 15 automatically return to 14") would display in an application in a computer. I am thinking of using ZigBee and it would be responsible for transferring the information but I am new with the technology.
Does anyone could help me how to program the ZigBee module? I have seen some articles saying that it could be programmed in eclipse CDT. I am bit confused how to get start.
Any help would be appreciated. Thanks!
Use USB Explorer device (or similar) to enter a serial terminal session on the receiving XBee.
Type ATMY to get the receiving XBee's address. Write it down.
Put the sender in the USB Explorer and type ATDL plus the receiver's address, like "ATDL798A728"
Type ATWR to save this setting.
Attach sender XBee's UART (TX and RX pins) to microcontroller.
Plug receiving XBee into USB Explorer attached to computer.
Run Processing sketch or similar to read from the serial port.
The two XBees will run by default in 'transparent mode,' which pipes data coming into one UART out of the other UART, exactly like a wire. So when your microcontroller writes data into the sender XBee, it will come out of the receiving XBee and be read (and displayed or whatever you need) by your software.
It really depends on how much configuration your installation can handle. Is this a one off installation, or a "system" of products you want to make that have to be able to work together in whatever configuration they're bought?
As already explained, xbee modules that have the whole radio + stack already setup and working for serial data are simple to use for the trivial case of you sending out a few pre-paired setups form the lab, or even site installation by an expert.
If your embedded devices have to find each other automatically, then you'd need a way to get the embedded microcontroller to get the modules discover each other, make a connection, and then have the application code in the embedded microcontrollers talk to each other and identify what they need to do with each other.
In this case, you probably would be better off with the (upfront much more complex and likely expensive) design where the zigbee stack is inside the embedded controller, so your application code can use it properly to control connectivity.
The TI zigbee pro evaluation kit is very comprehensive, and seems great to me so far. It sounds like you're at the point where you need to spend some money and get some experience with real modules, just to get a feel for the technology. Though be warned, you may need IAR embedded workbench to work with these long term, and that's pretty expensive software!
Alternatively, Atmel have a pretty interesting looking zigbee implementation with their "bitcloud" software platform (free zigbee pro stack!! woo! and they have a free ARM toolchain!) but I've found the getting started info around the bitcloud stuff is really lacking, and while I can get the code setup and compiling, I'm not confident to buy enough of their evaluation gear for a zigbee pro mesh network to test it in real life yet.
PS: if you're getting started with short range wireless, i can't recommend this book highly enough. http://www.amazon.com/Essentials-Short-Range-Wireless-Cambridge-Series/dp/0521760690/ref=sr_1_2?ie=UTF8&qid=1336091059&sr=8-2
It contains very good introduction to the different technologies available, and the strengths and weaknesses of all of them (and wireless in general) Plus it will leave you in a good position to start understanding the features you really need for the system you're designing.
some of the zigbee/xbee modules simply behave as wireless serial, no programming required just turn them on. Others require programming. It depends on what your needs really are. the ones that behave like wireless serial have an AT command set if I remember right so you can adjust some things, like for example if you want more than two (more than one wireless point to point connection) you can specify which two talk to each other...
I remember years ago my friend and i were playing command and conquer red alert and there was a mode were we put the others phone number and the game would dial up and connect. What was this called? and where can i find resource to program for this?
Dial-up Networking perhaps. You will have to learn how to control the modem. I remember there were some commands that looked like this: ATH0++ which was how you could make the modem do different things. Perhaps that will give you something to search for.
This resource looks kind of helpful: http://www.activexperts.com/activcomport/tutorials/modem/
One issue you might find is that there are two types of modems generally. One is an actual modem which is connected to your serial port. The other is what is typically known as a "winmodem" which is usually in a PCI slot and didn't have all of the functionality on the hardware but instead used the hardware drivers which typically only worked in Windows. MODEM stands for "MOdulator DEModulator" which means it just converts a digital signal to analog and vice versa.
In essence, it seems that if you can figure out how to program to the serial/com ports on your computer, you should be able to access the modem.
Another interesting link: http://en.wikibooks.org/wiki/Serial_Programming:Modems_and_AT_Commands
Have a look at TAPI (Telephony API). In Windows world there is a set of APIs in the OS for this (http://msdn.microsoft.com/en-us/library/ms737219(VS.85).aspx). The AT command set (Hayes commands) can also be used without TAPI in Windows if you treat your Modem as a COM port and send AT commands to that COM port (that's what actually TAPI does) but it isolates you from their different variants and also running initialization and other commands in a particular order.