flashforth-devel — FlashForth users and developers

[Flashforth-devel] (no subject)

[tur b. <mai...@gm...>]

Hi I am new to flashforth and forth. I seem to be making some progress but
seem to be missing sleep and forget in my words list. Both return sleep?
etc when used, can I use sleep in assembly? I can set the register, but I
am unsure how to call it in assembly, is it [sleep]?. I have burnt the hex
file in the avr folder, thoroughly enjoying interacting with it so far, any
help would be appreciated.

Re: [Flashforth-devel] PIC18F14K50 and UART receive buffer size

[Tristan W. <ho...@tj...>]

Hello Mikael,

Many thanks.

Best wishes,

Tristan

On 18Feb20 21:33, Mikael Nordman wrote:
> RXbuf larger than 32 bytes is not supported on PIC18F14K50 with USBCDC,
> It would require some code changes to ff-pic18.asm.
> 
> BR Mikael
> 
> On 2020-02-18 19:36, Tristan Williams wrote:
> > Hello,
> > 
> > I am using Flashforth with a PIC18F14K50 and USBCDC. I am also using
> > its UART and would like to increase the size of the UART receive
> > buffer (which I think is RXbuf) to 64 bytes, which is larger than the
> > maximum 32 bytes supported by the default linker file for the
> > PIC18F14K50.
> > 
> > Is there a way I can do this?
> > 
> > All help gratefully received.
> > 
> > Kind regards and thanks,
> > 
> > Tristan
> > 
> > 
> > 
> > _______________________________________________
> > Flashforth-devel mailing list
> > Fla...@li...
> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 
> -- 
> --
> Mikael
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 

Re: [Flashforth-devel] PIC18F14K50 and UART receive buffer size

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

RXbuf larger than 32 bytes is not supported on PIC18F14K50 with USBCDC,
It would require some code changes to ff-pic18.asm.

BR Mikael

On 2020-02-18 19:36, Tristan Williams wrote:
> Hello,
> 
> I am using Flashforth with a PIC18F14K50 and USBCDC. I am also using
> its UART and would like to increase the size of the UART receive
> buffer (which I think is RXbuf) to 64 bytes, which is larger than the
> maximum 32 bytes supported by the default linker file for the
> PIC18F14K50.
> 
> Is there a way I can do this?
> 
> All help gratefully received.
> 
> Kind regards and thanks,
> 
> Tristan
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] PIC18F14K50 and UART receive buffer size

[Tristan W. <ho...@tj...>]

Hello,

I am using Flashforth with a PIC18F14K50 and USBCDC. I am also using
its UART and would like to increase the size of the UART receive
buffer (which I think is RXbuf) to 64 bytes, which is larger than the
maximum 32 bytes supported by the default linker file for the
PIC18F14K50.

Is there a way I can do this?

All help gratefully received.

Kind regards and thanks,

Tristan

Re: [Flashforth-devel] ff5.0 2019-12-12

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

 Pete,
Thanks for your efforts at continuing documentation of FlashForth as well as Mikael's patient explanations to this old dinosaur!
If you have time to spare and inclination to write, a tutorial on Tasks vs User Interrupts would be useful (at least to me (grin)).
Into the new decade we go! 
Keep up the Good Work, guys.
(...and HI! to you too, Attila.)
craig


     On Sunday, January 5, 2020, 3:15:26 PM EST, Pete Zawasky <pza...@pz...> wrote:  
 
 Hi Mikael,

Thanks for continuing to support FF, especially on the Microchip PICs.

Best wishes for the New Year.  Hope all is well.

Pete
AG7C


_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
  

[Flashforth-devel] ff5.0 2019-12-12

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

Hi Mikael,

Thanks for continuing to support FF, especially on the Microchip PICs.

Best wishes for the New Year.  Hope all is well.

Pete
AG7C

Re: [Flashforth-devel] Interrupts - frequency of servicing

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

Tristan,
The best solution is to let the rising edge triggered interrupt
switch to falling edge mode, and to start a timer counting clock cycles.
Then in the falling edge interrupt routine you can just stop the counter 
and
read out the  value from the timer to get the pulse width.
Then zero the counter and switch to rising edge mode.

Mikael

On 2019-12-11 08:26, Tristan Williams wrote:
> Hello,
> 
> I would like to measure the width of some pulses using FlashForth on a
> PIC18F14K50. My first thought was to do this using the capture mode of
> the ECCP unit - setting it to look for a rising edge then switch to
> look for a falling edge in an interrupt routine. I have a working
> interrupt routine which is seems to be serviced every millisecond
> (driven from the 1ms timer1/ticks in my p18-main.cfg?). However, the
> pulses I wish to measure are only a few hundred microseconds in length.
> 
> Is there a way to increase the frequency of servicing of my interrupt
> routine or another way to approach this?
> 
> Kind regards and thanks,
> Tristan
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] Interrupts - frequency of servicing

[Tristan W. <ho...@tj...>]

Hello,

I would like to measure the width of some pulses using FlashForth on a
PIC18F14K50. My first thought was to do this using the capture mode of
the ECCP unit - setting it to look for a rising edge then switch to
look for a falling edge in an interrupt routine. I have a working
interrupt routine which is seems to be serviced every millisecond
(driven from the 1ms timer1/ticks in my p18-main.cfg?). However, the
pulses I wish to measure are only a few hundred microseconds in length.

Is there a way to increase the frequency of servicing of my interrupt
routine or another way to approach this? 

Kind regards and thanks,
Tristan

Re: [Flashforth-devel] more fun with PIC18F46K22-s...

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

Hi Craig. 

In fact all interrupts are serviced.
My point was just that it takes clock cycles when on the PIC18 you need
to scan all potential interrupt flags even if only one flag is set.
To optimize that a little bit the system tick code does a RETFIE without
checking any further interrupts.
These will then be serviced immediately afterwards when the interrupt
code is called again. 

Another tip is the use a lower system tick resolution. It will reduce
the load a little bit.
You can configure the system tick time in the latest FFs.
Do you really need a 1 ms resolution ? 

The buffers do not need to be aligned, but the size needs to be a power
of 2. The _FULL_BIT macros are checking the fill level counter. 

You can use TMR2 to control the HW PWM frequency. 
I suppose the A/D can just be polled whenever, as long as it is often
enough. 

I removed the buffered TX because I never used it. And I never heard of
anyone using it either.
But I have never pushed the PICs to the limit. Just using soft realtime
:-) 

BR Mikael 

On 2019-12-09 16:31, craig bair via Flashforth-devel wrote:

> Mikael,
> Thanks much! I'll see if I can get these suggestions to work for me this next weekend. 
> 
> I didn't know that the user interrupts might not be getting serviced, I may try setting up some vectors in eeprom and hook the main interrupt service to check them if they're set to something valid. I've extended the sys-tick to 32 bits and added a word "dticks" to toss the double onto the stack when needed.
> 
> I've looked back into the Buffered TX code and still don't see the hole that the character is leaking out of when the output string exceeds the buffer size, but since I'm going to use output packets of less than 32 bytes for my TX2 it might work to roll a custom version back into the kernal. It looks like you were using the linker to align all of the buffers on 16 byte boundries back then. Do the "**_FULL_BIT" macros rely on that? (I never used linker scripts, I just hard-positioned my variables in the *.asm (grin)).
> 
> Oh, and yes, I'm pushing the chip to 64mhz. I haven't tried overclocking yet.
> 
> Thanks Again! (and keep smiling),
> craig

Re: [Flashforth-devel] more fun with PIC18F46K22-s...

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

 Mikael,
 Thanks much! I'll see if I can get these suggestions to work for me this next weekend.
 I didn't know that the user interrupts might not be getting serviced, I may try setting up some vectors in eeprom and hook the main interrupt service to check them if they're set to something valid. I've extended the sys-tick to 32 bits and added a word "dticks" to toss the double onto the stack when needed.

 I've looked back into the Buffered TX code and still don't see the hole that the character is leaking out of when the output string exceeds the buffer size, but since I'm going to use output packets of less than 32 bytes for my TX2 it might work to roll a custom version back into the kernal. It looks like you were using the linker to align all of the buffers on 16 byte boundries back then. Do the "**_FULL_BIT" macros rely on that? (I never used linker scripts, I just hard-positioned my variables in the *.asm (grin)).

 Oh, and yes, I'm pushing the chip to 64mhz. I haven't tried overclocking yet.

Thanks Again! (and keep smiling),
craig
     On Sunday, December 8, 2019, 5:44:10 PM EST, Mikael Nordman <mik...@fl...> wrote:  
 
 I am not sure I fully understand what you are doing, but...
I hope you are  running at full clock speed.

To get more capacity I would use HW timers for the ADC and PWM.
That saves many cycles.

Remember that your user interrupt routine is checked
at every interrupt. Except in the latest FlashForths.
There the system tick will not check the user interrupt.

You can put the UART2 stuff in two background tasks.
Something like this.
I assume RX2 and TX2 calls PAUSE if they would block.

0 30 30 0 task: rx2.task
: rx2.loop
  init.rx2
  begin
    rx2
    processchar
  again ;

0 30 30 0 task: tx2.task
: tx2.loop
  init.tx2
  begin
    get.char.from.tx2.memory.queue
    tx2
  again
;

: main
  init.uart2
  ['] rx2.loop rx2.task tinit
  rx2.task run
  ['] tx2.loop tx2.task tinit
  tx2.task run
  begin
    bla.bla
    pause
    put.char.to.tx2.memory.queue
  again
;

Mikael


_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
  

Re: [Flashforth-devel] more fun with PIC18F46K22-s...

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

I am not sure I fully understand what you are doing, but...
I hope you are  running at full clock speed.

To get more capacity I would use HW timers for the ADC and PWM.
That saves many cycles.

Remember that your user interrupt routine is checked
at every interrupt. Except in the latest FlashForths.
There the system tick will not check the user interrupt.

You can put the UART2 stuff in two background tasks.
Something like this.
I assume RX2 and TX2 calls PAUSE if they would block.

0 30 30 0 task: rx2.task
: rx2.loop
   init.rx2
   begin
     rx2
     processchar
   again ;

0 30 30 0 task: tx2.task
: tx2.loop
   init.tx2
   begin
     get.char.from.tx2.memory.queue
     tx2
   again
;

: main
   init.uart2
   ['] rx2.loop rx2.task tinit
   rx2.task run
   ['] tx2.loop tx2.task tinit
   tx2.task run
   begin
    bla.bla
    pause
    put.char.to.tx2.memory.queue
   again
;

Mikael

Re: [Flashforth-devel] more fun with PIC18F46K22-s...

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

I am not sure I fully understand what you are doing, but...

You can put the UART2 stuff in  a background task.
: uart2rx-loop
   init
   begin
     rx2
     processchar
   again ;

: uart2tx-loop
   init
   begin


On 2019-12-08 21:33, craig bair via Flashforth-devel wrote:
> Maybe this is a bit ambitious, but I’m trying to build a temperature
> controller in a Pic18F46K22 involving the console (uart1), a network
> slave comm (uart2), an oled character display (spi1), and an external
> ADC (spi-bit-bang).  The PWMs and ADC reads are controlled from 4
> programmable soft timers through user-interrupt using timer4 rolling
> over each millisecond (I’ld have daisy-chained the sys-tick but
> haven’t put a hook into the kernel for that).  The networking comm has
> sparse activity, so I just use a buffered Rc2 in the user-interrupt to
> accumulate the small packets and process at leisure.  The display
> drive is blocking, but only used for a few characters at a time when
> the primary heat drive is active, so I’m not worried about that (yet).
>  I’ve run into what look like timing conflicts since activating the
> Tx2 response drive.  The blocking output approach will over-run the
> millisecond boundaries of my timer checking.  Buffering the output
> packet and using a user-interrupt trigger to send each character has
> been dropping bytes for no readily apparent reason. Most annoying, the
> timing behavior problems are still there.
> 
> I’ve never worked with multi-tasking in 8-bit processors so I’m a
> little unclear as to what tasks are supposed to do and how to launch
> and handle them.  Is it possible and practical to launch a packet-send
> task from inside an interrupt and have it execute outside while being
> interrupted when timing required it?  Does it make sense to try?  A
> somewhat more detailed walk-through of Task Setup would be much
> appreciated by this dinosaur who predates structured programming
> (grin).
> Point of curiosity:  Has buffered uart transmission now been
> permanently dropped from FlashForth?  I went back to an older source
> version and enabled it as an experiment and the first thing I noticed
> was that the warm-start greeting line routinely lost a character
> (although not always the same one).  The output line is longer than
> the buffer size when the buffer is set to 32 (documented as max
> without tweaking the linker file (what needs changed?)).  Is an
> unhandled buffer overflow problem why it doesn’t appear as an option
> anymore?
> 
> OBTW:  a couple of #ifdef-s in the WARM_: uart setup code appear to
> have gotten lost and need to be added back in for compiling to use
> UART2 as CONSOLE. I stumbled into that while grasping at straws and
> then found that compiling it gave a console baudrate that TerraTerm
> can’t match up with.  I found that only half of spbrgvalx4  was
> getting loaded into SPBRG2 but once fixed, there appears to be no
> console input at all...  There are only so many problems I can look
> into with only weekends available to chase my obsessions (grin).
> 
> I’m still fighting with GitHub, so I won’t try to publish a branch and
> throw a pull request, but here’s what I’ve got so far on the UART2
> problem:
> 
> 
> #else  ; UART == 2 ---------------------------------------
> #ifdef BRG16
>         bsf     BAUDCON2, BRG16
> ;        movlw   spbrgvalx4
>         movlw   high(spbrgvalx4)
>         movwf   SPBRGH2, BANKED
>         movlw   low(spbrgvalx4)
> #else
>         movlw   spbrgval
> #endif
>         movwf   SPBRG2, BANKED
> ; TX enable
>         movlw   b'00100100'
>         movwf   TXSTA2, BANKED
> ; RX enable
>         movlw   b'10010000'
>         movwf   RCSTA2, BANKED
>         bsf     PIE3, RC2IE
> #ifdef ANSEL18
> #ifdef ANCON2
>         bcf     ANCON2, ANSEL18, BANKED ; Enable digital RG2 for RX2
> (18F87K22 family)
> #endif                                  ; Other values may be needed
> depending on chip
> #endif
> #endif
> #else  ; K42 K83
> #if UART == 1 ; ----------------------------------------------
> 
> Thanks for your attention,
> craig bair -- still trying not to remember DEC-FORTRAN and MACRO-11...
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] more fun with PIC18F46K22-s...

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

Maybe this is a bit ambitious, but I’m trying to build a temperature controller in a Pic18F46K22 involving the console (uart1), a network slave comm (uart2), an oled character display (spi1), and an external ADC (spi-bit-bang).  The PWMs and ADC reads are controlled from 4 programmable soft timers through user-interrupt using timer4 rolling over each millisecond (I’ld have daisy-chained the sys-tick but haven’t put a hook into the kernel for that).  The networking comm has sparse activity, so I just use a buffered Rc2 in the user-interrupt to accumulate the small packets and process at leisure.  The display drive is blocking, but only used for a few characters at a time when the primary heat drive is active, so I’m not worried about that (yet).  I’ve run into what look like timing conflicts since activating the Tx2 response drive.  The blocking output approach will over-run the millisecond boundaries of my timer checking.  Buffering the output packet and using a user-interrupt trigger to send each character has been dropping bytes for no readily apparent reason. Most annoying, the timing behavior problems are still there.

I’ve never worked with multi-tasking in 8-bit processors so I’m a little unclear as to what tasks are supposed to do and how to launch and handle them.  Is it possible and practical to launch a packet-send task from inside an interrupt and have it execute outside while being interrupted when timing required it?  Does it make sense to try?  A somewhat more detailed walk-through of Task Setup would be much appreciated by this dinosaur who predates structured programming (grin).
Point of curiosity:  Has buffered uart transmission now been permanently dropped from FlashForth?  I went back to an older source version and enabled it as an experiment and the first thing I noticed was that the warm-start greeting line routinely lost a character (although not always the same one).  The output line is longer than the buffer size when the buffer is set to 32 (documented as max without tweaking the linker file (what needs changed?)).  Is an unhandled buffer overflow problem why it doesn’t appear as an option anymore?

OBTW:  a couple of #ifdef-s in the WARM_: uart setup code appear to have gotten lost and need to be added back in for compiling to use UART2 as CONSOLE. I stumbled into that while grasping at straws and then found that compiling it gave a console baudrate that TerraTerm can’t match up with.  I found that only half of spbrgvalx4  was getting loaded into SPBRG2 but once fixed, there appears to be no console input at all...  There are only so many problems I can look into with only weekends available to chase my obsessions (grin).

I’m still fighting with GitHub, so I won’t try to publish a branch and throw a pull request, but here’s what I’ve got so far on the UART2 problem:


#else  ; UART == 2 ---------------------------------------
#ifdef BRG16
        bsf     BAUDCON2, BRG16
;        movlw   spbrgvalx4
        movlw   high(spbrgvalx4)
        movwf   SPBRGH2, BANKED
        movlw   low(spbrgvalx4)
#else
        movlw   spbrgval
#endif
        movwf   SPBRG2, BANKED
; TX enable
        movlw   b'00100100'
        movwf   TXSTA2, BANKED
; RX enable
        movlw   b'10010000'
        movwf   RCSTA2, BANKED
        bsf     PIE3, RC2IE
#ifdef ANSEL18
#ifdef ANCON2
        bcf     ANCON2, ANSEL18, BANKED ; Enable digital RG2 for RX2 (18F87K22 family)
#endif                                  ; Other values may be needed depending on chip
#endif
#endif
#else  ; K42 K83
#if UART == 1 ; ----------------------------------------------

Thanks for your attention,
craig bair -- still trying not to remember DEC-FORTRAN and MACRO-11...

Re: [Flashforth-devel] Sending Forth files with macOS over USB

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

On 2019-11-24 00:14, Tristan Williams wrote:
> The transfer program I wrote takes the last approach.  However,
> originally I was hoping that somehow, through the USB CDC driver and
> configuring (in someway I was not aware of) the USB CDC serial port to
> use CRTSCTS, some emulated flow control would be created and I could
> avoid the byte by byte software handshaking.

Tristan,
On Linux/W7 I can use minicom/TeraTerm to send ascii files without any 
flow control at all.
The USB protocol itself performs the flow control.

The USB buffer on the PIC is 8 bytes max and it is owned either by the 
PIC or
the PC. FF does not release the buffer until it has been processed 
completely.
During the time the PIC owns the buffer the PC USB driver cannot not 
send anything to the PIC.

If the PIC is writing to flash it does not take ownership of the buffer 
until the
writing to flash has been completed. So when the buffer is full the PC 
cannot write more.

So I don't really understand what is going in with OSX.

I know the OSX is more picky in following the USB standard, so it could 
be that the my PIC USB
software lacks some functionality that the OSX expects to be there.

Can you check if OSX logs some errors related to USB_CDC?

Mikael

Re: [Flashforth-devel] Sending Forth files with macOS over USB

[Tristan W. <ho...@tj...>]

Mikael, Grant, Peter,

Thank you.

I've used Minicom as my interactive comms program for years, but I was
not aware of the inter-character delay option. Thank you.

On 23Nov19 20:14, Mikael Nordman wrote:
> HI.
> 
> ff-shell.py uses a line by line flow control.
> It waits to receive a new-line character before sending the next line.
> I would have thought that would work with any OS.
> I will add options to ff-shell.py for intercharacter delay and
> end-of-line delay.
> Possible also a character by character flow control.

The transfer program I wrote takes the last approach.  However,
originally I was hoping that somehow, through the USB CDC driver and
configuring (in someway I was not aware of) the USB CDC serial port to
use CRTSCTS, some emulated flow control would be created and I could
avoid the byte by byte software handshaking. My USB/CDC knowledge is
too low to speculate as to whether this was wishful thinking or
otherwise.

Byte by byte gets the Forth to the PIC quickly enough and when it's
there it is a joy to use. 

Best wishes and thanks,
Tristan

Re: [Flashforth-devel] Sending Forth files with macOS over USB

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

HI.

ff-shell.py uses a line by line flow control.
It waits to receive a new-line character before sending the next line.
I would have thought that would work with any OS.

I will add options to ff-shell.py for intercharacter delay and 
end-of-line delay.
Possible also a character by character flow control.

BR Mikael

On 2019-11-23 14:23, Tristan Williams wrote:
> Hello,
> 
> I am using a PIC18F14K50 with FlashForth 5 connecting over USB on
> macOS (10.11 & 10.14). I can enter Forth interactively using both 
> Minicom
> and ff-shell.py. However, with my setup, neither Minicom nor
> ff-shell.py is able to successfully send a file of forth source. The
> PIC appears to be overwhelmed by a torrent of Forth. I did wonder
> whether the PIC was making a value judgement about quality of my code,
> but think it more likely that my setup has a flow control
> problem. Both Minicom and ff-shell.py were setup to use CRTSCTS
> (though changing to XON/XOFF made no difference) which I think is
> correct for a USB CDC serial connection. Running Minicom and
> ff-shell.py interactively and checking the USB CDC serial port
> settings with stty whilst they are running showed that neither CRTSCTS
> nor XON/XOFF appeared to be set. I do not know if that is normal for
> macOS with CDC.
> 
> If anyone is using macOS and is able to send files via Minicom or
> ff-shell.py over USB I would appreciate any pointers as to where I am
> going wrong.
> 
> I've written a small transfer program for my setup, so I can send
> Forth files and am enjoying using FlashForth greatly. However, I am
> new to USB/CDC and would like to know what is wrong with my setup and
> how to fix it (if possible!) so I can use the existing shells.  All
> help gratefully received.
> 
> Thank you!
> 
> Tristan
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] Fwd: Sending Forth files with macOS over USB

[Peter C. H. <pet...@un...>]

CoolTerm (https://freeware.the-meiers.org) has the option to set character and line delays, and has worked well for us to send files.

Peter


> Begin forwarded message:
> 
> From: Grant Olson <kg...@gr...>
> Subject: Re: [Flashforth-devel] Sending Forth files with macOS over USB
> Date: 23 November 2019 at 15:18:49 CET
> To: fla...@li...
> 
> I had the same problem and did this writeup:
> 
> https://www.grant-olson.net/news/2019/09/04/using-minicom-with-flashforth-on-osx.html
> 
> -Grant
> 
> On 11/23/19 7:23 AM, Tristan Williams wrote:
>> Hello,
>> 
>> I am using a PIC18F14K50 with FlashForth 5 connecting over USB on
>> macOS (10.11 & 10.14). I can enter Forth interactively using both Minicom
>> and ff-shell.py. However, with my setup, neither Minicom nor
>> ff-shell.py is able to successfully send a file of forth source. The
>> PIC appears to be overwhelmed by a torrent of Forth. I did wonder
>> whether the PIC was making a value judgement about quality of my code,
>> but think it more likely that my setup has a flow control
>> problem. Both Minicom and ff-shell.py were setup to use CRTSCTS
>> (though changing to XON/XOFF made no difference) which I think is
>> correct for a USB CDC serial connection. Running Minicom and
>> ff-shell.py interactively and checking the USB CDC serial port
>> settings with stty whilst they are running showed that neither CRTSCTS
>> nor XON/XOFF appeared to be set. I do not know if that is normal for
>> macOS with CDC.
>> 
>> If anyone is using macOS and is able to send files via Minicom or
>> ff-shell.py over USB I would appreciate any pointers as to where I am
>> going wrong.
>> 
>> I've written a small transfer program for my setup, so I can send
>> Forth files and am enjoying using FlashForth greatly. However, I am
>> new to USB/CDC and would like to know what is wrong with my setup and
>> how to fix it (if possible!) so I can use the existing shells.  All
>> help gratefully received.
>> 
>> Thank you!
>> 
>> Tristan
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] Sending Forth files with macOS over USB

[Grant O. <kg...@gr...>]

I had the same problem and did this writeup:

https://www.grant-olson.net/news/2019/09/04/using-minicom-with-flashforth-on-osx.html

-Grant

On 11/23/19 7:23 AM, Tristan Williams wrote:
> Hello,
>
> I am using a PIC18F14K50 with FlashForth 5 connecting over USB on
> macOS (10.11 & 10.14). I can enter Forth interactively using both Minicom
> and ff-shell.py. However, with my setup, neither Minicom nor
> ff-shell.py is able to successfully send a file of forth source. The
> PIC appears to be overwhelmed by a torrent of Forth. I did wonder
> whether the PIC was making a value judgement about quality of my code,
> but think it more likely that my setup has a flow control
> problem. Both Minicom and ff-shell.py were setup to use CRTSCTS
> (though changing to XON/XOFF made no difference) which I think is
> correct for a USB CDC serial connection. Running Minicom and
> ff-shell.py interactively and checking the USB CDC serial port
> settings with stty whilst they are running showed that neither CRTSCTS
> nor XON/XOFF appeared to be set. I do not know if that is normal for
> macOS with CDC.
>
> If anyone is using macOS and is able to send files via Minicom or
> ff-shell.py over USB I would appreciate any pointers as to where I am
> going wrong.
>
> I've written a small transfer program for my setup, so I can send
> Forth files and am enjoying using FlashForth greatly. However, I am
> new to USB/CDC and would like to know what is wrong with my setup and
> how to fix it (if possible!) so I can use the existing shells.  All
> help gratefully received.
>
> Thank you!
>
> Tristan
>
>
>
>
>
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

[Flashforth-devel] Sending Forth files with macOS over USB

[Tristan W. <ho...@tj...>]

Hello,

I am using a PIC18F14K50 with FlashForth 5 connecting over USB on
macOS (10.11 & 10.14). I can enter Forth interactively using both Minicom
and ff-shell.py. However, with my setup, neither Minicom nor
ff-shell.py is able to successfully send a file of forth source. The
PIC appears to be overwhelmed by a torrent of Forth. I did wonder
whether the PIC was making a value judgement about quality of my code,
but think it more likely that my setup has a flow control
problem. Both Minicom and ff-shell.py were setup to use CRTSCTS
(though changing to XON/XOFF made no difference) which I think is
correct for a USB CDC serial connection. Running Minicom and
ff-shell.py interactively and checking the USB CDC serial port
settings with stty whilst they are running showed that neither CRTSCTS
nor XON/XOFF appeared to be set. I do not know if that is normal for
macOS with CDC.

If anyone is using macOS and is able to send files via Minicom or
ff-shell.py over USB I would appreciate any pointers as to where I am
going wrong.

I've written a small transfer program for my setup, so I can send
Forth files and am enjoying using FlashForth greatly. However, I am
new to USB/CDC and would like to know what is wrong with my setup and
how to fix it (if possible!) so I can use the existing shells.  All
help gratefully received. 

Thank you!

Tristan

Re: [Flashforth-devel] Larger PIC mcu

[Tristan W. <ho...@tj...>]

Hello Mikael,

Thank you.

Best wishes,
Tristan


On 10Nov19 07:59, Mikael Nordman wrote:
> Hi Tristan,
> 
> I can recommend
> PIC24FJ128GB202
> PIC24FJ64GB202
> PIC18F25K50
> 
> Also older chips like PIC18F2550 works well.
> 
> BR Mikael
> 
> On 2019-11-09 12:23, Tristan Williams wrote:
> > Can anyone recommend a PIC mcu with USB
> > that has more flash + ram and that works well with FlashForth?
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 

Re: [Flashforth-devel] Larger PIC mcu

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

Hi Tristan,

I can recommend
PIC24FJ128GB202
PIC24FJ64GB202
PIC18F25K50

Also older chips like PIC18F2550 works well.

BR Mikael

On 2019-11-09 12:23, Tristan Williams wrote:
> Can anyone recommend a PIC mcu with USB
> that has more flash + ram and that works well with FlashForth?

[Flashforth-devel] Larger PIC mcu

[Tristan W. <ho...@tj...>]

Hello, I am new to FlashForth and the mailing list.

I have FlashForth running on both a PIC24FV16KM202 (over UART) and a
PIC18F14K50 (over USB). Being able to use Forth over USB with a 20 pin
DIP IC is very nice indeed. However, the PIC18F14K50 has 16kB flash
and 512B ram which I am confident is not going to be sufficient for
the project I have in mind. Can anyone recommend a PIC mcu with USB
that has more flash + ram and that works well with FlashForth?

Kind regards,
Tristan

[Flashforth-devel] ff5.0 2019-09-15

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

Hi Mikael,

Bet you thought you were rid of me forever....
I am back to using ff5.0 on PIC18F6527.  Latest ff5.0.zip with a few 
minor edits of my own assembles fine on MPLABX.

Thanks for continuing to support FF.

Pete

Re: [Flashforth-devel] K42 problem

[Attila H. <exp...@vn...>]

Many thanks Mikael!
I will try it as soon as I have some time.

BR   Attila

2019. 09. 10. 19:39 keltezéssel, Mikael Nordman írta:
> Hi all PIC18xx K42/K83 users.
> I finally managed to get the interrupts to work.
>
> After some research and good luck it seems I found an undocumented
> bug in the processor core of those chips.
> By adding a NOP after every POP instruction the interrupts work in 
> stable manner.
>
> I am waiting for Microchip support to acknowledge this.
> But at least FlashForth works now in a stable manner on those chips.
>
> The vectored interrupts are not yet implemented.
>
> BR Mike
>
> On 2019-06-24 23:19, Attila Herman wrote:
>> With the elimination of the interrupt problems, the K42 family could
>> become the best alternative of K22.
>>
>> BR   Attila
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] K42 problem

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

Hi all PIC18xx K42/K83 users.
I finally managed to get the interrupts to work.

After some research and good luck it seems I found an undocumented
bug in the processor core of those chips.
By adding a NOP after every POP instruction the interrupts work in 
stable manner.

I am waiting for Microchip support to acknowledge this.
But at least FlashForth works now in a stable manner on those chips.

The vectored interrupts are not yet implemented.

BR Mike

On 2019-06-24 23:19, Attila Herman wrote:
> With the elimination of the interrupt problems, the K42 family could
> become the best alternative of K22.
> 
> BR   Attila