$0.03 microcontroller

Am 14.10.2018 um 03:20 schrieb snipped-for-privacy@gmail.com:

All instructions except for jumps are 1 cycle. Jumps if taken are 2 cycles, 1 otherwise.

Philipp

Reply to
Philipp Klaus Krause
Loading thread data ...

Am 14.10.2018 um 08:53 schrieb Philipp Klaus Krause:

idxm and ldxm seem to be 2 cycles, too.

Philipp

Reply to
Philipp Klaus Krause

Interesting, this at least confirms that the instruction word is 16 bits. In a Harvard architecture, the word length could have been

13-17 bits, with some dirty encodings in 113 bit case., but a cleaner encoding with 14-17 bit instruction words.

Assuming one would like to make an encoding for exactly 1024 code words and 64 byte data memory, a tighter encoding would be possible. Of course a manufacturer with small and larger processors, would make sense to use the same encoding for all processors, which is slightly inefficient for smaller models.

Anyway 1 kW/64 byes case, the following code points would be required:

2048 = 2 x 1024 call, goto 1792 = 7 x 256 Immediate data (8 bit) 2304 = 36 x 64 M-referense (6 bit) 1024 = 8 x 128 Bit ref (M and IO 3+4 bits others

This might barely fit into 13 bits, with some nasty encoding.

Limiting M-refeence to 4 bits (0-15), but you still can't fit into 12 bit instruction length.

So with 16 bit word length, I do not understand why word reference is limited to 4-5 bits.The bit address limit makes more sense, so that it would not consume 4096 code points.

Reply to
upsidedown

I think they've sold out since they went viral. EEVblog did a video showing

550 in stock - that's only $16 worth of parts, not hard to imagine they've been bought up.

The other option is they're some kind of EOL part and 3c is the 'reduced to clear' price - which they have done, very successfully.

Theo

Reply to
Theo

No - the BGA part is 1.6mm square (0.3mm pitch) - the 3mm is for 0.4mm pitch QFN and there is a 0.5mm pitch QFN part at 4mm square. The QFNs are reasonably prototype-able - needing only 0.15mm track and gap design rules and no filled vias in pads or other horrors. The point about the 32660 is that it is HARDWARE minimal but not constrained in software. At low volumes cost of the parts is nothing - a day of effort is $500 or more, in that context the difference between a free processor and a $2 processor is invisible.

MK

Reply to
Michael Kellett

My interpretation of the manual was that you only had access to the first 16 addresses with the M instructions. But it is entirely possible that I am wrong and your interpretation is right. I haven't tried the devices, or the IDE, and the manual does not have details of things like instruction format.

Certainly it would be nicer for the chip if you are right!

Reply to
David Brown

Single cycle, according to the manual. Instructions involving 16-bit values are two cycle, the conditional branch instructions may be one or two cycles, and everything else is one cycle.

It is not so hard to make the RAM dual ported when there is only 64 bytes of it. Or perhaps the core is clocked on both falling and rising edges, so that the instructions are effectively 2/4 clocks rather than 1 or two. We can only guess.

Reply to
David Brown

"idxm" is an indirect load or store (depending on the order of the operands). No, there are no other operations that can be combined with indirect accesses.

If you want to keep the TOS in the accumulator, then Forth "+" becomes:

mov temp, a; // 1 clock dec dsp; // 1 clock idxm a, dsp; // 2 clock add a, temp; // 1 clock

5 clocks is a good deal better than 9 clocks, but still a good deal worse than 2 clocks.

A stack-based system is often a good choice for very small cpus - it is certainly popular for 4-bit microcontrollers. But it seems that the designers of this device simply haven't considered support for Forth-style coding to be important.

Reply to
David Brown

Or you could read the SP, put that address into a different word memory location, and use that for indirect access to write to the stack.

It is all possible, but not particularly efficient.

Reply to
David Brown

Am 14.10.2018 um 14:37 schrieb David Brown:

Efficient stack acccess is important for C, too. Putting local variables on the stack makes functions reentrant (not so important for small devices), and also saves memory (bery important for small devices).

The STM8 and S08 with their efficent sp-relative adressing and the Z80 with the index registers thus make better targets for C compilers than the MCS-51 and HC08.

Philipp

Reply to
Philipp Klaus Krause

Am 14.10.2018 um 10:58 schrieb snipped-for-privacy@downunder.com:

Indeed Padauk makes variants with up to 256 B of RAM.

Maybe the M-reference limit only applies to the bit manipulation instructions? The line in the manual explains M.n, there is no seprate line for M; maybe they only documented the restrictions, with M then referring to the full 8-bit range outside of bit manipulation instructions?

Philipp

Reply to
Philipp Klaus Krause

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

Everyone. With an efficent stack-pointer-relative addresing mode, you put all local varibles on the stack and only need as much RAM as the local variables along the longest path in the call tree.

If your local variables are all static, the local variables of two functions that never get called at the same time still both takespace in RAM at the same time.

Compilers can sometimes overly local variables on non-reentrant functions as an optimization, but that will only work for some cases; often it would require link-timeoptimization, which is not that common

Example: main() calls f() and g(); both f() and g() call h(). All four functions are in different translation units, f() and g() both use a lot of local variables, while main() and h() use little. Without link-time optimization, the compiler will use about as much RAM as f() and g() together, when the local variables are static. When they are put on the stack, it will only need as much RAM as either f() or g().

Philipp

Reply to
Philipp Klaus Krause

ar

d
a

Efficiency has to be relative on such a limited machine. If there are no r egisters nearly everything is going to be clumsy and slow. I'm not sure us ing this CPU with Forth would be at all bad even if the CPU is not intended for Forth.

One of the things that makes Forth so useful is that it can be tailored to the target. Rather than use the standard words you can write your own word s that better fit the architecture. I'm not a Forth system designer, but I have designed CPUs in FPGAs and being able to target my CPU design with Fo rth is great. My CPU uses an 8 or 9 bit instruction size with multibyte in structions by prepending immediate addresses or data. I was able to make t hat work easily in Forth while it would have been a bear in C or other lang uages.

Rick C.

Reply to
gnuarm.deletethisbit

Am 12.10.2018 um 10:18 schrieb Philipp Klaus Krause:

And there is the MCS11, with 8 cores.

Philipp

Reply to
Philipp Klaus Krause

Am 12.10.2018 um 08:50 schrieb Philipp Klaus Krause:

On the other hand, saving those pseudo-registers at interrupts and across function calls will be painful.

Philipp

Reply to
Philipp Klaus Krause

Am 10.10.2018 um 03:05 schrieb Clifford Heath:

If you are willing to pay 0.04$, you can get twice the RAM and program memory (not OTP for this one):

formatting link

Philipp

Reply to
Philipp Klaus Krause

luni, 15 octombrie 2018, 15:35:22 UTC+3, Philipp Klaus Krause a scris:

Nah... not sure. 4c is too much... :-D

Reply to
raimond.dragomir

On Monday, October 15, 2018 at 9:05:23 AM UTC-4, snipped-for-privacy@gmail.com wrot e:

Too much you say? How about THIS deal???

formatting link

Three for a penny! But wait, there's MORE!!! It also has more memory and an ADC.

Not sure how you actually order any of this stuff.

Rick C.

Reply to
gnuarm.deletethisbit

That's 0.35 Chinese Yuan (not Japanese Yen, which uses a similar-looking currency symbol) so about 0.05 USD.

Reply to
Paul Rubin

Normally you'd use whole-program optimization, I thought. I don't know if SDCC supports that, but GCC does, as do the more serious commercial embedded compilers.

Reply to
Paul Rubin

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.