PicForth: updated IC16Fxxx -> PIC18F*

>>>>> "Chris" == easlab  <easlab <at> absamail.co.za> writes:

Chris> But from what I remember of picforth: - it hasn't kept up with
Chris> the new pic chips, but since by it's nature forth is very
Chris> 'open', you can modify/evolve it yourself;

  Sam wrote:
> Moreover, I don't use PIC16Fxxx anymore :) I use PIC18F*, for which I
> have written the rforth1 compiler (http://www.rfc1149.net/devel/rforth1).
> 

Ok I'll look at  -/devel/rforth1, because your desgns were well structured;
but I've lost enthusiasm for pic.

Because the whole original minimal design has been abandoned.
It's like taking a 2CV and adding electric windows and air bags.

IMO the pic architechture is not scaleable, and it's absurd to try
multitasking ...etc. as if it was eg. an ARM.

Perhaps the dspVersion is interesting ?
Perhaps for eg. cheap mp3 players ?
I don't know enough.

Thanks for picforth.

== Chris Glur.

Re: AtoD (again)

>GO/DONE: A/D Conversion Status bit
>If ADON = 1:
>1 = A/D conversion in progress (setting this bit starts the A/D conversion)
>0 = A/D conversion not in progress (this bit is automatically cleared by 
>hardware when the A/D
>conversion is complete)
>This clearly is confusing, because it is in fact the next ( implemented ) 
>bit that is named ADON. Its description:
>ADON: A/D On bit
>1 = A/D converter module is operating
>0 = A/D converter module is shut-off and consumes no operating current

ADON (bit 0) turns the A/D section on or off.   You would normally turn it 
on and leave it on, but you can turn it off to save power when you're not 
using it, in a battery-powered application.

GO/DONE (bit 2) is what you use to do your sampling.   Set it to 1 to start 
the conversion, wait until it changes back to 0 and now the answer's available.

Barry

AtoD conversions

_______________________________________________
PicForth mailing list
PicForth <at> lists.rfc1149.net
http://lists.rfc1149.net/mailman/listinfo/picforth

toggle .. silly question

Ummm,
   I can't make the 'toggle' work .. the port in question is
all outputs and picforth seems to compile an xorwf instruction ..
something about a read-modify-write not working in this case  ?

Thanks, P

--

-- 
<=>

Re: [gnupic] multitasking

do you have considered using freeRTOS.
It's GPL copyright and usable for embedded systems, because it have a
licence exception especially for embedded systems.

--

-- 
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl

pre-announcing Forth for PIC18F chips

Hi,
I am interested for this evaluation.
I am now working , on an ICD2 +PICDEM 2 plus board.
Let me know and regards.

Availability of rforth1

I have put online the development version of rforth1, my new optimizing
16 bits Forth compiler for PIC18Fxxx which generates native code.

The compiler is probably not suitable yet for general use. Moreover,
you need Darcs to access it (no tarball has been made available). We
use it for our participation to the 2005 French robotics cup.

If you want to try it, despites its lack of documentation, please be
my guest. I welcome bug reports and feature requests, however I will
probably not be able to provide any help on using the compiler or to
write any documentation until after the robotics cup which takes place
on May 8.

    http://www.rfc1149.net/devel/rforth1

(yeah, I know this is a bad pun 

  Sam
--

-- 
Samuel Tardieu -- sam <at> rfc1149.net -- http://www.rfc1149.net/sam

(no subject)

Ummm,
   I can't make the 'toggle' work .. the port in question is
all outputs and picforth seems to compile an xorwf instruction ..
Isn't there something about a read-modify-write not working in this case   
??

Thanks, Polly

--
<=>

16F88 bootLoader

Hi Folks,
   First, thanks and appreciation to Sam and to Dave for sharing work on  
monitor, boot loader.
In the spirit of giving back, I can report success in getting your boot  
loader working on
the PIC 16F88 chip.
   It's flash can be erased only in blocks of 32 words, using a sequence  
similar to the 'flash
write' code but with the 'Flash Row Erase' bit set in the EECON1 control  
word. It is obligatory
to erase flash locations before they can be programmed. I made these  
changes:

  1) In pic16f88.inc, I added an EECON1 bitfield for 'Flash Row Erase'
  2) I copied picflash.fs to picflash-f88 with 'flash-write' cloned as  
pic-row-erase,
     setting and clearing the 'flash row erase' bitfield in tandem with  
'write enable'
  3) In serial monitor code, I added a new command 'B' (Blank Block) that  
calls the
     above routine to erase a 64 byte block of flash
  4) I went to work on Dave's pfd.py serail downloader  to:
       Create a list of block start addresses needing to be erased,
       Vet those addresses to prevent whacking the vector space at 0000
         and of course the config word space
       Add tty commands to call the 'B' Blank Block commands to erase
         flash areas prior to writing the app.
       I've avoided serpents in the past, I'm not proud of the hacks.
     By the way, pfd.py uses a "sum()" function not available in Python
       prior to 2.3 .. for example in Fedora FC1 ..
  5) The 'block erase' nature of the 'f88 imposes a couple of restrictions:
       You must org your app at 0x0020 or higher so that you don't need to
       block erase the vector space at 0x0000.
       The jump vectors at the beginning of serial monitor must sit right  
at the
       edge of an erase block separate from the rest of the monitor, that  
way
       the jump vectors can be erased and re-written without clobbering the
       remainder of sermon
  6) Last point means
       the 'constant origin' at the start of sermon is set to S0DF8;
       pfd.py sets up a forced call to block erase 0x0DE0 thru 0x0DFF
       your app must start at 0x0020 lowest;  0x0DDF highest

   In the words of Miz McElhone, "It isn't so bed" !

  One more thing, I got prog84 working on 16F88 chips by adding  the  
following line
   in pictypes.h ..
   {"16F88"   , FLASH5, 14,  8,  1000,  1,  0, 4096,  256, 0, 0},

   So I don't have to wine any more !

  I hope this helps,

  Cheers, Polly

<=>

CBank manipulation patch

I've run into a few problems with a large (> 0x800 words) program not 
having the cbank bits always set correctly.  The attached patch fixed 
the problems for me.  I'm not sure if it's the best way to go about it, 
but it seemed to solve the problems in my case.

-- 
Alex R. Moon
Vice President
Steradian Technologies, LLC (http://www.steradiantech.com)

diff -ru orig/picforth.fs ./picforth.fs
--- orig/picforth.fs	2004-12-29 07:31:50.000000000 -0500
+++ ./picforth.fs	2005-02-09 15:50:29.875000000 -0500
@@ -1074,12 +1074,14 @@
 : set-cbank ( addr -- )
     \ If target is in bank 0, clear PCLATH
     cbank dup 0= if drop pclath clrf 0 current-cbank ! exit then
+    dup
     \ If current known bank is invalid, everything is wrong
     current-cbank @ -1 = if dup invert current-cbank ! then
     \ If current address is in bank 0 or 1, clear one bit
     tcshere cbank 2 < if current-cbank @ $d and current-cbank ! then
     \ Change only the right bits
     dup 0 set-cbank-bit 1 set-cbank-bit
+    current-cbank !
 ;

 : manipulate-cbank ( addr -- )
@@ -1985,7 +1987,7 @@
 \ reference.
 : backref ( -- BACKWARDMARK baddr ) BACKWARDMARK tcshere no-opt no-cbank ;

-: begin ( -- 0 BACKWARDMARK baddr ) 0 backref ;
+: begin ( -- 0 BACKWARDMARK baddr ) 0 backref tcshere manipulate-cbank ;

 : again ( 0 BACKWARDMARK baddr -- )
     swap BACKWARDMARK <> abort" Nested statements problem"

_______________________________________________
PicForth mailing list
PicForth <at> lists.rfc1149.net
http://lists.rfc1149.net/mailman/listinfo/picforth

compact object code ?

There's been some talk here about 'minimum sizing the obj code'...

I came across: ---------- start of extract ---------

   Newsgroups: comp.compilers,comp.lang.misc
   From: Chris F Clark <c...@shell01.TheWorld.com>
   Date: 30 Dec 2004 01:05:45 -0500
   Subject: Re: virtual machine efficiency

   > I have developed a simple stack based virtual machine. I would like
   > it to be as efficient as possible, in terms of both speed and object
   > code size. Size, as in size of the object code the VM processes
   > (byte-code), and not necessarily the size of the VM.
> ... <alignment problem>....

a...@mips.complang.tuwien.ac.at (Anton Ertl) replied:
 <plenty of references> ...
    annote =         "Interpreter performance is optimized by combining
                     operators during code generation, when they are
                     still organized as trees. So a different, optimized
                     interpreter
                     is used for each program. Speedups of 1.8--3.1 are
                     achieved, but this is probably strongly dependent on
                     the original set of operators. The paper uses lccs
                  intermediate code operators \cite{fraser&hanson91a}."
...
    abstract =         {Embedded systems often have severe memory
                    constraints requiring careful encoding of
                    programs. For example, smart cards have on the order
                    of 1K of RAM, 16K of non-volatile memory, and 24K of
                    ROM. A virtual machine can be an effective approach
                    to obtain compact programs but instructions are
                    commonly encoded using one byte for the opcode and
                    multiple bytes for the operands, which can be
                    wasteful and thus limit the size of programs
                    runnable on embedded systems. Our approach uses
                    canonical Huffman codes to generate compact opcodes
                    with custom-sized operand fields and with a virtual
                    machine that directly executes this compact code. We
                    present techniques to automatically generate the new
                    instruction formats and the decoder. In effect, this
                    automatically creates both an instruction set for a
                    customized virtual machine and an implementation of
                    that machine. We demonstrate that, without prior
                    decompression, fast decoding of these virtual
                    compressed instructions is feasible. Through
                    experiments on Scheme and Java, we demonstrate the
                    speed of these decoders. Java benchmarks show an
                    average execution slowdown of 9%. Compression
                    factors highly depend on the original bytecode and
                    the training sample, but typically vary from 30% to
                    60%. }
--- end of extracts ---

The point is:
  picforth is 'based' on gforth  [probably a very good idea],
and gforth is written/maintained by the above author: Anton Ertl.

And I'm guessing that Anton Ertl is a top specialist is 'code compaction'.
So you/we've come a full circle.

Best try to learn/copy from those who've done the research already ?

== Chris Glur.