Processor choice

Seems like a typical typo, missing decimal point, to me. "22.5 kHz" is "around 22 kHz".

--
Grant. . . . 
unix || die

On a sunny day (Fri, 26 Feb 2021 11:12:01 -0500) it happened neonjohn wrote in :

It is not the answer you want, but really asm has a lot of advantages both in developnent speed and efficieny of use of the hardware. I have programmed many micros and also 8086 stuff in asm. basically it is all the same C and C++ is a pest on very small micros creating not-needed overhead.

For a few sine waves all you need is a lookup table and DAC or R2R DAC. Simplest PIC has the DAC and the code space.

for some PIC asm.

The ATtiny214 is an 8-pin device with an 8-bit DAC and can be programmed in C. There are some even smaller ATtinys without DAC which can also be programmed in C. John

The ATTiny85 are used in the Arduino ecosystem.

Maybe the commercial one can be hacked to not turn off?

Why 8 pin? If you have size requirements give them. If you have requirements for price, give them. Are you making 1 of these, 10 of them, ten thousand of them?

And are you writing the program this century, or last century? Because "programmable only in assembly" has not been a feature of any microcontroller for a couple of decades. (Though it is fair to say that there are still some microcontrollers sold that are not very C friendly.)

As others have suggested, there are a number of ATTiny processors of that sort which are compatible with the Arduino code environment (C with some flourishes). The Atmel micros have a C-friendly instruction set.

If you need (or just want) more CPU power, you could look at some of the 8-pin ARM Cortex M0 chips, such as the STM32G0 devices. Up to 8 kB of RAM, 32kB of flash, 64 MHz CPU, ADC, other goodies. Somebody's probably added Arduino support for these by now, and the open-source Zephyr RTOS added support for them in August of 2019... threads, timers, GPIO support, lots of other stuff is available in Zephyr.

Look at the AT-Tiny. I used an 8-pin version for a blinker-dimmer project. Very easy to program. I got an $11 Sparkfun USB programmer for it. It has a DIP socket, but I used an SOIC version of the chip, so had to adapt the programming header to match.

Jon

Just don't use parameters and local (automatic) variables and a decent C-compiiler will generate acceptable code even on C-unfriendly controller :-).

These days C-compilers are in general so good that you can use it for general programming However, assembler is needed in order to utilize special hardware instructions that can't be expressed in C. One such example is multiple byte data manipulation such as long/floating point add/sub/mul/div which requires handling directly the Carry (and possibly overflow or half carry) bits, which can't be handled directly in C.

And avoid anything that draws on libraries over which you may have no control.

Sometimes, "helper routines" are automatically invoked to address these "more cumbersome" operators and data types. But, my above warning applies equally.

Often, esp when dealing with the hardware, it's easier to learn just enough of the applicable ASM to ensure the exact sequence of opcodes are executed that you need -- instead of hoping the compiler doesn't reorder instructions or that you forget a keyword, etc.

[Sorting out how the hardware actually works often takes longer than writing the ASM to drive it as you want; you're typically not "doing much" in the code, at that point]

I made my living writing assembly code for embedded realtime systems for a few decades. The last major assembly program I worked on had

70,000 lines of executable code.

I would not be afraid of assembly code. It's no harder that C code, but takes four times as many lines.

Most microcontroller C compilers will handle multiprecision and floating point math, generating the correct ASM code to implement the math using whatever arithmetic is built into the CPU. The code is slower than for direct math, but these processors are quite fast, so it is perfectly workable.

The Arduino family of processors have such C compilers.

Joe Gwinn

I don't imagine it is "fear". Rather, an up-front investment in a PARTICULAR processor family/device, coupled with a reduction in coding efficiency (time) and lack of portability -- if the solution proves to be inappropriate, the time spent learning THAT ASM and implementing that bit of code is effectively lost.

The stated application could likely move all of the math to compile-time. It appears the frequencies and sequencing are already known so the synthesis should be straightforward.

You just need one of these:

An ATTiny of your choice,

The Arduino environment:

And install this extension to the environment:

And then you can program the 8 pin ATTiny using the Arduino C/C++ language and all the library functions, and upload direct to the raw chip from the factory, don't need to flash a bootloader (and there isn't much room in 2-8k of program memory for one anyway.)

Another answer you don't want is to learn to use Forth. It is an ideal language for virtually any MCU. One implementation in particular is very useful and prolific, Mecrisp. It has been ported to many ARMs and MSP430 variants.

Does this thing need to do anything other than emit the signals? For that even an 8 pin MCU seems overkill, but I guess it's one of those things where there are many solutions, all good.

How large is this thing? Are we talking the size of a large pill, or more like a strawberry, or more like a lemon? I suppose it floats?

I put a contract on a house a year or so ago and to inspect the septic field they ran a camera up the pipe. Unfortunately there was nothing to find, no drain field, just a long pipe that went off the property.

--

Rick C. 

- Get 1,000 miles of free Supercharging 
- Tesla referral code - https://ts.la/richard11209

You may use a BluePill STM32F103. It is overkill but for less than 5$ you can have the board and the ST-Link :

You may work with Aduino IDE but I prefer the more powerfull STM32Cube with GUI configuration, middleware...

Great for fast prototyping. You may than switch to a low pin STM32 :

That makes no sense whatsoever.

If you are dealing with a brain-dead 8-bit microcontroller (as distinct from an 8 /pin/ device, which he asked for, and distinct from good 8-bit microcontrollers like the AVR family) then you cannot efficiently access data on a local stack. But decent C compilers for 8051, PIC16, and the like all know this - and they allocate parameters and local variables to fixed static addresses where they can. It is only if you need recursive or re-entrant functions that an unavoidably inefficient data stack frame is made.

These kinds of microcontrollers are unfriendly to program in any language - C, assembly, or anything else. But if you are using them with C, use (non-static) local variables whenever possible.

Of course, it makes even less sense to pick one of these devices in the first place. You need a very specialist and niche situation before they are an appropriate choice. (Many people still /do/ pick them, but that is often through ignorance and inexperience, and sometimes due to legacy code or boards.)

Total nonsense.

Any 8-bit microcontroller C compiler worthy of the name will handle your multibyte types and floating point types as simply and conveniently as any other C compiler. It might have some restrictions (such as no

64-bit types), and of course the generated code will be big and slow. But the point of using a high level language like C is that you don't need to handle these details yourself.

And any half-decent C compiler will have extensions, intrinsics or libraries for the most commonly needed actions that can't be handled in standard C (like interrupt control, sleep mode instructions, etc.).

(And again - the OP asked for an 8 /pin/ microcontroller, not an 8 /bit/ device. But that is an easy misinterpretation to make.)

I also used to write lots of assembly code, before progress in C compilers and microcontrollers made C (and now C++) more convenient.

And four times longer to write, and four times longer to debug, four times four times longer to port to a new microcontroller or platform, four times longer to find a new developer for the company that has a hope in hell of understanding the old code, and so on.

Assembly does have occasional use. And /understanding/ the assembly for your microcontroller can give you a far better understanding of how to write good C or C++ code for it.

But it's been 15 years or more since it has made sense to start a new project in assembly.

Damn dude what decade are you living in. gcc for the 8 bit AVR and the

32 bit ARM micro-controllers are about 99% C++11/C99 compliant, excluding for obvious reasons much of the STL and big-iron oriented library functions that don't translate well.

Anything you can write on a desktop x86 using the core of those languages will compile for an 8 bit processor like that. No you don't have to do anything special for floating-point operations on an 8 bit AVR with 512 bytes of RAM and 8k of program store, even if the chip doesn't even have a hardware multiplier (some of the little chips don't.) The compiler pulls in whatever it needs and you just notice your binary size increase by 10-20% if you start declaring "floats" in C and doing operations with them in that case.

And similar good practice for writing C/C++ on the desktop apply to those devices; you want to use automatic variables whenever possible. Data should be kept on the stack whenever possible, you only have persistent state when you have to.

On a sunny day (Sat, 27 Feb 2021 16:18:58 +0100) it happened David Brown wrote in :

For me at least the thing is 100% reversed First you look at the application requirements. If that fits in a micro I have, great. To program those (yes PIC in this case) you will need to

1) read the chip datasheet 2) understand all the internal hardware, timers, PWM generators, serial interface, memory, interrupt structure, etc etc 3) understand the instruction set, special registers, special instructions. 4) Once you know that, then you can write it in asm, even more so if you have, over time, collected a lot of tested code you wrote for various projects with that micro. Using C would be a big burden, like asking your mama to fix your car. Having a great C compiler for that chip does NOT free you from points 1,2,3,...

So using C you need a bigger micro / more memory, more power consumption, maybe less future support, and will be more depending on ever changing tools. I recently tried Ubuntu on a raspberry PI4 8GB, it had no gcc apt-get gcc gave me version 10.? or something, nothing compiled, errors all over the place. Somebody f*cked up gcc. Deleted it, have a working older version. Many of those C libraries 'maintained' by people who are clearly no programmer??? are no longer working right, The mess Linux has become... dependencies... So, asm and no external dependencies saves time too. I would not try to program ARM in asm, so simpler micro. Most of the things we do do not require floating point, I think somebody here recently pointed out that you can do most things in 32 bit integer.

Precisely.