flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] MPLAB config files

[Mikael N. <mik...@fl...>]

Basically I have abandoned MPLAB,
I use only MBLABX.

But I can try to clean up the MBLAB projects.

The clock could be moved to device file since the clock relies on the 
config bits.

BR Mikael

On 09.05.2016 00:50, zd...@al... wrote:
> For the second time in 3 months I've been loosing time looking for 
> the
> non existent bugs, so I would like to prevent the others falling into 
> a
> same hole. In my MPLAB (8.92), when I open the FF_UART project for 
> PIC18
> it contains 11 'other' files:
>
>
> Should 'clock =' go out of 'main.cfg' into .cfg specific for each 
> PIC?
>
> Any thoughts on that?
>
> Zdravko
>
>
>
>
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications 
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly 
> and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

[Flashforth-devel] MPLAB config files

[<zd...@al...>]

For the second time in 3 months I've been loosing time looking for the 
non existent bugs, so I would like to prevent the others falling into a 
same hole. In my MPLAB (8.92), when I open the FF_UART project for PIC18 
it contains 11 'other' files:

Two are marked as "file not found":
install.txt
readme.txt
Everything works without them so they could be removed from the project.
Then, there are 7 different .cfg files for specific PIC models of 
families. It is not clear if you should remove the files that are not 
exactly for your PIC.

These 2 files are neccesary in every case:
pic18f-main.cfg
pic18fxxxx.cfg
The problem is, these 2 files are also included in .asm:

#include "p18f-main.cfg"
#include "p18fxxxx.cfg"

So they are processed twice, first as specified in project, second time 
from a folder with the .asm file (and there are a few good reasons why 
to keep them in a separate folders). Of course, second pass overrules 
the previous settings. As my .asm was in a different folder I was 
getting wrong baud rate calculation for 48 instead of 64 MHz.

I would suggest removing all #include from .asm and placing only 3 files 
on project include list:
pic18f-main.cfg, pic18fxxxx.cfg and readme.txt with short explanation 
about which .cfg files are neccessary.

Should 'clock =' go out of 'main.cfg' into .cfg specific for each PIC?

Any thoughts on that?

Zdravko

[Flashforth-devel] bug fix xon/xoff uart2

[Robert L. <Rob...@em...>]

Hi,
There is a typo error at line #2662 of the file ff-pic24-30-33.s
RX2Q:
        mov     rbuf_lv2, W0
        mov     W0, [++W14]
        cp0     [W14]
        bra     nz, RX2Q1
        btsc    iflags, #fFC2    ; bug fix RLE was btss !
        bra     RX2Q1

This prevent from sending XON if uart2 is selected as the console uart.

Best regards,
Robert Lessard
[image002]
400 du Parc, Saint-Eustache, (Québec) J7R 0A1
T: +1.450.491.2100 p.643
F: +1.450.491.4138
www.emd-technologies.com<http://www.emd-technologies.com/>

*********************************************************************************************************************************************
Information confidentielle : Le présent message, ainsi que tout fichier qui y est joint, est envoyé à l'intention exclusive de son ou de ses destinataires; il est de nature confidentielle et peut constituer une information privilégiée. Nous avertissons toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci.

Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you.

Re: [Flashforth-devel] PIC18fxxk90

[<zd...@al...>]

Hey Mikael,

Some bad news: today's version from git doesn't work, looks like a baud 
rate problem (it returns some garbage characters). I'll check tommorow 
with scope.
Good news: your PCB works.

Zdravko

Re: [Flashforth-devel] PIC18fxxk90

[<zd...@al...>]

No, it didn't work for UART2. Transmit didn't work because the 
initialization was missing. You should just add #ifs and #endifs:

         movlw   spbrgval
;        movwf   SPBRG, A
	banksel	SPBRG2
         movwf   SPBRG2, BANKED
; TX enable
         movlw   b'00100100'
;        movwf   TXSTA, A
	banksel	TXSTA2
         movwf   TXSTA2, BANKED

Receive didn't work because RX2 is also an analog pin and while UART 
takes care about TRIS setting, analog pin takes priority. This is 
(probably) correct code:

; RX enable
#if UART == 1
#ifdef ANSELH
#ifdef ANS11
         bcf     ANSELH, ANS11, A ; Enable digital RB5 for RX(1)
#endif
#endif
#ifdef ANSELC
#ifdef ANSC7
         banksel ANSELC
         bcf     ANSELC, ANSC7, BANKED   ; Enable digital RC7 for RX(1)
#endif
#endif
#else
         banksel ANCON2
         bcf     ANCON2, ANSEL18, BANKED   ; Enable digital RG2 for RX2
#endif

Funny thing is that databook is totally misleading:

"In order to configure these pins as an EUSART: ... For EUSART2: ... 
TRISG<1> bit must be cleared (= 0) for Asynchronous ..."
Not true, and they admit it almost immediately. ;-)
"Note: The EUSART control will automatically reconfigure the pin from 
input to output as needed."
That's true, but it won't reconfigure this pin from analog to digital, 
and it is nowhere mentioned in UART chapter that you shoud do it.

Mikael, give me your address so I can send you a PCB with 18F66K22 (or 
65K90 if you prefer). It is pretty weird that I'm the only one in the 
whole world using this with FF, hope somebody else will join and find 
more use for all this.

Zdravko

Re: [Flashforth-devel] PIC18fxxk90

[Mikael N. <mik...@fl...>]

There is no support in FF-PIC18 for the second UART.

It should be easy to change the uart1 registers to uart2 registers
in the source code. Some support in the config could even be introduced 
for that.

I am reluctant to increase the code size in FF-PIC18 because then users 
have to select between
multiple linker files.

There has been a request before to add better error handling.
There was suggestion to have a unique error string like ???
so that the uploader script could pause and ask if the upload should be
abandoned.

Igor wrote a Teraterm uploader script for that.
https://github.com/igor-m/EXPERIMENTAL_ZZ/blob/master/shell/Upload2FF.ttl

A deferred word is flexible and it could have a default value of "emit 
?"

I could put in a deferred word for the error printout.
It would be global a ram defer initialized at warm start.
You would need to defer it again in turnkey if you want to have 
automatic initialization.

It could also have a default string to be set at compilation time.

One problem with the bell is that it will sound once for every missing 
marker,
which not an error as such.
It will also sound for redefinition of words.

BR Mikael

On 26.04.2016 01:01, zd...@al... wrote:
> Hi, everyone,
>
> Two months after my start with FF I finally have the combination I've
> been looking for: PIC18F65K90 working in FF.
> http://www.alara.hr/images/K90.jpg
> Debugging with 66K22 has paid off and this time it worked on the 
> first
> try. There is FTDI USB to UART which also supplies 3.3V for PIC, and
> just 10 capacitors + 5 resistors. Totally Plug@Play. It can be used 
> for
> anything as the most of PIC pins can be accesed via 2 x 16 pin
> connectors. I'll put a custom LCD on it, battery supply, quartz for 
> real
> time clock, and move communication to UART2 because LCD needs UART1
> pins.
> As the PICs 24 and bigger have support for both UART, hope this will 
> not
> be a big problem to implement.
>
> There is one thing that I'm not happy with: FF error reporting. It is
> hard to notice a question mark(s) when you compile 200 lines, and I
> would like to have a 'beep' for each error. Is it possible to make a
> vector which is executed on each error so I can choose if it just 
> prints
> "?" (by default) or add a character like ctrl-g which makes sound on
> terminal, or attributes for inverted or flashing letters?
> Does it make sense?
>
> Zdravko
>
>
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications 
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly 
> and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

[Flashforth-devel] PIC18fxxk90

[<zd...@al...>]

Hi, everyone,

Two months after my start with FF I finally have the combination I've 
been looking for: PIC18F65K90 working in FF.
http://www.alara.hr/images/K90.jpg
Debugging with 66K22 has paid off and this time it worked on the first 
try. There is FTDI USB to UART which also supplies 3.3V for PIC, and 
just 10 capacitors + 5 resistors. Totally Plug@Play. It can be used for 
anything as the most of PIC pins can be accesed via 2 x 16 pin 
connectors. I'll put a custom LCD on it, battery supply, quartz for real 
time clock, and move communication to UART2 because LCD needs UART1 
pins.
As the PICs 24 and bigger have support for both UART, hope this will not 
be a big problem to implement.

There is one thing that I'm not happy with: FF error reporting. It is 
hard to notice a question mark(s) when you compile 200 lines, and I 
would like to have a 'beep' for each error. Is it possible to make a 
vector which is executed on each error so I can choose if it just prints 
"?" (by default) or add a character like ctrl-g which makes sound on 
terminal, or attributes for inverted or flashing letters?
Does it make sense?

Zdravko

Re: [Flashforth-devel] free flash memory on atmega devices

[Mikael N. <mik...@fl...>]

I did not update the ZIP file yet in SF. Only the GIT is updated on SF 
and GITHUB

Testing is basically

#send pic18/forth/xdump.txt
hex
1234 07020. x!
07000. 30 xdump


dead 0f010. x!
0f010. 10 xdump
f010 10 dump

\ Check that the data does not go ram, but flash
babe 0fff0. x!
0fff0. 10 xdump
fff0 10 dump

\ check that the kernel is write protected
4567 ' marker 0 x!
\ shud cause an address error.


BR Mike

Re: [Flashforth-devel] free flash memory on atmega devices

[<zd...@al...>]

Sure, I get the part with compiling. What i didn't get is that the last 
version is on git, while on sourceforge it is not updated.
'Test program' that I've been talking about should be a few lines in 
forth. I guess it means to try reading & writing FLASH locations which 
are now mapped as RAM and EEPROM.

Zdravko

Re: [Flashforth-devel] free flash memory on atmega devices

[Mikael N. <mik...@fl...>]

On 06.04.2016 23:29, zd...@al... wrote:
> If you send me a test program, I can try it on 18F66K22.
>
If you send me your configuration files I can compile a hex file.

Or you can pull it from git, and compile it yourself.
You need to configure
#define IDLE_MODE DISABLE   ; ENABLE or DISABLE
#define XSTORE ENABLE


To fit the code using the default linker file you need to disable
some functionality so that the X! X@ gets some room.

Mike

Re: [Flashforth-devel] free flash memory on atmega devices

[<zd...@al...>]

If you send me a test program, I can try it on 18F66K22.

Re: [Flashforth-devel] free flash memory on atmega devices

[Mikael N. <mik...@fl...>]

So now FlashForth has extended memory fetch and store words.

X@ and X!

These can fetch and store 16-bit cells from/to any address in flash.
Except the kernel cannot be stored to.
The address is a direct unmapped address.

Tested on Atmega and PIC24.
Some testing still required on PIC18, but since I don't have any chips 
with large memory
I cannot test.

BR Mikael

On 16.11.2015 19:33, Donald Golding wrote:
> I don't think a 32 bit version of FlashForth would be necessary. You
> can build a very complex application in Forth just using the 16 bit
> implementation.
>
> If you need a request for extended memory words, I will vote yes they
> are needed. Users can then put arrays, small databases of sensor data
> logging, etc. in this space...

Re: [Flashforth-devel] PIC18F66K22

[<zd...@al...>]

Finally I had time to start from the scratch, check everything once more 
and now I have "FF 18F66k22 must do list":

project>add files to project> p18f66k22.cfg

-p18f-main.cfg
constant clock=d'64000000'  ; Hz

-p18f66k22.cfg
         constant flash_write_inner_loop = d'64'
#define PLL ENABLE	         ; ENABLE or DISABLE

-ff-pic18.asm
3x replace
PIR2, EEIF, A -> PIR6, EEIF, A


         clrf    PIE1, A         ; Disable all peripheral interrupts
         clrf    PIE2, A

Should we clean the new additional PIE registers? I guess so.
clrf PIE3-PIE6.

@Peter:
Thanks for locating the missing 'forget' command.

@Mikael:
Right, clock frequency has to be specified in p18fmain.cfg but it wasn't 
enough to get correct baud rate as PLL was disabled in p18f66k22.cfg. I 
changed a few things simultaneously so I got confused when it finally 
started working.
I'll send you updated register definitions for 65K22 66K22 85K22 86K22 
in mail as pic18f_regs.txt is not really usefull for me.

@Craig:Interactivity is the exact reason why I'm trying to turn to Forth 
again. Number of different sensors and modules that I have to put in 
function has increased recently and I have a serious bottleneck with 
drivers and testing.
If you (or anyone) need 64 pin in DIP, I can solder TQFP or QFN on 
adapter or just send you empty adapter if you prefer. Still have 5-6 
left unused from some previous project.
TBH I am not so much interested in xxK22 chips, but (pin compatible) 
xxK90 as my instruments need LCD driver. That's the reason why I'm 
asking for UART2 because UART1 shares pins with LCD. I'll try to patch 
this soon.

Thanks to everyone for your input,
Zdravko

Re: [Flashforth-devel] PIC18F66K22

[craig b. <dab...@ya...>]

I've been playing with FlashForth for a while and using it for device implamentation for a couple years.  I enjoy the interactivity that assembler doesn't have by itself.  I haven't used the high pin-count chips either (they don't have dip packages that fit my prototyping boards), but I've been very happy with the 26k22 and 46k22 performance.  Getting them up under FF-50 is a lot easier than FF-3.8 was, the config files are much more consolidated now.  I still recommend explicitly defining all the chip config bits, especially for the muxed pins.  Grep through the source for peripheral setups and feature-pin assignments.  Start simple disabling extensions you don't need (like multitasking and program interrupts) and figure these more obscure capabilities out as you need them.  The docs available actually have enough info, but they aren't quite a walk-through guide yet.

If you have a history with FORTH, you know how close to the hardware it runs...  Mike's implamentation is impressivly clean.

The second UART is a small wonder in its own right.  I recommend keeping the console on UART1 so you can concentrate the processor's attention on UART2.  My PC couldn't deal with anything above 460800 baud but a half-dozen 26K22-s and a BeagleBone White could all converse at 921600.  Not shabby at all and the embedded assembler makes it fairly easy to implament.  The 9-bit mode helped a lot.

Have at it!  Good luck, and have fun!

craig bair

OBTW: Banging the SPI config of the MSSP is impressive for an 8-bit processor (grin).  And it can even bit-bang at almost 1 M-bit...

Re: [Flashforth-devel] pic18f66k22

[Mikael N. <mik...@fl...>]

Zdravko,

Since you seem to be the first one to use these chips,
you get the honour of debugging, contributing to this open source 
project.

I will include your findings into FF as soon as I have time.

The clock frequency needs to specified in p18fmain.cfg
in order to get the baud rate calculation correct.


BR Mikael

Re: [Flashforth-devel] pic18f66k22

[Peter J. <pe...@me...>]

For the PIC18 and AVR, the definition of forget is in core.txt, which 
can be loaded once FF is up and running.  For the PIC24-30-33, the 
definition is in the main assembly program.  I've been thinking that I 
should put the guide and tutorial source files up on bitbucket to give 
people better access and make it easier to accept patches.

I've used DIP28 and DIP40 processors mainly and have not tried any of 
the high pin-count parts.  I've found FF very reliable on the 
pic18F2520, pic18F46k22 and pic18f26k22 parts.  In one of the teaching 
labs, we have pressure indicator box that uses a pic18f2520 running FF.  
It's been running continuously for a couple of years.

Also, haven't tried USART2.
Cheers,
Peter J.


On 23/02/16 02:52, zd...@al... wrote:
> Hi, everyone,
>
> It was easy to import files to MPLAB, and I expected that after my
> hardware was soldered only 1 download to PIC will be enough to start
> working in FlashForth. Well, I started programming in Forth in 1984 and
> I have 20 years of experience with PICs and shouldn't describe myself as
> an begginer, but still I needed almost a week to make FF work.
> I'm afraid most people could just give up. That's why I would like to
> discuss my problems here and make whole package more user frendly. MPLAB
> project has many files included, some of them non existent. Obviously, I
> had to include p18f66k22.cfg, but it wasn't clear that I have to exclude
> most of files because baud rate calculation didn't work correct.
> Apparently it was calculating for 48MHz although in p18f66k22.cfg it was
> correct 64MHz.
> Finally, I got some "FlashForth" response on my terminal but it was
> impossible to work as it didn't accept command line and kept restarting
> every couple of seconds. After one day with in-circuit emulator I wasn't
> smarter as it didn't behave the same way every time I tried to trace it,
> so the next day I conected a beeper and turned it on from different
> points in code to see how far it gets. In the end of the second day it
> was obvious it is freezing on attempt to write into EEPROM. No wonder,
> as EEIF flag is not in PIR2, but PIR6 on 18F66K22.
>
> ECSTORE1:
>           bcf     EECON1, EEPGD, A
>           bcf     EECON1, CFGS, A
>           bcf     PIR2, EEIF, A
>           bsf     EECON1, WREN, A
>           bcf     INTCON, GIE, A
>           movlw   h'55'
>           movwf   EECON2, A
>           movlw   h'aa'
>           movwf   EECON2, A
>           bsf     EECON1, WR, A
>           bsf     INTCON, GIE, A
> ECSTORE2:
>           btfss   PIR2, EEIF, A
>           bra     ECSTORE2
>           bcf     EECON1, WREN, A
>           bcf     PIR2, EEIF, A
>
> There are 2 conclusions. First, some important pointers have to be
> written into EEPROM before anything starts to work. Second, nobody ever
> tried this code on any 65K22, 66K22, 85K22 or 86K22.
> Now FF started working, but only until first colon definition and then
> everything fell apart. Few more days of reprogramming, reading code,
> reprogramming, reading "manual", reprogramming, reading dump, comparing
> until I found error in p18f66k22.cfg.
>           constant flash_write_inner_loop = d'128'
> Only 18x7K22 has 128 byte buffer and as a result all attempts to write
> to flash memory were fatal.
> As I can see now, Forth works but I'm still confused with words that
> exist in "Hitchhiker's Guide to FlashForth" but not in FF (forget) or
> vice versa (iflush).
>
> To patch the file i suggest copying this 3 times into FF assembler code:
> #ifdef PIR6
>           bcf     PIR6, EEIF, A
> #else
>           bcf     PIR2, EEIF, A
> #endif
>
> ... and change d'128' into d'64' in .cfg for 18F65K22, 18F66K22,
> 18F85K22 & 18F86K22.
>
> Has anyone tried to use USART2 instead of USART1?
>
> Zdravko
>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

[Flashforth-devel] pic18f66k22

[<zd...@al...>]

Hi, everyone,

It was easy to import files to MPLAB, and I expected that after my 
hardware was soldered only 1 download to PIC will be enough to start 
working in FlashForth. Well, I started programming in Forth in 1984 and 
I have 20 years of experience with PICs and shouldn't describe myself as 
an begginer, but still I needed almost a week to make FF work.
I'm afraid most people could just give up. That's why I would like to 
discuss my problems here and make whole package more user frendly. MPLAB 
project has many files included, some of them non existent. Obviously, I 
had to include p18f66k22.cfg, but it wasn't clear that I have to exclude 
most of files because baud rate calculation didn't work correct. 
Apparently it was calculating for 48MHz although in p18f66k22.cfg it was 
correct 64MHz.
Finally, I got some "FlashForth" response on my terminal but it was 
impossible to work as it didn't accept command line and kept restarting 
every couple of seconds. After one day with in-circuit emulator I wasn't 
smarter as it didn't behave the same way every time I tried to trace it, 
so the next day I conected a beeper and turned it on from different 
points in code to see how far it gets. In the end of the second day it 
was obvious it is freezing on attempt to write into EEPROM. No wonder, 
as EEIF flag is not in PIR2, but PIR6 on 18F66K22.

ECSTORE1:
         bcf     EECON1, EEPGD, A
         bcf     EECON1, CFGS, A
         bcf     PIR2, EEIF, A
         bsf     EECON1, WREN, A
         bcf     INTCON, GIE, A
         movlw   h'55'
         movwf   EECON2, A
         movlw   h'aa'
         movwf   EECON2, A
         bsf     EECON1, WR, A
         bsf     INTCON, GIE, A
ECSTORE2:
         btfss   PIR2, EEIF, A
         bra     ECSTORE2
         bcf     EECON1, WREN, A
         bcf     PIR2, EEIF, A

There are 2 conclusions. First, some important pointers have to be 
written into EEPROM before anything starts to work. Second, nobody ever 
tried this code on any 65K22, 66K22, 85K22 or 86K22.
Now FF started working, but only until first colon definition and then 
everything fell apart. Few more days of reprogramming, reading code, 
reprogramming, reading "manual", reprogramming, reading dump, comparing 
until I found error in p18f66k22.cfg.
         constant flash_write_inner_loop = d'128'
Only 18x7K22 has 128 byte buffer and as a result all attempts to write 
to flash memory were fatal.
As I can see now, Forth works but I'm still confused with words that 
exist in "Hitchhiker's Guide to FlashForth" but not in FF (forget) or 
vice versa (iflush).

To patch the file i suggest copying this 3 times into FF assembler code:
#ifdef PIR6
         bcf     PIR6, EEIF, A
#else
         bcf     PIR2, EEIF, A
#endif

... and change d'128' into d'64' in .cfg for 18F65K22, 18F66K22, 
18F85K22 & 18F86K22.

Has anyone tried to use USART2 instead of USART1?

Zdravko

Re: [Flashforth-devel] update to tutorial guide

[Peter J. <pe...@me...>]

Thanks Mikael.  I've enjoyed using FF and I'm hoping that these 
documents help others to get started.

To go with the tutorial guide, I've updated the quick-reference document 
over the past few days.
A current draft is at
https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/flash-forth-5-sheet-2016-02-06.pdf

Main changes:
- I think that I've now captured all of the words listed in your 
glossary file wordsAll.txt.  Where there's a difference between the 
glossary file and the assembler source, I've gone with the source.  
(names of serial queues, for example)
- Added recent I2C and SPI words from tutorial (forth source files attached)
- Added floating-point words.  I've not used them so I've used the 
descriptions from the C library manual.
- With these additions, the content is now 8 full pages (up from 6.5 for 
the previous version).  I had originally intended the document to fit on 
both sides of a single sheet.  I had greatly underestimated FF!
- Shuffled sections to better group the content.  Well, at least I think 
that the new arrangement is better.  Not being a master of the system, 
I'd be happy to get advice on that.
- Marked compile-only words by colouring them blue.

Since there are many words that I've never used, I have guessed at some 
of the descriptions.  If people have suggestions and/or corrections 
please let me know.

Cheers,
Peter J.


On 02/02/16 14:45, Mikael Nordman wrote:
> Thanks Peter for your excellent guide.
>
> It is the best FF documentation available.
>
> BR Mikael
>
> On 02.02.2016 02:56, Peter Jacobs wrote:
>> Thanks Pete.
>>
>> A new revision
>>
>> https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2016-draft-2016-02-02.pdf
>>
>> Changes in the past few days:
>> 1. Added analog read for the ATmega.
>> 2. Added SPI words for PIC18, PIC24 and ATmega.
>> 3. Changed abstract to reflect these additions.
>> 4. Added note to CoolTerm as per Thomas' suggestion.
>>
>> The CTMU is interesting but will have to wait until another day.
>> I might be able to get it into this semester's sensors course as an
>> example.
>>
>> Cheers,
>> Peter J.
>>
>>
>> On 30/01/16 15:09, Pete Zawasky wrote:
>>> Hi Peter,
>>> The Tutorial Guide looks very good.  Really glad to see the emphasis
>>> on
>>> the PIC24FV32KA302.
>>> Perhaps a short tutorial on capacitance measurement using the
>>> PIC24FV32KA302 CTMU can be added (when time permits).
>>> Look forward to SPI info being added, too.
>>>
>>> Thanks for the effort.  Good luck with the new teaching term.
>>>
>>> Pete
>>>
>>> On 1/26/2016 9:12 PM, Peter Jacobs wrote:
>>>> Fellows,
>>>>        I've been trying to update the tutorial guide before the
>>>> craziness
>>>> of the teaching term arrives.
>>>> Here is a pointer to a draft of the revised document.
>>>>
>>>>
>>>> https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2016-draft-2016-01-27.pdf
>>>>
>>>> Main changes are :
>>>> 1. use of a PIC24FV32KA302 rather than a PIC24FV16KM202.  There's a
>>>> more
>>>> comfortable amount of memory in the KA302.
>>>> 2. use of the ff-shell.tcl for interaction.  It "just works for me"
>>>> and
>>>> I find it convenient, so I'm hoping that it works for others too.
>>>> 3. use of the i2c-base-xxx words for all flavours of
>>>> microcontroller.
>>>> 4. updates to the bit-banging speed tests to reflect FF changes
>>>> since
>>>> the 2014 version of this guide.
>>>>
>>>> I would like to include some SPI words but semester is nearly here;
>>>> we'll see what we can fit in.
>>>>
>>>> Comments, corrections, wishes?  ...
>>>> Cheers,
>>>> Peter J.
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application
>>> Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application
>> Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] update to tutorial guide

[Mikael N. <mik...@fl...>]

Thanks Peter for your excellent guide.

It is the best FF documentation available.

BR Mikael

On 02.02.2016 02:56, Peter Jacobs wrote:
> Thanks Pete.
>
> A new revision
> 
> https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2016-draft-2016-02-02.pdf
>
> Changes in the past few days:
> 1. Added analog read for the ATmega.
> 2. Added SPI words for PIC18, PIC24 and ATmega.
> 3. Changed abstract to reflect these additions.
> 4. Added note to CoolTerm as per Thomas' suggestion.
>
> The CTMU is interesting but will have to wait until another day.
> I might be able to get it into this semester's sensors course as an 
> example.
>
> Cheers,
> Peter J.
>
>
> On 30/01/16 15:09, Pete Zawasky wrote:
>> Hi Peter,
>> The Tutorial Guide looks very good.  Really glad to see the emphasis 
>> on
>> the PIC24FV32KA302.
>> Perhaps a short tutorial on capacitance measurement using the
>> PIC24FV32KA302 CTMU can be added (when time permits).
>> Look forward to SPI info being added, too.
>>
>> Thanks for the effort.  Good luck with the new teaching term.
>>
>> Pete
>>
>> On 1/26/2016 9:12 PM, Peter Jacobs wrote:
>>> Fellows,
>>>       I've been trying to update the tutorial guide before the 
>>> craziness
>>> of the teaching term arrives.
>>> Here is a pointer to a draft of the revised document.
>>>
>>> 
>>> https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2016-draft-2016-01-27.pdf
>>>
>>> Main changes are :
>>> 1. use of a PIC24FV32KA302 rather than a PIC24FV16KM202.  There's a 
>>> more
>>> comfortable amount of memory in the KA302.
>>> 2. use of the ff-shell.tcl for interaction.  It "just works for me" 
>>> and
>>> I find it convenient, so I'm hoping that it works for others too.
>>> 3. use of the i2c-base-xxx words for all flavours of 
>>> microcontroller.
>>> 4. updates to the bit-banging speed tests to reflect FF changes 
>>> since
>>> the 2014 version of this guide.
>>>
>>> I would like to include some SPI words but semester is nearly here;
>>> we'll see what we can fit in.
>>>
>>> Comments, corrections, wishes?  ...
>>> Cheers,
>>> Peter J.
>>>
>>
>> 
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application 
>> Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
>
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application 
> Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] update to tutorial guide

[Peter J. <pe...@me...>]

Thanks Pete.

A new revision
https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2016-draft-2016-02-02.pdf

Changes in the past few days:
1. Added analog read for the ATmega.
2. Added SPI words for PIC18, PIC24 and ATmega.
3. Changed abstract to reflect these additions.
4. Added note to CoolTerm as per Thomas' suggestion.

The CTMU is interesting but will have to wait until another day.
I might be able to get it into this semester's sensors course as an example.

Cheers,
Peter J.


On 30/01/16 15:09, Pete Zawasky wrote:
> Hi Peter,
> The Tutorial Guide looks very good.  Really glad to see the emphasis on
> the PIC24FV32KA302.
> Perhaps a short tutorial on capacitance measurement using the
> PIC24FV32KA302 CTMU can be added (when time permits).
> Look forward to SPI info being added, too.
>
> Thanks for the effort.  Good luck with the new teaching term.
>
> Pete
>
> On 1/26/2016 9:12 PM, Peter Jacobs wrote:
>> Fellows,
>>       I've been trying to update the tutorial guide before the craziness
>> of the teaching term arrives.
>> Here is a pointer to a draft of the revised document.
>>
>> https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2016-draft-2016-01-27.pdf
>>
>> Main changes are :
>> 1. use of a PIC24FV32KA302 rather than a PIC24FV16KM202.  There's a more
>> comfortable amount of memory in the KA302.
>> 2. use of the ff-shell.tcl for interaction.  It "just works for me" and
>> I find it convenient, so I'm hoping that it works for others too.
>> 3. use of the i2c-base-xxx words for all flavours of microcontroller.
>> 4. updates to the bit-banging speed tests to reflect FF changes since
>> the 2014 version of this guide.
>>
>> I would like to include some SPI words but semester is nearly here;
>> we'll see what we can fit in.
>>
>> Comments, corrections, wishes?  ...
>> Cheers,
>> Peter J.
>>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] update to tutorial guide

[Pete Z. <pza...@pz...>]

Hi Peter,
The Tutorial Guide looks very good.  Really glad to see the emphasis on 
the PIC24FV32KA302.
Perhaps a short tutorial on capacitance measurement using the 
PIC24FV32KA302 CTMU can be added (when time permits).
Look forward to SPI info being added, too.

Thanks for the effort.  Good luck with the new teaching term.

Pete

On 1/26/2016 9:12 PM, Peter Jacobs wrote:
> Fellows,
>      I've been trying to update the tutorial guide before the craziness
> of the teaching term arrives.
> Here is a pointer to a draft of the revised document.
>
> https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2016-draft-2016-01-27.pdf
>
> Main changes are :
> 1. use of a PIC24FV32KA302 rather than a PIC24FV16KM202.  There's a more
> comfortable amount of memory in the KA302.
> 2. use of the ff-shell.tcl for interaction.  It "just works for me" and
> I find it convenient, so I'm hoping that it works for others too.
> 3. use of the i2c-base-xxx words for all flavours of microcontroller.
> 4. updates to the bit-banging speed tests to reflect FF changes since
> the 2014 version of this guide.
>
> I would like to include some SPI words but semester is nearly here;
> we'll see what we can fit in.
>
> Comments, corrections, wishes?  ...
> Cheers,
> Peter J.
>

Re: [Flashforth-devel] update to tutorial guide

[Thomas B. <fla...@bu...>]

Dear Peter,

thank you for the guide. It would nice if you can add a nice terminal what I use under OS X its CoolTerm http://freeware.the-meiers.org/ its easy and free. I attach a screenshot :-)

SPI words are nice too. I use spi on other pins (RB0-RB7) with my PIC18F2620, because the pins are used by I2C also.

 Gretes Thomas







> Am 27.01.2016 um 03:12 schrieb Peter Jacobs <pe...@me...>:
> 
> Fellows,
>    I've been trying to update the tutorial guide before the craziness 
> of the teaching term arrives.
> Here is a pointer to a draft of the revised document.
> 
> https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2016-draft-2016-01-27.pdf
> 
> Main changes are :
> 1. use of a PIC24FV32KA302 rather than a PIC24FV16KM202.  There's a more 
> comfortable amount of memory in the KA302.
> 2. use of the ff-shell.tcl for interaction.  It "just works for me" and 
> I find it convenient, so I'm hoping that it works for others too.
> 3. use of the i2c-base-xxx words for all flavours of microcontroller.
> 4. updates to the bit-banging speed tests to reflect FF changes since 
> the 2014 version of this guide.
> 
> I would like to include some SPI words but semester is nearly here; 
> we'll see what we can fit in.
> 
> Comments, corrections, wishes?  ...
> Cheers,
> Peter J.
> 
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

[Flashforth-devel] update to tutorial guide

[Peter J. <pe...@me...>]

Fellows,
    I've been trying to update the tutorial guide before the craziness 
of the teaching term arrives.
Here is a pointer to a draft of the revised document.

https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2016-draft-2016-01-27.pdf

Main changes are :
1. use of a PIC24FV32KA302 rather than a PIC24FV16KM202.  There's a more 
comfortable amount of memory in the KA302.
2. use of the ff-shell.tcl for interaction.  It "just works for me" and 
I find it convenient, so I'm hoping that it works for others too.
3. use of the i2c-base-xxx words for all flavours of microcontroller.
4. updates to the bit-banging speed tests to reflect FF changes since 
the 2014 version of this guide.

I would like to include some SPI words but semester is nearly here; 
we'll see what we can fit in.

Comments, corrections, wishes?  ...
Cheers,
Peter J.

Re: [Flashforth-devel] NMEA input

[Mikael N. <mik...@fl...>]

I noticed some errors in my previous post /Mike

ram
create command 8 allot
create param1  8 allot
create param2  10 allot

: lcd-emit ( char -- ) ;
: lcd-xy   ( x y -- ) ;

: parse-gpgga
    tib dup tibsize accept 'source 2! 0 >in !
    [char] , parse command place \ $GPGGA
    [char] , parse param1 place
    [char] , parse param2 place
    \ etcetera
;
: lcd-display
    0 0 lcd-xy
    param1 c@+ type
    param2 c@+ type
;

: lcd-nmea
    4800 baud-set u0-
    ['] lcd-emit 'emit !  \ redirect to lcd
    begin
      parse-gpgga
      lcd-display
    again
;

\ For autostart
' lcd-nmea to turnkey

Re: [Flashforth-devel] bit.txt problem

[Mikael N. <mik...@fl...>]

Or this. It depends on exactly what kind of SPI you want.

ddrb  out bit1: spi-out-pin
portb out bit0: spi-out-0 inlined
portb out bit1: spi-out-1 inlined
ddrb  clk bit1: spi-clk-pin
portb clk bit0: spi-clk-0 inlined
portb clk bit1: spi-clk-1 inlined

: spi! ( u --- )
   spi-pin-pin spi-clk-pin
   spi-clk-0
   #8 for
     dup $80 and
     if spi-out-1 else spi-out-0 then
     spi-clk-1 2* spi-clk-0
   next drop ;

Mike