TinyPilot founder here.
Happy to answer any questions about TinyPilot or KVM over IPs.
Happy to answer any questions about TinyPilot or KVM over IPs.
Lets say that I prototype something on dev board like something from Raspberry Pi, or ones from STM. Now I want to do a full product, (like the Tiny Pilot) with the microprocessor on a custom PCB board with just the necessary hardware.
I understand that you have to design the schematic and then get the PCB layout done, but in terms of figuring out which pins to connect, is it just a matter of figuring it out from the microcontroller manual? Additionally, how do you end up programming the microcontrollers, do you have to have a separate programmer since you don't have all the stuff on the dev board?
Programming microcontrollers is done using an in-circuit programmer, which connects to a header on the board. Adafruit has a great tutorial for this: https://learn.adafruit.com/proper-step-debugging-atsamd21-ar...
pretty much, you might end up tweaking which pins you use when designing the pcb because the one on the other side of the chip is just as good, but it simplifies the routing and layout of the board significantly.
The Voyager 2 will use custom PCBs for the HAT, but it will still be on top of the Pi.
In the next iteration, I'd like to use the Pi Compute Module to migrate to my own custom board, but I'll need to work with an EE firm on that, since I'm not knowledgeable enough about EE for that kind of project.
All existing CSI bridges that you have used so far have two very serious problems: they do not work with audio capture and due to HDMI backpowering, your Raspberry may stop booting until you physically disconnect the cable. Backpowering is especially common when using KVM switches and some HDMI converters.
Both of these problems are solved on v3 HAT, thanks to our CSI bridge design. Are you planning to solve these problems? Just interesting :)
There's no audio support, and audio would be a nice-to-have, but it's not my top priority at the moment.
I'd like to integrate the TC358743 onto the HAT itself, but Toshiba's got a huge lead time on orders right now.
Worth noting that your typical STM32 MCU is quite different class of device compared to the Broadcom SoC on a RPi. From a architectural point of view, the big difference is that MCUs typically have both flash and ram integrated in the package, while SoC requires external ram and flash. Designing PCB for high-speed DDR memory is not trivial. Modern SoCs come in high-density BGA packages usually sporting close to thousand pins (or more!), while MCUs usually come in more easy to work with packages with order of magnitude less pins.
Specifically the Broadcom chip in current RPis is custom made and not generally available.
yes. if you're using ST parts i suggest using their CubeMX tool, if only to figure out pin assignment. makes it way smoother.
i've seen multiple real projects with real engineers who should get this shit right screw up pin assignment.
also seen them just... not read the data sheet. i don't understand how they expected the board to work, but, it happened.
And do you listen to any of these Covenant Network radio stations that are now under TinyPilot’s control?
I started work on that earlier this year, but I paused it to focus on PoE. That work is almost done, so I should be able to revisit ATX early next year.
The challenge is more on the UX side. It's not that hard to connect the Pi's GPIO pins to a motherboard's ATX pins, but I want to do it in a way so that it minimizes the amount of nitty-gritty pin-matching that the user has to do to connect it correctly.
>And do you listen to any of these Covenant Network radio stations that are now under TinyPilot’s control?
I don't think they'll reach me out here in Massachusetts, but if I'm in the midwest, I'll check 'em out.