I want to connect the module HC05 (with UART protocol) to Raspberry pi and see the receiving result on wxwidgets (code-blocks GUI).
where can i write UART code in wxwidgets?
How can i write each protocol in wxwidgets?
wxWidgets doesn't provide a uniform API for communicating with serial ports, as explained here.
The Raspberry Pi is typically running a Linux distribution where serial ports are exposed as special device files such as /dev/stty0. Consult your favorite Linux/Raspberry Pi documentation for information on how to configure serial port parameters. Once configured, just read/write to the file in order to communicate with whatever devices is attached to the port.
Related
I am trying to integrate an RFID1356MIFARE, which uses NXP PN532, with an ESP32-EVB using their UART capabilities.
The NXP docs states that the PN532 is able to communicate on High Speed UART.
I am trying to use 38400 because that's the baud rate fixed by the reader that I'm using.
I've found a modified Adafruit PN532 library that added HSU support. This library states that HSU uses 115200 baud rate.
Now, I've modified PN532_HSU.cpp, where we can find:
void PN532_HSU::begin()
{
_serial->begin(115200);
}
into
void PN532_HSU::begin()
{
_serial->begin(38400, SERIAL_8N1, 36, 4);
}
Unfortunately, I haven't been able to establish communication between the reader and the ESP using this method.
I am able to get a readable output using normal Serial.read(), so UART communication works, but that's not how you read MIFARE cards.
I don't know what the problem is.
What do you think ?
[EDIT]
I went through the documentation and here is what i suggest: If you have a USB to serial device use it to directly connect reader module to computer else connect it directly using mini USB port in module. the follow following steps:
Put device in UART/ USB CDC mode depending on how you connected device to computer. Exact method to do this is provided in operation section of documentation
Use picoterm / screen or other serial terminal (if you are using Linux) or just use Arduino serial monitor with correct baud rate to connect device.(115200 for USB and 38400 for UART)
Type in commands listed in COMMAND SET FOR CDC AND UART MODE section in documentation to check if module is working or not.
Place some cards over reader to check what response does module sends when card is detected.
Use this information to develop your own library for reader.
It will not work with regular PN532 libraries. Instead you'll need to use regular Serial read and write to communicate.
[Original]
PN532 datasheet says host interface is selected by pulling up/down I0, I1 pins of device. For HSU both pins must be pulled down. This is implemented in hardware so you need to verify if the mode you want to use is set.
Looking into the link you posted for module, it says that it uses another micro-controller on board to extend communication capabilities, so maybe you need to use driver for that specific controller firmware? The link seems to have document explaining how to setup different communication system in Document section, please have a look there and check if it works.
Link: https://www.olimex.com/wiki/MOD-RFID1356MIFARE
I possess the USRP X310 with a Basic TX daughterboard installed. My plan is to use it via 10GbE together with LabView with a Win10 host machine.
I have connected the SDR with an Ethernet cable using Port 0 and the included SFP adapter to my host PC's (1GbE) ethernet interface for network testing purposes. The ethernet adapter is configured to use the static IP 192.168.10.1. Furthermore I have installed the UHD (uhd_3.15.0.0-release_Winx64_VS2017.exe). However when the device is connected and powered on, I can neither ping 198.168.10.2 nor detect it running the uhd_find_devices.exe. I have also started the NI-USRP Configuration Utility which I recently updated but it was not able to detect the SDR either. I do observe that none of the LEDs on the back is illuminated (especially not the Port 0 ethernet).
How can I get it working?
If you've worked with other usrps (I have a few), then you'll find the X310 to be somewhat different, to the lower models.
Anyway, there are different fpga loads / images, which corrospond to whether you are trying to connect via a 1G or 10G module.
"The PCIe interface is always available regardless of what FPGA image is loaded. Ettus ships two FPGA image variants, the HG or HGS image which has one 1 GigE interfaces and one 10 GigE interfaces, and the XG image which has two 10 GigE interfaces.
So you need to be sure you have the right image to connect to it via 1GE... or I expect it won't work, as it seems to be.
HTH's.
I'm looking to write a simple Windows driver to enable running TCP/IP over a proprietary RF module. The module already provides Ethernet-style data packets with source/destination MAC, so I just need to layer IP packets (generated by the regular Microsoft IPv4 subsystem), set the MTU appropriately so they will be the right size, and then call the module's serial API. I'll need to be able to handle transmit statuses and implement an ARP protocol as well. I want the driver to expose a new interface similar to a wifi or ethernet card in Network Connections and use the normal Windows IP stack.
The module is UART and might be connected via FTDI chip, RS-232 converter, or native UART on an IoT Core board, so it will just be talking to a generic serial port. I am fine with only running on Windows 10, but I'm still not sure what to use. Can I use the UWP VPN provider? Do I need to write an NDIS miniport driver, or an interface provider? Also, how will I handle the driver needing complete control over the serial port at all times? I can't write a serial driver as it might be connected via many different types of serial ports.
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
I need to create a Cocoa app that will create a virtual serial port available to other apps, meaning registered in the IO Kit Registry.
Gist of the app:
Create a virtual serial port (listed in /dev and registered with the IOKit Registry)
Initiate a tcp connection out to another computer
Proxy everything received on the virtual serial port out to the
network and vice versa.
This app will be used by third party apps that talk to serial ports on the computer, allowing for the particular serial device to be located across the network. The Cocoa and network part is no problem, I've written several apps that talk over the network. My hangup is the serial port.
I've done the test with socat/netcat/minicom to verify that it all works to proxy pty/tty traffic over the network but the tty I use doesn't show up as usable by random applications because it's not registered in the IO Kit Registry.
While I can use a pty/tty master/slave for the communication, I need this slave tty to show up to Mac applications. What would be very handy is a way to register a tty in the IO Kit Registry.
Do I really need to create a custom IOKit kext driver that gets registered at Cocoa app runtime? If so, I have a big learning curve ahead of me. Where should I start reading? Or, can I use IOKit to create a virtual serial port and register it as a usable serial port for applications without having to load any kernel extensions?
Thank you for any help you can provide,
Stateful
First of all, have you checked if you can borrow a solution from this app? It's not obvious from the website if they've managed to get their virtual serial ports fully integrated into the system.
If there is a way to do it from user space, I'm not aware of it. The user-space IOKit API generally doesn't let you create class instances, let alone new device driver classes. Maybe you can somehow otherwise persuade the Cocoa libraries to find it despite not being registered in the kernel.
I don't know if you could get away with creating a "dummy" serial port in the kernel and then move your tty into its place in /dev from your userspace daemon. Maybe that's an option.
In case you do have to do it all in the kernel:
The virtual driver itself shouldn't be too much work, at least, though it will require some time to get up to speed with kernel dev. Unfortunately, the documentation is pretty thin for serial port drivers - the key is subclassing the IOSerialDriverSync abstract class. Just about the only description I've seen is in Ole Henry Halvorsen's OSX and iOS Kernel Programming book. It also has a fragment of an example for the reading & writing operations. (disclosure: I was one of the tech reviewers for this book; I don't receive any incentives for recommending it - in this case it's literally the only documentation I know of) You can find the source for a complete serial port driver in Apple's USBCDC driver, AppleUSBCDCDMM is the class that actually represents the serial port node.
It's relatively straightforward to open a so-called "kernel control" socket in the kernel, the individual APIs are documented here; from user space you use the normal BSD socket send/recv APIs. (this is also described in the aforementioned book) Your daemon can then connect to that, and all you'd need to do is push the data between the socket and the virtual serial port device. You'll need to handle disconnect events and such correctly of course.
Still, I think this is achievable as a first kernel project for an experienced C programmer (with some C++).
I hope that helps!