Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serial encoding support #263

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Serial encoding support #263

wants to merge 7 commits into from

Conversation

mmehari
Copy link

@mmehari mmehari commented Mar 23, 2024

In this pull request, I will like to bring serial encoding support for Espotek/Labrador.

This topic has been discussed in a previous issue (#239) but instead of using GPIOs, I implemented it using the Signal Generator on CH1.

As Signal Generators make use of the hardware DMA support for playing waveforms repetitively, I extend this functionality for playing one-time waveforms. This way, a character pressed on the keyboard is sent to the hardware for it to be played once.

User interface wise, a single checkbox ("Serial Encoding") appears under Logic Analyzer CH1 and clicking it opens a new (one row) text-box. Everything written here will be serially transmitted over Signal Gen CH1. It also hides waveform, frequency and offset input parameters on Sig Gen CH1 since they are not used for serial communication.

I also extended the vendor request commands for sending the serial data to the hardware over USB.

Finally, I also added a filter for ANSI escape codes. After successfully controlling a raspberry pi4 hardware, I came to see ANSI escape codes being received and they were not been interpreted at our side. I then decided to filter them out before reaching the display buffer.

Note:
Tested on raspberry pi5 hardware + rpi OS

@EspoTek
Copy link
Owner

EspoTek commented Apr 5, 2024

Wow, this looks really solid! The only complaint I could possibly make is that it too perfectly integrates into my own ugly code. :P

Before I merge this into master, are you quickly able to confirm the changes to the .hex files?

Specifically:

  • labrafirm_0007_01.hex should have been compiled with #define SINGLE_ENDPOINT_INTERFACE commented out
  • labrafirm_0007_02.hex should have been compiled with #define SINGLE_ENDPOINT_INTERFACE enabled
  • Both firmwares should have been compiled as debug (or release with -O0), with #define OVERCLOCK 48 enabled

If you're unsure I can quickly recompile from here before this patch goes through.

Thanks again for sharing your work with everyone!

Cheers,
~Chris

@mmehari
Copy link
Author

mmehari commented Apr 5, 2024

Indeed that is correct.
labrafirm_0007_01.hex is compiled for non SINGLE_ENDPOINT_INTERFACE and labrafirm_0007_02.hex is compiled for SINGLE_ENDPOINT_INTERFACE.

Also #define OVERCLOCK 48 is enabled during both firmware compilations.

However, I wasn't paying attention on the (release) optimization flag and it was set to -Os after checking it again.

@EspoTek
Copy link
Owner

EspoTek commented Apr 7, 2024

Perfect! I'll test on Windows soon and then push the patch. Thanks again!

@mmehari mmehari force-pushed the master branch 2 times, most recently from 7b79da5 to 752b488 Compare June 22, 2024 13:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants