180 replies to this topic

[parallaxx]

I'm not able to get it working. PWM worker is not recognized on i2c1. Is this connection schema correct?

Thanks

 

https://drive.google...iew?usp=sharing

Edited by parallaxx, 14 July 2025 - 08:58 PM.

[mjr]

> I'm not able to get it working. PWM worker is not recognized on i2c1. Is this connection schema correct?

 

I don't quite understand what the picture is showing, but if the spots marked "pullup resistors" contain resistors under the electrical tape, then it's not quite right. The problem is that the resistors are between the main Pico GPIO and the Worker Pico GPIO.  Instead, those two GPIOs should be directly connected together with a wire, and the pullup resistor should go between that wire and 3.3V.

 

For the correct wiring, see the diagram under Application Circuit in the data sheet. 

Hopefully you haven't damaged the main Pico.  It looks to me like you have the main Pico GPIOs directly connected to 3.3V, which is creating a short circuit between 3.3V and GND when the Pico I2C module tries to drive those lines low.  The Pico GPIO drivers probably have enough internal protection against short circuits that it won't have fried anything, but if it still doesn't work after you fix it, you might want to try a new Pico in case this one got damaged in the process.

[parallaxx]

Thanks. Finally It's working! However I sometimes have these error lines in log:

 

2025/07/16 07:28:54 Info:    Starting bus scan on I2C0

2025/07/16 07:28:54 Info:    Starting bus scan on I2C1

2025/07/16 07:28:54 Info:    I2C1 bus scan: found device at 0x30

2025/07/16 07:28:54 Info:    I2C0 bus scan completed

2025/07/16 07:28:54 Info:    I2C1 bus scan completed

onfig.json" opened for read, 36026 us

0000/01/01 00:00:00 Config:  Config file loaded OK; parsed JSON memory usage: 13,544 bytes

0000/01/01 00:00:00 Info:    I2C0 bus reset OK, 0 clocks sent

0000/01/01 00:00:00 Config:  I2C0 configured on SDA=GP20, SCL=GP21; speed: 400000; DMA channels: TX 0, RX 1

0000/01/01 00:00:00 Info:    I2C1 bus reset OK, 0 clocks sent

0000/01/01 00:00:00 Config:  I2C1 configured on SDA=GP6, SCL=GP7; speed: 400000; DMA channels: TX 2, RX 3

0000/01/01 00:00:00 Config:  workerPico[0] configured on I2C1 addr 0x30

0000/01/01 00:00:00 Error:   WorkerPico[0]: I2C error requesting register reset (CTRL0_RESET_REGS)

0000/01/01 00:00:00 Error:   WorkerPico[1808]: I2C error reading device ID registers

0000/01/01 00:00:00 Error:   WorkerPico[1808]: I2C error setting PWM frequency

0000/01/01 00:00:00 Error:   WorkerPico[0], I2C1 address 0x30: device initialization failedrkerPico[0]

 

 

If I reset the main Pico (save config for example), error lines are gone:

 

 

===========================================

PinscapePico v0.1.16, build 202506302130

 

0000/01/01 00:00:00 Info:    Flash JEDEC ID: Mfg ID 68, Dev ID 40, Capacity ID 15

0000/01/01 00:00:00 Info:    Flash file system mounted; 262144 bytes allocated to 3 files

0000/01/01 00:00:00 Debug:   File "config.json" opened for read, 36050 us

0000/01/01 00:00:00 Config:  Config file loaded OK; parsed JSON memory usage: 13,544 bytes

0000/01/01 00:00:00 Info:    I2C0 bus reset OK, 0 clocks sent

0000/01/01 00:00:00 Config:  I2C0 configured on SDA=GP20, SCL=GP21; speed: 400000; DMA channels: TX 0, RX 1

0000/01/01 00:00:00 Info:    I2C1 bus reset OK, 0 clocks sent

0000/01/01 00:00:00 Config:  I2C1 configured on SDA=GP6, SCL=GP7; speed: 400000; DMA channels: TX 2, RX 3

0000/01/01 00:00:00 Config:  workerPico[0] configured on I2C1 addr 0x30

0000/01/01 00:00:00 Config:  WorkerPico[0], I2C1 address 0x30: device initialization OK, WHOAMI=0x24 (OK), Ver 1  

 

Is it expected? If not, how to fix it?

 

Thanks

- 

Edited by parallaxx, 16 July 2025 - 06:46 AM.

[mjr]

> However I sometimes have these error lines in log:

> Is it expected? If not, how to fix it?

 

No, errors should never be treated as normal, pretty much by definition.  If you're saying that it works reliably if you reset JUST THE MAIN PICO, but sometimes fails if you boot them both at the same time, my guess is that power to the Worker Pico is being delayed too long during the initial power-up, so it's not ready to respond when the main Pico tries to initialize it.  How are you powering the devices?

[parallaxx]

I'm using a micro-usb splitter adapter (data and power for main pico and power only for pwm worker).

 

Is there a way to delay pwm worker initialization?

Edited by parallaxx, 16 July 2025 - 08:53 PM.

[mjr]

> I'm using a micro-usb splitter adapter (data and power for main pico and power only for pwm worker).

 

So they're plugged into the same port?  That should probably be good enough to ensure they power up simultaneously, so I'm not sure why there'd be a delay.  That might not be the problem after all.  I was hoping that you had them powered through different USB ports or something like that where there might be a reason they wouldn't always receive power at the same instant.

 

> Is there a way to delay pwm worker initialization?

 

It already waits up to 20 ms, which is basically an eternity for these guys.  The Worker Pico should boot up in less than 1ms after power stabilizes.

 

You could try using the expansionBoard controls to simulate a peripheral power-on delay.  You wouldn't actually be controlling the power to anything, but it does give you a way to insert some delay time at power-on.  You'll have to assign it a GPIO port - if you have any that you're not using, you can just pick one.  You don't have to connect any wiring; you'd just be using it for the startup delay properties.

expansionBoard: {
  peripheralPowerEnable: {
    gp: 20,             // pick any port you're not using, leave it unconnected
    powerOffTime: 1,    // power-off time (not important for this scenario)
    waitTime: 100,      // wait before starting peripheral device initialization
  },
},

You can experiment with the waitTime to see if there's a long enough wait that it resolves the errors reliably.  It'll probably be a little random since we're talking about an asynchronous hardware process, so there'll likely be some value where the errors start getting less frequent, and some value a little higher where they disappear altogether.  IF this actually is a power-on delay issue at all, that is.

Edited by mjr, 16 July 2025 - 09:18 PM.

[parallaxx]

Thank you, will try that and let you know.

 

It's weird because they are powered by the same usb port.

Edited by parallaxx, 16 July 2025 - 09:31 PM.

[parallaxx]

UPDATE: with a value of waitTime: 50 and above it works consistently. Below that value I have random failures.

 

Maybe this trick could be added to the pwmworker documentation.

 

Thank you!

[mjr]

> UPDATE: with a value of waitTime: 50 and above it works consistently. Below that value I have random failures.

 

Great - the problem was probably just the boot time after all, then.

 

> Maybe this trick could be added to the pwmworker documentation.

 

I think what I'll do is add an explicit timeout setting to the pwmworker config itself.  Evidently the default 20ms timeout isn't always sufficient.

[parallaxx]

I don't understand why I get 2 different i2c0 address for 2 different Adafruit LIS3DH modules. Same config and same connections, I just swap the 2 modules:

 

 

1st module (not working because address is wrong)

2025/07/20 10:18:44 Info:    Starting bus scan on I2C0

2025/07/20 10:18:44 Info:    Starting bus scan on I2C1

2025/07/20 10:18:44 Info:    I2C0 bus scan: found device at 0x08

2025/07/20 10:18:44 Info:    I2C1 bus scan: found device at 0x20

2025/07/20 10:18:45 Info:    I2C0 bus scan completed

2025/07/20 10:18:45 Info:    I2C1 bus scan completed

 

2nd module (working correctly)

2025/07/20 10:02:23 Info:    Starting bus scan on I2C0

2025/07/20 10:02:23 Info:    Starting bus scan on I2C1

2025/07/20 10:02:23 Info:    I2C0 bus scan: found device at 0x18

2025/07/20 10:02:23 Info:    I2C1 bus scan: found device at 0x20

2025/07/20 10:02:24 Info:    I2C1 bus scan completed

2025/07/20 10:02:24 Info:    I2C0 bus scan completed

 

 

NOTE: I tried to solder the jumper pads on the bottom of the module. I got 0x09 for the first module.

 

Any idea?

 

 

I also have a question regarding configuration:

 

-- Is it possible to trigger an output (es: a solenoid) with a button press, without using DOF? I read about computed source, but cannot find any config example for what I'd like to achieve. Can you please provide a string example for that?

 

Thanks

Edited by parallaxx, 20 July 2025 - 04:11 PM.

[mjr]

My guess would be that the chip that’s reporting addresses 0x08/0x09 is defective. The I2C address is hard-wired into the chip, so you can’t change it (apart from any explicit address control wires they give you, which on the LIS3DH is the one wire to select between 0x18 and 0x19).

 

For the button-controlled output, the computed source is what you need. See ‘button()’ in the source list in the Config Ref.

[parallaxx]

I tried many times but cannot find the right syntax.

 

source: "button('left flipper', on, off)",  string gives this Error:   outputs[2].source, col 23: unknown function name 'on'

 

what is wrong?

Edited by parallaxx, 20 July 2025 - 08:20 PM.

[mjr]

> I tried many times but cannot find the right syntax.

> source: "button('left flipper', on, off)",  string gives this Error:   outputs[2].source, col 23: unknown function name 'on'

 

When the doc says something like

 

button('name', on, off)

 

..., you're not meant to write literally on and off in the expression.  The italics mean that on and off are just placeholders for the actual PWM values you want in those positions.  You already intuited that with the name slot, substituting the name of the actual button you want to use as the control input.  You just have to apply the same logic to the on and off slots.  In the slot for on, substitute the PWM level you want when the button is ON (pressed); in the slot for off, substitute the PWM level you want when the button is OFF (not pressed).  The results of all source expressions are DOF-style PWM levels, 0 to 255, representing PWM duty cycles from 0% to 100%.  So if you just want the output port to turn fully on (100% duty cycle) when the button is pressed, and fully off (0% duty cycle) when the button is not pressed, write

 

button('left flipper', 255, 0)

 

Nearly all of the substitution parameters can also be replaced by nested expressions, so you can also write something like this:

 

button('left flipper', blink(500, 500), 0)

 

... which means that the output port should blink on and off at 500ms intervals when the button is pressed.  You can create fairly complex effects by combining expressions that way.

Edited by mjr, 21 July 2025 - 06:08 PM.

[parallaxx]

Thank you, now it's clear. I suggest to add more notes/examples about this topic in the documentation since it's difficult to understand.

 

This is an amazing and very powerful feature!

Edited by parallaxx, 22 July 2025 - 01:26 PM.

[karlson18]

Solved.

 

thanks for the project

Edited by karlson18, 03 August 2025 - 03:04 PM.

[karlson18]

Hi,

 

got this error

 

22025/08/19 18:39:52 Error:   I2C0: too many consecutive timeouts; attempting a bus reset
2025/08/19 18:39:52 Info:    I2C0 bus reset FAILED (SDA and SCL stuck low), 0 clocks sent

 

Then i do a I2C Bus scan and it give me this

 

2025/08/19 18:25:34 Info:    I2C0 bus scan: found device at 0x18 => lis3dh
2025/08/19 18:25:34 Info:    I2C1 bus scan: found device at 0x20 => pca9555
2025/08/19 18:25:34 Info:    I2C0 bus scan: found device at 0x40 => pca9685
2025/08/19 18:25:34 Info:    I2C1 bus scan: found device at 0x48 => ads1115
2025/08/19 18:25:34 Info:    I2C0 bus scan: found device at 0x70 => ????

 

I can identify all devices except 0x70. What device could this be? I have only configured the known devices. If it possible that this device gives me the error? 

If i don't configure the lis3dh as nugde device the output looks like this

 

2025/08/19 18:49:48 Info:    I2C1 bus scan: found device at 0x20 => pca9555
2025/08/19 18:49:48 Info:    I2C1 bus scan: found device at 0x48 => ads1115

 

These errors are gone

 

22025/08/19 18:39:52 Error:   I2C0: too many consecutive timeouts; attempting a bus reset
2025/08/19 18:39:52 Info:    I2C0 bus reset FAILED (SDA and SCL stuck low), 0 clocks sent

 

Lis3dh functions as a nudge device when configured. I can see this in the pinscape config tool under nudge.

 

Greetings

 

kalle

[mjr]

The "SDA and SCL stuck low" message means that something on the bus is forcing those lines to ground.  If it's happening immediately at boot time, and always happens, you probably have a physical wiring problem that's shorting one or both lines to ground.  If it's intermittent, it might still be a wiring problem, but it could also be something going wrong with one of the I2C chips.  Those chips can sometimes get into error conditions that they can't recover from, which can lock up the whole bus if the device happens to be holding SDA and/or SCL low at the time the device stops working.

 

The best debugging approach will probably be to disconnect EVERYTHING, and try one device at a time.  If the problem you're having is intermittent, you'll have to test each chip in isolation long enough to satisfy yourself that it's not really not going to repeat if you wait a little longer.  Hopefully this will trace the problem to a single device.  If all of the devices work in isolation, then you'll have to start testing different combinations until you can find the minimum combination that's crashing it.  I don't expect that'll be necessary, since these things are usually pretty simple single-device issues, so try to focus on tracking down the single problem device first.

[MartCS]

I found that building a complete expansion board didn’t fit my simple needs, nor did it match my skill set. So, I created a small project with the Pinscape Pico that implements basic inputs -buttons, nudging, and an analog plunger- using the Adafruit MMA8451 and ADS1115 breakout boards.

 

I’ve documented my project here: https://github.com/m...c-pinscape-pico

 

I hope that by sharing my project, someone will be able to create their own basic cabinet.

 

Thanks for the project I could build upon, mjr!

 

Cheers!

Edited by MartCS, 04 September 2025 - 05:06 PM.

[mjr]

MartCS - that's great, thanks for the sharing your work!  That sounds like an excellent setup covering the input functions, which I'm sure plenty of other people will find useful.

[rickh]

Thanks MartCS.  Your project is well documented and the wiring diagram overlay is brilliant!

 

Cheers!

 

Rick