$0.03 microcontroller

Loading thread data ...

onsdag den 10. oktober 2018 kl. 03.05.27 UTC+2 skrev Clifford Heath:

formatting link

Reply to
lasselangwadtchristensen

Interesting. They have some very off-brand FPGA type devices as well at ve ry low prices, but they still don't do me any favors with the packages.

Rick C.

Reply to
gnuarm.deletethisbit

very low prices, but they still don't do me any favors with the packages.

they also do PCBs jlcpcb.com and I've heard they also have a dirt cheap ass embly service as long as you only use their list of components, though it s eems it is so far only available in China

Reply to
lasselangwadtchristensen

That is impressive! Seems to be an 8-bit RISC with no registers, just an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, enough for plenty of MCU things. Didn't check if it has an ADC or PWM. I like that it's in a 6-pin SOT23 package since there aren't many other MCUs that small.

Reply to
Paul Rubin

There is a lot of operations that will update memory locations, so why would you need a lot of CPU registers.

1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented assembly program listing.

At least the 8 pin version has both a PWM as well as a comparator, so making an ADC wouldn't be too hard.

Reply to
upsidedown

Has anyone actually used them - or worked out where to get the ICE and how much it costs ?

MK

Reply to
Michael Kellett

The cost of the ICE is not going to be significant for most people - you usually use a chip like this when you want huge quantities (even though it is available in small numbers).

What turns me off here is the programming procedure for the OTP devices. There is no information on it - just a simple one-at-a-time programmer device. That is useless for production - you need an automated system, or support from existing automated programmers, or at the very least the programming information so that you can build your own specialist programmer. There is no point in buying a microcontroller for $0.03 if the time taken to manually take a device out a tube, manually program it, and manually put it back in another tube for the pick-and-place costs you $1 production time.

Reply to
David Brown

Being able to (say) add register to register saves traffic through the accumulator and therefore instructions.

It would be nice to have a C compiler, and registers help with that.

Thanks.

Reply to
Paul Rubin

Looking at the instruction set, it should be possible to make a backend for this in SDCC; the architecture looks more C-friendly than the existing pic14 and pic16 backends. But it surely isn't as nice as stm8 or z80. reentrant functions will be inefficent: No registers, and no sp-relative adressing mode. On would want to reserve a few memory locations as pseudo-registers to help with that, but that only goes so far.

Philipp

Reply to
Philipp Klaus Krause

It looks like the lowest 16 memory addresses could be considered pseudo-registers - they are the ones that can be used for direct memory access rather than needing indirect access.

And I don't think inefficient reentrant functions would be much of a worry on a device with so little code space!

Some of the examples in the datasheet were given in C - that implies that there already is a C compiler for the device. Has anyone tried the IDE?

Reply to
David Brown

Am 10.10.2018 um 03:05 schrieb Clifford Heath:

They even make dual-core variants (the part where the first digit in the part number is '2'). It seems program counter, stack pointer, flag register and accumulator are per-core, while the rest, including the ALU is shared. In particular, the I/O registers are also shared, which means some multiplier registers would also be - but currently all variants with integrated multiplier are single-core. Use of the ALU is shared byt he two cores, alternating by clock cycle.

Philipp

Reply to
Philipp Klaus Krause

On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote :

CPUs like this (and others that aren't like this) should be programmed in F orth. It's a great tool for small MCUs and many times can be hosted on the target although not likely in this case. Still, you can bring enough func tionality onto the MCU to allow direct downloads and many debugging feature s without an ICE.

Rick C.

Reply to
gnuarm.deletethisbit

The real issue would be the small RAM size.

With such small ROM/RAM sizes, who needs reentrant functions ? Possibly only if you think that every problem must be solved by recursion :-).

Reentrancy is nice, when writing run time library (RTL) routines that might be called from different contexts, but who in their right mind would call RTL routines from the ISR ?

OK, some might put an RTOS into that processor, but even in that case, the RTOS might consist only of a simple foreground/background monitor, so unlikely need reentran routines.

If you insist of using "C", just declare all variables as

static uint8_t (and a few static uint16_t)

so no reentrant code is generated.

However, you could as well use some old 8 bitter languages such as PL/M-80.

Reply to
upsidedown

Interesting, that would make it easy to run a multitasking RTOS (foreground/background) monitor, which might justify the use of some reentrant library routines :-). But in reality, the available memory (ROM/RAM) is so small so that you could easily manage this with static memory allocations.

Reply to
upsidedown

Am 12.10.2018 um 20:30 schrieb snipped-for-privacy@downunder.com:

Devices with this architecture go up to 256 B of RAM (but they then cost a few cent more).

Philipp

Reply to
Philipp Klaus Krause

Did you find the binary encoding of various instruction formats, i.e how many bits allocated to the operation code and how many for the address field ?

My initial guess was that the instruction word is simple 8 bit opcode

  • 8 bit address, but the bit and word address limits for the smaller models would suggest that for some op-codes, the op-code field might be wider than 8 bits and address fields narrower than 8 bits (e.g. bit and word addressing).
Reply to
upsidedown

My major interest in this part was for fun - hence caring about the cost of the ICE. From a business point of view it makes no sense - by the time you reach numbers big enough to care about the cost of the micro the risk of using a part like this is too great. Different if you are next door to the manufacturer.

If you want a hardware minimal processor the Maxim 32660 looks like fun

My guess is that you need to be using at least 5k of them before the cheaper Padauk part offsets the cost of using one.

MK

Reply to
Michael Kellett

Forth is a good language for very small devices, but there are details that can make a huge difference in how efficient it is. To make Forth work well on a small chip you need a Forth-specific instruction set to target the stack processing. For example, adding two numbers in this chip is two instructions - load accumulator from memory X, add accumulator to memory Y. In a Forth cpu, you'd have a single instruction that does "pop two numbers, add them, push the result". That gives a very efficient and compact instruction set. But it is hard to get the same results from a chip that doesn't have this kind of stack-based instruction set.

Reply to
David Brown

rote:

hy

e

ed

d

ve

an be hosted

Your point is what exactly? You are comparing running forth on some other chip to running forth on this chip. How is that useful? There are many ot her chips that run very fast. So?

I believe others have said the instruction set is memory oriented with no r egisters. I think that means in general the CPU will be slow compared to a register based design. That actually means it is easier to have a fast Fo rth implementation compared to other compilers since there won't be a signi ficant penalty for using a stack.

Rick C.

Reply to
gnuarm.deletethisbit

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.