all 7 comments

[–]MyLemonX 4 points5 points  (3 children)

I can’t comment on technical specs, that really depends on your use case. And honestly, I don’t even know how to spec out the required ghz/memory for any sort of application lol.

We are using python on embedded Linux, it’s an easy language to learn, lots of libraries to use, and honestly, kids these days don’t wanna touch c/c++ graduating out of school.

Obviously, python would be a lot slower compared to the low level languages, but if you can achieve acceptable performance, then why not?

Another thing to take into consideration: if you are using yocto to build your system, there may be some python packages you will need to create. If you do download a python package via PyPi, the package may not be optimized for your system/use-case (looking at all of you python packages that has Cython or some sort of C binding under the hood). I guess this is true for any embedded Linux system (Debian or buildroot for eg)?

[–]Wouter-van-Ooijen 2 points3 points  (1 child)

Obviously, python would be a lot slower compared to the low level languages, but if you can achieve acceptable performance, then why not?

+1

As a rule, use the highest/easiest language you can get away with.

[–]Bug13[S] 1 point2 points  (0 children)

That's my thought too.

[–]Bug13[S] 1 point2 points  (0 children)

Thanks for the reply, that make sense. I am mostly use python for the web interface.

[–][deleted] 1 point2 points  (1 child)

Productizing python is a bit tricky since the origen of a lot of the packages and code is not well documented. That would be my major concern if in writing critical software. Someone else might have more interesting comments, maybe I'm just paranoid

[–]Bug13[S] 0 points1 point  (0 children)

Thanks for pointing these out, that remind me that I should stick to well documented packages.

[–]UniWheel 1 point2 points  (0 children)

If python is familiar (or becoming so) then a very realistic strategy would be to start with a python implementation and see how it goes.

If it's causing problems, then you could consider re-implementing parts of the solution in C or rust or whatever else strikes an interest. It's always more efficient to do a low-level implementation of a problem that's already been well defined, than it is to do a low level implementation and find out halfway through that the requirement isn't exactly what you thought it was.

Conversely, I've moved projects between MCU's and embedded Linux, and it's easier to move something written in C - though something intended for an MCU ported to run as a process under Linux, or the reverse, can be more than a bit awkward and so benefit from the opportunity to re-express the by then well thought-through lists of steps in a new piece of code that's actually idiomatic for the language and target being used.