On 12/10/18 08:50, Philipp Klaus Krause wrote:> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >> upsidedown@downunder.com 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. >> > > 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?
$0.03 microcontroller
Started by ●October 9, 2018
Reply by ●October 12, 20182018-10-12
Reply by ●October 12, 20182018-10-12
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 HeathThey 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 by ●October 12, 20182018-10-12
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: > > upsidedown@downunder.com 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. > > > > 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 the target 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.
Reply by ●October 12, 20182018-10-12
On Fri, 12 Oct 2018 09:44:15 +0200, David Brown <david.brown@hesbynett.no> wrote:>On 12/10/18 08:50, Philipp Klaus Krause wrote: >> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>> upsidedown@downunder.com 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. >>> >> >> 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!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.> >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 by ●October 12, 20182018-10-12
On Fri, 12 Oct 2018 10:18:56 +0200, Philipp Klaus Krause <pkk@spth.de> wrote:>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. > >PhilippInteresting, 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 by ●October 12, 20182018-10-12
Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com:> > The real issue would be the small RAM size.Devices with this architecture go up to 256 B of RAM (but they then cost a few cent more). Philipp
Reply by ●October 12, 20182018-10-12
On Fri, 12 Oct 2018 22:06:02 +0200, Philipp Klaus Krause <pkk@spth.de> wrote:>Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >> >> The real issue would be the small RAM size. > >Devices with this architecture go up to 256 B of RAM (but they then cost >a few cent more). > >PhilippDid 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 by ●October 13, 20182018-10-13
On 11/10/2018 14:56, David Brown wrote:> On 11/10/18 15:04, Michael Kellett wrote: >> 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 > > 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. >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 3mm square, 24 pin Cortex M4, 96MHz, 256k flash, 96k RAM, £1.16 (10 off). 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 by ●October 13, 20182018-10-13
On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote:> 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: >>> upsidedown@downunder.com 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. >>> >> >> 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 the target 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. >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 by ●October 13, 20182018-10-13
On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown wrote:> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: > > 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: > >>> upsidedown@downunder.com 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. > >>> > >> > >> 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 the target 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. > > > > 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.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 other chips that run very fast. So? I believe others have said the instruction set is memory oriented with no registers. 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 Forth implementation compared to other compilers since there won't be a significant penalty for using a stack. Rick C.
