Scope on Bus Pirate LCD by Paul Campbell

General
1

processed-7ba0c4d8-3045-4e70-8d73-6778e89a1c22_ha6mgxfE
processed-7ba0c4d8-3045-4e70-8d73-6778e89a1c22_ha6mgxfE600×552 65.8 KB

Paul, who I’ve had the pleasure to see many times in Shenzhen, made a scope mode for the Bus Pirate. It captures at 500KSPS, has triggers and zooms in and out on the LCD. It’s very cool!

Check out the demo:

  • program scope.uf2 into your FB
  • go into mode 7 using the ‘m’ command
  • set the I/O power supply to 3.3v using the ‘w’ command (w n )
  • set the trigger to ‘both’ enter t to get into trigger mode and then press ‘b’ press to exit
  • start the display with (sr 2n ) that starts the display on pin 2 in normal mode
  • next turn on the pullups (P ) you should see trace with a rising edge
  • and turn them off with a (p ) you should see an exponential decay curve
  • turn them on again with P then enter trigger mode with t and then enter + to only trigger on rising edges then to leave trigger mode
  • start a clock on pin 2 with (G 2 1ms 33% )
  • enter x mode (x ) you should see a bunch of square waves, try + and - to change the scale, and the left and right arrows to move around. Freeze a trace by typing ‘o’.
  • enter y mode and change the voltage scale with + and - (and use the up down arrows to move the display)
2 Likes
2

AMA - you’ll find the current code in the ‘scope’ branch in the above github repo

3

Welcome to the forum! I had so much fun trying the scope.

I added you to the git repo as well, push as you like :slight_smile:

4 

// private variables
static uint8_t mem_buffer[SPI_NAND_PAGE_SIZE + SPI_NAND_OOB_SIZE];
static bool allocated = false;

// public function definitions
uint8_t *mem_alloc(size_t size)
{
    if (!allocated && size <= sizeof(mem_buffer)) {
        allocated = true;
        return mem_buffer;
    }
    else {
        return NULL;
    }
}

void mem_free(uint8_t *ptr)
{
    if (ptr == mem_buffer) {
        allocated = false;
    }
}

Here is the bit of code used in the NAND flash to allocate a shared buffer resource. It’s nothing fancy.

Both logic analyzers I ported seem happy to do their ping pong DMA in a single 32K aligned variable of 128 * 1024 bytes.

1 Like
5

Hey Paul - Scope mode is merged into main. It’s really awesome, you did a nice integration with the existing commands. Thank you so much for contributing this amazing feature.

I added your .md documentation to the docs site with some photos for the quick start. The LCD was a bit tricky to photograph, we may take another stab at it. I also added the d-isplay mode command to the command reference.

I’d like to mull over the hd help, and sr ss t x y. You were right about the display mode being a major new concept. I feel like there should be a nice command line like way to wrap everything up consistently, but I’m just not seeing it yet. I’d like to lean into the display mode and make the commands consistent across modes. For example, someone asked about logic analyzer on the display: x y t all apply there too, and for that matter sr and ss. Maybe they can be reused in “default” mode to add user pin labels, something like that.

I also added a crude ownership variable in system_config for the big buffer, and show the current owner in the i-nfo screen. I’m not sure it will stay there, but I want it for debugging the logic analyzer (USB, not on the display yet) this coming week. One thing I noticed is that if you’re in scope mode, and use d to enter scope mode again, it errors about the buffer ownership. This also makes me feel like display modes could be handled like the protocols: an array of function references for each display mode with setup_exec, setup, and cleanup, sr,ss,x,y,t. I have some thoughts, but I probably need to build out another display mode (maybe default) and then see how the common bits all fit together.

I’m super excited to see you’re using the CH32V003. I bought a dev board, and someone in Belgium is also sending one. I hope to push into that later next week. The timing of the SW interface doesn’t look exactly like 1wire to me, but I can change the timing in the 1-wire PIO to get the best data rate with the shortest bit times possible. It looks like a cute interface to poke at registers, even manually. This is another place where I feel like BP5 is holding onto too much legacy v3 thinking. Your tweet was right, you absolutely need to be able to do a protocol mode and program/debug without switching modes. This is another place where it feels like there should be a consistent command line utility-like way to manage programmers/debuggers/loaders independently from the protocol mode. I’m not even sure it’s right to have a paradigm of a protocol mode, why not just load/enable functions on pins? Doing it with a clean intuitive interface will take some work though.

1 Like
6

I’ve just received my Bus Pirate 5 today - it’s a lovely thing!

I can’t quite seem to get the oscilloscope mode working, though.

I’ve updated to the latest firmware, which was apparently automatically built about two hours ago, and I can switch the display into oscilloscope mode fine. Once I do, however, I can’t use it: the ? menu says I should type in scope, which returns Invalid command: scope (but logic works as expected).

Following the command reference documentation, I should switch the display into scope mode (which works) and then type sr 2n to run the oscilloscope on Pin 2. If I do that, I just get Invalid command: sr. Same goes for ss, x, y, and t.

I’m assuming I’m doing something stupid here, but I’d welcome suggestions as to exactly what!

7

This is probably my fault. I’m reworking the command parsing system. Sorry about the bad first impression, I’ll do some testing and push a fix.

1 Like
8

The scope probably works in this firmware and earlier, if you want to try it now.

I found the issue, but I won’t have a fix until tomorrow. Thank you so much for the bug report.

1 Like
9

I investigated and understand where the issue is. I’m not sure of a minimally invasive solution, at the moment I’m causing crashes. I’ll get it sorted soon.

10

image

t/x/y seem to work, but ss and sr lead to a crash. I’m getting close though.

Would it make sense to rework this into the new command system? Currently the display mode gets a chance to check for commands independently, which makes sense and is the most flexible.

scope start //change to display mode and start scope
scope stop //pause scope
scope t //configure trigger or enter interactive mode
scope x
scope y
scope exit //reset display mode

However, it might fit better with the new command paradigm to do something like this. We can tie into the new help system as well so everything is consistent.

11

Sorry for the delay. I looked into the scope situation, it should be working in the present firmware. Be sure to follow the tutorial way of using the scope, the scope command is not yet working.

  • Use d command to set display mode to scope
  • Use the sr <io pin> <mode> to start the scope
  • Use the t command to set the trigger
  • Use x and y commands to navigate the sample buffer

I started a new scope command that rolls this all up into a single command, that will probably be ready tomorrow.

I have noticed the the ss (stop) command freezes the Bus Pirate, however switching back to default display mode usually doesn’t freeze it. I’ll try to see whats going on, and will contact Paul if I can’t.

1 Like
12

@ian

I have been playing with scope mode, and it actually works really well. I have some small suggestions though:

  1. grid color should probably be way darker, like dim, pale, barely pronounced, cause blue signal is pretty much lost on it.
  2. also worth making blue signal line a bit thicker (maybe not a problem if (1) can be adjusted)
  3. would be really good to allow moving 0V level to go up a bit, at least within bottom grid square. I mean go below zero using v in y mode. That should help to observe bottom signal level separate from grid line.
    4… probably make trigger arrow a but more (2px) thick.

Just saying :slight_smile:

1 Like
13

OK, did some tests on custom firmware, and to my taste yellow grid should be 0x004a or maybe even 0xa041. In This case blue signal has nice contrast against it as well as trigger marker.

1 Like
14

Thanks for doing the leg work on that. I don’t think Paul is following along at the moment so I will test any changes you have.

Please point me where to make the change did you can, I’m only moderately familiar with the scope code.

15

Created pull request: Scope: minor tweaks to improve signal readability by alexhude · Pull Request #23 · DangerousPrototypes/BusPirate5-firmware · GitHub
Feel free to try that and let me know what you think :slight_smile:

16

I went ahead and accepted your pull request, thank you!

1 Like
17

Thanks, hope others gonna like these changes too :smiley: