|
Re: Performance analysis tooling
I’d you’re using a Segger J-Link, you might find this useful:
Hello.
Are there any performance analysis tools that can help gain a sense of where and how much CPU time is consumed more? For comparison, the gprof tool under Linux provides such capability for user space programs. For Linux kernel profiling one is oprofile.
|
|
|
Olga Syrbachova <syrba4eva28@...>
Hi! I'm trying to create my own app. I decided to start by modifying a "synchronization" sample. In my app I want to have 2 threads and 1 queue, so one thread can send messages to this queue and another thread is reading messages from the queue. I didn't find any sample with queues and I'm not sure how exactly to make queues. And I don't understand what I should put in "data" here:
void producer_thread(void)
{
struct data_item_type data;
while (1) {
/* create data item to send (e.g. measurement, timestamp, ...) */
data = ...
/* send data to consumers */
while (k_msgq_put(&my_msgq, &data, K_NO_WAIT) != 0) {
/* message queue is full: purge old data & try again */
k_msgq_purge(&my_msgq);
}
/* data item was successfully added to message queue */
}
}
Data is of type struct data_item_type and it has 3 items in the example on the website. Does it mean I have to initialize my data in this way for example: data.field1 = 2; /* int = 2 */
data.field2 = 3; /* int = 3 */
Can you please suggest any sample with queues or tell me what I am doing wrong? Many thanks in advance.
|
|
|
Performance analysis tooling
Hello.
Are there any performance analysis tools that can help gain a sense of where and how much CPU time is consumed more? For comparison, the gprof tool under Linux provides such capability for user space programs. For Linux kernel profiling one is oprofile.
|
|
|
Dmitry Shichenko <dsh@...>
Hello! I'm Dmitry, working in Moeco to create IoT solutions for the b2b market. We're settling a new project - bluetooth temperature \ himidity sensor in connection with gateway, based on bluetooth long range. Right now we're testing nRF52840-DK on Zephyr hci-UART firmware to operate in HCI-UART (HCI only driver) mode, and Raspberri PI4 to operate host mode. We faced some problems caused by the Linux kernel (Raspberry pi4) using BlueZ stack, which does not support Bluetooth long range. Could you please help to find a bluetooth stack supported long range technology under linux kernel? Due to the fact Zephyr supports BT long range, there was info regarding this technology counterpiece. Thanks for your help! -- Best regards,
Dmitry Shichenko | Moeco | Project manager 
|
|
|
Hi,
I have successfully implemented OTA DFU using the smp_svr sample on my nrf52840dk. I'm now worried that anyone can connect to the device and update the firmware remotely using the nrf connect mobile app. Is there a way to request a passkey from the nordic nrf connect app when it tries to connect to the nrf52840dk?
|
|
|
Re: Error by building own app
Probably, you need to set some environment variables.
Look here for an explanation:
https://docs.zephyrproject.org/latest/guides/env_vars.html#zephyr-environment-scripts
|
|
|
Error by building own app
Olga Syrbachova <syrba4eva28@...>
Hi! I want to create my own app. So I've followed the instructions given on the website https://docs.zephyrproject.org/latest/application/index.html. For the beginning I just copied the src/main.c, CMakeLists.txt (here I changed the project name to "my_app") and orj.conf from zephyrproject/zephyr/samples/hello_world to Home/app. Next I ran west build -b qemu_x86
and got an error:
ol@ol-H270M-DS3H:~$ west build -b qemu_x86 ~/app
usage: west [-h] [-z ZEPHYR_BASE] [-v] [-V] <command> ...
west: error: argument <command>: invalid choice: 'build' (choose from 'init', 'update', 'list', 'manifest', 'diff', 'status', 'forall', 'help', 'config', 'topdir', 'selfupdate')
I also tried to run this command with --pristine, but it didn't work. What am I doing wrong? Any help would be highly appreciated. Thank you in advance.
|
|
|
Re: ODP: ODP: [Zephyr-users] console_getline vs 0ms char delay in UART comms
Piotr Barszczewski <piotr@...>
Had high hopes that it might have been this missing line in DTS but it didn’t change anything in the end.
Best regards,
On 18 March 2021 at 17:36:29, Chruściński, Krzysztof (krzysztof.chruscinski@...) wrote:
regards,
Krzysztof
Hello
Krzysztof,
Good
point, forgot to mention that. Flow control pins are specified in
DTS as well as FT232R has FC lines connected to nRF52832. Changing
FC settings in Cutecom doesn’t change anything and data is
corrupted as before.
Best regards,
Piotr
On 18 March 2021 at 15:08:13, Chruściński,
Krzysztof (krzysztof.chruscinski@...)
wrote:
Hi,
do you have flow control enabled? When it is disabled then
after each byte receiver is stopped and restarted after reading the
byte. Restarting may happen when transmitter is already started, in
the middle of the byte. In that case, byte will be
corrupted.
regards,
Krzysztof
I actually was about to check the
signals out of curiosity and sending them in the attachment. All of
the following were done with 8N1 @ 115200 and flashed
with https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html having different DTS for the custom board of course.
Every time I’ve sent "1234\r\n” to the nrf52832-QFAA chip and
connected with the probes directly to UART
lines.
I’ve checked the PCBs on Linux and OSX to get rid of
suspicion that the OS drivers might somehow be involved in makig
things funny.
- nrf52832-DK-0ms-delay.png - nRF52832 DK with 0ms delay
set. All ok
- nrf52832-DK-1ms-delay.png - nRF52832 DK with 1ms
delay set. All ok
- nrf52832-pcb-UART-0ms-char-delay.png - the tested custom
PCB with 0ms delay. Data gets corrupted actually on TX and RX but
what is returned is different thatn what is sent
- nrf52832-pcb-UART-1ms-char-delay.png - As above but 1ms
delay. All ok
- nrf52832-pcb-UART-OSX-0ms-char-delay.png - Same as 3 but
on OSX using Coolterm
- nrf52832-pcb-UART-OSX-1ms-char-delay.png - Same as 4 but
on OSX using Coolterm
I’ve also tried changing to
8N2 but the result was the same.
From
the nrf52832-pcb-UART-0ms it looks like the RX corruption
happens when nrf52832 starts transmitting but then it handles every
n-th byte correctly. What is even stranger is that the analyzer
gets a different value than what was sent and what nRF52832
received. I don’t really understand what could be the difference as
both are nrf52832 (same frequency clocks) in the end, the only
thing that is different is the way USB-UART converter is made and
handled on OS level. Though I can’t really say that FT232R has
failed like that before. It’s just this particular firmware and the
way it handles the data.
I will try to find some
USB-UART converter which will enumerate as ttyACM device on my
Linux, unsolder the FTDI chip and try talking through ttyACM it
instead of a /dev/ttyUSB one. Maybe there is something to
it.
Best regards,
On 17 March 2021 at 23:49:09,
Lawrence King (lawrence.king@...)
wrote:
I wasn’t suspecting your
FT232R HW, just how the various terminal programs set up the HW may
be different. When all other debugging fails, nothing beats the
certainty of capturing the waveforms with an oscilloscope and
validating that all of the characters were sent, and the signal
levels are good. But you are not likely to this level of debugging
yet.
When you are using cutecom, try
setting to 8N2. This adds one extra bit time between characters
which a lot less than 1mS and may be enough that you stop dropping
characters.
What baudrate are you running at?
The usual 115200? Do you see the same problem if you try slower
speeds like 38400 or 19200? Of course you need to change both ends
of the link if you select an alternat baud rate.
Finally, what processor and
processor clock rate are you running, you may simply be sending
characters faster than your processor can respond to interrupts and
receive the characters (which would make sense if you are missing
every second character).
Lawrence King
Principal Developer
+1(416)627-7302
From: Piotr Barszczewski
<piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>;
users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char
delay in UART comms
Thank
you for your reply. I’m working with 8N1 and the USB-UART is FT232R
of which I’m pretty certain that it’s working correctly. It works
with other firmware, developed with older Nordics SDK and haven’t
experienced issues with it yet. In my experience I’ve narrowed it
down to the 0ms delay in Cutecom making the getline console example
to loose some characters on hadrware which works ok with different
firmware with the same Cutecom settings.
As
for hardware design it uses a schematic which has been validated by
FTDI support as on a different device we’ve been experiencing
different issues so I find it unlikely that it would be at blame
here.
On
17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...)
wrote:
Hi
Piotr
There
are may be pieces of equipment along the path between cutecom
and the serial input on your micro-controller. Usually there is a
USB to Serial chip. The programs inside screen and cutecom set
parameters in the USB2Serial chip. Specifically I would be worried
about the number of databits and stop bits, also parity. The
‘normal’ setting is 8N1 which means send a start bit, 8 data bits,
no parity bits, and a single stop bit. However if cutecom selected
7N1, or screen selected 8N1 and the serial port on your Zephyr
board was set to 8N2 you would see these types of
problems.
Curiously
you are consistently loosing the characters with Even parity. Is
your Zephyr board set up to expect 7O1?
You
need to look at the data being send from the USB2Serial adapter and
ensure that it is valid. I have never had a problem with Zephyr
dropping characters, but it really depends on your board, and
kernel options.
Lawrence
King
Principal
Developer
+1(416)627-7302
From:users@...
<users@...>
On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in
UART comms
I’ve
been reviewing code from a colleague, which (code, not the
colleague) is heavily based on the
https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve
been experiencing some unexpected behaviour when using CuteCom vs
screen to communicate with the console. I’ve dug deeper and deeper
and eventually it seemed like the value returned
by console_getline function was indeed already corrupted. In
screen everything worked fine.
My
assumption was that when I’m using screen each character is passed
1-by-1 to a buffer and everything is golden. On the other hand
CuteCom buffers the input until I press enter and fires away at the
serial port - pretty much like M2M communications would work over
UART.
This
is an example of the output of FW when sending “1234” over Cutecom
with 0ms delay (which is what I have been using +/-
forever):
[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@
In
the end I’ve changed CuteComs char delay to 1ms and everything
works well:
[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊
Is
there some simple CONFIG_ argument to change this? I’ve looked in
menuconfig but without luck.
It’s
not much of a problem to instruct every user of the FW to change it
to 1ms but I’m a bit concerned about using various scripts to
communicate with the firmware which will use the console. Depending
on the implementation of serial driver it might require additional
work to accound for the buffer not handling bursts of
data.
|
|
|
ODP: ODP: [Zephyr-users] console_getline vs 0ms char delay in UART comms
regards,
Krzysztof
Od: Piotr Barszczewski <piotr@...>
Wysłane: czwartek, 18 marca 2021 17:20
Do: Lawrence King <lawrence.king@...>; users@... <users@...>; Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
Temat: Re: ODP: [Zephyr-users] console_getline vs 0ms char delay in UART comms
Hello Krzysztof,
Good point, forgot to mention that. Flow control pins are specified in DTS as well as FT232R has FC lines connected to nRF52832. Changing FC settings in Cutecom doesn’t change anything and data is corrupted
as before.
Best regards,
toggle quoted messageShow quoted text
On 18 March 2021 at 15:08:13, Chruściński, Krzysztof ( krzysztof.chruscinski@...) wrote:
Hi,
do you have flow control enabled? When it is disabled then after each byte receiver is stopped and restarted after reading the byte. Restarting may happen when transmitter is already started, in the middle of the byte. In that case, byte will be corrupted.
regards,
Krzysztof
I actually was about to check the signals out of curiosity and sending them in the attachment. All of the following were done with 8N1 @ 115200 and flashed with https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html having
different DTS for the custom board of course. Every time I’ve sent "1234\r\n” to the nrf52832-QFAA chip and connected with the probes directly to UART lines.I’ve checked the PCBs on Linux and OSX to get rid of suspicion that the OS drivers might somehow be involved in makig things funny.
- nrf52832-DK-0ms-delay.png - nRF52832 DK with 0ms delay set. All ok
- nrf52832-DK-1ms-delay.png - nRF52832 DK with 1ms delay set. All ok
- nrf52832-pcb-UART-0ms-char-delay.png - the tested custom PCB with 0ms delay. Data gets corrupted actually on TX and RX but what is returned is different thatn what is sent
- nrf52832-pcb-UART-1ms-char-delay.png - As above but 1ms delay. All ok
- nrf52832-pcb-UART-OSX-0ms-char-delay.png - Same as 3 but on OSX using Coolterm
- nrf52832-pcb-UART-OSX-1ms-char-delay.png - Same as 4 but on OSX using Coolterm
I’ve also tried changing to 8N2 but the result was the same.
From the nrf52832-pcb-UART-0ms it looks like the RX corruption happens when nrf52832 starts transmitting but then it handles every n-th byte correctly. What is even stranger is that the analyzer gets a different value than what
was sent and what nRF52832 received. I don’t really understand what could be the difference as both are nrf52832 (same frequency clocks) in the end, the only thing that is different is the way USB-UART converter is made and handled on OS level. Though I can’t
really say that FT232R has failed like that before. It’s just this particular firmware and the way it handles the data.
I will try to find some USB-UART converter which will enumerate as ttyACM device on my Linux, unsolder the FTDI chip and try talking through ttyACM it instead of a /dev/ttyUSB one. Maybe there is something to it.
Best regards,
On 17 March 2021 at 23:49:09, Lawrence King (lawrence.king@...) wrote:
I wasn’t suspecting your FT232R HW, just how the various terminal programs set up the HW may be different. When all other debugging fails, nothing beats the certainty of capturing the waveforms with an oscilloscope and validating
that all of the characters were sent, and the signal levels are good. But you are not likely to this level of debugging yet.
When you are using cutecom, try setting to 8N2. This adds one extra bit time between characters which a lot less than 1mS and may be enough that you stop dropping characters.
What baudrate are you running at? The usual 115200? Do you see the same problem if you try slower speeds like 38400 or 19200? Of course you need to change both ends of the link if you select an alternat baud rate.
Finally, what processor and processor clock rate are you running, you may simply be sending characters faster than your processor can respond to interrupts and receive the characters (which would make sense if you are missing
every second character).
Lawrence King
Principal Developer
+1(416)627-7302
From: Piotr Barszczewski <piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>;
users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char delay in UART comms
Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed
with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same
Cutecom settings.
As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely
that it would be at blame here.
On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...)
wrote:
Hi Piotr
There are may be pieces of equipment along the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The
programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a
single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.
Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?
You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters,
but it really depends on your board, and kernel options.
Lawrence King
Principal Developer
+1(416)627-7302
From:users@...
<users@...>
On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms
I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the
https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected
behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.
My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input
until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.
This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):
[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@
In the end I’ve changed CuteComs char delay to 1ms and everything works well:
[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊
Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck.
It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the
firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.
|
|
|
Re: ODP: [Zephyr-users] console_getline vs 0ms char delay in UART comms
Piotr Barszczewski <piotr@...>
Hello Krzysztof,
Good point, forgot to mention that. Flow control pins are specified in DTS as well as FT232R has FC lines connected to nRF52832. Changing FC settings in Cutecom doesn’t change anything and data is corrupted as before.
Best regards,
On 18 March 2021 at 15:08:13, Chruściński, Krzysztof (krzysztof.chruscinski@...) wrote:
Hi,
do you have flow control enabled? When it is disabled then after
each byte receiver is stopped and restarted after reading the byte.
Restarting may happen when transmitter is already started, in the
middle of the byte. In that case, byte will be corrupted.
regards,
Krzysztof
I actually was about to check the signals
out of curiosity and sending them in the attachment. All of the
following were done with 8N1 @ 115200 and flashed
with https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html having different DTS for the custom board of course.
Every time I’ve sent "1234\r\n” to the nrf52832-QFAA chip and
connected with the probes directly to UART lines.I’ve checked the PCBs on Linux and OSX to get rid of suspicion
that the OS drivers might somehow be involved in makig things
funny.
- nrf52832-DK-0ms-delay.png - nRF52832 DK with 0ms delay set. All
ok
- nrf52832-DK-1ms-delay.png - nRF52832 DK with 1ms delay
set. All ok
- nrf52832-pcb-UART-0ms-char-delay.png - the tested custom PCB
with 0ms delay. Data gets corrupted actually on TX and RX but what
is returned is different thatn what is sent
- nrf52832-pcb-UART-1ms-char-delay.png - As above but 1ms delay.
All ok
- nrf52832-pcb-UART-OSX-0ms-char-delay.png - Same as 3 but on OSX
using Coolterm
- nrf52832-pcb-UART-OSX-1ms-char-delay.png - Same as 4 but on OSX
using Coolterm
I’ve also tried changing to 8N2 but
the result was the same.
From the nrf52832-pcb-UART-0ms
it looks like the RX corruption happens when nrf52832 starts
transmitting but then it handles every n-th byte correctly. What is
even stranger is that the analyzer gets a different value than what
was sent and what nRF52832 received. I don’t really understand what
could be the difference as both are nrf52832 (same frequency
clocks) in the end, the only thing that is different is the way
USB-UART converter is made and handled on OS level. Though I can’t
really say that FT232R has failed like that before. It’s just this
particular firmware and the way it handles the data.
I will try to find some USB-UART
converter which will enumerate as ttyACM device on my Linux,
unsolder the FTDI chip and try talking through ttyACM it instead of
a /dev/ttyUSB one. Maybe there is something to it.
Best regards,
On 17 March 2021 at 23:49:09, Lawrence King
(lawrence.king@...)
wrote:
I wasn’t suspecting your FT232R HW,
just how the various terminal programs set up the HW may be
different. When all other debugging fails, nothing beats the
certainty of capturing the waveforms with an oscilloscope and
validating that all of the characters were sent, and the signal
levels are good. But you are not likely to this level of debugging
yet.
When you are using cutecom, try
setting to 8N2. This adds one extra bit time between characters
which a lot less than 1mS and may be enough that you stop dropping
characters.
What baudrate are you running at? The
usual 115200? Do you see the same problem if you try slower speeds
like 38400 or 19200? Of course you need to change both ends of the
link if you select an alternat baud rate.
Finally, what processor and processor
clock rate are you running, you may simply be sending characters
faster than your processor can respond to interrupts and receive
the characters (which would make sense if you are missing every
second character).
Lawrence King
Principal Developer
+1(416)627-7302
From: Piotr Barszczewski
<piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>;
users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char
delay in UART comms
Thank
you for your reply. I’m working with 8N1 and the USB-UART is FT232R
of which I’m pretty certain that it’s working correctly. It works
with other firmware, developed with older Nordics SDK and haven’t
experienced issues with it yet. In my experience I’ve narrowed it
down to the 0ms delay in Cutecom making the getline console example
to loose some characters on hadrware which works ok with different
firmware with the same Cutecom settings.
As
for hardware design it uses a schematic which has been validated by
FTDI support as on a different device we’ve been experiencing
different issues so I find it unlikely that it would be at blame
here.
On
17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...)
wrote:
Hi
Piotr
There
are may be pieces of equipment along the path between cutecom
and the serial input on your micro-controller. Usually there is a
USB to Serial chip. The programs inside screen and cutecom set
parameters in the USB2Serial chip. Specifically I would be worried
about the number of databits and stop bits, also parity. The
‘normal’ setting is 8N1 which means send a start bit, 8 data bits,
no parity bits, and a single stop bit. However if cutecom selected
7N1, or screen selected 8N1 and the serial port on your Zephyr
board was set to 8N2 you would see these types of
problems.
Curiously
you are consistently loosing the characters with Even parity. Is
your Zephyr board set up to expect 7O1?
You
need to look at the data being send from the USB2Serial adapter and
ensure that it is valid. I have never had a problem with Zephyr
dropping characters, but it really depends on your board, and
kernel options.
Lawrence
King
Principal
Developer
+1(416)627-7302
From:users@...
<users@...>
On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in
UART comms
I’ve
been reviewing code from a colleague, which (code, not the
colleague) is heavily based on the
https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve
been experiencing some unexpected behaviour when using CuteCom vs
screen to communicate with the console. I’ve dug deeper and deeper
and eventually it seemed like the value returned
by console_getline function was indeed already corrupted. In
screen everything worked fine.
My
assumption was that when I’m using screen each character is passed
1-by-1 to a buffer and everything is golden. On the other hand
CuteCom buffers the input until I press enter and fires away at the
serial port - pretty much like M2M communications would work over
UART.
This
is an example of the output of FW when sending “1234” over Cutecom
with 0ms delay (which is what I have been using +/-
forever):
[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@
In
the end I’ve changed CuteComs char delay to 1ms and everything
works well:
[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊
Is
there some simple CONFIG_ argument to change this? I’ve looked in
menuconfig but without luck.
It’s
not much of a problem to instruct every user of the FW to change it
to 1ms but I’m a bit concerned about using various scripts to
communicate with the firmware which will use the console. Depending
on the implementation of serial driver it might require additional
work to accound for the buffer not handling bursts of
data.
|
|
|
ODP: [Zephyr-users] console_getline vs 0ms char delay in UART comms
Hi,
do you have flow control enabled? When it is disabled then after each byte receiver is stopped and restarted after reading the byte. Restarting may happen when transmitter is already started, in the middle of the byte. In that case, byte will be corrupted.
regards,
Krzysztof
Od: users@... <users@...> w imieniu użytkownika Piotr Barszczewski via lists.zephyrproject.org <piotr=1am.pl@...>
Wysłane: czwartek, 18 marca 2021 14:35
Do: Lawrence King <lawrence.king@...>; users@... <users@...>
Temat: Re: [Zephyr-users] console_getline vs 0ms char delay in UART comms
I actually was about to check the signals out of curiosity and sending them in the attachment. All of the following were done with 8N1 @ 115200 and flashed with https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html having
different DTS for the custom board of course. Every time I’ve sent "1234\r\n” to the nrf52832-QFAA chip and connected with the probes directly to UART lines.I’ve checked the PCBs on Linux and OSX to get rid of suspicion that the OS drivers might somehow be involved in makig things funny.
- nrf52832-DK-0ms-delay.png - nRF52832 DK with 0ms delay set. All ok
- nrf52832-DK-1ms-delay.png - nRF52832 DK with 1ms delay set. All ok
- nrf52832-pcb-UART-0ms-char-delay.png - the tested custom PCB with 0ms delay. Data gets corrupted actually on TX and RX but what is returned is different thatn what is sent
- nrf52832-pcb-UART-1ms-char-delay.png - As above but 1ms delay. All ok
- nrf52832-pcb-UART-OSX-0ms-char-delay.png - Same as 3 but on OSX using Coolterm
- nrf52832-pcb-UART-OSX-1ms-char-delay.png - Same as 4 but on OSX using Coolterm
I’ve also tried changing to 8N2 but the result was the same.
From the nrf52832-pcb-UART-0ms it looks like the RX corruption happens when nrf52832 starts transmitting but then it handles every n-th byte correctly. What is even stranger is that the analyzer gets a different value than what
was sent and what nRF52832 received. I don’t really understand what could be the difference as both are nrf52832 (same frequency clocks) in the end, the only thing that is different is the way USB-UART converter is made and handled on OS level. Though I can’t
really say that FT232R has failed like that before. It’s just this particular firmware and the way it handles the data.
I will try to find some USB-UART converter which will enumerate as ttyACM device on my Linux, unsolder the FTDI chip and try talking through ttyACM it instead of a /dev/ttyUSB one. Maybe there is something to it.
Best regards,
toggle quoted messageShow quoted text
On 17 March 2021 at 23:49:09, Lawrence King ( lawrence.king@...) wrote:
I wasn’t suspecting your FT232R HW, just how the various terminal programs set up the HW may be different. When all other debugging fails, nothing beats the certainty of capturing the waveforms with an oscilloscope and validating that
all of the characters were sent, and the signal levels are good. But you are not likely to this level of debugging yet.
When you are using cutecom, try setting to 8N2. This adds one extra bit time between characters which a lot less than 1mS and may be enough that you stop dropping characters.
What baudrate are you running at? The usual 115200? Do you see the same problem if you try slower speeds like 38400 or 19200? Of course you need to change both ends of the link if you select an alternat baud rate.
Finally, what processor and processor clock rate are you running, you may simply be sending characters faster than your processor can respond to interrupts and receive the characters (which would make sense if you are missing every second
character).
Lawrence King
Principal Developer
+1(416)627-7302
From: Piotr Barszczewski <piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>;
users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char delay in UART comms
Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed
with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same
Cutecom settings.
As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely
that it would be at blame here.
On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...)
wrote:
Hi Piotr
There are may be pieces of equipment along the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The
programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a
single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.
Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?
You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but
it really depends on your board, and kernel options.
Lawrence King
Principal Developer
+1(416)627-7302
From:
users@... <users@...>
On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms
I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the
https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve
been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything
worked fine.
My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input
until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.
This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):
[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@
In the end I’ve changed CuteComs char delay to 1ms and everything works well:
[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊
Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck.
It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware
which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.
|
|
|
NRF52840 BLE DFU OTA - Please help
Hi,
I'm using Zephyr for my BLE nrf52840 project. I wish to implement OTA DFU's on an existing example eg peripheral_lbs. How is this done?
Regards
Renier
|
|
|
Re: console_getline vs 0ms char delay in UART comms
Piotr Barszczewski <piotr@...>
I actually was about to check the signals out of curiosity and sending them in the attachment. All of the following were done with 8N1 @ 115200 and flashed with https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html having different DTS for the custom board of course. Every time I’ve sent "1234\r\n” to the nrf52832-QFAA chip and connected with the probes directly to UART lines.I’ve checked the PCBs on Linux and OSX to get rid of suspicion that the OS drivers might somehow be involved in makig things funny. - nrf52832-DK-0ms-delay.png - nRF52832 DK with 0ms delay set. All ok
- nrf52832-DK-1ms-delay.png - nRF52832 DK with 1ms delay set. All ok
- nrf52832-pcb-UART-0ms-char-delay.png - the tested custom PCB with 0ms delay. Data gets corrupted actually on TX and RX but what is returned is different thatn what is sent
- nrf52832-pcb-UART-1ms-char-delay.png - As above but 1ms delay. All ok
- nrf52832-pcb-UART-OSX-0ms-char-delay.png - Same as 3 but on OSX using Coolterm
- nrf52832-pcb-UART-OSX-1ms-char-delay.png - Same as 4 but on OSX using Coolterm
I’ve also tried changing to 8N2 but the result was the same. From the nrf52832-pcb-UART-0ms it looks like the RX corruption happens when nrf52832 starts transmitting but then it handles every n-th byte correctly. What is even stranger is that the analyzer gets a different value than what was sent and what nRF52832 received. I don’t really understand what could be the difference as both are nrf52832 (same frequency clocks) in the end, the only thing that is different is the way USB-UART converter is made and handled on OS level. Though I can’t really say that FT232R has failed like that before. It’s just this particular firmware and the way it handles the data.
I will try to find some USB-UART converter which will enumerate as ttyACM device on my Linux, unsolder the FTDI chip and try talking through ttyACM it instead of a /dev/ttyUSB one. Maybe there is something to it.
Best regards,
On 17 March 2021 at 23:49:09, Lawrence King (lawrence.king@...) wrote:
I wasn’t suspecting your FT232R HW, just how the various terminal programs set up the HW may be different. When all other debugging fails, nothing beats the certainty of capturing the waveforms with an oscilloscope and validating that all
of the characters were sent, and the signal levels are good. But you are not likely to this level of debugging yet.
When you are using cutecom, try setting to 8N2. This adds one extra bit time between characters which a lot less than 1mS and may be enough that you stop dropping characters.
What baudrate are you running at? The usual 115200? Do you see the same problem if you try slower speeds like 38400 or 19200? Of course you need to change both ends of the link if you select an alternat baud rate.
Finally, what processor and processor clock rate are you running, you may simply be sending characters faster than your processor can respond to interrupts and receive the characters (which would make sense if you are missing every second
character).
Lawrence King
Principal Developer
+1(416)627-7302
From: Piotr Barszczewski <piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>; users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char delay in UART comms
Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed
with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same
Cutecom settings.
As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely
that it would be at blame here.
On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...)
wrote:
Hi Piotr
There are may be pieces of equipment along the path between cutecom and the serial input on your micro-controller.
Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start
bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.
Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?
You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had
a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.
Lawrence King
Principal Developer
+1(416)627-7302
From:
users@... <users@...>
On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms
I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the
https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve
been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything
worked fine.
My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden.
On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.
This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been
using +/- forever):
[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@
In the end I’ve changed CuteComs char delay to 1ms and everything works well:
[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊
Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck.
It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using
various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.
|
|
|
Re: console_getline vs 0ms char delay in UART comms
Lawrence King
I wasn’t suspecting your FT232R HW, just how the various terminal programs set up the HW may be different. When all other debugging fails, nothing beats the certainty of capturing the waveforms with an oscilloscope and validating that all
of the characters were sent, and the signal levels are good. But you are not likely to this level of debugging yet.
When you are using cutecom, try setting to 8N2. This adds one extra bit time between characters which a lot less than 1mS and may be enough that you stop dropping characters.
What baudrate are you running at? The usual 115200? Do you see the same problem if you try slower speeds like 38400 or 19200? Of course you need to change both ends of the link if you select an alternat baud rate.
Finally, what processor and processor clock rate are you running, you may simply be sending characters faster than your processor can respond to interrupts and receive the characters (which would make sense if you are missing every second
character).
Lawrence King
Principal Developer
+1(416)627-7302
toggle quoted messageShow quoted text
From: Piotr Barszczewski <piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>; users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char delay in UART comms
Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed
with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same
Cutecom settings.
As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely
that it would be at blame here.
On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...)
wrote:
Hi Piotr
There are may be pieces of equipment along the path between cutecom and the serial input on your micro-controller.
Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start
bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.
Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?
You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had
a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.
Lawrence King
Principal Developer
+1(416)627-7302
From:
users@... <users@...>
On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms
I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the
https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve
been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything
worked fine.
My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden.
On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.
This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been
using +/- forever):
[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@
In the end I’ve changed CuteComs char delay to 1ms and everything works well:
[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊
Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck.
It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using
various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.
|
|
|
Re: console_getline vs 0ms char delay in UART comms
Piotr Barszczewski <piotr@...>
Hello Lawrence,
Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same Cutecom settings.
As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely that it would be at blame here.
Best regards, Piotr
On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...) wrote:
Hi Piotr
There are may be pieces of equipment along the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically
I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial
port on your Zephyr board was set to 8N2 you would see these types of problems.
Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?
You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.
Lawrence King
Principal Developer
+1(416)627-7302
From: users@... <users@...>
On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms
I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the
https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the
value returned by console_getline function was indeed already corrupted. In screen everything worked fine.
My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press
enter and fires away at the serial port - pretty much like M2M communications would work over UART.
This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):
[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@
In the end I’ve changed CuteComs char delay to 1ms and everything works well:
[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊
Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck.
It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which
will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.
|
|
|
Re: console_getline vs 0ms char delay in UART comms
Lawrence King
Hi Piotr
There are may be pieces of equipment along the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically
I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial
port on your Zephyr board was set to 8N2 you would see these types of problems.
Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?
You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.
Lawrence King
Principal Developer
+1(416)627-7302
toggle quoted messageShow quoted text
From: users@... <users@...>
On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms
I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the
https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the
value returned by console_getline function was indeed already corrupted. In screen everything worked fine.
My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press
enter and fires away at the serial port - pretty much like M2M communications would work over UART.
This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):
[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@
In the end I’ve changed CuteComs char delay to 1ms and everything works well:
[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊
Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck.
It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which
will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.
|
|
|
console_getline vs 0ms char delay in UART comms
Piotr Barszczewski <piotr@...>
Hello,
I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.
My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART. This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever): [17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@ In the end I’ve changed CuteComs char delay to 1ms and everything works well: [17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊
Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck. It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.
Best regards
|
|
|
Adding of Azure SDK to Zephyr as a module
#AzureSDK
Hi, I found a discussion on github regarding adding the Azure SDK to Zephyr as a module. The milestone was set for February. Is there any news on when it will be included in Zephyr?
Thanks.
Kind regards,
Jurgens
|
|
|
Azure Firmware Overt The Air updates (FOTA)
#fota
Hi, are there any plans to expand the current mqtt_azure sample/library to include FOTA. I would really like to update my devices from Azure IoT Hub using something like Azure Blob storage.
Thank you in advance
Kind regards,
Jurgens
|
|
|
DPS functionality, direct method and support for X509 certificate support
#mqtt
Hi, I would like to use the Device Provisioning Service (DPS) along with the mqtt_azure sample/library. Are there any plans to expand the mqtt_azure sample/library to include DPS? I am also looking to use the direct method to send simple commands from Azure to my devices, Are there any plans to include this functionality?
Lastly, the current mqtt_azure sample makes use of a SAS token for authentication. Would it be possible to adapt the example to use X509 certificates? Does the current MBED TLS library in Zephyr allow the use of a root certificate, device certificate, and device key to authenticate connections to Azure?
Your feedback is highly appreciated.
Kind regards,
Jurgens
|
|
|
