150 replies to this topic

[mjr]

I've had a few people ask over the last couple of years about the possibility of moving Pinscape to the Raspberry Pi Pico, since the KL25Z is no longer in production.  I've had to answer that it's something I'm looking to, but didn't have anything to share yet.  Until now, anyway:

 

https://github.com/mjrgh/PinscapePico

 

It's still a work in progress, but I think it's at a point where technically confident users can start looking at it.  The main github project page has extensive information about the project, so I won't reiterate all of that here.

 

I don't have a Frequently Asked Questions list to offer yet, because the project hasn't been around (publicly) long enough for anyone to have asked any questions about it yet, but I did try to anticipate the sorts of things virtual pin cab enthusiasts would probably want to know, and I tried to cover many of them in the github cover page.  So take a look at that, and I'll be happy to follow up here on any questions that leaves unanswered.

 

 

[fhjui]

That are very good news

[pinking83]

Very good to know that there will be an alternative!

But why do you think that KL25Z is no longer in production? The website of NXP states the KL25Z still as active.

https://www.nxp.com/...mcus:FRDM-KL25Z

[Suikazz]

Very good to know that there will be an alternative!

But why do you think that KL25Z is no longer in production? The website of NXP states the KL25Z still as active.

https://www.nxp.com/...mcus:FRDM-KL25Z

 

 

because the mma8451 is "end of life" and i think nxp will produce batches of KL25z until their stock is empty

[mjr]

> But why do you think that KL25Z is no longer in production?

 

Mostly due to the lack of any sign over the past five years or so that they intend to ever make any more.  Also, as rickh has pointed out, some of the key components (including the accelerometer) are out of production.

 

> The website of NXP states the KL25Z still as active.

 

Indeed, and Mouser shows 39 on order, with a 109-week factory lead time (a weirdly specific estimate for such a long time), which has been the case since perhaps late 2019.  Electronics manufacturers do normally provide the courtesy of an EOL notice.  My theory is that the NXP department or group responsible for FRDM-KL25Z was disbanded several years ago and that there's simply no one on payroll tasked to change the listing.

 

But whatever the case, I'd heartily encourage you to keep using the KL25Z if you've got one or can find one to buy.  It's a great little platform, and the integrated accelerometer sets it apart from the Pico, especially for virtual pin cab use.  But the Pico is a nice platform in its own right, with a lot more power in several areas, which made it possible to expand the Pinscape feature set quite a bit.

Edited by mjr, 21 January 2025 - 06:52 PM.

[Firepower68]

Thank you so much for this new contribution to the community mjr!
I just can not imagine, how much effort already has been put into this project.
A loved to read all the information on github.

Thank you again for all of your work! You make me smile everytime I am working or gaming at my Cab!

Stefan

[rickh]

Mike,

 

Congratulations on all the hard work (and ingenuity) you do.  Let me know if I can be of any assistance in taking this project forward.  In the meantime, I plan to send out 20 each Bang! Plus PCBs for build.  I would gladly add 20 each of your boards as well.  Let me know if I should proceed. 

 

 

Cheers! 

 

Rick 

[mjr]

> In the meantime, I plan to send out 20 each Bang! Plus PCBs for build.

 

Great - look forward to hearing how the software works for you on those.

 

> I would gladly add 20 each of your boards as well.

 

Thanks for the offer!  I'll get in touch by PM.

[DeKay]

@mjr, I just found out about the existence of this project yesterday (while flashing my KL25Z, no less) and it looks really impressive! The design looks to be quite mature and very full featured at this point already. The documentation is outstanding to boot, as always. Amazing work.

 

I hope you don't mind some questions.

• Is there any capability for control of WS2812B LED's using this design? There is no mention of it that I saw, but perhaps this is in work.
• I know you stress in the Readme's how the two DIY boards are meant to be built up as a pair, but what is it that prevents using just a main board if I don't have much need for a large amount of I/O or a clock?
• Do you have a rough cost estimate for the BOM?
• Might you happen to know if your software runs under Wine for Linux fanboys like myself :-)

Thanks!

[mjr]

> Is there any capability for control of WS2812B LED's using this design?

 

There's not - I'm still leaving that to a separate controller.  The Pico is more than capable of handling it at the processing level, so I might look into it at some point, but I think the limiting factor with the Pico might be its small number of GPIO ports.  The Teensy controller has provisions for 8 strings, which requires 8 GPIO ports.  The DIY boards use all but one of the GPIO ports, so there would be some severe tradeoffs if you wanted to take 7 more GPIOs away from the Pinscape side to use on the WS2812B side.  But I don't know how people actually deploy the Teensy in pin cabs - do most people take advantage of the ability to create multiple strings, or could everyone get by with just one string?  If one string is sufficient for real-world use, it could be feasible.  But if that's too constraining, if people normally do use 4 or 8 strings, I'd say everyone's going to be a lot happier just using separate dedicated controllers for the two functions, so that both devices have plenty of ports to work with.

 

> I know you stress in the Readme's how the two DIY boards are meant to be built up as a pair,

> but what is it that prevents using just a main board if I don't have much need for a large

> amount of I/O or a clock?

 

Nothing stops that at all!  I did try cram as many ports onto the main board as I could so that it would be usable by itself - it has the full set of flasher/strobe ports plus 12 high-current MOSFET ports, which is certainly enough for a decent set of toys.  I should edit the doc so that it doesn't sound like the second board is a requirement.

 

> Do you have a rough cost estimate for the BOM?

 

Not at the moment - I've been meaning to assemble a Mouser cart to get that info.

 

> Might you happen to know if your software runs under Wine for Linux fanboys like myself :-)

 

I haven't tried any of the Windows tools under Wine.  I suspect they might not be compatible mostly because they use WinUsb for the vendor interface access, and I'd be surprised if Wine is that comprehensive - WinUsb is an obscure corner of Win32.  But if you have a chance to try it, let me know if you find otherwise.

As for a Linux *port*, that would be doable if someone's motivated (although I'm not enough of a Linux person to take that on myself).  The USB interfaces are all documented, so it would be possible to write a Linux libusb version of the C++ API library.  It would probably even be fairly straightforward to adapt the Windows C++ API, since WinUsb and libusb have very similar architectures.  From there it would be easy to start writing command-line-based tools based on the API.  GUI tools are always a lot more work, so maybe that's beyond what anyone would be interested in taking on, but it would at least be possible given an API layer.

[Suikazz]

Most people prefer separate strips for the different purposes, eg. side stripes, undercab, matrix, speaker rings etc.

All current available controllers have 4-8 dedicated outputs, be it teensy control box, wemos d1 or usual teensy+ octows board or all the other options.

 

for the BOM:

It is a rough estimate but i think i paid around 120-140 euros/usd for a complete set of diy expansion sets parts.

[DeKay]

Thanks for getting back to me so quickly!

 

> But I don't know how people actually deploy the Teensy in pin cabs - do most people take advantage of the ability to create multiple strings, or could everyone get by with just one string?  If one string is sufficient for real-world use, it could be feasible.
 

Not sure. Some people aren't running that many LEDs and could probably easily get away with one or two outputs and multiple sections. Others take the 144 LEDs/m approach all over the place with a high density matrix above the playfield and their cab looks like July 4th :-)  What is nice though is that addressable LEDs can now be driven by ESP32-based Wemos boards that are super cheap and readily available everywhere. Given that, incorporating such functionality into your design probably isn't worth it.

 

> But if you have a chance to try it, let me know if you find otherwise.

 

I gave it a shot not hoping for much and that is what I got. I first flashed the Pico with the firmware with the drag & drop method and then tried to get the config via the command line but it couldn't find the Pico. Very likely this is the WinUsb issue you were afraid of.

[dk@ryzen PinscapePico-v0.1.2-20250120]$ wine ./ConfigTool.exe  --get-config
002c:fixme:winediag:loader_init wine-staging 10.0 is a testing version containing experimental patches.
002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
Pinscape Pico Config Tool  Version 0.1.2, build 20250120155645
Copyright 2024 Michael J Roberts / BSD-3-Clause License / NO WARRANTY

012c:fixme:setupapi:CM_Get_Device_Interface_List_SizeW 000000000011F6B8 0000000140056350 (null) 0x00000000: stub
Error enumerating device paths (HRESULT 8007000d: Invalid data.)
012c:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000011F7F0

Separate comments & questions if that is OK..

• It looks like the code supports both the RP2040 and the RP2350 depending on which SDK is installed. Is there a reason to prefer one over the other?
• Are the builds on Github specific to one device or do they work on both?
• Your readme mentions that the Socketed Pico version of the DIY boards are the ones development will go forward in, so moving the others to a "deprecated" folder or something would be nice. When I started browsing around, I saw all the different DIY designs with no idea of which to focus on until I dove into the readme.

I was also going to suggest putting the Gerbers and Drill files in the repo for people like me that don't use Eagle. But it appears the process is somewhat fab specific so scratch that.

[mjr]

> Most people prefer separate strips for the different purposes, eg. side stripes, undercab, matrix, speaker rings etc.

 

That's about what I figured - I figured the controllers wouldn't bother with multiple ports if people weren't using them.  I guess that leaves the question of whether the multiple ports are a necessity or a nice-to-have or somewhere in between.  In other words, which is the better compromise?:

 

- Having everything on one controller board, BUT with the limitation that you only get one addressable light strip port; or...

 

- The status quo, where you have one dedicated controller for smart strips, and a separate controller board for everything else

 

The latter seems better to me, since the light strip controller is cheap.

 

Another possibility is that I could add another Pico to the expansion board set, dedicated to the addressable strips.  You still have two USB connections (one to the Pico running Pinscape and one to the light strip Pico), and you still have two software configurations and two DOF devices to maintain.  So it's ALMOST identical to the current setup.  But it's at least integrated into one board set, so maybe it saves a little space in the cab and saves some work installing boards.  

 

> for the BOM:

> It is a rough estimate but i think i paid around 120-140 euros/usd for a complete set of diy expansion sets parts.

 

Thanks for that!  I figured it was roughly on par with the old Main + Power board since it's about the same number of parts, and that about tracks with your numbers.

[mjr]

> I first flashed the Pico with the firmware with the drag & drop method and then tried to get the config

> via the command line but it couldn't find the Pico.  Very likely this is the WinUsb issue you were afraid of.

 

Yeah, looks like it - actually looks like it's failing even before getting to the WinUsb stage, just in the basic USB device management subsystem.  Unfortunate but not surprising; Wine isn't really meant to be a complete Win32 emulation as far as I've seen, more for running GUI programs than fully emulating the whole sprawling Windows kernel.

 

> It looks like the code supports both the RP2040 and the RP2350 depending on which SDK is installed.

> Is there a reason to prefer one over the other?

 

For the moment I'd stick with RP2040, because I haven't attempted to build or test on RP2350.  I tried to lay some groundwork where I'm aware of differences, but I expect there's more that will need to be done that will turn up the first time someone tries to actually build with an RP2350 target.  The devices are MOSTLY similar, but they did make a few significant hardware changes that will probably require some more code adjustments.  Longer term I'd definitely like to get the RP2350 going, just because it's the newer device and probably has a longer production horizon.  I don't think it'll make too much difference feature-wise or performance-wise, though.  The RP2350 "Pico 2" doesn't have any more exposed GPIO ports than the original, which is probably the biggest limit I'd like to see eased in a future generation.  The CPU itself does have extra GPIOs, though, so maybe they'll come up with a Pico 2-1/2 at some point that adds pads for them.

 

By the way, I'm pretty sure they merged support for both boards into the one SDK.  I think it's just a matter of selecting the target board in your build configuration.  The SDK also supports a bunch of third-party Pico clones that you can target the same way.

 

> Are the builds on Github specific to one device or do they work on both?

 

RP2040 only, as far as I know.  I think the RP2350 has a somewhat different image layout that requires a separate build.

 

> Your readme mentions that the Socketed Pico version of the DIY boards are the ones development will

> go forward in, so moving the others to a "deprecated" folder or something would be nice. 

 

Yeah, you're right, I should make that more apparent in the file structure.

 

> I was also going to suggest putting the Gerbers and Drill files in the repo for people like me that don't

> use Eagle. But it appears the process is somewhat fab specific so scratch that.

 

That is precisely the reason.  I need to look into automating the Gerber generation process - if I can make that happen, I can have my release scripts generate Gerbers for a few top vendors and add new ones as needed.  As it is, it's a manual process, so they'd always be going out of date when I forget to update them; I figure everyone's happier if I just upload the "source files" (the EAGLE layouts) and let people generate the Gerbers on demand.  It would be nice if Autodesk or someone else had an online Gerber generator so that you could run through the process without EAGLE installed, but I don't know of anything like that.  OSH Park accepts the .BRD files directly, but almost no one else does that I've seen.

Edited by mjr, 07 February 2025 - 11:11 PM.

[DDH69]

Mike,

 

Congratulations on all the hard work (and ingenuity) you do.  Let me know if I can be of any assistance in taking this project forward.  In the meantime, I plan to send out 20 each Bang! Plus PCBs for build.  I would gladly add 20 each of your boards as well.  Let me know if I should proceed. 

 

 

Cheers! 

 

Rick 

 

Rick, interested if you get something moving.

[Suikazz]

>That's about what I figured - I figured the controllers wouldn't bother with multiple ports if people weren't using them.  I guess that leaves the question of whether the multiple ports are a necessity or a nice-to-have or somewhere in between.

 

The multiple port option was a nice-to-have in the beginning.

With the use of Hd-Matrix panels (16x32) it became a neccessity in order to address 512+ pixels per port with 60+pfs or 1014pixels/30fps due to speed limitations of the ws2812b themselves

 

>The status quo, where you have one dedicated controller for smart strips, and a separate controller board for everything else

 

Definitely! Additional usb connections on a single board always confuse people, this already happened with the kl25z. people complaint (rarely, but they did) about not getting their pinscape detected because of using the wrong port.

 

Especially the Teensy 4.0 is a beast and can handle up to 22,000 pixels @ 60fps with the newest libraries!

[rickh]

 

Mike,

 

Congratulations on all the hard work (and ingenuity) you do.  Let me know if I can be of any assistance in taking this project forward.  In the meantime, I plan to send out 20 each Bang! Plus PCBs for build.  I would gladly add 20 each of your boards as well.  Let me know if I should proceed. 

 

 

Cheers! 

 

Rick 

 

Rick, interested if you get something moving.

 

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

[Suikazz]

 

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

[DDH69]

Just starting to play today when a few Pico's arrived.  Any plans for an equivalent to PinscapeCmd.exe ?  Specifically my interest is triggering the send of IR codes.

[mjr]

> Any plans for an equivalent to PinscapeCmd.exe ?

> Specifically my interest is triggering the send of IR codes.

 

ConfigTool.exe is the command-line version of the config tool, and it does include IR send/receive commands.  (You might prefer to use the GUI tool for "learning" commands from remotes, since it provides friendlier tools for that.  But once you have the codes, sending is straightforward through the ConfigTool.exe options.)