Assigning different GPIOs for channel

[Ashram56]

Good morning,

I have built a small board that will act as a bus "decoder", to be used in an old generation pinball machine.

Unfortunately, I made a basic mistake with my first run: instead of wiring sequentially adress/strobe/data/rst on the Pico GPIOs, I split them for ease of routing (hey, I'm a HW guy, not a SW guy :-) )

So my data bus ends up at pins 0-7
Adress bus is 26-29
IOSTB (active low) is pin 15
and RST is pin 14

I need to trigger on pin 15, decode the adress and read the data

I was hoping that to validate at least the concept I could use your SW directly on my test HW, but it seems your reference schematics uses the standard Raspberry Pi Pico module, whereas my board use the smaller RPI Pico Zero from Waveshare, which exposes GPIO29 for example

Also, I'm not sure why you have GPIO0 and GPIO1 tied together in your schematics

I also have three output signals, planned to control external HW, GPIO 9 to 11. If you are actually using GPIO0-1 as a loopback monitor in your code, I can easily wire 9 and 10 for example

I can start adjusting your code, but I will fully admit I'm not proficient enough in SW so it's likely going to take me ages... (not to mention that my experience with coding on Pico has been an uphill battle - I'm using PlatformIO and I could never get anything to run properly when using Wizio-SDK, which is the baremetal version)

And actually, your code is pretty well structured, even a non SW engineer can somewhat find his way around, so I found the mapping in the PIO code (line 180).

However it seems that you are using GPIO0-1 in the scope of your Fast_Capture and Complex_capture program, and the starting bit is defined to 2 (you make an explicit mention of that in your code).

In my case I only need to start capture when IOSTB (ie pin 15) is asserted, so I'm hoping that just changing the channel mapping (line 180) would be sufficient ? Or does your POSITIVE and NEGATIVE capture code also relies on GPIO0-1 ?

Cheers

[gusmanb]

Hi.

If I understand it correctly you want to use the firmware and the analyzer software to put it in your hardware which is not a standard pico, right?

Well, as you have found the pins are mapped using the pinMap array, so channel1 is the GPIO specified in the first position of the array and so on up to channel24. You can remap those and it should work, all the code will use that mapping and the samples will be reordered before being sent to the LogicAnalyzer software (here is the code that sorts the samples).

About GPIO0 and 1, those are used for the complex and fast triggers, as I wanted to capture at 100Msps it is impossible to check complex patterns using only two PIO instructions so the complex and fast triggers use a second PIO program that triggers GPIO0 and it is received by GPIO1 and at the end the capture program still uses two instructions acting like the simple trigger one (it is all explained in the main page and in the comments of the complex/fast trigger capture start code).

If you are going to use only a simple trigger you can use those pins in the mapping, it should not matter, they only need to be interconnected and reserved for the fast/complex triggers and from what you describe you only need to use the simple trigger.

Hope it helps!

[Ashram56]

Thanks, that's good to know

Now, I need to compile the code using baremetal on PlatformIO, that's going to be interesting...

[gusmanb]

I'm not sure if this can be built directly in PlatformIO as it is a CMAKE project and it configures a lot of things in there like the used libraries, type of comms and so on...

Take this: LogicAnalyzer.zip

I've configured channels 1 to 8 as data (GPIO 0 to 7), 9 to 12 as addres (GPIO 26 to 29), 13 as RST (GPIO 14) and 14 as IOSTB (GPIO 15).

Cheers!

[Ashram56]

Ah many thanks,

I was able to complile with PlatformIO using Wizio-Pico baremetal environnement, but indeed I don't know if it's going to work. So at least I have a reference binary with your file

[gusmanb]

BTW, I forgot it, you can also create your own protocol analyzer for the software, in this way the LogicAnalyzer will be capable of showing the address/bus values without you needing to "read" manually the signal values.

The SerialAnalyzer is a good example on how this can be done, create a new library project for .net 6, add a reference to the LogicAnalyzer app and implement the ProtocolAnalyzerBase class, then after compiling it copy the resulting DLL to the "analyzers" folders and you will have your own protocol analyzer ready :)

[Ashram56]

Thanks for the tip, although reaching that level is slightly (a lot) above my skillset... at least if I can decode the adress bus and read the data bus, that will be a good starting point :-)

[Ashram56]

Coming back on this

I had some issues with my HW, which seem now seem resolved, at least at the input connector. However when capturing, I get literally zero data.

I checked using a scope, at the input of the SN74LVC245 buffer (as unfortunately, I did not plan for test points between the buffer and the Pico), and signal period is about 100uS, hold time for #IOSTB is about 10uS (there's a lot of noise on my signal acquisition, can't be entirely sure).

When triggering on channel 1, I get all zero data (which is odd, given that there's a mix of pull up / pull down on the input side of the buffer, A0 to A3 and IOSTB are pulled up, D0 to D7 are pulled down).

When triggering on channel 14, which is #IOSTB, capture never takes place

I'm not excluding a bug in my HW, although schematics are super simple (basically input in the buffer, output of the buffer directly to the RPI Pico Zero waveshare module). I'm going to hook up some extended wires to check on signaling.

But in the meantime:

• Do you trigger on a falling edge, or do you require a minimum hold time to capture
• I assume that 200Khz frequency (shannon theorem) should be sufficient to capture data, am I correct (or 1MHhz for that matter) ?
• Is there a way for continuous capture as soon as we hit "capture" button in the app ?

Thanks !

[gusmanb]

Do you trigger on a falling edge, or do you require a minimum hold time to capture

The hold time needs to be at least one cycle, the analyzer captures continuously and compares the input value, it's not triggered by an edge interrupt, so if your IOSTB period is 10us and you're sampling at 200Khz it's more than enough.

I assume that 200Khz frequency (shannon theorem) should be sufficient to capture data, am I correct (or 1MHhz for that matter)

More than enough, I have tested the device in extreme conditions (sampling a 100Mhz signal at 100Msps) and it worked without losing any bit.

Is there a way for continuous capture as soon as we hit "capture" button in the app

Nope, there is no continuous capture mode.

As you are using a modified firmware for your device I would do a basic check to ensure it really works, I have never used PlatformIO and I'm not sure if it will really work.
Connect each odd channel to VCC and each even channel to GND directly, except one channel that you will use as trigger. Tie that one with a 4k7 pull-down to GND and after starting the capture trigger it connecting it to VCC. You must see the high/low pattern in the capture. If you don't see it or the capture does not trigger then something is wrong with the firmware.

Cheers.

[Ashram56]

Thanks, I managed to check at the input of the Pico, and I do have a signal so my input buffers is working. I stand corrected on the period, it's actually 500ns period, 100ns hold time (I have a clean measurement)

I'm using the firmware you provided earlier in this thread, I did not try to compile mine. I'll check with the default firmware, and acquire only data 0 to 7, since it should be supported with your default firmware (GPIO 1 to 8).

[Ashram56]

So using the official firmware, I can trigger on channel 1 and get data that looks like they are legit. So it's the modified firmware to account for my specific numbering which is causing problem.

That said in any case, I do have another problem, as I did find an odd behaviour which could explain some of my issues triggering: time scale of the IOSTB signal, input side of the buffer is 500uS, but time scale on the buffer output is 500ns. I suspect I have a noise issue which triggers the buffer.

On another note: is it possible to vizualize more than 2000 samples in the application ?

[gusmanb]

I think you have your GPIO numbers totally wrong, GPIO 0 and 1 cannot be used as triggers as they are internal for the complex/fast/external triggers, the first GPIO that is used for simple trigger and sampling is GPIO 2.

https://github.com/gusmanb/logicanalyzer/wiki/02---LogicAnalyzer-Hardware#barebones-configuration

On another note: is it possible to vizualize more than 2000 samples in the application ?

Nope, too many lines to be drawn when using high count of channels in slow machines :)

[Ashram56]

ah yes absolutely, I had the numbering wrong

So... I have it working now, with GPIO15 (ie CH14) as the trigger, with standard firmware

Now "just" need to recompile with the original mapping: 1 to 8 as data (GPIO 0 to 7), 9 to 12 as addres (GPIO 26 to 29), 13 as RST (GPIO 14) and 14 as IOSTB (GPIO 15).

I'll take a look at the PIO code used in 4.0

[Ashram56]

a few sidenotes:

• the modified firmware you nicely provided above in the thread does not trigger on channel 14
• scope shoot of the cleaned up IOSTB signal shows 500ns period, 100ns hold time, so I'm sampling now at 20Mhz

[Ashram56]

Good morning,

1/ So I can confirm that using the standard firmware, I manage to capture GPIO2 to 7 (since 0 and 1 are used for cascade), and I can trigger on GPIO14. The resulting capture is coherent (although of course I can't really interpret it, since I lack the adress bus and part of the data bus).

2/ I then attempted to use the precompiled binary you provided to be able to use it on my HW, and unfortunately it fails. More precisely it does trigger, but literally all data are stuck at zero (which should not be the case since many signals have pull-ups).

3/ I attempted to compile from source, using the same IO assignment as your own code just to be sure, but unfortunately my resulting firmware does not seem to work. It never triggers on GPIO14 (it does on other GPIOs - but data are all zero, as in step 2 above)

So... I have a compilation issue (which is not unexpected, I'm using VSCode, I have yet to try CMake), but there might be still an underlying bug, since in step 2/ i'm using your own precompiled library.

I would appeciate if you could take a look

Regards

[gusmanb]

Hi.

I'm back at work so right now I don't have as much time as the past months, but I will check it on the weekend.

Cheers.

[Ashram56]

On a sidenote, since reading your various exchanges I see that you've been doing this in the scope of retro/arcade machines, my purpose for this is on a pinball machine (Stern SAM/whitestar generation) And as it turns out, I'm also part of a retrogaming association in France, called Retroplay, who is maintaining arcade machines with the goal of making them available to kids in hospitals Le lun. 27 mars 2023 à 19:17, Agustín Gimenez Bernad < ***@***.***> a écrit :

…

Hi. I'm back at work so right now I don't have as much time as the past months, but I will check it on the weekend. Cheers. — Reply to this email directly, view it on GitHub <#43 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEA6YFK2NECOAWUPCUTVDFTW6HDSHANCNFSM6AAAAAAUXP6TOU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gusmanb]

Yeah, my hobby is retro-computing, I'm mostly focused into Sinclair machines (zx spectrum, QL, and so on) but I give love to any retro machine, I have a good collection with Commodores, Amigas, Atari ST's, MSX's, Amstrad CPCs and so on :)

I'm glad that the device will be useful for this nice project :)

[gusmanb]

Hi Asram.

As promised I reviewed the code and I got it working in the RP2040-Zero (I have some of these), I have tested every channel one by one for triggering and data capturing and all are working ok.

The channels are mapped sequentially to the pins on the edge of the board, so gpios 0 to 15 are channels 1 to 16, and gpios 26 to 29 are channels 17 to 20.

Please report if this works ok or not as I'm starting to make the firmware "universal" and this build is the first step for it :)

Cheers!

LogicAnalyzer.zip

[gusmanb]

Hi again @Ashram56

I got the firmware ready with the universal system :)
Now to add a new board only a need of defines need to be modified so this is going to be great to add support for new models.

For the Zero I got implemented finally all the functionalities, even the RGB led, I created a driver and it seems to work well enough without disturbing the rest of the device.

This new version may be handy for you as it supports the fast and complex triggers, instead of shorting GPIOs 0 and 1 you need to short GPIOs 17 and 18, the first two GPIOs from the back side.

The fast/complex triggers allow use the first 16 channels, in this case GPIOs 0 to 15, so they will cover GPIOs 14 and 15 with your control signals. Also, the new version has the full 24 channels, you can even use the back side GPIOs (but in any case I left the channel numbering sequential to the edge pins, it makes more sense, the back side pins are channels 21 to 24).

I will upload the source next week as I need to prepare the documentation and I don't have more time today, but I'm attaching the compiled firmware so you can use it.

Cheers!

LogicAnalyzer.zip

[Ashram56]

Many thanks for your work. I'm out of home so won't be able to test before Monday though

Regards

[Ashram56]

Sorry, I forgot to update the github. Your code from your before last update did work fine, I managed to trigger and record the entire bus. So very exciting to see this forward.

I also managed to debug my own code by the way, I now have capture and data interpretation working as well :-) The issue was caused by the fact I had not explicitly set the last bits (26 to 29) as input, which is required for the Pico because these pins also act as analog input.

One more question: which tool do you use to read the resulting complete analyzer log ? I need to identify some of the commands and assess the frequency at which they occur.

[gusmanb]

Hi Ashram.

Glad it works :)

About reading the log, what do you mean? You have the LogicAnalyzer app, you can measure intervals and so on, is that what you mean?

If you need something else that reads the values from the lines and displays it as data in the analyzer you will need to implement it yourself as right now there is no parallel bus protocol analyzer.

Another option you have is to export your captured data from the app and use something else like pulseview to analyze the results.

Cheers.

[Ashram56]

The LogicAnalyzer app is limited to 2000 samples if my memory is correct, I need to be able to zoom and extract data across the entire sample acquisition. I'll try Pulseview Cheers Le mar. 11 avr. 2023 à 09:41, Agustín Gimenez Bernad < ***@***.***> a écrit :

…

Hi Ashram. Glad it works :) About reading the log, what do you mean? You have the LogicAnalyzer app, you can measure intervals <https://github.com/gusmanb/logicanalyzer/wiki/06---The-LogicAnalyzer-program#measuring> and so on, is that what you mean? If you need something else that reads the values from the lines and displays it as data in the analyzer you will need to implement it yourself as right now there is no parallel bus protocol analyzer. Another option you have is to export your captured data <https://github.com/gusmanb/logicanalyzer/wiki/06---The-LogicAnalyzer-program#file-menu> from the app and use something else like pulseview to analyze the results <https://sigrok.org/wiki/Protocol_decoder:Parallel>. Cheers. — Reply to this email directly, view it on GitHub <#43 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEA6YFKATSKGC6S7ITF6XV3XAUDL3ANCNFSM6AAAAAAUXP6TOU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gusmanb]

That's only on-screen, you can select ranges that are beyond the 2k samples if you need to measure things larger :)

To select ranges that go beyond what fits on screen place the temp marker at the beginning of the range to measure (single click on the sample marker), go to the last sample you want to measure and shift-click the sample marker, it will select all the range between the temp marker and the last selected sample.

Cheers.