[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...