Replies: 17 comments
-
Looks like zenoh-pico is talking a protocol that zenohd doesn´t accept pub(super) fn read_messages(&self, mut batch: RBatch, link: &Link) -> ZResult<()> {
while !batch.is_empty() {
let msg: TransportMessage = batch
.decode()
.map_err(|_| zerror!("{}: decoding error", link))?;
log::trace!("Received: {:?}", msg);
#[cfg(feature = "stats")]
{
self.stats.inc_rx_t_msgs(1);
}
match msg.body {
TransportBody::Frame(msg) => self.handle_frame(msg)?,
TransportBody::Fragment(fragment) => self.handle_fragment(fragment)?,
TransportBody::Close(Close { reason, session }) => {
self.handle_close(link, reason, session)?
}
TransportBody::KeepAlive(KeepAlive { .. }) => {}
_ => {
log::debug!(
"Transport: {}. Message handling not implemented: {:?}",
self.config.zid,
msg
);
}
}
}
// Process the received message
Ok(())
}
|
Beta Was this translation helpful? Give feedback.
-
Some additional logging at server side
|
Beta Was this translation helpful? Give feedback.
-
Ok, got a step further. After increasing the time between 2 sessions to > 10 sec.
|
Beta Was this translation helpful? Give feedback.
-
Watchdog timers
|
Beta Was this translation helpful? Give feedback.
-
To avoid watchdogs biting you, change
|
Beta Was this translation helpful? Give feedback.
-
Then I got a crash in printf coming from : Maybe a border condition where there are no local subscribers I commented this line out and now , the publishing works. |
Beta Was this translation helpful? Give feedback.
-
New challenge : after sending a 1000 messages, the esp crashed
|
Beta Was this translation helpful? Give feedback.
-
Looks like z_close is trying to stop tasks that were already stopped by zp_stop_read_task and zp_stop_lease_task. Something fatal on FreeRtos of espidf. Wrong conclusion yet, commenting out the zp_stop_xxxx didn´t help yet |
Beta Was this translation helpful? Give feedback.
-
Looks like zp_join_task and zp_cancel_task are both calling vTaskDelete in src/system.c for espidf Now phenomenon :
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
It looks like , that when the zenoh-pico starts up and there is too much data waiting in the buffer, it fails. Error codes on uart_driver_install and uart_driver_delete are not checked.. Still some work there for espidf serial. A pity there is not that much documentation on the protocol or structure of the code, otherwise I could give it a try.... |
Beta Was this translation helpful? Give feedback.
-
For what it's worth , the core dump I forced on zenohd as it was 100% cpu without clients For help, type "help". |
Beta Was this translation helpful? Give feedback.
-
I am now able to have multiple sessions and send in each session 1000 messages, but occasionally this arrives :
|
Beta Was this translation helpful? Give feedback.
-
Adding delays in the close down of the session, seems to address the above. Something creates a racing condition. printf("Closing Zenoh Session...\n");
z_undeclare_publisher(z_move(pub));
vTaskDelay(1000 / portTICK_PERIOD_MS); // wait flush ?
zp_stop_read_task(z_loan(s));
vTaskDelay(1000 / portTICK_PERIOD_MS); // wait flush ?
zp_stop_lease_task(z_loan(s));
z_close(z_move(s));
vTaskDelay(1000 / portTICK_PERIOD_MS); // wait flush ?
} |
Beta Was this translation helpful? Give feedback.
-
When this message arrives in the zenohd , then it is game over :
until the zenohd is restarted manually. . |
Beta Was this translation helpful? Give feedback.
-
Seems that zonoh has less supports on Rust lib style user interface than CLI style string parsing, and this makes one too confused to understand how to make it work in a user customized manner, let alone implementing more low level transport links based on it. Did you succeed in the end? |
Beta Was this translation helpful? Give feedback.
-
I was able to make it work by correcting the zenoh client code and did a pull request for this. But there is still a small memory leakage at each new session in the client. Also the server doesn't support serial port discovery as new USB devices are added. So looking at creating my own zenoh proxy for this. Special attention need to be used on the default sizes for buffers, which are by default way too big for most micro-controllers ( 65k in each direction ). |
Beta Was this translation helpful? Give feedback.
-
I got Zenohd running on linux and via USB serial FTDI chip connected to UART2 of an ESP32 board
The ESP32 board is running zenoh-pico via UART2. I use UART0 for debugging.
It looks that the daemon and the micro-controller, see each other but the session is not opened.
At µC side
At Linux side
Source µC : https://github.com/vortex314/zenoh-projects/blob/main/zenoh-espidf/src/main.cpp
zenohd config : https://github.com/vortex314/zenoh-projects/blob/main/zenohd/zenoh.json5
Build flags for zenohd : https://github.com/vortex314/zenoh-projects/blob/main/zenohd/zenoh.json5
Beta Was this translation helpful? Give feedback.
All reactions