$0.03 microcontroller

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
<https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html
<http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf



Clifford Heath

Re: $0.03 microcontroller
onsdag den 10. oktober 2018 kl. 03.05.27 UTC+2 skrev Clifford Heath:
Quoted text here. Click to load it
24.pdf>
Quoted text here. Click to load it

Quoted text here. Click to load it

https://youtu.be/VYhAGnsnO7w

Re: $0.03 microcontroller
On Tuesday, October 9, 2018 at 9:05:27 PM UTC-4, Clifford Heath wrote:
Quoted text here. Click to load it
24.pdf>
Quoted text here. Click to load it

Quoted text here. Click to load it

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.

Re: $0.03 microcontroller
torsdag den 11. oktober 2018 kl. 02.51.17 UTC+2 skrev snipped-for-privacy@gmail.c
om:
Quoted text here. Click to load it
l>
Quoted text here. Click to load it
0124.pdf>
Quoted text here. Click to load it

Quoted text here. Click to load it
very low prices, but they still don't do me any favors with the packages.
  
Quoted text here. Click to load it

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




Re: $0.03 microcontroller
Quoted text here. Click to load it


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.

Re: $0.03 microcontroller
On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin

Quoted text here. Click to load it

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it


Re: $0.03 microcontroller
snipped-for-privacy@downunder.com writes:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Thanks.

Re: $0.03 microcontroller
Am 12.10.2018 um 01:08 schrieb Paul Rubin:
Quoted text here. Click to load it

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

Re: $0.03 microcontroller
On 12/10/18 08:50, Philipp Klaus Krause wrote:
Quoted text here. Click to load it

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?



Re: $0.03 microcontroller
On Fri, 12 Oct 2018 09:44:15 +0200, David Brown

Quoted text here. Click to load it

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.


Quoted text here. Click to load it


Re: $0.03 microcontroller
Am 12.10.2018 um 20:30 schrieb snipped-for-privacy@downunder.com:
Quoted text here. Click to load it

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

Philipp

Re: $0.03 microcontroller
wrote:

Quoted text here. Click to load it

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).


Re: $0.03 microcontroller
Am 12.10.2018 um 22:45 schrieb snipped-for-privacy@downunder.com:
Quoted text here. Click to load it

People have tried before (https://www.mikrocontroller.net/topic/449689 ,
https://stackoverflow.com/questions/49842256/reverse-engineer-assembler-which-probably-encrypts-code ).
Apparently, even with access to the tools it is not obvious.

However, a Chinese manual contains these examples:

5E0A MOV A BB1
1B21 COMP A #0x21
2040 T0SN CF
5C0B MOV BB2 A
C028 GOTO 0x28
0030 WDRESET
1F00 MOV A #0x0
0082 MOV SP A

Philipp

Re: $0.03 microcontroller
wrote:

Quoted text here. Click to load it

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.


Re: $0.03 microcontroller
Am 14.10.2018 um 10:58 schrieb snipped-for-privacy@downunder.com:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Re: $0.03 microcontroller
Am 12.10.18 um 22:45 schrieb snipped-for-privacy@downunder.com:
Quoted text here. Click to load it

It is more complicated. Apparently the encoding changed from a 16-bit
instruction word used by older types
(https://www.mikrocontroller.net/topic/461002#5616813 ) to a 14-bit
instruction word used by newer types
(https://www.mikrocontroller.net/topic/461002#5616603 ).

Padauk also dropped and added various instructions at some points (e.g.
ldtabh, ldtabl, mul, pushw, popw).

Philipp

Re: $0.03 microcontroller
Am 12.10.2018 um 20:30 schrieb snipped-for-privacy@downunder.com:
Quoted text here. Click to load it

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

Re: $0.03 microcontroller
Quoted text here. Click to load it


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.

Re: $0.03 microcontroller
Am 15.10.2018 um 16:29 schrieb Paul Rubin:
Quoted text here. Click to load it

Quoted text here. Click to load it


anyhting supported by GCC tends to have rather powerful insturction sets
and plenty of registers aynway, so functions could be made reentrant by
default without any problems resulting.

While some link-time optimizations are commonly requested features for
SDCC, currently none are supported. In SDCC, even inter-procedural
optimizations within the same translation unit are not as powerful as
they should be.
Well, there always is a lot of work to do on SDCC, and there are only a
few volunteers with time to work on it. So SDCC developers priorize
(usually by personal preferences).

Still, when looking at the big picture, SDCC is doing quite well
compared to other compilers for the same architectures (see e.g.
http://www.colecovision.eu/stm8/compilers.shtml - comparison from early
2018, around the time of the SDCC 3.7.0 release - current SDCC is 3.8.0).

Philipp

Re: $0.03 microcontroller
On 16/10/18 09:19, Philipp Klaus Krause wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it


No.

Quoted text here. Click to load it

Most gcc targets are quite powerful, with plenty of registers - and
re-entrancy is not a problem.  Some are a bit weaker, like the 8-bit
AVR, and get inefficient with complicated stack usage.  But it does not
support the 8-bit CISC accumulator-based devices that SDCC targets.

Quoted text here. Click to load it


Site Timeline