experchange > comp.arch.embedded

Clifford Heath (10-10-18, 03:05 AM)
<https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html>
<http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf>

OTP, no SPI, UART or I²C, but still...

Clifford Heath
lasselangwadtchristensen (10-11-18, 01:12 AM)
onsdag den 10. oktober 2018 kl. 03.05.27 UTC+2 skrev Clifford Heath:
> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html>
> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf>
> OTP, no SPI, UART or I²C, but still...
> Clifford Heath


gnuarm.deletethisbit (10-11-18, 02:51 AM)
On Tuesday, October 9, 2018 at 9:05:27 PM UTC-4, Clifford Heath wrote:
> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html>
> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf>
> OTP, no SPI, UART or I²C, but still...
> Clifford Heath


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

Rick C.
lasselangwadtchristensen (10-11-18, 03:56 AM)
torsdag den 11. oktober 2018 kl. 02.51.17 UTC+2 skrev gnuarm.del...@gmail.com:
> On Tuesday, October 9, 2018 at 9:05:27 PM UTC-4, Clifford Heath wrote:
> > <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html>
> > <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf>
> > OTP, no SPI, UART or I²C, but still...
> > Clifford Heath

> Interesting. They have some very off-brand FPGA type devices as well at 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 assembly service as long as you only use their list of components, though it seems it
is so far only available in China
Paul Rubin (10-11-18, 04:29 AM)
Clifford Heath <no.spam> writes:
> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html>
> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf>
> OTP, no SPI, UART or I²C, but still...


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.
upsidedown (10-11-18, 10:39 AM)
On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin
<no.email> wrote:

>Clifford Heath <no.spam> writes:
>> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html>
>> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf>
>> OTP, no SPI, UART or IC, but still...

>That is impressive! Seems to be an 8-bit RISC with no registers, just
>an accumulator, a cute concept.


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

>1K of program OTP and 64 bytes of ram,


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

>enough for plenty of MCU things. Didn't check if it has an ADC or PWM.


At least the 8 pin version has both a PWM as well as a comparator, so
making an ADC wouldn't be too hard.
Michael Kellett (10-11-18, 03:04 PM)
On 10/10/2018 02:05, Clifford Heath wrote:
> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html>
> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf>
> OTP, no SPI, UART or I²C, but still...
> Clifford Heath


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

MK
David Brown (10-11-18, 03:56 PM)
On 11/10/18 15:04, Michael Kellett wrote:
> On 10/10/2018 02:05, Clifford Heath wrote:
> Has anyone actually used them - or worked out where to get the ICE and
> how much it costs ?
> MK


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.
Paul Rubin (10-12-18, 01:08 AM)
upsidedown writes:
> There is a lot of operations that will update memory locations, so why
> would you need a lot of CPU registers.


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

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


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

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


Thanks.
Philipp Klaus Krause (10-12-18, 08:50 AM)
Am 12.10.2018 um 01:08 schrieb Paul Rubin:
> upsidedown writes:
> 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.


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
David Brown (10-12-18, 09:44 AM)
On 12/10/18 08:50, Philipp Klaus Krause wrote:
> Am 12.10.2018 um 01:08 schrieb 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.


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?
Philipp Klaus Krause (10-12-18, 10:18 AM)
Am 10.10.2018 um 03:05 schrieb Clifford Heath:
> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html>
> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf>
> OTP, no SPI, UART or I²C, but still...
> 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
gnuarm.deletethisbit (10-12-18, 06:11 PM)
On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote:
> Am 12.10.2018 um 01:08 schrieb 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.


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

Rick C.
upsidedown (10-12-18, 08:30 PM)
On Fri, 12 Oct 2018 09:44:15 +0200, David Brown
<david.brown> wrote:

>On 12/10/18 08:50, Philipp Klaus Krause wrote:
>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!


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.
upsidedown (10-12-18, 08:39 PM)
On Fri, 12 Oct 2018 10:18:56 +0200, Philipp Klaus Krause <pkk>
wrote:

>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


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.

Similar Threads