$0.03 microcontroller

Am 14.10.2018 um 10:58 schrieb upsidedown@downunder.com:
> 
> 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.

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

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

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

Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com:
> 
> With such small ROM/RAM sizes, who needs reentrant functions ?

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
in compilers for small µCs.

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

On Sunday, October 14, 2018 at 8:39:10 AM UTC-4, David Brown wrote:
> On 13/10/18 18:59, Niklas Holsti wrote:
> > And one more iteration (sorry...)
> > 
> > On 18-10-13 19:46 , Niklas Holsti wrote:
> >> On 18-10-13 18:31 , Niklas Holsti wrote:
> >>
> >>> I don't think that an interpreted Forth is feasible for this particular
> >>> MCU. ...
> >>> Moreover, there is no indirect jump instruction -- "jump to a computed
> >>> address".
> >>
> >> Ok, before anyone else notices, I admit I forgot about implementing an
> >> indirect jump by pushing the target address on the stack and executing a
> >> return instruction. That would work for this machine.
> > 
> > Except that one can only "push" the accumulator and flag registers, 
> > combined, and the flag register cannot be set directly, and has only 4 
> > working bits.
> > 
> > What would work, as an indirect jump, is to set the Stack Pointer (sp) 
> > to point at a RAM word that contains the target address, and then 
> > execute a return. But then one has lost the actual Stack Pointer value.
> > 
> 
> 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.

Efficiency has to be relative on such a limited machine.  If there are no registers nearly everything is going to be clumsy and slow.  I'm not sure using 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 words 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 Forth is great.  My CPU uses an 8 or 9 bit instruction size with multibyte instructions by prepending immediate addresses or data.  I was able to make that work easily in Forth while it would have been a bear in C or other languages.  

Rick C.

Am 12.10.2018 um 10:18 schrieb Philipp Klaus Krause:
> 
> They even make dual-core variants […]

And there is the MCS11, with 8 cores.

Philipp

Am 12.10.2018 um 08:50 schrieb Philipp Klaus Krause:
> On would want to reserve a few memory locations as
> pseudo-registers to help with that, but that only goes so far.

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

Philipp

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&sup2;C, but still...
> 
> Clifford Heath

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

https://detail.1688.com/offer/562502806054.html

Philipp

luni, 15 octombrie 2018, 15:35:22 UTC+3, Philipp Klaus Krause a scris:
> 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&sup2;C, but still...
> > 
> > Clifford Heath
> 
> If you are willing to pay 0.04$, you can get twice the RAM and program
> memory (not OTP for this one):
> 
> https://detail.1688.com/offer/562502806054.html
> 
> Philipp

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

On Monday, October 15, 2018 at 9:05:23 AM UTC-4, raimond....@gmail.com wrote:
> luni, 15 octombrie 2018, 15:35:22 UTC+3, Philipp Klaus Krause a scris:
> > 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&sup2;C, but still...
> > > 
> > > Clifford Heath
> > 
> > If you are willing to pay 0.04$, you can get twice the RAM and program
> > memory (not OTP for this one):
> > 
> > https://detail.1688.com/offer/562502806054.html
> > 
> > Philipp
> 
> Nah... not sure. 4c is too much... :-D

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

http://www.youboy.com/s504250937.html

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.

gnuarm.deletethisbit@gmail.com writes:
> http://www.youboy.com/s504250937.html
> Three for a penny!  But wait, there's MORE!!!  It also has more memory
> and an ADC.

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

Philipp Klaus Krause <pkk@spth.de> writes:
> 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
> in compilers for small &micro;Cs.

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.