[sdiy] Programming Language Recommendation

[Brian Willoughby]

Nice!

That actually addresses all of my concerns. If the Faust toolchain can output C source that can be built with the chip-maker's own tool chain, then I can't imagine them complaining about not being able to reproduce the bug on their own setup.

Thanks for the summary.

Brian


On Dec 5, 2020, at 14:29, Tony Sidaway <tonysidaway at gmail.com> wrote:
> All excellent points. Faust does compile down to C, but that doesn't solve every problem. The reason I'd try Faust is because I wanted to use a high level language. But bugs can strike at any point in the software stack and a high level language can quickly become a liability.
> 
> On Sat, 5 Dec 2020, 21:36 Brian Willoughby, <brianw at audiobanshee.com> wrote:
>> I've not used Faust for any embedded firmware design, so I won't comment on that language, per se, other than to point out that it violates the KISS principle.
>> 
>> Any additional technology is a potential source for unique problems. If you don't use Faust, then you can't have any problems that are due to Faust.
>> 
>> My single most important driving factor in choosing a language for firmware development is: *support from the chip vendor.*
>> 
>> I've designed many products right at the edge of what an embedded processor can handle, and when I uncover a hardware issue that the vendor hasn't seen before, they invariably want to see source code that runs on their standard evaluation hardware so that they can reproduce the bug and suggest a solution. Admittedly, it's already difficult when designing a custom audio or musical controller hardware platform that's unique, because you can't exactly send a prototype to the chip vendor for bug repro. For this reason, I stick to standard C and leverage the vendor libraries unless performance demands custom code.
>> 
>> I had one hardware DSP project with full bandwidth USB isochronous streaming, and managed to reproduce a bug on the standard evaluation board. However, the isochronous USB client only ran on macOS (because Windows at the time required a kernel driver to handle isochronous traffic), and the vendor could not reproduce the bug *because nobody there had a Mac*!
>> 
>> I'm telling you that you don't want anything unique about your design if you want to push the limits and get support from the vendors. I can't imagine an MCU vendor setting up a Faust tool chain to help repro a bug report...
>> 
>> Brian
>> 
>> On Dec 5, 2020, at 12:01, Tony Sidaway <tonysidaway at gmail.com> wrote:
>> > We're straying rather too close to religious matters, I fear. By far the most important factor in choosing a language is the purpose you'll use it for. In that decision, access to library code features highly. This is one of the reasons I suggest that those seeking a combination of high level language and powerful signal processing features could do worse than examine Faust.
>> > 
>> > It's a highly portable high level language and it'll run just about any collection of DSP algorithms you can name right out of the box, in any combination and with very concise textual code which can also be graphically visualised in a manner comparable to Pure Data. It's a bit of a memory hog but modern boards like those based on ESP-32 will run it well.
>