So here is the thing, I want to conceive a universal BUS CAN adapter using stm32 with a desktop interface using Qt.
Still in the conception phase, I'm wondering how to treat the frames coming from the stm to PC GUI, weather 1) as a USB frame; in this case, how to encapsulate and decapsulate them into CAN frames and is there a Qt library to facilitate the job, or 2) as a CAN frame in this case I found the QCanBusDevice and QCanBusFrame Class which seem to be so helpful but in this case a CAN plugin must be specified during the object creation. So what should i do?
It doesn't really matter what you do because you're designing a custom protocol that rides on top of USB. Here you have an option of implementing a USB communications class device so that you don't need custom drivers nor libusb - especially given that the performance of libusb on Unixes is abysmal.
Once the data is available to the userspace, you can access it using QSerialPort. You'll have to frame the CAN frames somehow, as serial port is a stream-oriented transport and doesn't know of any packets. Most trivially, you can encapsulate the frames using RFC 1662 HDLC octet-stuffed framing. You can encapsulate the commands to your device, and their responses, in the same fashion, using one of the fields, e.g. the ADDRESS field, to multiplex CAN data and commands/responses.
If you now wish to expose this device to the Qt Serial Bus framework, you'll have to write a custom CAN plugin to access it.
To give some idea of how much code this is: total for Qt code and microcontroller code should be well under 1500 lines for a proof-of-concept. A minimal demo would be probably <400 lines of Qt code and <400 lines of STM32 code.
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 have the following: STM32F407G-DISC1. My goal is to communicate (sending strings back and forth) between my pc and the mcu over serial and I currently am able to do so using the micro-usb (otg) port, while powering separately using the mini-usb st-link port (so using two cables).
Is it possible to use the mini-usb port for serial communications? (eliminating one of the cables)
I have read the user manual and my interpretation is that this is not possible without physical modifications. But I am a beginner and would like to verify I am correct in this interpretation. I have researched thoroughly however most sources seem to not refer to this specific board and it is my understanding with the newer version of st-link it uses this should be achievable.
It is possible - just send the messages via the USART2
You need to solder those two wires as they screw up the design.
I have some nodes with installed Xbee s2 on them. the zigbee modules configured as routers and coordinator, in zigbee mesh topology. I want to send data from each node to some other nodes.
question:
how I have to send data? here is a pseudo code that I have in mind. I want to know if there is any API in zigbee stack that I can use for this, and if I miss anything:
init_network;
fragment_data_to_frames;
fork();
if(process_is_parent)
for(i=0;iMbum_frames;i++){
send_frame(i);
wait(x miliseconds)// how much do I have to wait? or do I have to wait upon receiving ack,i.e. wait(ack(i));
}
}
if(process_is_child){
check_acknowledgment_packets();//does zigbee notify me that the frame is lost? or I have handle it by myself, e.g. by assuming frame is lost after specific time.
}
resend_lost_frames;
in the destination node, how I can retrieve the data? Do I have to handle it by myself by checking the sequence number and profile, and concatenating the packets? or Zigbee stack will do it for me.
XBee radio modules in API mode will generate a "Transmit Status" frame to indicate that a frame number was received by the remote module. There's no guarantee that the host on the other side successfully processed it, since it's a network-layer acknowledgement and not application-layer.
How much data are you planning to send? ZigBee was designed for low-speed, low-volume data transmission. If you're just using XBee modules, you can make use of their proprietary protocols (like transparent serial). For interoperability, you'll need to read up on the ZigBee Cluster Library and how it uses general commands and attributes to transfer information between nodes.
I am currently working on a project for my university course. I am design a device which will be an intermediate interface between the computer and a USB flash drive, i.e. data go from computer->my device->USB drive.
One of the functions I want on this device is to be able to detect if there is any data activity going on, and send this information to the microcontroller. I don't need to know anything about the data itself, just whether there is data being transferred.
I've done some research online about how USB works, but I can't seem to find a good way of doing this. I have spoken to a tutor at uni. Apparently this is "very easy" to do, but I don't really know how. Can anyone suggest some ideas? Thanks very much.
In this case the simplest way is to use additional soft which can log USB protocol as well as a microcontroller, like USBlyzer (http://www.usblyzer.com/) or USB data capture (http://www.eltima.com/products/usb-capture/)
You need to insert your flash drive to device which is plugged to USB port in your computer. Then run USB data analyzer software and find the USB port. That's all! After that you can monitor and analyze all data between microcontroller and the app. Moreover, you can save and export captured data
Your tutor not quite right.
USB bus always have activity, even if no data transferred.
Carefully read USB specification (http://www.usb.org/developers/docs/), especially 'Protocol layer' section. Some basics you may read in 'USB in a nutshell' article.
Explore bus with oscilloscope.
Also you may use software analyzers like http://desowin.org/usbpcap/ or http://freeusbanalyzer.com/ to explore data on bus.
I think, will be enough to capture all packets on bus with external microcontroller, measure their duration and sort waste SOF packets and valuable data packets.
Sure, your microcontroller must be fast enough, to keep pace of USB 2.0 bus. Detection of activity of low-speed devices, like keyboard, will be much simplier, and may be done even with arduino.
You are trying to make a protocol analyzer like catc http://teledynelecroy.com/protocolanalyzer/protocolstandard.aspx?standardid=4
These is a device which is like man in middle for any network.
You would need your device to act as USB host(master) and USB device(slave) at same time. Also while copying data from one port to another you need to make a data copy for analysis. USB devices have critical timing requirements and operate at high data rate. So you might need good amount of processing power in your device. Also this makes such analyzers expensive.
If there is no requirement for analyzing USB protocol, you can have device that will analyze slower buses like uart,spi I2c etc.You can check hobby manufacturers like sparkfun for such tracing devices.
Best luck with your endeavor
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...