I'm writing a Qt 5.5.0 app that communicates with a BLE peripheral LinkitONE. The peripheral is pre-programmed in such a way that to read or change a variable first I have to write the variable name into a specific characteristic and then either read or write the data from another characteristic.
I write with QLowEnergyService::writeCharacteristic and read with QLowEnergyService::readCharacteristic. It all works well unless I have to read or write anything longer than 20 bytes in which case the data is cut at the end. Is there any way to either increase the write buffer size or specify the offset for writing?
Related
I am using Windows 10, VS 2019, C++, WinRT
I have a questions about writing to a Tx characteristic after I have connected 2 devices with the same Tx characteristics. I want to control 2 identical BLE devices separately. I have all of the code in place for connecting and running 1 of these devices but as I studied my existing code I don't see that the characteristic write refers to a particular device object.
The device objects are created with
auto device1 = co_await BluetoothLEDevice::FromBluetoothAddressAsync(deviceAddress1); // Same with device2
I then get the main service and the Tx and Rx characteristics which are the same for device1 and 2.
After setting up the writer with
auto writer = Windows::Storage::Streams::DataWriter();
and then filling in the command to be written with
writer.WriteString(wstrCommand);
I then do the actual write to the Tx characteristic with
status = co_await TxCharacteristic.WriteValueWithResultAsync(writer.DetachBuffer(),
winrt::Windows::Devices::Bluetooth::GenericAttributeProfile::GattWriteOption::WriteWithoutResponse);
To which device would this command be sent? Am I leaving out a reference to the device1 or device2 object?
Edit
Is it that the TxCharacteristic object contains the Service object with contains the deviceID and therefore if I write to TxCharacteristic1 and 2 it will write to the proper device? I guess I will have to do the code and find out.
Thanks.
Ed
The answer is that the Characteristic object will write to the device object from which it was read. My original mistake was to be thinking of the characteristic as the GUID and forgetting that in WinRT the characteristic is an object that contains properties (one of which is the Uuid) which contain properties. I have not looked at the WriteValueWithResultAsync code but it appears that the code will direct the write to the characteristic of the device associated with that characteristic so you need to keep the characteristic objects separate.
What I had to do was alter my memory variable names from TxCharacteristic to TxCharacteristic1 and TxCharacteristic2 and, of course, put in a lot of if...else clauses. I also had to create RxCharacteristic1 and RxCharacteristic2 and to create 2 separate Rx callbacks. Live and Learn.
I'm building a firmware for a device based on Atmel/Microchip AT SAMG55.
In a simple function, trigger some relais connected to GPIO pins.
Because I want to interlock different I/O, avoiding that 2 specific outputs are high level on the same time, I need to know the pin level I set before.
In another project, based on the SAMD21, there was a function that reads output pin state
static inline bool port_pin_get_output_level(const uint8_t gpio_pin)
The SAMG55 port library in ASF is quite different, so i tried ioport_get_pin_level(pin), but i'm not getting expected result. I think that it works only with pins configured as inputs.
Are there any recommended solutions?
Referring to Figure 16-2 in the SAMG55 data sheet, and to sections 16.5.4 and 16.5.8:
16.5.4 Output Control
... The level driven on an I/O line can be determined by writing in the Set Output Data Register (PIO_SODR) and
the Clear Output Data Register (PIO_CODR). These write operations,
respectively, set and clear the Output Data Status Register
(PIO_ODSR), which represents the data driven on the I/O lines. ...
16.5.8 Inputs
The level on each I/O line can be read through PIO_PDSR. This register indicates the level of the I/O lines regardless of their
configuration, whether uniquely as an input, or driven by the PIO
Controller, or driven by a peripheral. Reading the I/O line levels
requires the clock of the PIO Controller to be enabled, otherwise
PIO_PDSR reads the levels present on the I/O line at the time the
clock was disabled.
So, as long as the pin is configured such that the actual level on the pin always corresponds to the level we're trying to drive - which is not the case with an open collector configuration, for example - then Tarick Welling's answer is correct: you can read the output state from the Output Data Status Register (PIO_ODSR).
However the true state of the pin, regardless of driver configuration, can be read (subject to a resynchronisation delay that may or may not be relevant in any given application) from the Pin Data Status Register (PIO_PDSR).
You can do some low level programming. You use the high level HAL functions to configure, set and reset the pins but before you do that you would. Read the value for the pin by addressing the data value of the register. In AVR that would be done by reading PORTx. In a STM32 this can be done by reading the value of GPIOx->ODR. You would of course then need to extract the correct pin but this can be done.
You can also look inside the definition of port_pin_get_output_level and check how they did it and convert that into the way this board/vendor/HAL does its addressing.
update:
When looking inside the datasheet for the SAM G55G/J. Page 340 gives us the answer we need.
The level driven on an I/O line can be determined by writing in the Set Output Data Register (PIO_SODR) and the
Clear Output Data Register (PIO_CODR). These write operations, respectively, set and clear the Output Data
Status Register (PIO_ODSR), which represents the data driven on the I/O lines.
So we can drive the output by writing to PIO_SODR and PIO_CODR to set and reset the pins respectively. But also read from PIO_ODSR this is a register which contains the state of the pin.
A quick google search turns up two options for Atmel/AVR controllers:
read back from the same location you used to set your output value (PORTx register)
This will give you the value that you have written into the register before.
read the actual value using the PINx registers
This will give you the value that you could actually measure on your device.
The difference between the two can be important: if you set a GPIO that is pulled down below the logic voltage threshold (i.e. if connected to GND) to HIGH, PORTx will read HIGH (the value you set) while PINx will read LOW (the actual value).
https://www.avrfreaks.net/forum/reading-pin-set-output
I have been writing lots of different kinds of Sketches for Arduino, but there is something I have not heard if it is possible.
I would like to be able to get an Arduino to save preferences that can be restored back when the Arduino restarts. The kind of data that you want to change (in the field) without having to hardcode it in the sketch, or needing to upload changes from the IDE.
Examples:
Thermostat settings
Time lapse camera frame rate
So if I set the thermostat for 68° and the power goes out, I want it to remember what temperature I set when the power comes back on.
Unless you have a large amount of settings that you wish to save, EEPROM should suffice for your purposes. What I would do is define a struct to store the relevant options, and use the EEPROM library to read/write the entire struct.
A wonderful example of how to do that exists on the Arduino reference pages:
EEPROM Put
I was hoping to do some kind of open file, read/write operation like you can do in php, where I can read/write whole strings at a time
There is really no need to do this unless you have a large amount of options. Otherwise your best bet is to use something like an SD card, which does support FileIO operations
Seems you looking for Arduino EEPROM
EEPROM: memory whose values are kept when the board is turned off (like a tiny hard drive). This library enables you to read and write those bytes.
I'm developing a desktop application with qt which communicates with stm32 to send and receive data.
The thing is, the data to transfer, follow a well-defined shape, with a previously defined fields. My problem is that I can't find how read () or readall() work or how Qserialport even treats the data. So my question is how can I read data (in real time, whenever there is data in the buffer) and analyze it field by field (or per byte) in order to be displayed in the GUI.
There's nothing to it. read() and readAll() give you bytes, optionally wrapped in a QByteArray. How you deal with those bytes is up to you. The serial port doesn't "treat" or interpret the data in any way.
The major point of confusion is that somehow people think of a serial port as if it was a packet oriented interface. It's not. When the readyRead() signal fires, all that you're guaranteed is that there's at least one new byte available to read. You must cope with such fragmentation.
I'm working on a project with an Arduino, and I'd like to be able to save some data persistently. I'm already using an Ethernet shield, which has a MicroSD reader.
The data I'm saving will be incredibly small. At the moment, I'll just be saving 3 bytes at a time. What I'd really like is a way to open the SD card for writing starting at byte x and then write y bytes of data. When I want to read it back, I just read y bytes starting at byte x.
However, all the code I've seen involves working with a filesystem, which seems like an unneeded overhead. I don't need this data to be readable on any other system, storage space isn't an issue, and there's no other data on the card to worry about. Is there a way to just write binary data directly to an SD card?
It is possible to write raw binary data to an SD card. Most people do this using the 4-pin SPI interface supported by the SD card. Unfortunately, data isn't byte-addressed, but block-addressed (block size usually 512 bytes).
This means if you wanted to write 4 bytes at byte 516, you'd have to read in block 0x00000001 (the second block), and then calculate an offset, write your data, then write the entire block back. (I can't say that this limitation applies to the SD interface using more pins, I have no experience with it)
This complication is why a lot of people opt for using libraries that include "unneeded overhead".
With that said, I've had to do this in the past, because I needed a way of logging data that was robust in the face of power failures. I found the following resource very helpful:
http://elm-chan.org/docs/mmc/mmc_e.html
You'll probably find it easier to make your smaller writes to a memory buffer, and dump them to the SD card when you have a large enough amount of data to make it worthwhile.
If you look around, you'll find plenty of open-source code dealing with the SD SPI interface to make use of directly, or as reference to implement your own system.