learning to write Linux programs, where to start - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: January 04, 2024, 01:16:16 pm
content: So I decided to bit the bullet and jump into learning to write programs for Linux and keep micro controller bare metal stuff for simple stuff.So I bought "the book" "The Linux programming interface" uh, yea, 1500 pages, sure at some point I read that I should be familiar with the standard C libraries, so downloaded the manual for the GNU C libraries (libc), uh, yea, 1200 pages, but reading this it feels like I need to understand more of the underlying concepts of Linux that when reading the programming interface book are almost written as though I should have prior knowledge of something else.So where do I start and what order do I go in? essentially at the moment I want to write a program that will use something like canopen node to perform the duties of a canopen master. So I assume that the canopen node library will have to be started and will do it's thing and I need to understand how my program will talk to it along with other programs/drivers that happen outside of my program.I have started the chapter on signals in the Linux programming interface book but the detail is not making much sense.

author: tszaboo
author_rank: Super Contributor
timestamp: January 04, 2024, 01:44:21 pm
content: First, try to read and write from a serial port. It should be easy enough to start with without going into details on how to control a more complicated hardware on Linux. Linux has this concept that "everything is a file". But I think others might be able to explain it better than me.C Library references are here:https://cplusplus.com/reference/clibrary/Reading through that would be almost as boring as reading the Silmarillion book.But I would seriously consider going for a higher level language. Even embedded Linux machines have plenty of resources to run that nowadays. Plus it makes your code portable.

author: darkspr1te
author_rank: Frequent Contributor
timestamp: January 04, 2024, 02:10:34 pm
content: Theres quite a few guides about on getting started in Linux C , covers topics like file access , math library , graphics library(SDL for example) , hardware access (eg changing com port speed, changing power profiles of cpu )opensrource.com is one i think off, dummies guide is another. These cover right from creating your makefile to writing a simple hello world and having it compile.Another good read is kernel basics, handy for writing/patching drivers and also covers a lot of the topics of including headers in code you write directly for the kernel.Dont panic about not knowing the C library , it really is just a bunch of helpers for your code, example is printf , if you dont want to write code to print to screen via vga registers then use printf assigned to default IO, most common it's the command prompt but you can point it elsewhere as is the fun of linux PIPES , thats the ability of printf to send data out to a screen and the user who ran the program can then pipe that data elsewhere , eg to a file or serial portIf you have some code experience from MCU's or similar then think of the C libs as the HAL you get sometimes to speed up code development.You mentioned canopen , when i last did a project in that area I found quite a few githubs of started projects for just that, one was a sniffer, another was a client node. there was many.i started with this onehttps://github.com/CANopenNode/CANopenLinuxand that took me down the rabbit hole of socketcan hardware and linux side drivers ( a fun diversion) and learned a lot in MCU/CAN hardware softwarehope that helps,darkspr1te

author: dferyance
author_rank: Regular Contributor
timestamp: January 04, 2024, 02:18:52 pm
content: It sounds like you are trying to learn several things all at once: learning C, associated libraries, Linux kernel, low-level hardware, usermode Linux. While it is ok to learn a few things at the same time, you may be taking on too much. Try to narrow it down a bit. Maybe learn C and use a C library that does the communication work. Or learn a higher-level programming language.

author: pcprogrammer
author_rank: Super Contributor
timestamp: January 04, 2024, 03:01:02 pm
content: Yes, start simple and build up from that.There is no need to directly know all about how Linux internally does things. For example signals are mostly useful for programs you run as a daemon. A simple command line utility does not need it per se.When you run into a problem the internet is a great source in finding the information needed.I myself started a couple of years back to write programs that work under Linux because I needed some to help with the FNIRSI-1013D reverse engineering. I needed a graphical interface, and the simplest for me to use was directly program onto X11. Sure there are several solutions for making GUI's on Linux, like for instance qt, but I did not find them to be so simple to use for the things I wanted.Everything has a learning curve.The usage of some dedicated library from C is quite straight forward. Include the header file and use the functions in your code. The usage of a lot of hardware systems under Linux are indeed based on files. So you open() the file, read() or write() to or from it and close() it when done.The programming itself is just the same as writing C for a MCU. It starts with the main() function and you build on from there.

author: Simon
author_rank: Unknown
timestamp: January 04, 2024, 04:27:58 pm
content: Quote from: dferyance on January 04, 2024, 02:18:52 pmI already program micro controllers in C, in terms of taking on too many things at once, that is why I am asking. As soon as I look into one thing I find I may need another so it's working out how to make that first start on something simple. I have got as far as using visual studio code to write, compile and run code on a RPi P400 so that I have a graphical interface to work on but am not having to work on an unfamiliar OS to get the work done. As my results will be embedded I am working on the server command line only version. Any graphics will be produced with the LVGL library

author: darkspr1te
author_rank: Frequent Contributor
timestamp: January 04, 2024, 05:47:29 pm
content: Awesome, so in terms of your normal c in a mcu world you setup your HAL(uart etc) , in linux C world a lot is assumed from a base file and the compiler your choose, so in your world arm-none-eabi-gcc is now just gcc (example)so you have main.c and to print hello world you doCode:#include "stdio.h"#include "stdint.h"int main(int argc, char* argv[]){#foo do stuff#if error return 1int error_code = printf("hello world\r\n print command line $s \r\n", argc); //dont have to init uart or anything as os provides that, print name of file called or run then exitreturn error_code; //if non zero you cant use printf locally}in mcu world you think loop forever, in os world you run operations and end. otherwise it's the same except you have os provided HAL.oh, LVGL is available for x86/arm os'es /minimal arm cpus no ext ramdarkspr1te

author: Simon
author_rank: Unknown
timestamp: January 04, 2024, 05:54:09 pm
content: Yes I have gotten as far as every program sits in it's own main with a while loop and then a sleep() function is called.

author: Simon
author_rank: Unknown
timestamp: January 04, 2024, 05:56:57 pm
content: Quote from: darkspr1te on January 04, 2024, 02:10:34 pmCan you be more specific about those book titles.Yes I found CANopen node and have it downloaded. I need to look into how to get that setup and running and control it from my application. I expect that as soon as I read it's documentation it will take a deep dive into aspects of Linux I need to learn.

author: darkspr1te
author_rank: Frequent Contributor
timestamp: January 04, 2024, 05:58:38 pm
content: Quote from: Simon onTodayat 07:54:09 pmOk, so for your opencan/socket can you to now declare those items, the device (socket can->tty) and the pipe (opencan->socket can ) in almost the same way you declare in your HAL for a MCUin this case you might have to declare and open one device before you get the option of declare open on another, order operando so to speak.darkspr1te

author: Simon
author_rank: Unknown
timestamp: January 04, 2024, 07:58:21 pm
content: I don't use chip vendor HAL's for MCU's,

author: golden_labels
author_rank: Super Contributor
timestamp: January 05, 2024, 08:00:15 am
content: Simon:What’s your ultimate goal? Writing programs for Linux systems? Or is the goal, specifically, learning the Linux API?If it’s the first, just writing programs:forget about Linux API. Just pick up your favourite language and use its libraries. Trying to write any bigger program directly using system’s facilities is going to be royal pain. Not only due to the amount of doing-nothing code to write, but also from risks associated: misuse of the features,(1)much larger bug-spawning areas, and — if some “deeper magic” is used — stability.(2)If that is going to be a fully-fledged modern application, you may already have enough of other things to master (like dbus, Freedesktop specs, integration with existing services &c.)If you must extend your program beyond what libraries may offer, then it may be worth going for system facilities. But for this you don’t need to know all of them. Just the particular topic and its surroundings. And these you may learn, when needed. The few basic topics, which IMO are shared among most features, are:File descriptors (open,read,write, …): most things are using streams as the underlying abstraction.Signals: even if not used directly, they do afffect many other calls.Threads (pthread_*): same as above.Process management (fork,exec*,wait, …): critical to understanding interactions between various things, when multiple processes are usedprocfs and sysfs: many, many things may rely on the information there.Namespaces and cgroups: you may not need to use these directly, but they may affect your program. Best approached from the perspective of the user/admin (e.g. through their use in systemd), as the theoretical, system-side view is complicated, hardly meaningful, and still quite unstable.You will also encounterfcntloften, but this is not something that can be learned in isolation.If the answer is the latter, learning system facilities per-se,then don’t learn all of them. Or at best skim over the concepts to just know they are there and what they are about. But focus only on the few selected topics, which are of interest to you. Maybe try writing some programs, that use them, and then use the book to solve the problem.If you need additional resources, I can’t offer many anymore. But certainly you should see the ever-current classic from Beej:Beej’s Guide to Network Programming. There is also a guide to IPC: not as legendary, but gives equally easy access to the topic.Always search the internet for comments on the facilities. What seems very obvious may not be as simple, and nuances are way too easy to miss. What you used/learned 2 years earlier may be superseded or acquire new, unexpected behavior.Of course you may be the kind of a person, who just reads reference books back-to-back. Nothing wrong with that and I agree it gives great overview of a topic as a whole. Guess how I know. But I guess you wouldn’t start this thread, if that was the case, and certainly this is not an efficient method of learning stuff.(1)In particular these related to very low-level stuff. Sometimes even hardware level. There are dragons out there, which 99% of programmers got completely wrong. And that despite warnings in the documentation and even rudimentary Stack Overflow results suggesting, that the there is something wrong with their understanding.(2)Linux APIs, in particular thes aligned with POSIX, are stable, when you rely on their basic semantics. As soon as you start playing with “may”, “might”, “could”, “optionally”, and various “heavy wizardry”, the features become more and more influenced by the environment, configuration, kernel version, and phase of the moon. Even if the facility itself is stable, what world demands from you may be not. Forcing you to rewrite low-level code just to adjust to current standards.

author: Simon
author_rank: Unknown
timestamp: January 05, 2024, 10:21:23 am
content: Yes it is the former. Learn to write a program. Unfortunately beyond the flashing LED program (done that actually but as per another thread I do not wish to use the Pi GPIO) anything useful to me will involve connecting to someone else's code, I mean this is partly the point of using a computer and Linux rather than operate on a resource constrained MCU.I noticed in the PIGPIO library that there are several ways of making this contact. I don't know which is the best way and I expect that very soon I will be headlong into needing an interrupt/signal from the CANopen system to tell me when data has been updated.