150 replies to this topic

[DDH69]

Thanks for the reply.

 

First test Pico configured.  DOFLinx now set to recognise.  Once I set a unit up with outputs I will continue with testing.  

 

11-Feb-25 16:44:11.643 * 1 Pinscape Pico device(s) found

11-Feb-25 16:44:11.656 - DOFLinx device: 1 Initializing as PSPico #1 with name=DDH69 Pico

11-Feb-25 16:44:11.690 - DOFLinx device:1 PSPico setup with 2 outputs

 

My first real build will be a custom with 32 inputs via 74hc165 and 6 worker Picos for outputs.

[Suikazz]

 

Thanks for the reply.

 

First test Pico configured.  DOFLinx now set to recognise.  Once I set a unit up with outputs I will continue with testing.  

 

11-Feb-25 16:44:11.643 * 1 Pinscape Pico device(s) found

11-Feb-25 16:44:11.656 - DOFLinx device: 1 Initializing as PSPico #1 with name=DDH69 Pico

11-Feb-25 16:44:11.690 - DOFLinx device:1 PSPico setup with 2 outputs

 

My first real build will be a custom with 32 inputs via 74hc165 and 6 worker Picos for outputs.

 

thanks for implementing pico in doflinx!!!

what are you going to control with 6 worker picos? each is capable of 24 ports, right?!

[DDH69]

>> what are you going to control with 6 worker picos? each is capable of 24 ports, right?!

 

It may only be 5, not sure yet.  The device is a MAME arcade machine with lots of RGB buttons and LEDs.  Today I blew up 6 x TLC5940's with a power surge from my desktop PSU and I don't fancy soldering more of the surface mount version of that chip, so time for a change!

[rickh]

 

 

Pinscape and Bang Plus PCBs have been ordered.  Meanwhile, Mike is working on a BOM through either Mouser or Digikey.

 

 

pcbs or populated boards?

 

if people from europe are interested, I have some diy V1 in spare i'd like to give away for supporters

 

These are PCBs only.  MJRs Pinscape DIY friendly boards are all Through-Hole technology, allowing easy board assembly.  A few of these PCBs will be shared with MJR to validate his design.  Once validated, MJR will release his BOM. Anyone that wants a set of PCBs can purchase them from me.    

 

Regards,

 

Rick

[DDH69]

@mjr should I be able to have i2c0 and i2c1 active at the same time?  I seem to hit the watchdog timer and revert to safe-mode when I try to do this.

 

This works (but I believe i2c0 is not enabled due to "on demand"

    i2c1: {
        sda: 26,              // GPIO port of I2C0 SDA (serial data) connection
        scl: 27,              // GPIO port of I2C0 SCL (serial clock) connection
        speed: 400000,       // bus speed, bits per second
        pullup: false,       // disable internal pull-ups on the GPIO ports
    },


    i2c0: {
        sda: 0,
        scl: 1,
        speed: 400000,
        pullup: false,       // disable internal pull-ups on the GPIO ports
        enable: "on-demand",
    },

This does not

    i2c1: {
        sda: 26,              // GPIO port of I2C0 SDA (serial data) connection
        scl: 27,              // GPIO port of I2C0 SCL (serial clock) connection
        speed: 400000,       // bus speed, bits per second
        pullup: false,       // disable internal pull-ups on the GPIO ports
    },


    i2c0: {
        sda: 0,
        scl: 1,
        speed: 400000,
        pullup: false,       // disable internal pull-ups on the GPIO ports
//        enable: "on-demand",
    },

Log shows

PinscapePico v0.1.2, build 202501201554

 

0000/01/01 00:00:00 Info:    *** Safe Mode engaged (due to unexpected watchdog reset, or by user request) ***

[mjr]

>  //        enable: "on-demand",

 

Changing just that one line causes the crash?  (Just to make sure there's not something else you're changing at the same time that might be the cause.)

 

Enabling both at the same time is definitely fine.  (I routinely run with such a configuration, so that's well tested.)  But I'm not sure I've tested it with zero devices configured on a bus, so that might be the problem.  Maybe try defining some dummy device on I2C0 to see if that's it.  You probably don't have any MXC6655A chips, so that might be a good one to add as a test:

  {
     mxc6655xa: {
        i2c: 0,
        gRange: 2,
     },
  }

That'll generate errors in the log because no actual device is present, but those shouldn't do any harm.  If that fixes the crash, let me know, that'll point to where I need to investigate.

Edited by mjr, 13 February 2025 - 01:45 AM.

[DDH69]

Thank you. 

 

Yes, just that one line.

 

Adding a device to ic20 stopped the crash (tried mxc6655xa then removed that and tried a workerpico).  Going back to no device recreates the crash.

Edited by DDH69, 13 February 2025 - 02:16 AM.

[mjr]

> Adding a device to ic20 stopped the crash (tried mxc6655xa then removed that

> and tried a workerpico).  Going back to no device recreates the crash.

 

Great - thanks for testing the different cases.  I'm guessing there's a case in there where it's assuming the device list is non-empty.  I'll take a look.  Hopefully you can work around it for the time being.

[DDH69]

> Adding a device to ic20 stopped the crash (tried mxc6655xa then removed that

> and tried a workerpico).  Going back to no device recreates the crash.

 

Great - thanks for testing the different cases.  I'm guessing there's a case in there where it's assuming the device list is non-empty.  I'll take a look.  Hopefully you can work around it for the time being.

 

Happy to test.  I'm on the early journey with this one.  Got 3 x Pico, another 7 on the way plus assorted parts.  Building my 74HC165 input board today.  Plenty of parts in the test board, etc.

[DDH69]

@mjr, back again.

 

I have just built an input board using 4 x 74HC165 connected as per the wiring diagram you provide with Pinscape Pico.

 

The problem is that the inputs from the chips show on the Pinscape Pico test screen incorrectly and also map incorrectly to the configuration.  While I can align the correct keys to the inputs I thought it best to pursue before doing that.  So unless I've managed to find a new and exciting way to wire up 4 x 74HC165's I suspect there is a bug in there somewhere.  Happy to be corrected, happy to test and provide more info.

 

Following the naming on the PS Pico Config screen the problem is:

 

Wiring Diagram                Reports as

Chip 0                               Chain 0 / chip 2

Chip 1                               Base

Chip 2                               Chain 0 / Chip 0

Chip 3 (by extension)       Chain 0 / Chip 1

 

I've attached a screen snip with the chip numbers written on it as well.

Attached Files

•  74HC165 Mapping.JPG   16.97KB   3 downloads

[mjr]

> Attached Thumbnails

 

It took me a minute to understand what I was seeing there, but I think I see the problem now - those lists of green squares are meant to be vertically stacked, with the chip number caption TO THE RIGHT of each row of boxes.  The way it's being presented it looks like the caption is drawn above the green boxes that it applies to.  I'll fix that and post an update, then we can re-evaluate and see if the numbering looks any more rational.

Edited by mjr, 17 February 2025 - 09:36 PM.

[DDH69]

> Attached Thumbnails

 

It took me a minute to understand what I was seeing there, but I think I see the problem now - those lists of green squares are meant to be vertically stacked, with the chip number caption TO THE RIGHT of each row of boxes.  The way it's being presented it looks like the caption is drawn above the green boxes that it applies to.  I'll fix that and post an update, then we can re-evaluate and see if the numbering looks any more rational.

 

Argh, yes, I see what you mean about the caption and alignment.  I grabbed 0.1.3, installed firmware and Gui, but the label alignment is the same.  Having said that reading the labels I can see to the right (instead of above) of the 0-7 boxes it looks like the chips are 1 out with a wrap, so

chip 0 reading as 3

chip 1 reading as 0

chip 2 reading as 1

chip 3 reading as 2

 

Was the alignment fix meant to be in 0.1.3 or is that still to come?

Edited by DDH69, 17 February 2025 - 10:30 PM.

[mjr]

No, I posted 0.1.3 before I saw this.

[DDH69]

@mjr, another potential issue.

 

On the circuit diagram (http://mjrnet.org/pi...erDataSheet.htm) for the MOSFET output using the UCC2752P I suspect R6 and R7 should be 4K7 not 4R7.  Experimentation and a couple less 2752P's tells me that 4R7 and 12V makes them a useless blob of silicon.  If you could please confirm my thoughts before I kill any more that would be great.  I did a quick test with 4K7 and the UCC2752P survived but I would like a more scientific approach and second opinion.

[mjr]

>  I suspect R6 and R7 should be 4K7 not 4R7

 

That's actually correct as written.

 

> using the UCC2752P

 

You mean UCC27524P, right?  I don't think there is such a chip as UC2752P, but if there is and you're using that, that might be the problem.

 

UCC27524P is a gate driver rated for 5A pulses on the OUT pins.  4.7 yields a limiting current of 2.55A on the gate drive, which should be in range.  I've tested the identical circuit with the inverting-input sibling of the chip (UCC27523) and that seems happy and robust with the 4.7 ohm/12V supply combination, which is what I'd expect from the data sheet.

 

You don't want to increase the gate resistor too much, because a larger value slows down the MOSFET switching time (by slowing the gate charge/discharge rate).  The MOSFET dissipates the most power while it's in the zone between fully on and fully off - i.e., during the switching transition time - so that's where it heats up the most.  For PWM operation in particular, slow gate switching will make the MOSFET get hot fast.  The purpose of a gate driver chip like this is charge and discharge the MOSFET gate as rapidly as possible, so that it spends as little time as possible in the high-heat switching zone and thus runs cooler.  For a typical large power MOSFET with a gate charge around 10nC, I think you're okay increasing the gate resistor to around 100 Ohms.

 

But if the UCCxxx is blowing, it makes me suspicious that something else is wrong with the circuit.  It really should be able to handle the 4.7 Ohm pretty easily, by my reading of the data sheet and my own experiments.  What MOSFET are you using?  And you've double-checked that the UCC27524P OUT pin is connected to the MOSFET gate (through the resistor) and to nothing else?

Edited by mjr, 18 February 2025 - 08:43 PM.

[mjr]

I posted a 0.1.4 with a fix for the display layout for the 74HC165 ports.  I also did a little quick testing with a 4-chip 74HC165 chain, and I'm not seeing any anomalies in the chip ordering; looks like everything's showing up where it should.  Hopefully with the fixed display layout it'll look right in your setup.

[DDH69]

I posted a 0.1.4 with a fix for the display layout for the 74HC165 ports.  I also did a little quick testing with a 4-chip 74HC165 chain, and I'm not seeing any anomalies in the chip ordering; looks like everything's showing up where it should.  Hopefully with the fixed display layout it'll look right in your setup.

 

Thank you.  I can now clearly see the alignment as you described earlier.

I can clearly see my 4 configured chips from the config below

    "74hc165": {
        nChips: 4,
        data: 18,
        shift: 19,
        load: 20,
        shiftClockFreq: 6000000,
    },

They are however still returning button presses one chip out.  So physically grounding Input "A" on chip 0 returns input "A" on chip 3 through the software.  Grounding Input"B" on physical chip 2 is seen by the software as button 1 on chip 1.  The mismatch is both for the green box image on screen and the resultant key stroke configured.  So the configuration below

    buttons: [
        // Button #0
        { 
            source: { type: "74hc165", chip: 0, port: "A" },
            action: { type: "key", key: "left shift" },  // Left Shift = left flipper button
        },
....

requires you to connect Input "A" of chip 1 to trigger whereas it should be Input "A" of chip 0.

 

I have attached a screen shot with the actual chip in red on the right hand side.

 

Being out by 1 from physical chip to reported chip continues as I decrease the number of chips down to 2.  With 1 chip (chip 0) only, the button mappings then match correctly.

 

 74HC165 Mapping.JPG   52.67KB   3 downloads

[mjr]

> They are however still returning button presses one chip out.

 

Strange, I wonder why I can't reproduce it.  Everything's showing up where it should in my setup.  The only thing I can suggest is to try physically disconnecting all of the chips, then rebuild the chain one chip at a time, testing at each step.

Actually, one simple thing you can try first is to reduce the data frequency:

"74hc165": {
  shiftClockFreq: 1000000,
},

It could conceivably be that the clock is too high for the wiring.  It's perfectly stable for me at the default with crappy breadboard wiring, so I doubt that's the issue, but worth a quick try.

[DDH69]

>> one simple thing you can try first is to reduce the data frequency:

 

Same result.  It is stable at both frequencies.  I have not seen any stability issues.  Buttons return immediately as expected.

 

>> The only thing I can suggest is to try physically disconnecting all of the chips, then rebuild the chain one chip at a time

 

I did a bit of this before but have gone further this time.  Fortunately the chips are socketed so removing and grounding pin 10 of the last chip is easy.

Regardless of the number of physical chips, any configuration of greater than 1 chip

    "74hc165": {
        nChips: 4,

does not work correctly.  So 1 physical ship set up as nChips:1, works, nothing else.  So while knowingly not correct, 1 physical chip with a setup of nChips:2 has the only physical chip reading as chip 1 not chip 0, so the same issue.

[mjr]

I think I might have spotted a possible configuration-dependent timing issue, which might explain why you're getting the persistent off-by-one problem.  Here's a test build (just the firmware):

 

http://mjrnet.org/pi...t-20250218a.zip

 

Give it a try and if that helps.