flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] Trouble getting serial comms to work

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

Hi yourself Richard,

Running the calculation Microchip gives us:
     ((12288000 / 38400) / 64) - 1 = 4
  looks tight on the SPBRG, but the error is nill so the crystal should get it close enough.

I occasionally have to reset my terminal program (TerraTerm) when it gets bloody-minded and acts like that.

Old School Debugging would say try turning the starting comm-rate down to 9600 baud and see if it talks.

It's been a while since I've had to do massive tweaking with my 18F46K22-s because Mikael's done a good job with the sources.

Good Luck!
craig bair

[Flashforth-devel] Trouble getting serial comms to work

[Richard B. <ric...@gm...>]

Hi all,

I was given a board with a pic on it, the 18f45k20. It uses a 12288kHz
crystal. While I have used several forths on micro's I'm not claiming
any expertise.

So I compile an image, using
  constant clock=d'12288000'  ; Hz
in p18f-main.cfg.

And in p18f2x4xk20.cfg
#define PLL DISABLE	         ; ENABLE or DISABLE

And somewhere I remember a setting to use the external crystal.

So I flash the pic and hook up a serial port at 38400, 8N1. And on
power all I get is garbage. I used Pulseview to see what is coming out
of the serial port. The minimum pulse in the data stream at power up
is consistent with 38400 baud. But instead of any kind of ascii being
decoded I get frame errors on each byte and nothing like ascii.

In ff-pic18.lst I can see that  at line 481
00481             #include p18f45k20.inc
the right processor is being included so I assume I have everything
set up correctly.

But clearly I am making a silly error somewhere. Does anyone have
advice on what I should check please? Or what further information
should I supply to shed light on this please?

Many thanks
Richard

Re: [Flashforth-devel] arduino

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

FlashForth needs to write to flash in order to compile new words.

Normally the bootloaders are set up so that only the bootloader can 
write to flash.
And the bootloaders do not have an interface enabling the application 
code to write to flash.

Of course one could write special bootloader that offers what is needed. 
But then you anyway need to program the bootloader first into the chip.


On 2018-09-15 00:58, hc wrote:
> What operation do you mean?
> 
> As I understand it, the bootloader 
> (https://github.com/Optiboot/optiboot)  is
> generic (not arduino specific) and just loads the binary into the 
> absolute
> addresses, except for the coldstart reset vector.
> 
> As long as FF is compiled below the bootloader area  ( top 512 bytes), 
> it
> should load, and get run by the bootloader.
> Perhaps some of the flags mapping the bootload area have to be 
> adjusted.
> 

Re: [Flashforth-devel] arduino

[hc <ml...@i2...>]

What operation do you mean?

As I understand it, the bootloader (https://github.com/Optiboot/optiboot)  is 
generic (not arduino specific) and just loads the binary into the absolute 
addresses, except for the coldstart reset vector.

As long as FF is compiled below the bootloader area  ( top 512 bytes), it 
should load, and get run by the bootloader. 
Perhaps some of the flags mapping the bootload area have to be adjusted.



On Saturday, 15 September 2018 06:51:23 NZST Mikael Nordman wrote:
> That would be great, but sadly that kind operation is not supported by
> the Arduino bootloader.
> 
> On 2018-07-26 00:11, hc wrote:
> > I think it would be beneficial for FF to be Arduino bootload-able, so
> > it can be
> > uploaded straight into an Arduino without a programmer. I think that
> > would
> > make it much more accessible, and would have saved me quite a bit of
> > faffing
> > about.
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] arduino

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

That would be great, but sadly that kind operation is not supported by 
the Arduino bootloader.


On 2018-07-26 00:11, hc wrote:
> I think it would be beneficial for FF to be Arduino bootload-able, so 
> it can be
> uploaded straight into an Arduino without a programmer. I think that 
> would
> make it much more accessible, and would have saved me quite a bit of 
> faffing
> about.
> 

Re: [Flashforth-devel] FlashForth on the PIC18F26K42

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

Hey Jordan.

This is great !
I suspected that it would be a substantial effort, so I did not even 
start.

It would be best if you can merge master into the k42 branch and test 
that some  legacy PIC18 chips work with the code.
After that the k42 branch can be merged to master and pulled to my main 
FF repository.

I can contribute with testing on some legacy PIC18 chips, I have a 
fairly large selection.

Part of merge can be done with ifdefs and part with macros.
I wonder if movff can be macro or can movff be replaced by a M_MOVFF 
macro which generates
movff or movffl instruction based on the selected chip. Using macros 
would make the code more readable than a myriad of ifdefs.

Having a separate source file for the k42 could also be acceptable, 
since the k42 is so different.
Or dividing FF into file(s) with common parts and file(s) with k42 
parts.

BR Mikael

On 2018-09-12 07:51, Jordan Niethe wrote:
> Hi everyone,
> 
> I have been working on getting FlashForth running on the PIC18F26K42
> as part of my final year engineering project.
> I thought people might be interested in my work to that end, which can
> be seen at
> https://github.com/iamjpn/flashforth on the k42 branch.
> 
> The 26K42 has quite a few differences from the other PIC18s.
> * The BSR is now 6 bits rather than 4 bits, and data memory ranges
> from $0000-$3FFF.
> However, for the 26K42, banks 16 - 55 are not implemented and banks 56
> - 63 are SFR.
> This made me decide to keep the same memory mapping as the other
> PIC18s, with the RAM starting at $F000.
> I further split the memory, to keep all the SFRs available:
> $F000-$F7FF in FlashForth = $0000-$07FF in hardware
> $F800-$FFFF in FlashForth = $3800-$3FFF in hardware
> 
> All this requires a lot of bit masking, makes storing more complicated
> and makes half the RAM unavailable.
> It would be a better idea to just RAM at  $C000 on the 26K42, which is
> what I'm now working on.
> 
> The larger memory size also means that movff does not have enough
> reach, movffl needs to be used.
> You need to be using the latest MPASM or movffl will not work.
> ( https://www.microchip.com/forums/FindPost/1064775 )
> 
> * Many SFRs are no longer in the Access Bank.
> A lot more bank selecting needs to be done.
> 
> * No more USART.
> The 26K42 has a new, different UART module, different code needed for
> this.
> 
> * Instruction Memory
> The 26K42 uses a block size of 128 bytes for writing and erasing
> program memory.
> 64 bytes was previously assumed throughout FF.
> 
> * Timers
> Slightly different set up
> 
> * EEPROM
> Begins at address $310000 instead of $F00000
> 
> * Naming
> A few names used in FlashForth conflicted with names used by the
> 26K42, so had to be renamed.
> 
> I have not yet touched multitasking, HW flow control, cpu load, cpu
> idle mode or USB serial emulation, will work on these next.
> I have not used my changes in anger yet, but it seems to be
> functional.
> 
> The changes I have made make FlashForth no longer compatible with the
> other PIC18s. After it is fully working on the 26K42 it would be nice
> to integrate the changes back in.
> I'm a little unsure what is the best way to go about this.
> It would need quite a lot ifdefs if used in a similiar way to how
> currently differences in devices are handled, but I'm not sure what a
> better approach would be.
> 
> I hope this is interesting to people,
> Jordan Niethe.
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] FlashForth on the PIC18F26K42

[Jordan N. <jni...@gm...>]

Hi everyone,
I have been working on getting FlashForth running on the PIC18F26K42 as
part of my final year engineering project.
I thought people might be interested in my work to that end, which can be
seen at
https://github.com/iamjpn/flashforth on the k42 branch.

The 26K42 has quite a few differences from the other PIC18s.
* The BSR is now 6 bits rather than 4 bits, and data memory ranges from
$0000-$3FFF.
However, for the 26K42, banks 16 - 55 are not implemented and banks 56 - 63
are SFR.
This made me decide to keep the same memory mapping as the other PIC18s,
with the RAM starting at $F000.
I further split the memory, to keep all the SFRs available:
$F000-$F7FF in FlashForth = $0000-$07FF in hardware
$F800-$FFFF in FlashForth = $3800-$3FFF in hardware
All this requires a lot of bit masking, makes storing more complicated and
makes half the RAM unavailable.
It would be a better idea to just RAM at  $C000 on the 26K42, which is what
I'm now working on.

The larger memory size also means that movff does not have enough reach,
movffl needs to be used.
You need to be using the latest MPASM or movffl will not work.
( https://www.microchip.com/forums/FindPost/1064775 )

* Many SFRs are no longer in the Access Bank.
A lot more bank selecting needs to be done.

* No more USART.
The 26K42 has a new, different UART module, different code needed for this.

* Instruction Memory
The 26K42 uses a block size of 128 bytes for writing and erasing program
memory.
64 bytes was previously assumed throughout FF.

* Timers
Slightly different set up

* EEPROM
Begins at address $310000 instead of $F00000

* Naming
A few names used in FlashForth conflicted with names used by the 26K42, so
had to be renamed.

I have not yet touched multitasking, HW flow control, cpu load, cpu idle
mode or USB serial emulation, will work on these next.
I have not used my changes in anger yet, but it seems to be functional.

The changes I have made make FlashForth no longer compatible with the other
PIC18s. After it is fully working on the 26K42 it would be nice to
integrate the changes back in.
I'm a little unsure what is the best way to go about this.
It would need quite a lot ifdefs if used in a similiar way to how currently
differences in devices are handled, but I'm not sure what a better approach
would be.

I hope this is interesting to people,
Jordan Niethe.

Re: [Flashforth-devel] arduino baudrate mishmosh

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

Hi again,
I think I found my problem with assembling the ATMEGA FlashForth...  AtmelStudio 7.0 does NOT like the converted source code. Too modern, I suppose.

I located and installed a copy of AVRStudio 4 and everything was much happier except the ISP-mk_II programmer that isn't supported. Maybe if I rat about a bit longer I might find something old enough to work for debugging (grin).

Anyway, thanks for the attention. I still remember the classic Linux reply from ver. 0.x days, "You don't like it? You've got the source code, fix it." (big evil grin).

Mikael, it's a lovely piece of work. Carry On!
craig

[Flashforth-devel] arduino

[hc <ml...@i2...>]

I think it would be beneficial for FF to be Arduino bootload-able, so it can be 
uploaded straight into an Arduino without a programmer. I think that would 
make it much more accessible, and would have saved me quite a bit of faffing 
about. 

[Flashforth-devel] AVR FlashForth on Arduinos baudrate?

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

Hi,
I'm not particularly fluent in Atmel AVR the way I am in Microchip 8-bit PIC assembler, but since I've got AS7 available for working on SAM chips and a couple piles of 'duinos on the bench I thought I'ld put up my favorite foreign language on a couple (just to annoy the young doctorates, mind you (grin)).
I've installed both hex files, one on an UNO the other on a MEGA 2560.  Both run just fine as far as I've tested them (once the fuses are set right) but both communicate at 9600 baud rather than 38400 that's set in the source code.  One of the calculations appears to do a divide-by-16 which seemed ripe for an experiment changing it to a divide-by-4...  
Then I tried to build it.
AS7 let me import it as an AS4 project but the build came back with over 650 errors, so I'm obviously doing something wrong.
I'ld like to know what my optimal Atmel Studio version is for this and a little more explanation of the import and build procedures just to get me started.
Thanks,
craig bair
(...and keep up the good work, guys!...)

[Flashforth-devel] Issues controlling flashforth from windows application via usb serial port

[hc <ml...@i2...>]

in https://sourceforge.net/p/flashforth/mailman/message/36299729/

When I was trying to use pic18 USB last year, I couldn't find/use the port from 
Realterm. I don't remember exactly what the problem was now, and reflashed for 
uart.

At the time I thought that there is something not right in the USB info so it 
is not creating a vcp properly

Anyway you can try Realterm and see if it works for you. When you plug a USB 
device in, Realterm shows it on notification.

https://realterm.i2cchip.com/
Realterm_BUG_TESTERS_ONLY_BETA2_3.0.1.45_setup.exe

This version has the Send tab comboboxes changed, so you can just type lines 
then <enter> and they are sent, so more fluid as a FF console. If there is any 
interest, I may add more FF support.  Discuss here:

https://sourceforge.net/p/flashforth/discussion/726813/thread/f2531242/

[Flashforth-devel] Issues controlling flashforth from windows application via usb serial port

[hc <ml...@i2...>]

in https://sourceforge.net/p/flashforth/mailman/message/36299729/

When I was trying to use pic18 USB last year, I couldn't find/use the port from 
Realterm. I don't remember exactly what the problem was now, and reflashed for 
uart.

At the time I thought that there is something not right in the USB info so it 
is not creating a vcp properly

Anyway you can try Realterm and see if it works for you. When you plug a USB 
device in, Realterm shows it on notification.

https://realterm.i2cchip.com/
Realterm_BUG_TESTERS_ONLY_BETA2_3.0.1.45_setup.exe

This version has the Send tab comboboxes changed, so you can just type lines 
then <enter> and they are sent, so more fluid as a FF console. If there is any 
interest, I may add more FF support.  Discuss here:

https://sourceforge.net/p/flashforth/discussion/726813/thread/f2531242/

Re: [Flashforth-devel] Issues controlling flashforth from windows application via usb serial port

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

You are right. FF does not store new serial settings.
I removed that part when I made the USB code as small as possible.

Maybe I can put it back, I did not realize it would cause problems,
since the terminal emulators do not seem to care about that part.

BR Mikael

On 2018-04-21 18:25, Bob Edwards via Flashforth-devel wrote:
> 
> Is the flashforth usb port fully compliant to the standard? Calling
> the api to read the settings of the port completes successfully
> (returns the DCB structure) but writing a modified DCB to the port
> fails (to set 9600,n,8,1,n,Xon/Xoff etc ). Doing the same thing to
> COM1 works. This is probably what prevents the labview library from
> opening the port since it assumes you would always want to set baud
> rate etc.
> Cheers, Bob G4BBY

[Flashforth-devel] Issues controlling flashforth from windows application via usb serial port

[Bob E. <bob...@ti...>]

I have a pic18f4553 board set up for USB serial link. It is going to 
control an antenna tuner from a linx 10 tablet running 32 bit windows 8, 
which also hosts a software defined radio (ham radio).

In windows 8, I have to use zadiq to install the USB serial port for 
flashforth because it is not a registered product - that's OK.

I use teraterm to program  and manually test flashforth. This works 
reliably with inter-char and inter-line delays fitted. The delays seem 
to be needed when loading flashforth from a file, else it can fail. Thus 
I know that extended communication between teraterm and my flashforth 
board works. I've downloaded some large files to further test this.

However, I want to control the flashforth board from a control 
application written in LabView on the tablet. When I use the serial port 
library that comes with LabView, it fails to open the flashforth port, 
although it successfully opens COM1, a normal serial port (but no 
external connector so not usable)

I wrote my own serial port driver in LabView that directly calls the 
windows serial port api. Still not successful - I get a blue screen of 
death after up to 200 messages to and fro with the BSOD message *"STOP 
0x0000000A: IRQL_NOT_LESS_EQUAL – usbser.sys".*

Is the flashforth usb port fully compliant to the standard? Calling the 
api to read the settings of the port completes successfully (returns the 
DCB structure) but writing a modified DCB to the port fails (to set 
9600,n,8,1,n,Xon/Xoff etc ). Doing the same thing to COM1 works. This is 
probably what prevents the labview library from opening the port since 
it assumes you would always want to set baud rate etc.

What I want to know is, has anyone successfully controlled flashforth 
via usb serial link from Windows 7/8/10? What were the details and did 
you have this same problem along the way?

(It's quite possible I have a bug still in my code or that USBSER.SYS is 
corrupt)

Cheers, Bob G4BBY

*
*

Re: [Flashforth-devel] PIC18F - Problems with code above $8000

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

Fixed !
-- 
--
Mikael

Re: [Flashforth-devel] PIC18F - Problems with code above $8000

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

I need to fix that.1 rshift instead of 2/ shud work.Or mayby there is a bitmask that can be changed to mask away the uppermost address bit. Need to check that.
Thanks for reporting this.Mikael

[Flashforth-devel] PIC18F - Problems with code above $8000

[Pablo M. <ea...@ho...>]

Hello Mikael,


I am writing a relatively big (o lousy coded) program, and have found that words created above $8000 sometimes result in a processor reset when compiled into new words.


Here is a simple example:

hex flash here u. 895a  ok<$,flash>
ram   ok<$,ram>
: test1 1 1 + ;    ok<$,ram>
test1  ok<$,ram>2
: test2 test1 ;  ok<$,ram>2
test2
 FlashForth 5 PIC18F26K20 07.10.2017     -->   [test2 has produced a reset]

After a lot of head scratching, I have found that CALL and GOTO instructions have an incorrect destination address when the target is above $8000:
' test1  ok<$,ram>8962

hex see test2
897a efb1 f0c4 goto  test1

The destination addresss should be 44b1 (= 8962 / 2), but the compiled address is c4b1. This results in a jump outside the program.

The problem is that the destination address is calculated with the 2/ code (TWOSLASH routine). But 2/ is designed to work with signed numbers. It does so by shifting 1 bit right but maintaining the sign bit.

8962 2/  ok<$,ram>c4b1                  <--- This is the used (incorrect) address
8962 1 rshift  ok<$,ram>c4b1 44b1       <--- This is the correct address

The simplest solution would be to change 2/ to work with unsigned numbers. But I see that the current implementation of 2/ is correct according to the ANS94 standard, so it doesn't seem right to change it.

Perhaps the best solution is to create a new subrutine "u2/"
UTWOSLASH:
        bcf     STATUS, C, A
        rrcf    Sminus, F, A
        rrcf    Splus, F, A
        return
and use it instead of TWOSLASH in "br?" and "br3".



   73, Pablo - EA4FUK

Re: [Flashforth-devel] >digit word fail?

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

At some point I changed the ">digit" to "digit"

The wordsAll.txt is wrong and needs to be updated.

BR Mikael

On 2018-03-17 23:40, Thomas Buschhardt wrote:
> Hallo,
> 
> I looking for ">digit" but found only "digit?" and "digit". Here is my
> log:
> Is that an error?
> 
> Greetings Thomas

[Flashforth-devel] >digit word fail?

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

Hallo,

I looking for ">digit" but found only "digit?" and "digit". Here is my log:

S FlashForth 5 PIC18F2620  01.01.2018␍␊

words:

p2+ p++ pc@ @p hi d. ud. d> d< d= d0< d0= dinvert d2* d2/ d- d+ dabs
?dnegate dnegate s>d rdrop endit next for in, inline repeat while again
until begin else then if until, again, begin, else, then, if, not, nc,
nz, z, br? dump .s words >pr .id ms ticks s0 latest state bl 2- ['] -@ ;
:noname : ] [ lst does> postpone create cr [char] ( char ' abort" ?abort
?abort? abort prompt quit true false .st inlined immediate shb interpret
'source >in tiu tib ti# number? >number a> >a ud/mod ud* sign? *digit?*
find immed? (f) c>n n>c @+ c@+ place cmove word parse \ /string source
user base pad hp task ulink bin hex decimal . u.r u. sign #> #s #
*digit* <# hold up min max ?negate tuck nip / u*/mod u/ * u/mod um/mod
um* 'key? 'key 'emit p+ pc! p! p@ r>p !p>r !p u> u< > < = 0< 0= <>
within +! 2/ 2* >body 2+ 1- 1+ negate invert xor or and - m+ + abs dup
r@ r> >r rot over swap drop allot ." ," s" (s" type accept 1 umax umin
spaces space 2swap 2dup 2drop 2! 2@ cf, chars char+ cells cell+ aligned
align cell c, , here dp ram eeprom flash c@ @ c! ! sp@ 2constant
constant co: 2variable variable @ex execute key? key emit ver warm empty
btfss, btfsc, bsf, bcf, bra, rcall, call, goto, br3 br2 as3 as1 rshift
lshift ic, i, operator Fcy mtst mclr mset iflush pause turnkey is to
defer value cwd u1- u1+ fl+ fl- >tblp literal int! ;i di ei scan skip n=
rx1? rx1 tx1 i] [i andlw, movf, w, a, load busy idle exit 

Is that an error?

Greetings Thomas

Re: [Flashforth-devel] FF_USB - fails to link

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

Hi Bob,

If you are using the PIC18F2550 you must uncomment

#define USB_CDC

in p18f2455-2550-4455-4550.cfg

BR Mikael

[Flashforth-devel] FF_USB - fails to link

[Bob E. <bob...@ti...>]

Hi Mike,

In project FF_USB for PIC18 from version 
flashforth-code-be9b8e6c20de01eca8402871aace2990021d3eeb, I get:-

Error - section 'IRQ_STACK' has a memory 'irqstack' which can not fit 
the section. Section 'IRQ_STACK' length=0x0000013b.
Errors    : 1

Do you see the same? I'm using MPLAB X IDE v4.15 on windows.


Regards, Bob

[Flashforth-devel] PIC18 1.1.2018

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

Hi Peter and all,

The ff51 branch was merged to master today.

The biggest change is the way the return stack is managed.
FSR2 is used as the return stack save pointer in task switching
and for R> >R R@
R> does not store into the HW return stack, but into the user area 
reserved for
the return stack buffer.
So R> does not work for modifying the return address anymore.
It can only be used for temporary data storage.

Another change is that PAUSE skips the task switch if there are no 
background tasks to be run.

Therefore the newest versions of task.txt and doloop.txt must be used.

A more complete table driven SEE is included.

BR Mike

On 2017-12-30 08:01, Peter Jacobs wrote:
> Mike,
> 
> For other hardware projects, I've been happily using FF5.0 on some
> PIC24FV32KX30x micros.  It appears that your new ff51 branch touches
> only pic18 code so, for PIC24 work, I guess that I should continue
> with the master branch.
> Cheers,
> Peter J.

Re: [Flashforth-devel] changes to FF for PIC18F26K42

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

Mike,
Although the eeprom reading and writing for the K42 looks to be 
compatible to that for the K22, right down to the bits in the control 
registers, there are a number of other changes to bit locations (e.g. 
other registers for peripheral interrupt bits).  I think that I'll take 
a bit of time to learn about the K42 family without the benefit of FF 
for the moment.  To try out FF5.1, I'll stay with the K22 family.

For other hardware projects, I've been happily using FF5.0 on some 
PIC24FV32KX30x micros.  It appears that your new ff51 branch touches 
only pic18 code so, for PIC24 work, I guess that I should continue with 
the master branch.
Cheers,
Peter J.



On 29/12/17 18:37, Mikael Nordman wrote:
> The flash and eeprom control registers have new names, NVMxxx instead 
> of EExxx.
>
> Silly change. Maybe they are incompatible.
>
> M.
>
> ------------------------------------------------------------------------------ 
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] changes to FF for PIC18F26K42

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

On 29/12/17 17:33, Mikael Nordman wrote:
> BTW,
> There is a ff51 branch in git which you could base your changes on.
> It will soon be the latest master code.

Thanks for the hints Mike.  I will try the adjusting the ff51 branch for 
the new PIC18F26K42 chip and then learn how to package the changes with 
git.  (I use Mercurial, mostly.)

This evening, I have tried the ff51 branch on the older PIC18F26K22 
chip.  It looks good.  It emits a "S FlashForth 5 PIC18F26K22 
20.12.2017" banner when the interpreter restarts so, for a while, that 
did have me wondering if I had the correct branch checked out.  I am 
reasonably sure that I did, although I am not yet confident with my use 
of git.

Cheers,

Peter J.

Re: [Flashforth-devel] changes to FF for PIC18F26K42

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

The flash and eeprom control registers have new names, NVMxxx instead of 
EExxx.

Silly change. Maybe they are incompatible.

M.