Porting to Bus Pirate 5, SUMP protocol, using TinyUSB

[DangerousPrototypes]

Hello!

We had an exchange on Twitter yesterday about a few things, just hoping to continue it here.

Burst and Chaining features, complex trigger support in Bus Pirate 5

I only have 8 IO pins to work with, so I've only implemented the simple trigger support to use all 8IOs. Implementing complex/fast trigger and chaining would be nice, but I haven't yet figured out if it's possible to support 8 IOs in simple, and 6IOs + 2 trigger pins in other modes.

TinyUSB firmware update

Sure, I'd be interested in working from the latest version. I use a custom printf that feeds into a circular USB output queue, so I've never actually used the pico stdio. I adapted your firmware to read from my USB input queue, and write directly with TinyUSB (bypassing my output queue while it operates). For example here:

https://github.com/DangerousPrototypes/BusPirate5-firmware/blob/gusmanb_logic_analyzer/lib/gusmanbla/LogicAnalyzer.c#L383

My printf outputs to a user terminal UART. I have a second UART for binary things like logic analyzers, so I removed the printf and just pass via the cdc_transfer() function:

https://github.com/DangerousPrototypes/BusPirate5-firmware/blob/gusmanb_logic_analyzer/lib/gusmanbla/LogicAnalyzer.c#L160

And in the transfer function I made just small updates to deal with the 2 UART setup:

https://github.com/DangerousPrototypes/BusPirate5-firmware/blob/gusmanb_logic_analyzer/lib/gusmanbla/LogicAnalyzer.c#L356

Finally, I needed to add a tud_task() in the main loop. Not sure this is the best place. I still don't understand if the stdio functions do this on a timer interrupt or somehow else in the background:

https://github.com/DangerousPrototypes/BusPirate5-firmware/blob/gusmanb_logic_analyzer/lib/gusmanbla/LogicAnalyzer.c#L524

SUMP protocol

Work is in progress to support the SUMP protocol which works not only with sig-rok, but several other LA GUIs. I've done 4 or 5 SUMP logic analyzers in the past so it's not a big project, but porting cramped code written for 8 and 16 bit PICs 15 years ago is a bit annoying for some reason and takes more time than I'd like :)

After that, I'd like to see if I can make both protocols live in harmony. However, for my board, it is also possible to configure the binary interface from the user terminal to emulate whatever. Even if I can't get them to work at the same time, I will support both protocols.

Is there a key startup sequence that I could look for? For SUMP: I look for 5 x 0x00 (reset), then 0x02 (ID command) and then enter SUMP emulation mode.

Cheers,

ian

[DangerousPrototypes]

It seems like I can look for the 0x55 0xaa and then hand it off to the code that supports your client.

In startCapture it might be nice to add a define for the number of pins check so I can send error if more than 8.

    //Calculate clock divider based on frequency, it generates a clock 2x faster than the capture freequency
float clockDiv = (float)clock_get_hz(clk_sys) / (float)(freq * 2);

SUMP gives a straight frequency divider based on 100MHZ: f = clock / (x + 1). On one hand I can prepare a value to stick in the req struct to be back-converted, or maybe it's easier on me to make some changes to startCapture to deal with this.

I made the req struct extern and just started populating it from the SUMP protocol. Here's an example (non working code):

https://github.com/DangerousPrototypes/BusPirate5-firmware/blob/gusmanb_logic_analyzer/mode/sump.c#L158

Ive got a good idea how to get it done, but I will pause now and wait for your feedback before getting too far with existing code.

I would like to say that your protocol and mode of gathering/populating a struct in one easy line is my favorite LA protocol I've worked with.

[gusmanb]

Hi!

Ok, there is a "dirty cheap" way of supporting 8 channels for the simple trigger and 6 channels for complex/fast.

There is a pinMap array, for example this is the one used for the zero:

const uint8_t pinMap[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,26,27,28,29,22,23,24,25,COMPLEX_TRIGGER_IN_PIN};

Assume that your GPIO's are GPIO 0 to 7 for this example being GPIO0 channel 1 to GPIO7 channel 8. You can configure the array like this:

const uint8_t pinMap[] = {0,1,2,3,4,5,6,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,COMPLEX_TRIGGER_IN_PIN};

Then you can set COMPLEX_TRIGGER_IN_PIN to be GPIO6 and COMPLEX_TRIGGER_OUT_PIN to be GPIO7.

Last entry on pinMap is used by the chaining feature and that's why it is added at the end, when you select a chain of devices in the application and you start a capture what is done is to configure the slave logic analyzers as a simple capture but the app sets the trigger channel to be the COMPLEX_TRIGGER_IN_PIN GPIO, so in this way each slave can capture all the 24 GPIO's but still be triggered through that pin.

If I'm not forgetting any detail, with this you will be able to capture with the simple trigger eight channels (1 to 8) and six channels (1 to 6) for the complex/fast trigger, it will also support the chaining feature, you could chain two devices connecting pins 6/7 from the master to pin 6 of the slave, as COMPLEX_TRIGGER_IN_PIN and COMPLEX_TRIGGER_OUT_PIN are only reserved in the complex/fast triggers the simple trigger capture will still be able to use these pins as regular channels, you will need to instruct your users to not to use them with the fast/complex triggers but it should work.

Of course the user will need to short GPIO6 and GPIO7 with a jumper or whatever method is the best to be able to use the complex/fast triggers.

In any case I am thinking in something more robust to be done. As the current protocol is only used by my app I can introduce breaking changes without disturbing anyone, so I'm thinking in this:

1-Implement different pin mappings for simple/complex/fast triggers
2-Include in the board definitions three defines for the ammount of channels that each mode has.
3-Modify the protocol to include a descriptor of the capabilities of the device at the handshake, so the app instead of be configured based on the board name to be configured based on the exposed capabilities.
4-Modify the capture functions to use each one the different mappings and apply the limits based on the defined specs.

This will make a lot easier to support different boards with different specs and will allow the buspirate to be correctly configured.

Finally, the burst mode. This is one feature (like the chaining) that I think is not possible to implement in SUMP and loses one of the best features of the device, in fact I studied the SUMP protocol and didn't implemented it because I saw no way of doing it, but if you can manage to do an implementation that can coexist at the same time with the main protocol I would be happy to add it to the firmware to give the users the option.

In burst mode the device captures short bursts of data and it rearms the trigger immediatelly, this is very powerful as it maximizes the usage of the available samples. If you are used to capture with logic analyzers you know that between good data there is a lot of wasted samples where the buses (or whatever you're analyzing) are idle. As the pico has not too much memory and it limits the ammount of samples you can capture this is very useful, you can set-up the device to capture burst of 50-100 samples and do for example 100 loops, if the burst is too short as the trigger is rearmed mostly immediatelly you will still capture all the samples correctly, but when the idling starts the analyzer will stop capturing until another trigger condition is met avoiding wasting the memory in unneeded data.
The application will even show you when a burts ends/starts so you can know when idling happened.

So this is more or less what I was thinking, with these changes to the firmware and the protocol I can modify the app to properly support the BusPirate with its specs, and also will make easier for you to add the SUMP protocol to your version and if it's possible to bring it in to the "regular" firmware.

What do you think?

Cheers!

[DangerousPrototypes]

Thank you so much for the detailed info! I'll dig in tomorrow, today I had a debug nightmare with another area of the code.

You're right, SUMP can't do burst, and that is also a feature that appeals to me. The Bus Pirate is a terminal interface to various protocols. Eventually, I want the Bus Pirate to show the logic graph every time it does stuff on the bus. I've been pondering how to implement that, but it seems I can just adopt your protocol and client when I get there :)

[gusmanb]

Hi!

Sorry for not answering before, life got in the middle :P

If I get ttime next week will start implementing the changes, will update the thread once I get it working.

Cheers!