4 ms·

I considered addressing this point in my initial post, but decided not to open the can of worms. You're right, if I have an FPGA I can do anything I want. But w

I considered addressing this point in my initial post, but decided not to open the can of worms. You're right, if I have an FPGA I can do anything I want. But what I want to do is take existing RP2040 PIO programs, and write RP2040 SDK C code to run them and interact with them, but I want to drive more pins and manage more state than the RP2040 offers. If I have a design that takes two RP2040s today and some very careful communication between them, I'd love to try and run it on FPGA but not throw out all the work.

robomartin 3y ago
OK, I get it. Not sure how that might work. To run compiled RP2040 SDK C PIO code on a PIO "clone" inside an FPGA you are going to have to do a ton of work. That's kind of where I was going with my question. By the time you do all that work to use an FPGA you might as well implement the functionality in hardware. I love FPGA's...and yet I hate them with a passion. When they are the right fit for the job you can't beat them. However, this comes at a pretty serious cost in terms of debug cycles per day, troubleshooting complexity and just plain time. I am known for saying that developing a solution on an FPGA takes "cubic time" when compared to other options. I have worked on a number of projects where compile times are in excess of an hour and debugging is excruciatingly painful. You need an 18 hour day just to iterate through two to four attempts at fixing a problem. Like I said, painful. These days I avoid them as much as possible or, when necessary, I prefer to license well-designed and well-tested cores that just work.