Processor choice

--
You may find that 6hrs is the battery capacity.   Adding 
 rechargeable will reduce that time. 
 Click to see the full signature
Reply to
Martin Rid
Loading thread data ...

Interesting that this question was asked here in sed with a group of argumentative miscreants rather than in comp.arch.embedded among people who do this all day long and largely are so much more helpful and supportive.

I'm just sayin'...

--
Rick C. 

+ Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

CPU microcode? That is rarely accessible.

As for what is visible, that depends on how you think about it. Often by looking at the assembly, you can see the details but not the overall picture.

But certainly programmers who are only used to high level languages often have a poor appreciation for what is going on at the low level - they write things like "int x = y * 0.5;" and are surprised when the code on their 8-bit microcontroller is slow, or they use "std::string" because that's what they learned in their C++ classes. Having an understanding of assembly is useful for embedded programming (as is having an understanding of basic electronics).

All techniques have their advantages and disadvantages. Well-written C++ template programming can give you very clear and flexible source code that turns into extremely tight and efficient assembly results - which are then nearly impossible to follow with single-stepping or breakpoints on functions (since the functions don't exist).

I've seen cases where C++ layers have made it very difficult to find the problems. But I've also seen cases where assembly has made it difficult to find the problems.

My experience is that these kind of things are often design flaws, rather than coding flaws, and the design might be clearer in a higher level language.

It is extremely rare that I find cases where I can do something in assembly, but not in C or C++. It is now extremely rare where I think I can do things more efficiently in assembly. (SIMD code might be one case, but that doesn't turn up in my usual work.) Very occasionally, I might use a single instruction in inline assembly, but not whole functions.

Yes, I agree on that. It is especially the case for weaker C compilers. (The compiler for the Arduino is gcc, which is normally one of the top compilers available, but there are limitations to its efficiency on the

8-bit AVR. This is combined with the Arduino environment making it as inconvenient as possible to fine-tune your compiler flags.)
Reply to
David Brown

The discussion has wandered a bit, as they are wont to do. Which tasks would you say you can do in assembly, but not in an HLL? We can agree that debugability varies, as well as when it is clear what is going on. But which tasks /can't/ be done using a good quality C or C++ toolchain? (That could perhaps be extended to Ada and Forth too, if you like.)

My experience is that when people say "the optimizer is causing a problem" or "optimisations are breaking my code", the problem almost invariably lies in the source code, not the optimiser. Bugs in compilers are not unknown, but they are extremely rare compared to bugs in the users' code.

Sometime changing optimisation settings can help reveal the bugs in the user code, however.

I've used gcc for embedded programming for about 25 years. It has been my main compiler for perhaps 15 years. But it has never supported 8-bit accumulator-based microcontrollers, so its rise to dominance in embedded development has come with the decline of that kind of device.

I have certainly seen C compilers where "while (n--) ... " will generate more efficient code than "for (int i = 0; i < n; i++) ..." and that kind of thing. Better quality compilers suffer less from this. But no matter how good a compiler's optimisations, it is always restricted by the rules of the language - it is easy, for example, to write a loop where you know the limits are constant but the compiler can't prove they are. A refactoring of the source code could then make a noticeable difference.

Reply to
David Brown

There's an argument that such suboptimalities are due to poor design in one case and poor tools in the others :)

I submit that, given people are the root cause, it is easier to improve the tools than design :)

Reply to
Tom Gardner

People don't always agree on the definition of "high level language", but there is pretty much universal agreement that assembly is a "low level language".

The definition I use is that a "high level language" is a language that is defined in terms of an abstract machine, rather than any particular implementation. C has some parts defined as "implementation dependent", and thus has some low level aspects, but is primarily a high level language. Assembly is completely defined in terms of the processor and is thus entirely low level.

Sorry, I have no idea what you are trying to say.

You wanted to show me a strawman? Yes, you managed that fine.

Or were you just trying to show that one person - you - failed to install a particular C compiler, and you thought that meant that everyone will have trouble with all C compilers?

Do you also think that because you had some trouble with your car, everyone else would be better off using horses and wagons?

Reply to
David Brown

On a sunny day (Sun, 28 Feb 2021 16:12:27 +0100) it happened David Brown wrote in :

Maybe you are here for the arguing only?

Oh boy, you behave like an a*hole, apt-get install gcc is not MY work.

Sometimes I say: For 100$ I will say you are right, and I will give you a discount: for 199$ I will say it twice. But for you the price is much higher now. Show us some code babble man!

From me there is plenty on my website, you COULD learn from that, electronics too. Your turn.

Reply to
Jan Panteltje

Your definition is way too generic and no, C has no low level aspects.

Unless you have the register model ***of a particular processor*** in mind while programming you are writing in a high level language. Somewhere in the middle between high and low level is my vpa, which gives you 32 general purpose registers to think about no matter what the processor is and allows you low level - access to CPU specific - registers as well.

C and the rest of the high level languages are good as long as you will not spend more than a month of programming on a project. From there on they become an obstacle, you have to fit your work to the language instead of vice versa; for serious programming you just need a more semantically rich language than any high level language is. IOW high level languages are the phrase books of programming, you just don't write novels at phrase book level because everybody who tries to read your novel will at best have a laugh at you. Since the public is still widely illiterate when it comes to programming unlike on reading novels they get away with it.

Dimiter

====================================================== Dimiter Popoff, TGI

formatting link
======================================================
formatting link

Reply to
Dimiter_Popoff

No, I have been trying to give sensible suggestions to the OP and to have discussions with others in this thread.

I genuinely could not figure out what you meant here. If you want to expand on it, maybe it would be worth discussing - if not, then let's drop it.

You generally have to be /very/ unlucky, or have messed up your system, before you can't install a working gcc in a Linux system using the distribution's standard methods. But whether it was something you did, or failed to do, or whether it was a mess-up by Ubuntu, your failure to get gcc working on your Pi has /nothing/ to do with the suitability of C for programming a microcontroller!

You've been listening to John Larkin too much.

Reply to
David Brown

By my definition, C has low level aspects - such as the size of types, the format for signed integers, etc. Basically, everything that goes under "implementation defined behaviour" is low level.

However, I happily accept that the definition of "high level language" that I use (it's not really "my" definition) is not the only possibility. I'd be happy to hear the one you use.

Whether you write your code in a portable "high level" manner or a system-specific "low level" manner is somewhat orthogonal to the level of the language. Obviously different languages have better support for different types of programming.

If you write C code that uses only fully defined implementation-independent behaviour, you are clearly writing high-level code - and C is designed to support that kind of programming. Many people also write C code that is /not/ portable - it relies on assumptions about the sizes of types, for example, or upon extensions for a particular implementation - and that is then low level programming. C is designed to support that too. (One of the goals of C was to reduce the need to write so much code in assembly.)

And somewhere in the middle is the way most people write C code - somewhat portable, but not fully. Typically they assume "char" is

8-bit, integer types are 8-bit, 16-bit, 32-bit and 64-bit, with two's complement encoding. Some people are more careful than others - using "int32_t" when they need 32 bit, rather than just using "int" and assuming it all works.

What a strange thing to say! C has been used successfully for some of the longest running projects ever (such as the Linux kernel). And the general consensus is that when you have a larger project (in time and/or lines of code), higher level is better than lower level.

I know you have had success with your own personal language - that's fine. But I think it gives you a rather "coloured" view of the rest of the programming world.

Reply to
David Brown

Portability is not directly related to high or low level. Basically any language is portable as long as you are willing to put in the effort to write a translator (which is how my vpa started, I had a large amount of good 68k assembly code (about 8 megabytes of sources back then IIRC) so I made it portable for power (called PPC back then, for the record).

High or low level programming depends on what goes on in your head when you write, not on the toolchain. If you think in a machine specific way - say, accumulator a, accumulator b, x and sp and go through all the hoops these impose on you (remember doing tsx/txs to access operands on stack?... :) you write low level. If you think variables and let the compiler worry about tsx/txs you write in a high level language.

Well I might agree with that, though the "middle" is a bit stretched and your example is closer to high level than mine I suppose.

I know I am alone against the rest of the world with that. Consensus does not mean truth, you know. Not so long ago there was a wide consensus that the Earth was flat.... I have yet to encounter a person of programming productivity comparable to mine - and since I only have a single head and one pair of hands it must be down to the different path I took all those years ago.

Oh my view is probably a lot more coloured than you think. And my language when I speak about all the bloated PC/phone you name it software is proboably as colourful as anyone could imagine :).

Dimiter

====================================================== Dimiter Popoff, TGI

formatting link
======================================================
formatting link

Reply to
Dimiter_Popoff

Well, I think we are talking about a somewhat different kind of "high" and "low" level.

"Somewhere in the middle" means between the extremes, not not necessarily close to the centre (a somewhat meaningless idea when there is no specified scale).

Actually, there was never a known time when there was a consensus, or even a majority, that thought the world was flat. You can look at the horizon on the sea, and it is obviously curved - our ancestors were never as stupid as modern flat-earthers!

Programming productivity varies hugely. It can vary between professional programmers by orders of magnitude, due to all sorts of reasons. There is nothing to suggest you would not also have been highly productive with another language or methodology, nor anything to suggest other people would be as productive using your language.

I would not offer PC's or phones as examples of efficient programming!

Reply to
David Brown

Jon, did you program the AT Tiny from your Linux system? And, if you did, what Linux version are you using? I'm looking for Linux version that functions pretty much like a basic Unix system.

Hul

J> >

Reply to
Hul Tytus

You can program AVRs under linux. Most distibutions package up avrdude - which is a versatile programmer, which can work with lots of programmers, avr-gcc for compiling C and avr-libc for the c libraries.

I have a headless Pi setup for programming AVRs running an old version of rapsbian. If you want a Linux distro without systemd, try devuan . It has a sysV init system by default.

Reply to
Jim Jackson

formatting link

Five bucks, Arduino like.

Reply to
Reinhardt Behm

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.