change the DCB structure of a boost::asio::serial_port - serial-port

I'd like to disable RTSControl using boost::asio::serial_port::set_option function. and also be able to raise or lower the DTR line?
boost::asio::serial_port_base::baud_rate baud_option(115200);
serialPort.set_option(baud_option);
The standard options work great, but I can't figure out, how to change the
DCB structure, or how to control the RS232 signal lines.

Settable serial port option requirements (emphasis mine):
In the table below, X denotes a serial
port option class, a denotes a value
of X, ec denotes a value of type
error_code, and s denotes a value of
implementation-defined type storage
(where storage is the type DCB on
Windows and termios on POSIX
platforms), and u denotes an
identifier.

Related

How to enable scattered mode in DPDK?

I set the dataroom of the mbuf from 2048 to 64B. To receive large packets(>64B) with a 64B size dataroom mbuf, DPDK reminds me that I need to enable scattered mode. So how can I enable scattered mode?
Rx scatter can be enabled at the stage when rte_eth_dev_configure() is invoked. To do that, one should pass flag RTE_ETH_RX_OFFLOAD_SCATTER via dev_conf.rx_mode.offloads, with dev_conf being passed by pointer as the last argument to rte_eth_dev_configure().
To check the feature with testpmd, one can pass command-line argument --enable-scatter.

Sending 20-byte characteristic values with CurieBLE

The documentation for Arduino/Genuino 101's CurieBLE library states the following, in the section "Service Design Patterns":
A characteristic value can be up to 20 bytes long. This is a key
constraint in designing services. [...] You could also combine readings into a single characteristic, when a given sensor or actuator has multiple values associated with it.
[e.g. Accelerometer X, Y, Z => 200,133,150]
This is more efficient, but you need to be careful not to exceed the 20-byte limit. The accelerometer characteristic above, for example, takes 11 bytes as a ASCII-encoded string.
However, the typed Characteristic constructors available in the API are limited to the following:
BLEBoolCharacteristic
BLECharCharacteristic
BLEUnsignedCharCharacteristic
BLEShortCharacteristic
BLEUnsignedShortCharacteristic
BLEIntCharacteristic
BLEUnsignedIntCharacteristic
BLELongCharacteristic
BLEUnsignedLongCharacteristic
BLEFloatCharacteristic
BLEDoubleCharacteristic
None of these types of Characteristics appear to be able to hold a 20-byte string. (I have tried the BLECharCharacteristic, and it appears to pertain to a single char, not a char array.)
Using CurieBLE, how does one go about using a string as a characteristic value, as described in the documentation as an efficient practice?
Yours issue described here in official arduino 101 example. Few strings of code how to set an array:
BLECharacteristic heartRateChar("2A37", // standard 16-bit characteristic UUID
BLERead | BLENotify, 2);
...
const unsigned char heartRateCharArray[2] = { 0, (char)heartRate };
heartRateChar.setValue(heartRateCharArray, 2);
As you can see characteristic's value set using "setValue" function with desired array as an argument. You can pass a String as char* pointing to an array.

Read USB to Serial port Info in Xojo

I am writing a simple code to find the USB to serial port in Windows platform, if the port is what I want (can be filt by VID/PID number), then the program will open the port.
I use MonkeyBread plugin, WinUSBDeviceMBS, with property of VendorID and ProductID, I can select specific USB port. sample code as following.
Dim devices() As WinUSBDeviceMBS = WinUSBDeviceMBS.devices
For Each d As WinUSBDeviceMBS in devices
msgbox d.vendor+"-" + str(Hex(d.VendorID),"0000") + " " +d.product+"-" + str(Hex(d.ProductID),"0000")+d.serialnumber
Next
'this will give you a message box with "FTDI-0403 FT232R USB UART-6001 A60251HV"
Also, with help of Serial.serialport.Name, I can get the COM port name for serial device.
dim i, count as Integer
count = System.SerialPortCount
for i = 0 to count - 1
Msgbox System.SerialPort( i ).Name
next
'this will popup msgbox with "COM1" or "COM3"... all the valid port number, but no vendor info or product info
But I can't find a method to match those two together. Any ideas?
Assuming you are only using Windows you will need to use the registry to get this information.
You can get a list of all COM ports on the system here: HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM. Values will be listed according to their type, so a real serial port will show up with a name \Device\Serialn and data COMxx, other devices might be different. If you look here you can find a name you can use to filter which type of device a COM port belongs to, then simply list these in your application.
You can do this in Xojo by using the Declare statement to hook into the API of the Windows DLLs:
https://docs.xojo.com/index.php/Declare
Here is a document on the Registry API functions, they will be used as described here, but using the Declare statement mentioned above:
http://support.microsoft.com/kb/145679

Using ElectricImp server.show() and Arduino

I'm following the sparkfun tutorial for connecting an arduino to electric imp. I only have one arduino and imp, so I'm trying to get whatever I type in the arduino serial monitor to display in the imp node using server.show().
I've modified one of the functions in the sparkfun code to look like this:
function pollUart()
{
imp.wakeup(0.00001, pollUart.bindenv(this)); // schedule the next poll in 10us
local byte = hardware.uart57.read(); // read the UART buffer
// This will return -1 if there is no data to be read.
while (byte != -1) // otherwise, we keep reading until there is no data to be read.
{
// server.log(format("%c", byte)); // send the character out to the server log. Optional, great for debugging
// impeeOutput.set(byte); // send the valid character out the impee's outputPort
server.show(byte)
byte = hardware.uart57.read(); // read from the UART buffer again (not sure if it's a valid character yet)
toggleTxLED(); // Toggle the TX LED
}
}
server.show(byte) is only displaying seemingly random numbers. I have an idea of why this is, I just don't know how to fix it because I'm not that familiar with UARTs and squirrel.
local byte = hardware.uart57.read(); reads in the ascii characters from the arduino in byte form (I think), and they're not being 'translated' into their ascii characters before I use server.show(byte).
How do I do this in squirrel?
Also, I think polling every 10us is the wrong way to go here. I'd like to only poll when there's new information, but I also don't know how to do that in squirrel. Can someone point me to an example where this happens?
Thanks!
I think you are passing the wrong data type to the show method of the server object. The electric imp docs state that it takes a string, server.show(string). I think that local is the correct type to receive the value from hardware.uart57.read(). You can tell from the docs as well. So, you need to find a way to cast your byte to a string. I bet you could find the answer here. From what I read Squirrel use's Unicode so there is a probably a function that takes Unicode bytes and loads them into a string object.

UUIDs and byte-swapping over network

Is there are a standard accepted way to byte-swap UUIDs for transmission over a network (or file storage)? (I want to send/store the 16 raw bytes rather than convert the UUID to a string representation.)
I thought at first I should partition the UUID into 4 32-bit integers and call htonl on each of them, but that didn't smell right. A UUID has internal structure (from RFC 4122):
typedef struct {
unsigned32 time_low;
unsigned16 time_mid;
unsigned16 time_hi_and_version;
unsigned8 clock_seq_hi_and_reserved;
unsigned8 clock_seq_low;
byte node[6];
} uuid_t;
Would it be correct to do:
...
uuid.time_low = htonl( uuid.time_low );
uuid.time_mid = htons( uuid.time_mid );
uuid.time_hi_and_version = htons( uuid.time_high_and_version );
/* other fields are represented as bytes and shouldn't be swapped */
....
before writing, and then the correpsonding ntoh...calls after reading at the other end?
Thanks.
Yes, that is the correct thing to do.
Each number (time_low, time_mid, time_hi_and_version) are subject to byte ordering. the node field is not. clock_seq_hi_and_reserved and clock_seq_low are also subject to byte ordering, but they are each one byte, so it doesn't matter.
Of course, it is up to you to make sure that you choose the right ordering on both ends, or understand what the ordering is on the other end if you don't control it. Microsoft of course uses little endian for their UUIDs. You can see Microsoft's definition of a UUID here.

Resources