Question about C language.

[Phishfry]

Have you thought about what you want to build?

I have. I am interested in displaying GPIO. First via command prompt program and perhaps later an HTTP application.

I have been experiencing moving roadblocks. I have some hardware experience now and can solder.
So my roadblock is now software.
I want to display some sysctl's. Previously I had experienced sysctlbyname. I am just not sure I want to learn C or python.

There are two different python libraries for FreeBSD GPIO I have found. So I bought the NoStarch Python book.

But I am doubting which path to go.

 

[kpedersen]

Your work tends to be around embedded stuff so I would highly recommend C. Not because of the language itself but instead access to compilers, middleware, documentation and ecosystem.

But if you are wanting to get involved more in "hobby / consumer" embedded (RPI, Beaglebone, etc) then Python is probably the way to go because ironically, again its not about the language but instead the ecosystem. So much more middleware and documentation for all the "hats" and things.

I do a lot of "stuff" with the RPI and my dabbling with embedded is almost always consumer so Python probably was the better choice. However I stuck with C mostly out of principle and whilst it is not the worst choice, you do need to unpick all these python libraries and their bindings and work out exactly what is happening in the C underneath.

For example, in my last fun project (a mechanical owl), all the PWM servo motor python APIs (i.e gpiozero) end up using pigpio underneath as the best supported "backend" reducing jitter rather than using GPIO PWM directly (a non trivial problem it seems). What is so funny to see from the C end of is how ad-hoc and rough this "one-man" pigpio effort is that so many projects depend on. In many ways I *like* to know this and going from the bottom of the tech stack, upwards, is the only way to really uncover this kind of stuff.

(Pic 1, Pic2 to show just how amateur my use-case is. Yes, that is a Chinese take-away pot)

 

[Crivens]

Wow. You going to hogwarts?

 

[kpedersen]

Wow. You going to hogwarts?

It was.. ehem a prototype on behalf of my partner to try to automate "Hootle" from the Tales of Arise special edition box set (ours was similar). She bought a load of random crap (Servo motor, wires, servo board) to make it, realized it was a bit beyond her IT skillset so handed it all to me to "get working".

Whilst I don't feel the project was a "failure", she decided it was best to not let me replace the internals of the actual owl in question.

It would basically flap its wings and make owl noises from the game. The cheap USB speaker I bought was remarkably loud, I had to set it to 25%.

 

[Phishfry]

you do need to unpick all these python libraries and their bindings and work out exactly what is happening in the C underneath.

Well said. Exactly my sediment. Is cffi a wrapper for the ignorant? Why bother learning a wrapper go straight to the core.
Strictly talking from inexperience here.
So Python would be safest where 'C' low level could get you into trouble with memory managment?

 

[Phishfry]

Ok the crux of my question here.

Is there any advantage to using Python over 'C' for working with lib/GPIO?
Put another way is there anything that Python does that 'C' cannot (gracefully)?

 

[kpedersen]

Python in general is safer. However depending on the middleware, especially in the embedded world, you can run into the same errors by i.e not closing access to the GPIO device, etc.
I would also say that typically embedded projects don't do so much with memory (i.e less string handling, no XML, no GUI components), so there is little risk of memory errors.

For GPIO specifically, there isn't much benefit, other than Python does have more documentation on it (weirdly). Since I have tried both languages for this darn owl, If I had to do it again, I would choose C again personally.

 

[Phishfry]

Python does have more documentation on it (weirdly).

Whats burned me here is versioning.
I had bought a bunch of used Python books and most were python2. The syntax for examples had changed.

So when it comes to versioning C-2011 was the last revision? Most all back code will still work unlike python?
So from a versioning perspective C rules.
C++ seems to be 'evolving' so I m wary there.

I must also say that Python does have quite a educational foothold with the Pi community. Thonny IDE makes for a good starter tool.

 

[ccammack]

I have. I am interested in displaying GPIO. First via command prompt program and perhaps later an HTTP application.

I think you'll have an easier time overall using Python because it's a higher-level language than C and will allow you to get something working more quickly.

• The tools will be easier to use because the ecosystem considers the needs of artists and hobbyists.
• There will be libraries available for almost everything you want to do.
• You'll find lots of code examples because it's so popular, although old examples and the version change can be a pain. You'll have to do lots of searches like "python 2 vs python 3 print".
• The REPL will allow you to try new things interactively and online REPLs will make it easier to get help from others when you get stuck on language features

If you write the program a little at a time and test each part separately, the whole thing is more likely to work when you put it all together. Take the time to learn the debugger when you get really stuck; stepping through a running program is the best way to see what it's actually doing. Once you get something working that you're afraid of breaking, learn a little git or start taking backup snapshots so you have a fallback. Slow and steady wins.

 

[zirias@]

everything in C is a function. int main(), (xx==1) returns a value...etc
by that definition it is "functional".

Oh you REALLY want to make up your own definitions. Well then, go on. It certainly won't help with communication

"C is object-oriented" is wrong, but has its merits.
"C is functional" is, well, "not even wrong"

 

[zirias@]

Original definition of C++ by Stroustrop was "C with objects"

Which is kind of funny.

Have a look at the C language standard (any version will do). Count the occurrances of the word "object".

In C, any (stored) value of any type (simple or complex) is an object (which has a scope and a storage duration). That of course doesn't make it object-oriented, because this is all about organizing your whole program structure around these objects (using methods, constructors, inheritance and what-not). C just gives you the most basic tools to implement your own OOP scheme if you want ....

But still, "C with objects" sounds kind of silly.

 

[kent_dorfman766]

I have. I am interested in displaying GPIO. First via command prompt program and perhaps later an HTTP application.

I have been experiencing moving roadblocks. I have some hardware experience now and can solder.
So my roadblock is now software.
I want to display some sysctl's. Previously I had experienced sysctlbyname. I am just not sure I want to learn C or python.

There are two different python libraries for FreeBSD GPIO I have found. So I bought the NoStarch Python book.

But I am doubting which path to go.

In deference to all the other entertaining posts in this thread, if you intend to do hardware control (GPIO) professionally then you better learn C, and a lot about safe embedded practices. Code safety is HUGE on the professional side of embedded systems. If you're just playing around then yes, python has some useful GPIO libraries for toy platforms: ie PI.

 

[mer]

But still, "C with objects" sounds kind of silly

I don't disagree, but I'm just relaying what the man said about his creation

 

[kent_dorfman766]

FWIW, the term "objects" wasn't used in the original work. It was "C with classes".
https://en.wikipedia.org/wiki/C++

 

[mer]

Objects, classes, what's the difference?

 

[bakul]

Objects, classes, what's the difference?

For that you will have to take a class, but I expect you will object!

 

[kent_dorfman766]

Objects, classes, what's the difference?

An easier way to wrap your head around it is to think of classes as types, where objects are instantiations of the class/type.

ie, there is no object until you instantiate one of a specific class/type.

 

[mer]

I know the difference hence the emoji thing at the end.

 

[baaz]

This is Off-topic in a Off-topic; But
Any ideas on C23?
I personally really like the 0b literals borrowed from the embedded space .

 

[hruodr]

if you intend to do hardware control (GPIO) professionally then you better learn C

The same if he intends to write a hardware driver.

 

[kent_dorfman766]

I know the difference hence the emoji thing at the end.

Sarcasm is detected so easily over the InterNet.

I love the InterNet. Never before in human history has it been so easy to simultaneously offend so many.

 

[ralphbsz]

But still, "C with objects" sounds kind of silly.

There are things that are more silly. For example: The name "C++" for the new programming language is an in-joke, meaning "increment C in place". The name chosen for the object-oriented version of another language is:

ADD 1 TO COBOL GIVING COBOL.

 

[Holger]

There are things that are more silly. For example: The name "C++" for the new programming language is an in-joke, meaning "increment C in place". The name chosen for the object-oriented version of another language is:

ADD 1 TO COBOL GIVING COBOL.

C++ means “increase (complexity) but return the old value”. Better would have been ++C, I guess.

 

[kpedersen]

C++ means “increase (complexity) but return the old value”. Better would have been ++C, I guess.

These modern days with modern C++ it would be something modern like:

std::increment<std::atomic_lock<[](){++}>>(C);

 

[mer]

I love the InterNet. Never before in human history has it been so easy to simultaneously offend so many.

I am offended that you think I was offended.
Where's my "Object Oriented Programming in Basic" book?