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