In fairness, many of these will end up in consumers hands shortly after a bit of additional value-add. On the bare-bones side, that's things like JLC PCB stocking them for pro-hobbyists to get custom low-volume PCB's made with them. A bit higher up the food chain, mere tinkerers could expect to find more form factors of fully ready-to-use boards available at microcenter/ailexpess/amazon/sparkfun/etc.
For mere hobbyists, adding network connectivity will be the biggest hurdle for most of their projects, and hopefully some of the microcenter (et. al) options will provide options. It doesn't have any on-board solutions for this (unlike, say an STM32F207 which has low-level ethernet capability that just needs to be broken out to a physical interface).
Generally though I think most networking solutions for the RP2040 will max out at 66.5Mbps max theoretical throughput, because this is the limitation of SPI interface when the RP2040 has its system clock set to 133MHz (perhaps a bit more throughput is possible with overclocking).
Note that the dual Cortex M0+ cores have some (serious) limitations, namely: No floating point math (although the compilers usually do a pretty decent job of letting hobbyists forget this!). No Embedded Trace Macrocell or Program Trace Macrocell for debugging (only Micro Trace Buffer). Only 4 breakpoints and 2 hardware watchpoints.
It's important to truly understand the hardware limitations as much as possible to avoid issues caused by things like interrupt priority inversion[0].
This could be incredible for us. We've been facing the same shortages of various STM32 ARM MCU's as everyone else, but most (all?) of our designs could theoretically be replaced with RP2040's -- and the dual core M0+ could provide some key performance/latency guarantees that single, more powerful cores like the M3 might not be able to.
Whether it's worth the engineering time to port the code and re-design PCB's is...dubious, at our low volumes. But any option that attempts to promise to "beat" the contemporary supply chain challenges would be strongly considered. The long-term price savings are attractive as well (~$10 less per board over what we currently use -- which admittedly was optimized for development convenience, not per-unit cost).
I have a lot of experience in the industrial SCADA domain. I largely agree with you, but I will say that historically most installations have had all the relevant source code available to them, or owned by them.
In most cases, the limiting factors for lifespan were:
1) Inability to get replacement hardware
2) Inability to find anyone who can understand the source code.
There's really no way around issue #1. Having the software source doesn't really help that much because most of the time they'll use "migrations" every 10-15 years to rewrite the code using updated understanding of how they want the plant to work. Kicking off a SCADA upgrade is used as a wonderful convenient excuse to drive a lot of meetings/paperwork processes to define "How can we improve safety, improve reliability, make life easier for the human operators, etc?"
Nowadays, the thing time-limiting many SCADA installations are licensing for Windows LTSB and PLC/DCS vendor software. Often times newer versions will require new Dell/HPE servers for compatibility. It's expensive, but also not expensive enough to focus on changing.
The main point is that while licensing artificially limits "longevity" of a machine, closed-source does not. Instead, unavailable replacement hardware limits "longevity" more than "closed source" does.
If/when Windows Terminal integrates sixel support, any cheap laptop should be able to do that OOB (some of them with a USB to serial adapter of course)
From what little insight I could gain, I agree about the hardware problem. The customer I was talking about was nervously trying to find a reliable supplier of motherboards with ISA slots and parallel ports.
I really love the nostalgia this kind of hardware stirs in me, but I am glad I do not have to deal with that kind of trouble. (A few years ago, I read on another forum about an IT guy getting a call on the weekend from a desparate customer looking for an HDD using some standard that predates non-S-ATA... MFM, I think?)
Luckily for that guy, someone has made a MFM-to-SD-card with arbitrary command and geometry transformation recently, it it has turned out to be great. There are MFM-to-SCSI and even SCSI-to-floppy interfaces. The great thing about SCSI in the middle is that it's the same protocol supported by systems today so you could then just convert using generic hardware and software available right now. The system on the other end is none the wiser and thinks everything is still the old interface with the old parameters.
This is super cool! I started toying around with pretty much the exact same concept at the same time as this (2019 - https://github.com/rckoepke/dog_training_NN/blob/master/DogT...) but realized I needed significantly more skills in embedded and mechanical areas to realize my vision.
I completely agree with targeting use at shelters and dayboarding...if this works at all for untrained dogs it will probably only work for under-stimulated dogs. Shelters are a rich environment for finding under-stimulated dogs.
I wish I could say the concept won't work in people's homes but honestly so many pets are probably also lacking sufficient meaningful interaction with their owners.
Great timing. I'm looking for solutions to run Siemens Simatic PDM without being a local admin. Installing it with temporary admin rights seems to silently fail.
I'm also trying to use libpcap and USBPcap without local admin. They request UAC every time I open Wireshark to start a new capture session. (Needed for debugging raw Ethernet and serial stacks)
If you have any tips for either of these I am all ears!
Use npcap and check the settings for the admin-not-required button (forgot the exact name). But generally, accessing raw anything needs elevated rights and should need elevated rights. For a normal user to be able to sniff network and usb traffic is usually a huge security hole and therefore correctly locked away. Not at all comparable to the other cases someone discussed above about some crappy app needing admin to write c:\windows\crappyapp.ico...
See also RENEW, the “world’s first fully programmable and open-source Massive-MIMO Platform” which may help to provide open source hardware and firmware for high-end installations. https://news.ycombinator.com/item?id=24026416
The UI seems very thoughtful, it's clearly a high-quality effort! I'm pleasantly surprised by how intuitive it appears at first glance. It's one of a vanishingly few examples of a "modern"-looking UI with high information density and minimal whitespace.
Your team also picked the right hero image for the homepage, and I love that it opens up into a YouTube video. It did take me awhile to realize that it opens into a video though - the bright purple "Play Demo Video" button was treated as spam by my brain. I believe that's because the UI in the image is very busy, so there are a lot of higher-priority details that I can focus on/explore until my internal "look elsewhere on the site" timer expires and I scroll off the hero image.
It feels like this does deserve more attention. I suspect people who aren't currently working with self-propelled robots may be skipping this as they aren't able to envision where they'd use it. I'd enjoy exploring it with something like this starter kit, though: https://foxglove.dev/blog/building-and-visualizing-your-firs...
Will have a think about how to make the "Play demo video" option more obvious. Maybe an additional link under the hero image would be more likely to catch your eye.
I'm trying to learn how to use the touch displays included in the included in the STM3210C-EVAL or STM3220G-EVAL. If anyone at least knows of some resources with good examples, I'd be super appreciative to find them.
For mere hobbyists, adding network connectivity will be the biggest hurdle for most of their projects, and hopefully some of the microcenter (et. al) options will provide options. It doesn't have any on-board solutions for this (unlike, say an STM32F207 which has low-level ethernet capability that just needs to be broken out to a physical interface).
Generally though I think most networking solutions for the RP2040 will max out at 66.5Mbps max theoretical throughput, because this is the limitation of SPI interface when the RP2040 has its system clock set to 133MHz (perhaps a bit more throughput is possible with overclocking).
Note that the dual Cortex M0+ cores have some (serious) limitations, namely: No floating point math (although the compilers usually do a pretty decent job of letting hobbyists forget this!). No Embedded Trace Macrocell or Program Trace Macrocell for debugging (only Micro Trace Buffer). Only 4 breakpoints and 2 hardware watchpoints.
It's important to truly understand the hardware limitations as much as possible to avoid issues caused by things like interrupt priority inversion[0].
0: https://kentindell.github.io/2021/03/05/pico-priority-invers...