Shop OBEX P1 Docs P2 Docs Learn Events
Tachyon NEON V5 (FAT32 and Ethernet Servers in 32kB EEPROM!) - Page 13 — Parallax Forums

Tachyon NEON V5 (FAT32 and Ethernet Servers in 32kB EEPROM!)

1101113151625

Comments

  • When I use the ? symbol as a suffix I hope by convention to mostly imply that this returns with a yes/no true/false flag. So LOW? will test a pin and return with a true if high or false if low.

    Shouldn't LOW? return a true if low, and a false if high? Apologies, if that's what you meant :smile:
  • CtlAltDel wrote: »
    When I use the ? symbol as a suffix I hope by convention to mostly imply that this returns with a yes/no true/false flag. So LOW? will test a pin and return with a true if high or false if low.

    Shouldn't LOW? return a true if low, and a false if high? Apologies, if that's what you meant :smile:

    Hmmm.... I forgot that I have only just defined HIGH? and LOW? the other day as part of the counter modes.
    --- measure frequency
    pub FREQ? ( pin -- freq )	B APIN POS EDGE DETECT 99,989 us COUNT@ 10 * ;
    
    --- measure high or low pulse width
    pub HIGH? ( pin -- clks )		WAIT! WAITLO WAITHI WAITLO 1 COG@ 2 COG@ - ;
    pub LOW? ( pin -- clks )		WAIT! WAITHI WAITLO WAITHI 2 COG@ 1 COG@ - ;
    
    Perhaps I should choose better names for these functions but in this case the ? signifies a measurement of some kind.
  • I think the convention of a '?' suffix indicating a binary test is a good one. If the test is to return a number rather than simply true/false, maybe add a '#' e.g. HIGH#?
  • Typically I use a @ which normally returns the contents of a variable so maybe HIGH@ and LOW@ since it also conforms with a source parameter, in this case a pin.
    Same goes for FREQ@ as well.
  • Peter,
    Typically I use a @ which normally returns the contents of a variable so maybe HIGH@ and LOW@ since it also conforms with a source parameter, in this case a pin.
    Same goes for FREQ@ as well.
    For my $0.02 worth, this wouldd be my preference. When do you think we will see these changes in Extend?
    Jim

  • RS_Jim wrote: »
    Peter,
    Typically I use a @ which normally returns the contents of a variable so maybe HIGH@ and LOW@ since it also conforms with a source parameter, in this case a pin.
    Same goes for FREQ@ as well.
    For my $0.02 worth, this wouldd be my preference. When do you think we will see these changes in Extend?
    Jim

    That's already been changed but there have been many times where I am testing out a new function and shortly thereafter I rename and/or redo it. For instance, the DETECT words I initially did a bit differently but decided to lock in a "prefix" to the DETECT sequence with POS and NEG and add in modifiers EDGE and FB since it reads so much better.

  • OK
    I have to re-install Extend on my QS board as I have some how managed to trash it. The clock will load once and display the tine at the start up but no repeats and the color is missing from the post boot Display on the console.
    Jim
  • Peter,
    What are the specific words to load PHSA (PHSB) and FRQA(FRQB) to the counters. I want my rain guage counter for example to increment PHSA by a constant value that allows for reading the output in .01 inch increments of rain without the need for any complicated math, other than decimal place management. Probably will be able to do the same with the wind velocity once the anamometer is calibrated. Is it as simple as PHSA! FRQA! and PHSA@, PHSB@? I will probably be using the EDGE detection feature.
    Jim
  • RS_Jim wrote: »
    Peter,
    What are the specific words to load PHSA (PHSB) and FRQA(FRQB) to the counters. I want my rain guage counter for example to increment PHSA by a constant value that allows for reading the output in .01 inch increments of rain without the need for any complicated math, other than decimal place management. Probably will be able to do the same with the wind velocity once the anamometer is calibrated. Is it as simple as PHSA! FRQA! and PHSA@, PHSB@? I will probably be using the EDGE detection feature.
    Jim

    Just use POS EDGE DETECT to set it up but change the FRQx value directly with FRQ. All the SFRs are named as constants such as PHSA PHSB etc so you just need to use COG@ or COG! instead of @ and ! so it addresses the COG memory.

    Now you may have noticed that I said FRQ and not FRQA or FRQB and that is because there this word is part of the counter words that allow an A or a B counter to be selected and operated with a common set of words rather than duplicating code. So strictly speaking if you want to use both counters you need to select them with an A or a B word as in A POS EDGE DETECT. You can read PHSA and PHSB with this method too with COUNT@ which will read the PHSx counter that has been selected. Both A and B words are simply selectors and don't need to be reselected each time.

    If you are using CTRB and also want to change the FRQx value to 12, just do it like this.
    B POS EDGE DETECT 12 FRQ
    

    BTW, scaled integer maths are easy to do in Forth.
  • Hi all,

    I've knocked together some code to drive a 4-quadrant X/Y piezoelectric scanner. I've checked it with a 'scope and it works, but since I'm a Tachyon noob, I would be interested in comments on how I could make it tidier/more efficient.

    Thanks in advance!
    {
       Generate bipolar raster scan waveforms for a 4-quadrant piezodisk scanner
    
       Waveform outputs are via an LTC2754-16 SPI 4-channel DAC:
    
       DAC A = -X
       DAC B = +X
       DAC C = -Y
       DAC D = +Y
    
       Horizontal (X) waveforms are triangular
    }
    
    --- LTC2754 Commands
    $00300000 := LTC2754_DAC_A
    $00320000 := LTC2754_DAC_B
    $00340000 := LTC2754_DAC_C
    $00360000 := LTC2754_DAC_D
    $00500000 := LTC2754_UPDATE
    
    &13.14.12.11 SPIPINS
    
    --- scan origin
    word xorg
    word yorg
    --- number of scanline points
    word xpts
    word ypts
    --- DAC increments between scanline points
    word xinc
    word yinc
    --- -X,Y scan values: subtract from $FFFF for +X,Y
    word xval
    word yval
    --- xinc gets inverted for reverse slope of triangle, so temp copy is used for scan
    word xinctmp
    --- delay in ms between scan points
    word xypause
    
    : XORG xorg W! ;
    : YORG yorg W! ;
    : XPTS xpts W! ;
    : YPTS ypts W! ;
    : XINC xinc W! ;
    : YINC yinc W! ;
    : XYPAUSE xypause W! ;
    
    --- set scan origin and copy xinc
    : SCANINIT xorg W@ xval W! yorg W@ yval W! xinc W@ xinctmp W! ;
    
    --- Writing to LTC2754 in 24-bit mode, MSB first
    : LTC2754! ( cmd -- ) SPIWR32 DROP 13 HIGH ;
    
    --- calc -X,Y from +X,Y and write all 4 values to the LTC2754
    : XYOUT 
       xval W@ $FFFF xval W@ - yval W@ $FFFF yval W@ -
       LTC2754_DAC_A + LTC2754! 
       LTC2754_DAC_B + LTC2754! 
       LTC2754_DAC_C + LTC2754! 
       LTC2754_DAC_D + LTC2754! 
       LTC2754_UPDATE LTC2754! ;
    
    --- do a single complete scan
    : SCAN 
       SCANINIT 
       ypts W@ 
       FOR 
          xpts W@ 
          --- output X scanline
          FOR XYOUT xinctmp W@ xval W+! xypause W@ ms NEXT 
          --- subtract xinc to get us back to the X val of the end of the scanline, which is the X val for the start of the next one
          xval W@ xinctmp W@ - xval W! 
          --- negate xinctmp for next X scanline
          xinctmp W@ -1 * xinctmp W! 
          --- increment Y
          yinc W@ yval W+! 
       NEXT ;
    
    --- example usage: start at $8000,$8000 (centre of range), 20 points in X and Y (so 400 points total), DAC increments of 1000 counts per point, 1 ms between points 
    $8000 XORG $8000 YORG 20 XPTS 20 YPTS 1000 XINC 1000 YINC 1 XYPAUSE SCAN
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-09-23 00:54
    CtlAltDel wrote: »
    Hi all,

    I've knocked together some code to drive a 4-quadrant X/Y piezoelectric scanner. I've checked it with a 'scope and it works, but since I'm a Tachyon noob, I would be interested in comments on how I could make it tidier/more efficient.

    Thanks in advance!

    Looks good, not much to improve upon but here's my take on it nonetheless and also by using longs we can store and handle signed values more easily. I noticed that you were subtracting values from $FFFF but that would not be the same as negating the value as it would be off by one unless that was your intention.
    TACHYON
    {
       Generate bipolar raster scan waveforms for a 4-quadrant piezodisk scanner
    
       Waveform outputs are via an LTC2754-16 SPI 4-channel DAC:
    
       DAC A = -X
       DAC B = +X
       DAC C = -Y
       DAC D = +Y
    
       Horizontal (X) waveforms are triangular
    }
    
    ( use longs for signed values )
    
    --- scan origin
    long xorg
    long yorg
    --- DAC increments between scanline points
    long xinc
    long yinc
    
    --- -X,Y scan values: subtract from $FFFF for +X,Y
    long xval
    long yval
    --- xinc gets inverted for reverse slope of triangle, so temp copy is used for scan
    long xinctmp
    
    --- number of scanline points
    long xpts
    long ypts
    --- delay in ms between scan points
    long xypause
    
    : XORG 		xorg ! ;
    : YORG 		yorg ! ;
    : XPTS 		xpts ! ;
    : YPTS 		ypts ! ;
    : XINC 		xinc ! ;
    : YINC 		yinc ! ;
    : XYPAUSE 	xypause ! ;
    
    --- LTC2754 DAC        Bipolar –10V to 10V 
    : DAC! ( val chan --  ) $18 OR 17 << SWAP $FFFF AND +
    --- Writing to LTC2754 in 24-bit mode, MSB first with dummy byte for 32-bits
    : LTC2754! ( cmd -- ) 	SPIWR32 DROP SPICE ;
    
    : VAL! ( val chan -- )  OVER NEGATE OVER DAC! 1+ DAC! ;
    
    --- calc -X,Y from +X,Y and write all 4 values to the LTC2754
    : XYOUT   		yval @ VAL! xval @ 2 VAL! $00500000 LTC2754! ;
    
    --- do a single complete scan
    : SCAN
       &13.14.12.11 SPIPINS		--- init SPI pins (works if rebooted)
       xorg xval 12 CMOVE 		--- SCANINIT
       ypts @
       FOR
          xpts @
          --- output X scanline
          FOR XYOUT xinctmp @ xval +! xypause @ us NEXT
          --- subtract xinc to get us back to the X val of the end of the scanline, which is the X val for the start of the next one
          xinctmp @ NEGATE xval +!
          --- negate xinctmp for next X scanline
          xinctmp @ NEGATE xinctmp !
          --- increment Y
          yinc @ yval +!
       NEXT ;
    
    
    ( SHORTCUTS )
    
    : CENTER	-32768[s][/s]
    : XYORG		DUP XORG YORG ;
    : XYINC		DUP XINC YINC ;
    : FINE		20
    : XYPTS 	DUP XPTS YPTS ;
    : FAST		1,0000 XYPAUSE ;
    : SLOW		5,0000 XYPAUSE ;
    
    END
    ?BACKUP
    
    --- example usage: start at $8000,$8000 (centre of range), 20 points in X and Y (so 400 points total), DAC increments of 1000 counts per point, 1 ms between points
    \ $8000 XORG $8000 YORG 20 XPTS 20 YPTS 1000 XINC 1000 YINC 1,000 XYPAUSE SCAN
    
    CENTER FINE 1000 XYINC FAST SCAN
    
    EDIT: I was really tired last night and made some mistakes so I've fixed them up now.
    So now after breakfast I wrote a specialized LTC2754 module that simplifies the code so that XYOUT now takes 53.6us. It also auto-updates after you write to the last channel.
  • Thanks very much for that Peter, that's a lot more readable. Calculating the DAC words cleans the code up nicely, and the block copy to initialise variables for SCANINIT is a good idea too.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-09-23 01:21
    CtlAltDel wrote: »
    Thanks very much for that Peter, that's a lot more readable. Calculating the DAC words cleans the code up nicely, and the block copy to initialise variables for SCANINIT is a good idea too.

    Thanks, this is the other one where I have updated the kernel with an LTC2754 module that is twice as fast. Untested and certainly some bugs but basically ok.
    TACHYON
    {
       Generate bipolar raster scan waveforms for a 4-quadrant piezodisk scanner
    
       Waveform outputs are via an LTC2754-16 SPI 4-channel DAC:
    
       DAC A = -X
       DAC B = +X
       DAC C = -Y
       DAC D = +Y
    
       Horizontal (X) waveforms are triangular
    
       -2 version uses LTC2754 runmod and executes XYOUT in 53.6us
    }
    
    ( use longs for signed values )
    
    --- scan origin
    long xorg
    long yorg
    --- DAC increments between scanline points
    long xinc
    long yinc
    
    --- -X,Y scan values: subtract from $FFFF for +X,Y
    long xval
    long yval
    --- xinc gets inverted for reverse slope of triangle, so temp copy is used for scan
    long xinctmp
    
    --- number of scanline points
    long xpts
    long ypts
    --- delay in ms between scan points
    long xypause
    
    : XORG 		xorg ! ;
    : YORG 		yorg ! ;
    : XPTS 		xpts ! ;
    : YPTS 		ypts ! ;
    : XINC 		xinc ! ;
    : YINC 		yinc ! ;
    : XYPAUSE 	xypause ! ;
    
    
    : VAL! ( val chan -- )  OVER NEGATE OVER RUNMOD 1+ RUNMOD ;
    --- calc -X,Y from +X,Y and write all 4 values to the LTC2754 - 53.6us
    : XYOUT   		yval @ 0 VAL! xval @ 2 VAL! ;
    
    --- do a single complete scan
    : SCAN
       &13.14.12.11 MODPINS [LTC2754]		--- init LTC2754 MODULE
    
       xorg xval 12 CMOVE 		--- SCANINIT
       ypts @
       FOR
          xpts @
          --- output X scanline
          FOR XYOUT xinctmp @ xval +! xypause @ us NEXT
          --- subtract xinc to get us back to the X val of the end of the scanline, which is the X val for the start of the next one
          xinctmp @ NEGATE xval +!
          --- negate xinctmp for next X scanline
          xinctmp @ NEGATE xinctmp !
          --- increment Y
          yinc @ yval +!
       NEXT ;
    
    
    ( SHORTCUTS )
    
    : CENTER	-32768
    : XYORG		DUP XORG YORG ;
    : XYINC		DUP XINC YINC ;
    : FINE		20
    : XYPTS 	DUP XPTS YPTS ;
    : FAST		1,0000 XYPAUSE ;
    : SLOW		5,0000 XYPAUSE ;
    
    END
    ?BACKUP
    
    --- example usage: start at $8000,$8000 (centre of range), 20 points in X and Y (so 400 points total), DAC increments of 1000 counts per point, 1 ms between points
    \ $8000 XORG $8000 YORG 20 XPTS 20 YPTS 1000 XINC 1000 YINC 1,000 XYPAUSE SCAN
    
    CENTER FINE 1000 XYINC FAST SCAN
    
  • Hi Peter,

    I have got the first version going (LAP XYOUT LAP .LAP = 90.4 us at 100 MHz)

    I'm having problems with the 2nd version that uses the new module - beyond the CE line going high, I can't see any further SPI bus activity on the scope.

    If I put XYOUT into an infinite loop (BEGIN XYOUT 1 ms AGAIN) and probe the SPI lines, there's nothing going on. XYOUT with RUNMOD is taking 42.88 us at 100 MHz.

    I'm a pasm noob too, but I've written assembler on other architectures and I can follow the source of the module, makes sense so far. Even if it has bugs though, I would have expected to see, for example, the CE line going up and down.

    Any ideas?
  • Great that you tried it. I see the problem with the runmod, it is referring to the standard SPI masks, not the runmod masks. Easy way around it is to use SPIPINS but I will fix it up in the meantime and test it out.
  • Well, it would have been rude not to try it after you went to the trouble of writing it :smile: And it's a >50% performance improvement, which is a big win.

    SPIPINS did the trick. Could you explain SPIPINS vs MODPINS?
  • MJBMJB Posts: 1,235
    CtlAltDel wrote: »
    Well, it would have been rude not to try it after you went to the trouble of writing it :smile: And it's a >50% performance improvement, which is a big win.

    SPIPINS did the trick. Could you explain SPIPINS vs MODPINS?


    from EXTEND.fth
    
    1		== @SCK
    @SCK 1 +	== @MOSI
    @SCK 2 +	== @MISO
    @SCK 3 +	== @CE
    @SCK 4 +	== @CNT
    
    15		== @SCL
    10		== @SPISCK
    
    
    \ pri MASK? ( n -- mask )		>B DUP 32 U< IF MASK ELSE DROP 0 THEN ;
    \ pri MASK? ( n -- mask )		>B DUP 5 >> IF DROP 0 ELSE MASK THEN ;
    
    --- Set the SPI pins using a long as 4 octets = &ce.miso.mosi.clk  as this allows passing a single long
    pub SPIPINS ( &ce.miso.mosi.clk --- )  ( 20us )
     	@SPISCK
    pub SETPINS ( &pins dst -- )  ( ~190us)
      	1!
    	DUP MASK L 1@ COG! 8>> 1++
    	DUP MASK L 1@ COG! 8>> 1++
    	DUP MASK F 1@ COG! 8>> 1++
    	MASK H 1@ COG!
    	;
    
    pub MODPINS  	@SCK SETPINS ;
    
    
    
    there are two sets of SPI pin descriptions one for the internal SPI functions and a separate one for the runm@sckam Internal is at COG address 1 = @SCK other is at COG address 10 = @SPISCK
    So
    SPIPINS is really @SPISCK SETPINS
    MODPINS @SCK SETPINS

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-09-23 11:35
    SPIPINS & MODPINS both call SETPINS but with different destination mask addresses. So MODPINS is for the RUNMODs and SPIPINS for the SPI instructions. I have code that uses both at the same time. What I'd like to do is find an easy way to add modules, even if we do compile with the Prop tool, much like I create the ROMs too. Ideally I'd have an inline assembler in Tachyon and although I have tackled this method before it doesn't seem practical to tie up all that memory just for an assembler as it needs even more dictionary and symbol memory than code memory just to support the assembler itself. The whole reason for Tachyon is to provide the on-chip support infrastructure and resources for applications, so it's usually a good idea to have some memory left over :)

    EDIT: I see that there is a command 9 that writes DACn and updates all so that could be used in place of a separate command to update. I've updated the kernel accordingly, I will check the timing now.

    BTW, I would have written it anyway just for the exercise but I'm not used to anyone actually trying it!

    OK - Just tested it. Looks good with using a cmd 9 for channel 3 to update all at the same time. Saves one more write operation.
    LTC2754.jpg
  • Beautiful, Peter! XYOUT now runs in 35 us at 100 MHz. There is a beer (or ten) waiting for you if you ever make it out to Christchurch :smile:
    BTW, I would have written it anyway just for the exercise but I'm not used to anyone actually trying it!

    Well, Tachyon isn't just an intellectual curiosity for me - it's an integral part of my project (a homebrew scanning tunnelling microscope).

    Tachyon will extend the useful life of the Prop 1 for many years, I think.
  • ErNaErNa Posts: 1,738
    Hello Peter, moving from V4 to V5 we ran into problems using the UART. The word .UART prints the uart settings to console and uses the word X1. This word was defined in EXTEND of V4 and is no longer available in EXTEND of V5.
  • ErNa wrote: »
    Hello Peter, moving from V4 to V5 we ran into problems using the UART. The word .UART prints the uart settings to console and uses the word X1. This word was defined in EXTEND of V4 and is no longer available in EXTEND of V5.

    Looks like that may have been deprecated in 4.7 even but seems this is the section?
    PRIVATE
    16 longs locals
    locals 4 +	== @x2
    locals 8 +	== @x3
    locals 12 +	== @x4
    
    pri @X		4* locals + ;
    pub X1		locals @ ;
    pub X2		@x2 @ ;
    pub X3		@x3 @ ;
    pub X4		@x4 @ ;
    
    --- pop the n top stack elements to the local space, TOS => X1, TOS+1 => X2 ..
    pub LOCAL ( <data> n --  )
    	DUP 4* ( <data> n bytes )
    	locals 2DUP + ROT <CMOVE
    	FOR I @X ! NEXT
    	;
    
    --- pop and release emove n elements from locals, of no longer used )
    pub RELEASE ( n -- )		DUP @X locals ROT 4* $40 SWAP - CMOVE ;
    

    You could just paste it in with the slight change of == to := but I never really used locals like this so I think you shouldn't really need it.
  • MJBMJB Posts: 1,235
    ErNa wrote: »
    Hello Peter, moving from V4 to V5 we ran into problems using the UART. The word .UART prints the uart settings to console and uses the word X1. This word was defined in EXTEND of V4 and is no longer available in EXTEND of V5.

    Hi Werner
    this ode I find in EXTEND (as comment)
    It implements a stack of local variables which sometimes come convenient, but not really necessary.
    If you need it, just cut & paste it.
    btw. I could not find .UART
    From which file did you load it?
    Probably you can just modify .UART to do without the X1.. local variables
    {
    PRIVATE
    16 longs locals
    locals 4 +	== @x2
    locals 8 +	== @x3
    locals 12 +	== @x4
    
    pri @X		4* locals + ;
    pub X1		locals @ ;
    pub X2		@x2 @ ;
    pub X3		@x3 @ ;
    pub X4		@x4 @ ;
    
    --- pop the n top stack elements to the local space, TOS => X1, TOS+1 => X2 ..
    pub LOCAL ( <data> n --  )
    	DUP 4* ( <data> n bytes )
    	locals 2DUP + ROT <CMOVE
    	FOR I @X ! NEXT
    	;
    
    --- pop and release emove n elements from locals, of no longer used )
    pub RELEASE ( n -- )		DUP @X locals ROT 4* $40 SWAP - CMOVE ;
    \ locals $40 ERASE			\ Clean out the locals (easier for debugging)
    
    }
    
  • ErNaErNa Posts: 1,738
    edited 2018-09-25 13:38
    the problem morphed a little. We wanted to have .UART1 to see the pointers of the communication buffer between Tachyon and the assembler UART-COG. Since 4.5 ROMS has changed as the code was in the kernel, now there is a separate SPIN-ASM file, which is compiled and the binary is converted to INTEL HEX with help of "bin2hex.py", (for convenience renamed to bh.py by pj) We use the SAVEROM word to place the hex into memory (Start Address $C01C, 468 Bytes). Next we start a COG:
    uart1 6 " UART " LOADCOG
    We can not check, if this was successful. A communication is not possible, when we output to the UART: UART> ." 8charact" the sendbufferpointer show 7, but the uart pointer stays at 0, so obviosly the uart doesn't work properly.
    Is there an easy way to dump eeprom to check, if the ROM code is stores properly?

    Symptoms: we remember, that LOADCOG answered with address values. Now we only get an "ok". Making some experiments with misspelled roms names also resulted in LOADCOG ok, and no other output.
    It looks as if the ROM is not found by FINDROM as in the LOADCOGS word OVER .W DUP .W should print addresses!
  • MJBMJB Posts: 1,235
    edited 2018-09-25 20:26
    double deleted
  • MJBMJB Posts: 1,235
    ErNa wrote: »
    Is there an easy way to dump eeprom to check, if the ROM code is stores properly?

    sure
    --- Select EEPROM device for DUMP command access
    --- Usage: 0 $100 EE DUMP
    pub EE		DUMP: EC@ EW@ E@ ;
    
    
    
  • LOADROM is insensitive to line endings etc, it just looks for the : that marks a hex line and continues until it reaches the last line which has the hex end of load command and count of zero (iirc). In that case it reports the size of the load. You still need some kind of line delay and the line delay depends upon whether it sees an end of line, usually a CR so make sure that is happening. I will see under what conditions i can make it fail.
    Btw, EE modifies the dump word temporarily to use eeprom after which it reverts back to hub ram. But all the dump words such as DUMPW DUMPL DUMPA DUMPAW DUMPC etc use the selected memory method. Other dump memory modifiers are RTC, SD, FS, SF, WIZ etc
  • ErNaErNa Posts: 1,738
    We found, that the glossary showed the old stack usage of LOADCOG, while the source and examples are correct. Changed glossary:

    LOADCOG ( name pars cog pars name -- ) Load cog with ROM if found (ex: " VGA32x15" 3 vgapars 3 " VGA32x15" LOADCOG)

  • ErNaErNa Posts: 1,738
    edited 2018-09-26 20:44
    Using the correct stack values to start a cog, the LOADCOG seems to work, as the FINDROM dumps address values.
    We start the cog with the UART.
    " UART       " 4 uart1 LOADCOG
    
    We get the right start address and length reported.
    If we change the write pointer value, the expectation is that the UART follows with the read pointer, what doesn't happen.
    So our impression is that the parameters are not transfered to the UART correctly, so the UART doesn't see the write pointer.

    In a next step we made a simple pin toggle program as ROM without parameters. This program, when loaded with a spin frame stand alone was functional. But the ASM part as ROM loaded by LOADCOG didn't work. LOADCOG showed name and addresses correctly (plausible) and even the cog# as an response on cognew was correct.

    If I only had time... as Tachyon is so powerfull and I only have a little glue, going down from a LOADCOG needed to extent to kernel I end up to see LMM which I should have analyzed for years.... It definitely is a pity, that FORTH is not the first choice when learning to program. The world would become more simple and even a low grader could gain success. ;-(

    There is one sympton: at reboot EASYNET is started and running. The STACK ends up in Level 2: .S Data Stack (2) $0000.51DA - 20954 $0000.51CE - 20942 ok.
    I had expected the stack to be empty.
  • @ErNa - I will have a look today to see what's happening but it would be a lot easier if you could at least send me a copy of your code and at the very least I should be able to get it going and perhaps offer a pointers. Most of the problems in learning something "different", is well, because it is different and thinking in one while trying to do in the other does not work as well.

    Forth is very "unstructured" but flexible and extensible and it is up to the user to define the structure they need for that application. The trouble is that many try to "program" without thinking about and creating a structure to build on, and it looks a mess and can easily crumble into one big mess. Once the structure is in place such as thinking about the "division of labor" and how they work in together then each section can be clearly seen, coded, and tested. So even though we might code bottom up we still do so with a top down view in mind.
  • ErNaErNa Posts: 1,738
    Thanks Peter, we will drill down a little more, I will check this stack level behavior, as I think, after booting the system the stack level should be 0. Maybe the problem finds the roots there. In V4 we had this running but as some forumistas now engage in V5 and as P2 is near, I believe V5 will be final, become stable and still it is the cheapest way to start with learning forth and so documentation will be made. That allows for a less steep learning curve.
Sign In or Register to comment.