@nanobot Work should definitely be fun. But personally I think the fun comes from interesting tasks, friendly collegues, a good company culture, and easy to use documentation; not pseudo-engaging emojis.

@rEaL-jAsEs No, you shut up. Or I will tell my mom!

@rEaL-jAsEs Shut up

I used the Blitz3D (PC) variant and it was a good start. Plain and simple to work with, good speed, no fancy features language-wise. The editor was bad. Only nostalgic value today.

@petergriffin At least [Fix], [Feat], [Chore], etc are easily searchable. If someone cannot differentiate these visually of they are placed in a single column, emojis won't help them either. And in documentation they absolutely make no sense at all.

In my opinion being money-minded is a good business practice. Being greedy is not.

C is not the easiest language to learn and it has many quirks and missing features. But it is well designed (especially for the time).
If you need to go low-level C (C++) is a great option. But I haven't tried Rust yet, does anybody have experience with it (in an embedded system)?

More like: "You have 1789 errors".
*fixes missing semicolon after function declaration*
"Looks great now"

Great stuff. Could you share some info on how you did it?

Positive thing: All dumb meetings cancelled.

You learn a lot more by figuring things out yourself. And comparing your solution with a tutorial is a great way to check if you're following best practices.

Because I'm an over-confident hipster, who likes to brag and feel special by paying a ridiculous amount to a company which dictates what I'm allowed to do with my devices. Also, I like to be scammed on repairs.
(There are good reasons to like OSX, but SCNR)

Don't worry, it's not you. It's them. They are shit.

An ad blocker

@Fast-Nop That would be a great and we make use of it as often as possible.
Our 'base' products have a lifetime for about 7-10 years and the market is changing. So a lot gets changed during the products lifetime and in-field.
For our custom products, unfortunately we can't send devkits to customers for evaluation.
I use your method often to make 'simulations' of the final hardware/firmware for our back-end team.

@Root We're on the edge between full Cortex-A with Linux and a Cortex-M. For our application, cost is still lower with a "big" MCU than a Cortex-A with a small MCU as a helper.
So yes, we're in a special (one could say paradoxical) position. On one hand we have a one hardware fits all mentality, because units per customer is low, on the other the way the device is used differs significantly per customer. Time to market is important for the customer, but managing different firmware for each customer is not feasible (there are to many customers and many of them are short-lived).
And there a more high-level approach could be helpful. Like I said, for me it's about modularity and maintainability, not runtime efficiency (we have enough hardware ressources).
I'm pretty sure things will change in the future based on our experiences and the evolving market (Linux? C++?). Time is the limiting factor.

@Fast-Nop Why should I have any problem with function pointers or manual memory management?
Like I said, there is no suitable alternative yet.

And 2MB of Flash is pretty common, just like external RAM.
It really depends on the application what is suitable.
Our customers won't mind a few bucks more on the product because we use a bigger flash, but they would mind waiting for a feature or product/protoype.
And for us it is cheaper to use a bigger flash than to manage customer-specific firmware variants.

@Root I basically only program in C. I quite like the language and I also think it's the best choise for microcontrollers yet. There are also important aspects that cannot be tackled with Pythons and alike yet. But this doesn't mean that C is the end of the line and there won't be anything more suitable ever. As I said, standard Python it is not.
In the product we make, low level stuff is important but only makes a fraction of the whole application. The high-level stuff would be easier to manage with features of high-level languages. Maybe C++ would be sufficient. But that's not going to happen for us, I guess.

@Manjeet Just Google it. It even has a Wikipedia page called literally "CS50".

@Fast-Nop I don't want to work around the limitations of C and it's preprocessor and I don't want to manually manage architecture and high-level code. I want convenience to work efficiently. That doesn't mean not to low-level control the hardware when it's beneficial.
But I think that can be achieved with a version of Python adapted for MCUs. There have always been good solutions like inline assembly in C or calling C libraries from Python. I don't think it's ready yet, but we shouldn't stop looking for improvements because of tradition.

C makes it hard to build modular and easy to maintain code. For products which have those requirements over runtime efficiency, MicroPython could be a viable option (especially when it's compiled, not interpreted).

Any "Learning programming with/in C" book.
But why C?

Send it to the police and/or media anonymously if this is a crime in your jurisdiction (and it is safe that you can't be identified).
Greed is the lowest motive for endangering people.

People regulary working on weekends or doing overtime because of performance comparisons are big red flags and signs of a broken culture. You should leave as soon as you can.

Online certificate on scamming with digital "masterclass" certificates (2+ hours video course, makes you rich, totally not a scam)*
*results may vary

This.

@RememberMe Should be implemented in Jira.

I do embedded stuff and Python is ideal for scripts. I use it for data conversion, doing measurement series, interactive plotting, etc.

The best part is that it is easy to use for people without much programming experience. It is simple to run, modify and extend. This saves me a lot of work.
My non-programmer colleges often send a modified version of a script I made them back. I extract, optimize and reactor the core functions and add them to our product-utility module, which they can then use to get even more automated by themselves.

Clearly it is not used in production, but it helps a lot during development, testing and certification.

I find accepance testing much more useful in firmware development. Nevertheless there are parts in firmware development where unit testing is a great tool. I can also recommend the book posted by OP.

Also create Screenshots (full screen with current time/date from the on-screen clock and the URI from the Brower's address bar), print them together with the full URL and take them to the police. Include as much in the images as possible (group name, description, time/date of the post, account names, account pages, comments, personal messages).