Closed binqbit closed 1 month ago
Thanks. If I understand the protocol, it ignores everything unless it sees a byte with the value 0x00.
I don't think Blaustahl should be sending 0x00 when it starts up, but maybe it is?
I'll look into this, but there is an issue #12 when building with the latest pico-sdk that I need to debug first.
When the device reads the byte 0x00, it redirects input data processing and then processes the required number of bytes. However, the problem lies in the fact that the device itself sends a data stream during initialization. This disrupts the correct operation of the software as it expects strictly formatted data, but instead receives initialization data from the buffer. I added a channel purge before each SRWP command, but it did not yield the expected result—part of the initialization data still remains in the buffer, which seems strange.
Most likely, this is related to the same issue #12, which hinders the normal functioning of the protocol. The current version of the editor somehow disrupts data transmission during initialization. I believe this issue will be automatically resolved when issue #12 is fixed.
I've merged srwp and am using pico-sdk 1.5.1 for now. There seems to be another possibly unrelated USB CDC issue with pico-sdk 2.0.0.
I now see the issue you mentioned, where the test fails with serialport_srwp. However, I am able to write FRAM data using serialport_srwp. I wonder if you're raising DTR before purging. I believe Blaustahl will wait for DTR before the editor initializes and sends output.
I added a simple python script for testing echo but it's not quite working yet either:
https://github.com/machdyne/blaustahl/blob/main/sw/srwp.py
Will look into this more later. Thanks again.
In the current project implementation, there is a compatibility issue — the SRWP protocol is not fully compatible with the editor running simultaneously. When the device connects, it automatically sends data from the editor, which creates interference for the SRWP protocol. I haven't had the opportunity to address this problem yet. For now, to build the driver, I've temporarily disabled the editor initialization in the blaustahl.c file. Here's the relevant code:
This code temporarily resolves the issue, but a more robust solution will be needed in the future for the editor and SRWP protocol to work together efficiently.