[PicForth] Re: Installation, test, refine & BIG picture.

[J.C. Wren]

    Tell ya what, just forget I mentioned it.  It's pretty obvious why 
there are so few PicForth users.  I'll go play with it in my corner, and 
if I have any problems, I'll either solve them myself, or just work 
around them.  I have about a half dozen examples I wrote for the 
PICDem.Net board.  If anyone's interested in them, they can find them 
(eventually) with Google.  But I wouldn't want to to burden anyone or 
make them have to think or anything.  I realize if it's not pre-chewed 
and digested, it's just too much work.  It's pretty clear at this point 
that a soliciation for help, suggestions and contributions are unwanted.

    --jc

easlab at absamail.co.za wrote:

>J.C. Wren wrote:-
>  
>
>>    I'm playing with the timer 1 registers, and can't figure out how to 
>>express something correctly.  Let's say you're running at 19.6608Mhz.  
>>At that speed, there are 49152 ($c000) counts in a 10 millisecond 
>>interval.  The counter counts up, so you load the TMR1H and TMR1L 
>>registers with the negated value, which would be 16384 ($4000).  I'd 
>>like to put this as a constant at the top, so '$c000 constant 
>>tmr1Reload'.  In the handler code, I want to change modes (correct term, 
>>please?) so that rather than taking the constant and AND'ing it with $ff 
>>or / 8 at run time, it's done at compile time.  I know (I think) this 
>>needs to be handled outside of the PicForth compilation because PicForth 
>>doesn't understand 16 bit values of any kind.
>>    
>>
>
>Does your paragraph reduce to "I want the compiler to be 'smarter' " ?
>I was amazed how 'smart' it was.
>This no doubt because much of the 'research' of the gforth software could
>just be 'taken over'.
>Let's no lose sight of the expressed intention and history of picforth.
>Your project must be VERY progressed if such optimisations are your
>concern ?
>Have you tested substantial 'operations' and constructs ?
>Which pic have you used ?
>I think we should have a 'graduated test-set' for beginners -- also to
>help build some forth fluency, incrementally.
>When I left off I was unsuccessfully investigating the use of arrays.
>
>  
>
>>Yea, it runs fine under 0.5.0.  I created a patch for the Gentoo emerge 
>>that basically deleted the emacs junk, and filed a bug report on Gentoo 
>>Bugzilla.
>>    
>>
>
>It's difficult enough to have the necessary knowledge for this list:
>1. hardware,
>2. minimum of linux
>3. minimum of forth
>4. special features of picforth,
>so lets NOT 'dilute' ourselves with Gentoo, Bugzilla and emacs.
>'Information hiding' is a key, proven method of handling complexity.
>
>  
>
>>>What programmer do/will you use ?
>>>My programmer is DOS based, so I tried to use dosemu, instead of
>>>having to transfer data to a dos-box.  [one wants a rapid turn around,
>>>to make many small steps towards the goal].  Dosemu is a bit of
>>>a 'can of worms' and I couldn't get it to drive the par-port.
>>> 
>>>
>>>      
>>>
>>I use the ICD2 under Windows for another project.  I share a directory 
>>on the Windows box out to the Linux box.  I do all the development under 
>>Linux, copy the hex file to the mounted Windows directory, spin around 
>>to the laptop, import the hex file, and program the board.  It's an 
>>extra step, but last time I checked there was no support for the ICD2 
>>under Linux.  And it would just be too much trouble to move it between 
>>the two boxes.
>>    
>>
>
>Yes, it's important to be able to have a rapid turn-around-time for each
>iteration.
>
>  
>
>>What is your project?  (or did I overlook where you already defined it?)
>>    
>>
>
>I was looking into a 5 key serial 'mouse' input-device.
>
>  
>
>>    I've added a couple words to the dictionary.  I've done some testing 
>>on them, but I don't know if they meet the "approved" methods or not.  I 
>>also added the bit definitions for the sspcon2 register in the 16F877.  
>>I don't know if all the parts have that or not.
>>
>>    Included is the diff file against 0.31, generated with 'diff -u 
>>picforth.fs picforth.new'
>>
>>    Feedback would be appreciated.
>>
>>    --jc
>>
>>--- picforth.fs 2004-06-25 00:22:16.295092007 -0400
>>+++ picforth.new        2004-06-25 00:07:13.067416538 -0400
>>@@ -742,6 +742,17 @@
>>   1 sspcon bit sspm1
>>   0 sspcon bit sspm0
>>
>>--- snip ---
>>    
>>
>
>Well I'm not a linux enthusiast, and have never used 'diff' files and cvs,
>and in principle I don't browse or suck-it-and-see. 
>So I'd want a description of what the contribution attempts to acheive.
>Before I contribute by testing and feeding-back.
>It's very simple: the designer would need a fraction of the time to just give
>the basic documentation, compared to the time that I'd have to spend
>'discovering' the documentation.   It's elementary economics: maximum 
>results from minimum effort for the COMBINED team.
>
>Thanks,
>
> == Chris Glur.
>
>_______________________________________________
>PicForth mailing list
>PicForth at lists.rfc1149.net
>http://lists.rfc1149.net/mailman/listinfo/picforth
>
>  
>