Just practise and learn from your mistakes. There's no way to speed up programming without introducing more bugs.
Regarding microcrontrollers, stick with C.
My guess is I might have to unlearn the procedural programming style and move to OOP. Or maybe I'm really bad at programming. I don't know what I'm doing wrong, but I know my projects are eventually abandoned because the software part became overwhelming.
More like 2, or more like 200 hours?
after you have completed almost 90 percent of/ (https://www.reddit.com/r/webdev/comments/gxcq78/ah_after_you_have_completed_almost_90_percent_of/)
- Implement a serial, USB or ethernet link with your linux host.Oscilloscope screen capture over LAN (either Linux or Windows)
- Implement a LCD or TFT displayLCD display packed as an Arduino library (only attached as a zip in EEVblog, not pushed to the online Arduino libs repositories): https://www.eevblog.com/forum/projects/a-2-wires-lcd-with-hd44780-and-3-x-74ls74-(put-2-shift-registers-on-same-2-pins)/ (https://www.eevblog.com/forum/projects/a-2-wires-lcd-with-hd44780-and-3-x-74ls74-(put-2-shift-registers-on-same-2-pins)/)
- Implement a sensor with SPI or I2Chttps://hackaday.io/project/2823-how-are-you-errr-are-you-alive (https://hackaday.io/project/2823-how-are-you-errr-are-you-alive)
- Implement a RTOSNot exactly an RTOS, the closest I might have wrote is a CP/M BIOS, written in Z80 assembler long time ago, it was about 4kB of assembled code, and took a couple of years to finish, didn't count the hours:
- others..Some Python simulation of an inflating universe:
https://hackaday.io/project/2823-how-are-you-errr-are-you-aliveIsn't that a Kinetis board? I would try to run that Kinetis project on the bluepill in order to not lose the effort. Porting things you already know is a good exercise. When i do these things i usually write a work protocol into a text file, so others (or me) can later understand and recover what happened.
What to do to become more productive in writing code (for small/hobby projects)? Some programming exercises/books/classes to follow?Read the book Programming Pearls by Jon Bentley.
What to do to become more productive in writing code (for small/hobby projects)? Some programming exercises/books/classes to follow? Something else to learn? :-//
In software engineering, rubber duck debugging is a method of debugging code by articulating a problem in spoken or written natural language. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line by line, to the duck
Sorry, but no. I'm asking for debugging/review of what I am doing wrong. Not asking for encouragement.
Since others can write complex programs while I keep failing at it over and over, for decades, I guess I might be doing something wrong. Or I might have developed bad programming habits. Sure, there's always a possibility that I'm not suitable for programming, would not mind if so, though I would like to know why.
Can you design and implement electronic hardware without such problems?
Ever refactored something?
When writing code, write in small units that you can test. The smaller the amount of code a problem can hide in, the easier it is to find. Test often. You probably should spend at least as much time testing your code, as you spend writing it.
I often write tiny test programs to test a single data structure and its associated function interfaces, just so I can check it really works.
Can you design and implement electronic hardware without such problems?
That's an interesting question, I never thought about programming that way. I guess even complex hardware projects (i.e. when I designed a full Z80 Spectrum from scratch, with video and disk controller included https://hackaday.io/project/1411-xor-hobby-a-vintage-z80-computer-prototype ), are still low complexity when compared to software projects.
For the hardware projects, the most agonizing tasks to me are about how to design something using only parts I already had in the inventory, without ordering anything extra. Another problem (with hardware) is to commit between something very basic, or something very generic. ... So, for hardware is more of a problem about choice, than a problem about braking a big project into small blocks.
Your question made me think I might have a problem with decision making and committing to fixed specs. Could be. In hardware such problems are smaller, because the choices are limited by the available parts, and other limitations from the physical world, while in software the possibilities are endless. In software it is always possible to want/add more, or to switch between a completely different programming ways.
A side effect to this is that even the nicest working program still feels unfinished. There is always something more you could add, or you could improve to a program. Very frustrating.
When writing code, write in small units that you can test. The smaller the amount of code a problem can hide in, the easier it is to find. Test often. You probably should spend at least as much time testing your code, as you spend writing it.
I often write tiny test programs to test a single data structure and its associated function interfaces, just so I can check it really works.
I've read once some book that was in fashion, about TDD (Test Driven Design). Write a test for every line seems nonsense to me. Who's testing the test, then? I recall even from one of the working places where a software team tried TDD. Very often the tests were failing because of bugs in the tests, and after struggling with the TDD paradigm for a couple of weeks, they ended up being less religious about TDD, and they only kept a few test that were making sense. It was a huge software project, and those guys were top programmers at a multinational, not amateurs.
I'm confused what should I test, and how. Many of my projs have some hardware, so I guess it will take considerable effort to mock the hardware signals.
Can not write small programs fast enough, can not write larger programs at all. :-\
How to fix this?
the number of lines of code in the project reduces. (Explodes the brains of idiots that count LoC as a measure of productivity, though!)
i0=0;
test_report = {}
is_ok=False
while(is_ok)
{
dev (in_out: it, in: test_report); /* development team */
test(in: it, out:test_report); /* testing team */
nbugs=test_report.nbugs;
is_ok=(nbugs <= eps);
i0++;
test_report.is_ok=is_ok;
}
... AI-assisted automatic testing ...
In the declaration Mr. Schwartz filed this week, he described how he had posed questions to ChatGPT, and each time it seemed to help with genuine case citations. He attached a printout of his colloquy with the bot, which shows it tossing out words like “sure” and “certainly!”
After one response, ChatGPT said cheerily, “I hope that helps!”"
as the time to analyze the number of linearly-independent paths through a module grows exponentialy with the number of module lines, that's why in my-C I imposed a finited number of arguments passed to a function and a finited number of lines themselves of the body of function.
Your question made me think I might have a problem with decision making and committing to fixed specs. Could be. In hardware such problems are smaller, because the choices are limited by the available parts, and other limitations from the physical world, while in software the possibilities are endless. In software it is always possible to want/add more, or to switch between a completely different programming ways.
Ever refactored something?
Usually that's where I lose control, so I need to re-arrange/redesign some parts. I've read a refactoring means better structured code, while retaining the same functionality from before. I usually end up with buggy code after a refactoring attempt, or with a broken project that doesn't work any more.
I've read once some book that was in fashion, about TDD (Test Driven Design). Write a test for every line seems nonsense to me. Who's testing the test, then?
I recall even from one of the working places where a software team tried TDD. Very often the tests were failing because of bugs in the tests, and after struggling with the TDD paradigm for a couple of weeks, they ended up being less religious about TDD, and they only kept a few test that were making sense. It was a huge software project, and those guys were top programmers at a multinational, not amateurs.
I'm confused what should I test, and how. Many of my projs have some hardware, so I guess it will take considerable effort to mock the hardware signals.
Your question made me think I might have a problem with decision making and committing to fixed specs. Could be. In hardware such problems are smaller, because the choices are limited by the available parts, and other limitations from the physical world, while in software the possibilities are endless. In software it is always possible to want/add more, or to switch between a completely different programming ways.
In software, do the simplest thing that could possibly work. You can always change it later. Don't add generality "just in case" -- "You aren't gonna need it" (YAGNI)
QuoteEver refactored something?
Usually that's where I lose control, so I need to re-arrange/redesign some parts. I've read a refactoring means better structured code, while retaining the same functionality from before. I usually end up with buggy code after a refactoring attempt, or with a broken project that doesn't work any more.
HUGE red flag.
Refactoring should be a simple mechanical code transformation. It is so mechanical that people make IDEs with the common refactorings built in: "rename variable/function", "move code out of loop", "convert global to function argument", "extract code block into a function", "inline function into its callers", and so on.
Test after every small refactoring. Commit each individual change to git so that you can always backtrack if you break something.QuoteI've read once some book that was in fashion, about TDD (Test Driven Design). Write a test for every line seems nonsense to me. Who's testing the test, then?
That's very simple.
You write the test for a feature (or bug) before you implement the feature (or fix the bug).
Check that the test fails.
Implement the feature or fix the bug.
Check that the test now passes.
It's not a test for every line of code. It's tests for every feature.
...My guess is I might have to unlearn the procedural programming style and move to OOP. Or maybe I'm really bad at programming. I don't know what I'm doing wrong, but I know my projects are eventually abandoned because the software part became overwhelming.
What to do to become more productive in writing code (for small/hobby projects)? Some programming exercises/books/classes to follow? Something else to learn? :-//
Most of the hobby projects require to write some MCU firmware, usually in C, and sometimes a PC interface, usually in Python. Any directions of how to write that faster is welcome.
When writing embedded code, I used to write comment sections stating what the code has to do, and briefly why. The I'd write code to do exactly that.
I'd use this as a go/no-go test - if I couldn't write that comment section, it meant I didn't really know what I was trying to do. So I'd stop, generate supplementary
design documentation that nailed down that particular aspect, then go again. That supplementary document might be something small - a decision table, a timing
diagram, a pinout, a sketch of data flows. But it was something I couldn't keeo in my head, and needed to see in front of me, while I wrote the code for it.
Quoteas the time to analyze the number of linearly-independent paths through a module grows exponentialy with the number of module lines, that's why in my-C I imposed a finited number of arguments passed to a function and a finited number of lines themselves of the body of function.
Those problems are best kept under control by having a design strategy based around the concepts of locality, cohesion and coupling. The language is of secondary importance.
You are living in a state of sin. If you ask the AI whether it has supplied sufficient tests, it will "hallucinate" the answer "yes".
...
dev (in_out: it, in: test_report); /* development team */
test(in: it, out:test_report); /* testing team */
...
(1) note that in the military sector it is absolutely forbidden for the development team to talk to the testing team, so even that they don't even have to greet each other, that they are sitting in two different openspaces, that they go to two different bathrooms and different canteens (same physical canteen room, but different timetables), and the only allowed form of communication is the test_report, as I indicated in the loop above.
I've read once some book that was in fashion, about TDD (Test Driven Design). Write a test for every line seems nonsense to me. Who's testing the test, then? I recall even from one of the working places where a software team tried TDD. Very often the tests were failing because of bugs in the tests, and after struggling with the TDD paradigm for a couple of weeks, they ended up being less religious about TDD, and they only kept a few test that were making sense. It was a huge software project, and those guys were top programmers at a multinational, not amateurs.I'm a pragmatist. I use tests to find out. Mad scientist with his experiments, perhaps.
I'm confused what should I test, and how. Many of my projs have some hardware, so I guess it will take considerable effort to mock the hardware signals.
There have been a couple of jobs at medium-large companies where I have ended up dating the QA person responsible for torturing my code!
There have been a couple of jobs at medium-large companies where I have ended up dating the QA person responsible for torturing my code!
the theory, the practice ... the problem is that in the QA department there was a beautiful Swedish girl with green eyes and long legs ... how can you not invite her to lunch? maybe outside the base so as not to point out that you have the yellow card (from the development department) and she has the red one (from the QA department), and therefore you shouldn't even say hello to her?
We are human after all... :-//
When writing embedded code, I used to write comment sections stating what the code has to do, and briefly why. The I'd write code to do exactly that.
I'd use this as a go/no-go test - if I couldn't write that comment section, it meant I didn't really know what I was trying to do. So I'd stop, generate supplementary
design documentation that nailed down that particular aspect, then go again. That supplementary document might be something small - a decision table, a timing
diagram, a pinout, a sketch of data flows. But it was something I couldn't keeo in my head, and needed to see in front of me, while I wrote the code for it.
That's a useful technique for all software, and hardware for that matter.
The three kinds of relationships include association, inheritance, and aggregation.
Note that OOD is not the same thing as OOP.
Most authors can't write concise sentences.You have no idea how difficult it is to be precise, concise, and easily understood at the same time. :'(
Searched all morning browsing books that teach programing with objects. Browsed 5-10 top titles that come up from a Google search. Very disappointed. Talking about the form, can't judge the content myself.I recommend Object-Oriented Programming in Oberon-2 by Hanspeter Mössenböck, published by Springer-Verlag.
The goal of this book is to convey the fundamentals of OOP, namely classes, inheritance and dynamic binding. The emphasis is on the concepts rather than on the specifics of a particular programming language. In addition, readers should learn to determine for which problems OOP is most suitable, and which problems would be better solved with conventional means.
Did an inventory of my unfinished tinkering projects last weekend, and most are stalled without firmware/software.Use an MCU that supports Micropython and don't care about the costs especially if you want to get a project finished quickly. Spare time is valuable! I have been venturing into implementing the high level parts of MCU firmware using scripted languages like Lua and Micropython. I'm currently working on a project for a customer that uses Micropython to implement the logic. It is a whole lot less tedious compared to using C.
The goal is to write fast enough and good enough code, so to get functional projects, not to become a programmer able to work in a team. Environment is Linux and FOSS tools.
I've wrote small programs occasionally, starting decades ago. Fortran was probably the first I read a book about in the high school, but didn't practice, later practiced some Basic on home computers, then at university we did some Turbo Pascal, then read K&R which later applied to programming microcontrollers, with some other languages and algorithm books/classes in between (i.e. the Knuth's 'Algorithms' books, about half of the 4-5 volumes). Latest language I've dealt with is Python. I know the basics of OOP, but not able to take advantage of it. I'm stuck with the procedural writing style. Never tried functional programming or other fancier stuff.
My guess is I might have to unlearn the procedural programming style and move to OOP. Or maybe I'm really bad at programming. I don't know what I'm doing wrong, but I know my projects are eventually abandoned because the software part became overwhelming.
What to do to become more productive in writing code (for small/hobby projects)? Some programming exercises/books/classes to follow? Something else to learn? :-//
Most of the hobby projects require to write some MCU firmware, usually in C, and sometimes a PC interface, usually in Python. Any directions of how to write that faster is welcome.
Most authors can't write concise sentences.You have no idea how difficult it is to be precise, concise, and easily understood at the same time. :'(
I have been venturing into implementing the high level parts of MCU firmware using scripted languages like Lua and Micropython. I'm currently working on a project for a customer that uses Micropython to implement the logic. It is a whole lot less tedious compared to using C.