Skip to main content ↑ ↓
Topic: SUMP metadata command (Read 3951 times) previous topic - next topic

SUMP metadata command

Is there documentation on the protocol changes?

I would also note that I ran the 2.12 software without firmware/bitstream upgrades  (I was just trying to find a version of the program that would run without crashing) and it was none the wiser that it was using old firmware.  It also lets me select 24K samples @ 32 bits, which is not a valid combination (and displays 24K worth of samples) on this hardware, regardless of fpga bitstream version.

Re: SUMP meta data command

Reply #1 –
there are no protocol changes, client attm has no way of knowing what obls is capable of so it is up to the user to select valid combination. If you select sample size larger then what obls can store you will get repeated data from the board as buffer is read from the beginning. The latest version of "alternative java client" does not allow you to select impossible combinations (4 channels 24K for example) but again, it assumes you have the 2.12 bitstream, there's no way it can check if it is actually available. There was a thread on the forum about adding the "capability" extension to the protocol where obls board can return info on capabilities, but no work is done in that direction

Re: SUMP meta data command

Reply #2 –
That's probably an upcoming feature. I'd like to add it to get to know VHDL better, it's just a matter of copying the 0x02 -> 1ALS command, so it shouldn't be too hard. Though support will also have to be added to the client and I am not a Java programmer.
Got a question? Please ask in the forum for the fastest answers.

Re: SUMP meta data command

Reply #3 –
[quote author="ian"]
it's just a matter of copying the 0x02 -> 1ALS command, so it shouldn't be too hard. [font=verdana:]Though support will also have to be added to the client and I am not a Java programmer.[/font:]
[/quote]


Please don't rush this. A lot more information than this is needed. There are quite a few clients now, so there needs to be a clear protocol definition that clients can follow to be sure that certain features will be supported. A protocol extension should be able to report ALL of the features the device supports. Off the top of my head:
  • device name (e.g. "Openbench Logic Sniffer v1.0", "Bus Pirate v3b"
       
  • number of usable probes (BP has only 5, OLS has 31 usable)
       
  • how much sample memory is available
       
  • version of the FPGA firmware
       
  • version of the PIC firmware (not so easy, I know)
       
  • maximum sample rate
There's probably quite a bit more that would be interesting to support (please add to the list). What's needed is a protocol extension that can report all of these, and is extensible. I would suggest something along the lines of a set of defined 1-byte keys followed by a a null-terminated text (reporting numbers as "31" for example. Like this:
[tt:]0x01 "Openbench Logic Sniffer v1.0" 0x00
0x02 "8192" 0x00
0x00 (end of capabilities)[/tt:]

Re: SUMP meta data command

Reply #4 –
Quote
version of the PIC firmware (not so easy, I know)

I imagine two approaches. One is to build an identical SUMP state machine in the PIC and follow all commands and intercept /spit out the firmware version number when the command is issued. Another is to add a command that the PIC can use to program a version number into the FPGA at startup. We'd need a volunteer for the first because I won't do it :D
Got a question? Please ask in the forum for the fastest answers.

Re: SUMP meta data command

Reply #5 –
[quote author="ian"]
Quote
version of the PIC firmware (not so easy, I know)

I imagine two approaches. One is to build an identical SUMP state machine in the PIC and follow all commands and intercept /spit out the firmware version number when the command is issued. Another is to add a command that the PIC can use to program a version number into the FPGA at startup. We'd need a volunteer for the first because I won't do it :D[/quote]Because the PIC implements USB, you could create a second Interface (besides the CDC) and send USB commands over that.  The caveat is that I have no idea whether the Windows CDC driver would choke upon seeing an unexpected Interface, or if it would safely ignore it.  I also don't how hard it would be on Windows to access the Custom USB Interface.  The thing is that USB actually makes all of this sort of thing rather easy, but Windows makes it hard.

On OSX, I'm actually using custom USB commands to debug my firmware.  I can send requests for information while the rest of the USB function is going along at full speed.  I almost wish I knew more about Windows (but I don't do Windows).

Re: SUMP meta data command

Reply #6 –
I believe, though have never done it, that the PIC can present multiple interfaces without a problem. For example 2 serial ports, 2 HID devices, etc. I think there is a demo in the USB stack download.

The key thing I guess is something to test it with, a client to support it (or develop in conjunction). I'd also like to do it with the open source USB driver if possible, so we don't have to do everything again after that's out.
Got a question? Please ask in the forum for the fastest answers.

Re: SUMP meta data command

Reply #7 –
[quote author="ian"]I believe, though have never done it, that the PIC can present multiple interfaces without a problem. For example 2 serial ports, 2 HID devices, etc. I think there is a demo in the USB stack download.

The key thing I guess is something to test it with, a client to support it (or develop in conjunction). I'd also like to do it with the open source USB driver if possible, so we don't have to do everything again after that's out.[/quote]I agree that you wouldn't want to redesign after changing the USB stack, but would it be possible to design your own USB driver in a way that's compatible with the Microchip USB stack?  As far as I recall, their stack only requires that a main USB function be called periodically, and the rest of the firmware is up to you.  That's for polled USB, and I haven't worked with the USB interrupt mode yet.

Since I have the OLS, then I can help with the USB design and Mac OS X client, once you get to that stage.  I don't know what would work on Windows, though, although libusb seems to be what people are using (on both OSs).

Re: SUMP meta data command

Reply #8 –
[quote author="rsdio"]
[quote author="ian"]The key thing I guess is something to test it with, a client to support it (or develop in conjunction).[/quote]

Since I have the OLS, then I can help with the USB design and Mac OS X client, once you get to that stage.  I don't know what would work on Windows, though, although libusb seems to be what people are using (on both OSs).
[/quote]


It's actually really easy to write test clients -- libusb + pyusb (python bindings for libusb) lets you interface directly with USB in a couple of lines of code. This may look like pseudocode, but it actually runs:

Code: [Select]
import usb


device = usb.core.find(idVendor=0x0483, idProduct=0x5721)
device.set_configuration()
device.write(2, "hello USB device")   # endpoint 2


However, I will use the sigrok driver to test this functionality, so that it's supported right away.


So the conversation having drifted into the one part of my suiggestion that is not so easy to implement, does that mean you guys agree on the need to a more elaborate version/capability reporting system in the sump protocol?

Re: SUMP meta data command

Reply #9 –
Quote
does that mean you guys agree on the need to a more elaborate version/capability reporting system in the sump protocol?

It's always been in the plans. It's a lot of effort on both sides (bitstream and client), so it has been pretty low on the list of priorities compared to things like getting RLE to work at all sample depths, or integrating all sample depths.
Got a question? Please ask in the forum for the fastest answers.

Re: SUMP metadata command

Reply #10 –
I split this into a new topic. I added an outline for a proposed format on the wiki.

Let's get this hammered out and I will add it.

I like the format proposed by Bert because it's easy to store in various devices, and only takes one command. It's like a USB descriptor with field markers.

I added the proposal to a wiki page and added a few items:
http://dangerousprototypes.com/docs/The ... ata_format

Quote
0x01   device name (e.g. "Openbench Logic Sniffer v1.0", "Bus Pirate v3b"
0x02   number of usable probes (BP has only 5, OLS has 31 usable)
0x03   how much sample memory is available
0x04   dynamic memory available
0x05   maximum sample rate
0x06   version of the FPGA firmware
0x07   axillary version 1 (PIC firmware)
0x08   axillary version 2 (unused)
0x09   axillary version 3 (unused)

I also made this page with a tiny table of features/version info for different SUMP versions:
http://dangerousprototypes.com/docs/Log ... ure_status
Got a question? Please ask in the forum for the fastest answers.

Re: SUMP metadata command

Reply #11 –
I've changed the format on the wiki, to make it easier for the FPGA firmware to generate, but still easy for the client to deal with.

Re: SUMP metadata command

Reply #12 –
I like the format.  The keys are like the debugging commands that I added to a USB device that I am developing.  The USB Control endpoint is used to read and write specific variables in the firmware.  Some of the bits determine the scope (where the circuit has multiple versions of the same hardware), some determine the size (8, 16, 32, extended), and the remaining bits select the variable.

The difference is that using a Control endpoint means that these commands are not part of the main data stream, and thus I don't have to worry about state.

Re: SUMP metadata command

Reply #13 –
Looks great. I changed the Ancillary version (PIC firmware)  from 0x00 to 0x03, I think that is correct.
Got a question? Please ask in the forum for the fastest answers.

Re: SUMP metadata command

Reply #14 –
All right, the FPGA side of this is on my to do list.