Downloaded from dropbox today, and loaded spin with 115200 baud. try'd to load EXTEND.FTH on a Propeller Platform with 32kb eeprom. I use'd GtkTerm with 10ms. delay line.
I normally use minicom since it allows me to run at much higher speeds and is also more configurable than gtkterm. However I loaded a kernel set for 115200 baud, loaded up gtkterm, set the line delay to 10ms, and sent a raw file. The result?
The date I have for my EXTEND.FTH is Sun 11 Jun 2017 14:08:43 AEST but just so you are synchd I have just made some mods to some other part of it to save some memory otherwise it is identical so the new one has this header:
Thank you, after a new download from dropbox, I loaded the spin kernel, and subsequent I sent EXTEND.FTH I even try'd with 50ms delay.
But after a reset I only get garbage!
Propeller .:.:--TACHYON--:.:. Forth V4.4 DAWN 440170610.0600
Cold start - no user code - setting defaults
--------------------------------------------------------------------------------
( 0001 $1B00 ok ) TACHYON V4
Propeller .:.:--TACHYON--:.:. Forth V4.4 DAWN 440170610.0600
( 0009 $3462 ok ) ENDGET SAVEROMS--------------------------------------------
End of source code, 0000 errors found Load time = 0 cycles at 80MHz = 0.000us
Code bytes used = 6498
CODE:$3462 =12898 bytes NAME:$5AE0 =6432 bytes DATA:$76E8 =216 bytes =9854 bytes free Data Stack (0)
( 0010 $3462 ok )
( 0011 $3462 ok ) AUTORUN BOOT
( 0012 $3462 ok )
( 0013 $3462 ok ) ?BACKUP
FAIL @7380|
( 0014 $3462 ok )
( 0015 $3462 ok ) BOOT
MODULES LOADED:
1B00: EXTEND.fth Primary extensions to TACHYON V4.4 kernel - 170611-0000
AUTORUN BOOT
FREQ = 80.0MHz
*** INITS ***
NO ROMS
*** I2C ***
A0 EEPROM
PPNET: &00.00.00.00 @2,000,000
CODE:$3462 =12898 bytes NAME:$5AE0 =6432 bytes DATA:$76E8 =216 bytes =9854 bytes free Data Stack (1)
$0000.76D8 - 30424
( 0016 $3462 ok )
( 0017 $3462 ok ) }
( 0018 $3462 ok )
( 0019 $3462 ok )
after reset I get this
�����������`
�������������������`
�����������`
�������������������?���f<����f<?�������������`3�0����������憘��������x0��?`?���x3`��`�`00~3�������`
�����������`
������������������`
�����������`
������������������`
�����������`
�������������������?���f<����f<?�������������`300����������憘��������x0��?`?���x3`��`�`00~3�������`
�����������`
������������������`
�����������`
������������������`
�����������`
�������������������?���f<����f<?�������������`300����������憘��������x0��?`?���x�`�`�`00~3�������`
�����������`
������������������`
�����������`
������������������`
�����������`
�������������������?���f<����f<?�������������`300����������憘��������x0��?`?���x3`��`�`00~3�������`
�����������`
������������������`
�����������`
������������������`
�����������`
�������������������?���f<����f<?�������������`300����������憘��������x0��?`?���x3`��`�`00~3�������`
�����������`
������������������`
�����������`
������������������`
�����������`
�������������������?���f<����f<?�������������`300����������憘��������x0��?`?���x3`��`�`00~3�������`
�����������`
������������������`
Yet another GG this time with 64kb and her we go.
Thank you.
I've been having a few boards that don't seem to load the ROMS as I noticed the same with yours. I suspected a rather fast clock pulse was the problem so I inserted a NOP in there and now the board works. Perhaps that was the reason for the failure to program the EEPROM properly before? Try the latest EXTEND which has that extra nop in there
pub I2C!? ( data -- flg )
#24 REV
--- data masks
*SDA DUP HIGH MASK SWAP
8 FOR SHROUT CLOCK NOP CLOCK NEXT
DROP DUP INPUTS --- Float SDA
CLOCK IN 0<> CLOCK --- ack clock
;
caskaz
Looking at your code there are a lot of very inefficient methods there and there also seems to be unnecessary delays, for instance:
: lcd_enable data_h #500 us data_l #500 us ;
An LCD display only needs somethings like a 1us enable pulse yet you have 1ms total on top of all the other methods for each and every byte and command that is written to the display. The other thing is the shifting method used which takes around 50us and is fine for simple interfaces but if you are writing a lot of data you would want to use the SPI instructions which zip the data across to the shift register in around 1us.
I can give you an optimized version if you like based on your file which you can use as a guide or we could go through the code bit by bit starting with removing these unnecessary delays, then implementing SPI operations.
caskaz, btw, I do remember interfacing an LCD via a 164 shift register a long time ago except what I did was use the clock and data from the I2C lines and so all I needed was a single I/O line as the enable. An arrangement like this is a lot more efficient. Is there a reason for the double npn arrangement?
This curcuit made several years ago.
Because I had many NPN Transistor.
I had no PNP Transistor.
Yes, what I meant was why not a single npn and simply invert it in software?
However if you connected clk and data to the I2C bus, then used one I/O as the enable and perhaps another simply as the backlight control you could access the LCD in a much more efficient manner. A simple write of 4-bit data and RS twice with short enable pulses after each transfer could be effected in less than 10us and no real modifications to your circuit would be required, just rerouting. Also no need to clear it (although I'm a bit confused about the need for that anyway). As we say, food for thought.
Hi Peter.
If PNP-Tr is used, it's simple like atacched curcuit.
When QH is low, LCDbacklight is on.
If logic change(QH-Hi ->backligh-on), backlight blink during transfering data to shift-register.
caskaz - besides clocking this register from the I2C lines and using a separate E and backlight line, you could also even leave everything intact with the backlight and E as is, connect clk and data to I2C and simply connect the CLR pin of the 164 to a I/O. When you are not actively clocking data in you would hold the CLR low thus preventing any chatter on the I2C lines from affecting the display. When you want to transmit data you release the CLR line knowing that the register is all zeros and then send your first nibble with enable, clear again, then send second nibble with enable, then leave with CLR active. This takes one less I/O than you are already using.
btw, here's I would translate the x y cursor for the display using a simple lookup table.
--- translate xx 1 2 3 4 ( add DDRAM command minus one for 1,1 offset)
TABLE ycur 0 | 0+$7F | 64+$7F | 20+$7F | 84+$7F |
--- position using 1,1 as home
: lcdxy ( x y -- ) ycur + C@ + lcd_com ;
vs the old code
: lcd_pos
2 U/MOD SWAP 0=
IF
1 =
IF $40 ELSE $50 ENDIF \ Line is 2 or 4
ELSE
0=
IF 0 ELSE $10 ENDIF \ Line is 1 or 3
ENDIF
1- +
$80 OR lcd_com \ Add DDRAM Addr command
;
I try to translate switch-code.
Trying to load file, error occur.
But I cannot understand where errors occur.
TACHYON V4
IFDEF sw_1.fth
@rest org
FORGET sw_1.fth
}
pub sw_1.fth ." switch 2017/06/12 22:34:11 " ;
@org W@ == @rest --- remember
{
2017/06/12 11:40:54
3V3
|
10kohm
|
P0 -------|
|
sw
|
GND
|\|
P1 ----| | ----220ohm---GND
|/|
LED
}
\ ===========================================================================
\ Constants
\ ===========================================================================
#P0 == swpin
#P1 == ledpin
#4000000 == 50msec
swpin MASK == swMask
ledpin MASK == ledMask
\ ===========================================================================
\ Variables
\ ===========================================================================
word swState
word debounce
word lastswState
long lastDebounceTime
word alternate
\ ===========================================================================
\ Main
\ ===========================================================================
\ read current sw-state
\ ( -- n1 ) n1:1[sw:off] 0[sw:on]
: rd_sw ina COG@ swMask and ;
: init
\ Set initial values
1 swState W!
0 lastDebounceTime !
1 lastswState W!
0 debounce W!
ledMask dira COG@ OR dira COG! \ Set led to uutput
;
\ On/Off switch
\ LED on when pushed sw, LED off when release sw
\ ( -- )
: sw1
init
BEGIN
\ Read current sw and check if pushed or released
rd_sw DUP lastswState W@ <>
IF
\ If sw is under debouncong
debounce W@ 0=
IF
cnt COG@ lastDebounceTime !
1 debounce W!
ENDIF
ELSE
0 debounce W!
ENDIF
debounce W@
IF
cnt COG@ lastDebounceTime @ - 50msec >
IF
\ Update current swState and lastswState
DUP
swState W! lastswState W!
ELSE
DROP
ENDIF
ELSE
DROP
ENDIF
\ Activate LED when sw-on
outa COG@ ledMask
swState W@
IF INVERT AND ELSE OR ENDIF
outa COG!
0
\ fkey? swap drop
UNTIL
;
END
\ ?BACKUP
error below;
( 0001 $33B0 ok ) cnt COG@ .
1795087403
( 0002 $33B0 ok ) TACHYON V4
Propeller .:.:--TACHYON--:.:. Forth V幹幹幹 幹40170522.0000
( 0044 $33DA ok ) ??? in 幹幹 玩t ina
??? in 幹幹 玩t and
( 0052 $33E0 ?? ) ??? in 幹幹 at dira
??? in 幹幹 at dira
??? in 幹 玩t init
( 0061 $3402 ?? ) ??? in 幹 at rd_sw
( 0066 $3402 ?? ) ??? in
幹 at cnt
( 0068 $3402 ?? ) Structure mismatch! *error*
( 0001 $3402 ok ) -----------------------------------------------------------
Table is nothing more than a code variable where you can store information which you normally see allocated using C, or , etc. The C, may be the correct byte version of , but it looks messy and obfuscates the data itself, so I prefer to use a single vertical | character to separate the values and if correctly spaced gives the appearance of a table.
You can create a simple table in data memory by saying "5 bytes ycur" but then you would have to store values in there and then have it backed up in EEPROM. The TABLE word does what it says and calling it returns the address of the first element from where we can index.
Now all we need to store in there are the character LCD controller values we need to address each line, they are 0, 64, 20, and 84. However we also need to $80 OR and also subtract 1 for the X parameter since it is offset from zero by one (1,1 vs 0,0 use). So why not add $80-1 to the value in the table and come up with the right value immediately?
frida - this is just a simple test to check for device memory size which relies on mirroring to reveal if it is only 32kB as larger EEPROMs have the same device address as smaller ones. If it is mirrored then all that needs to be recorded at that point is the page size which helps us program larger EEPROMs faster. Later on when we need to check if the EEPROM is only 32kB or not we only need to look at the "ep" constant. While location 0 does contain the information concerning the clock frequency this does not matter as a BACKUP will restore that value from RAM anyway plus Tachyon uses the constant CLKFREQ rather than reading location 0. The main reason for not using location 0 is that this is one location that ends up with garbage when there's a bug and a function returns with a false which is a zero rather than an address and this is not checked.
There is no real need to replace the EEPROM unless you need the extra memory or also need to use the ROMS such as the high-speed UART, or F32, VGA, or others. These ROMs are binary images that are optionally loaded into cogs at runtime and originate from the Tachyon compiled source that is first loaded with the Prop tool. Although they consume hub memory they end up being moved into upper EEPROM if it is available when EXTEND is loaded. Thereafter they can be loaded by name as required from upper EEPROM into Tachyon's BUFFER area and then into the target cog using this format:
<partbl> <cog#> " HSUART " LOADCOG
Upper EEPROM is also used for the dictionary whenever COMPACT is loaded and run which is normally the case for large applications that also require EASYFILE file system and possibly EASYNET Ethernet servers etc.
caskaz - you've reminded me to fix something up - the fact that a long is not always a long as sometimes it is non-aligned. This wasn't a bug because of the way I might have to create structures but I find it too much of a nuisance so I will fix it up. In the meantime just define a long as "1 longs xxx" as that does align itself. On that note you will find it best not to intermix bytes/words/longs unless you are not worried about losing some memory due to alignments. btw, you can define byte variables as well.
Comments
I normally use minicom since it allows me to run at much higher speeds and is also more configurable than gtkterm. However I loaded a kernel set for 115200 baud, loaded up gtkterm, set the line delay to 10ms, and sent a raw file. The result?
The date I have for my EXTEND.FTH is Sun 11 Jun 2017 14:08:43 AEST but just so you are synchd I have just made some mods to some other part of it to save some memory otherwise it is identical so the new one has this header:
But after a reset I only get garbage!
I will try another, and come back.
with 32kb eeprom.
edit:
Another GG board and still the same.
Thank you.
I've been having a few boards that don't seem to load the ROMS as I noticed the same with yours. I suspected a rather fast clock pulse was the problem so I inserted a NOP in there and now the board works. Perhaps that was the reason for the failure to program the EEPROM properly before? Try the latest EXTEND which has that extra nop in there
Say it with me D.P 0 is always false any non-zero is true.
SanDisk ultra (red) 16GB vs 4GB no name (worked with V3)
does not lok like a timing problem to me so far ...
some more: - after a full reformat and nothing else - plus reboot of the prop
I still see this TESTXX.TXT on the card
Translated 2wire-charLCD to Tachyon.
But WAVE take about 14sec.
In case of PropForth it takes 1800msec.
Maybe I think because it use assembler word.
How to make assembler-word by Tachyon?
Looking at your code there are a lot of very inefficient methods there and there also seems to be unnecessary delays, for instance: An LCD display only needs somethings like a 1us enable pulse yet you have 1ms total on top of all the other methods for each and every byte and command that is written to the display. The other thing is the shifting method used which takes around 50us and is fine for simple interfaces but if you are writing a lot of data you would want to use the SPI instructions which zip the data across to the shift register in around 1us.
I can give you an optimized version if you like based on your file which you can use as a guide or we could go through the code bit by bit starting with removing these unnecessary delays, then implementing SPI operations.
I changed lcd_enable below; [1 DROP] takes 2usec.
Wave takes 1.944sec.
That's a bit of a start I suppose, I've found quite a few other things too but I will have to get back to you later on that.
Well done with grappling with the nuances of Tachyon Forth!
Btw, if you already have a non-zero flag, then it's true, no need for this then: Just say:
This curcuit made several years ago.
Because I had many NPN Transistor.
I had no PNP Transistor.
Yes, what I meant was why not a single npn and simply invert it in software?
However if you connected clk and data to the I2C bus, then used one I/O as the enable and perhaps another simply as the backlight control you could access the LCD in a much more efficient manner. A simple write of 4-bit data and RS twice with short enable pulses after each transfer could be effected in less than 10us and no real modifications to your circuit would be required, just rerouting. Also no need to clear it (although I'm a bit confused about the need for that anyway). As we say, food for thought.
If PNP-Tr is used, it's simple like atacched curcuit.
When QH is low, LCDbacklight is on.
If logic change(QH-Hi ->backligh-on), backlight blink during transfering data to shift-register.
btw, here's I would translate the x y cursor for the display using a simple lookup table.
vs the old code
I cannot understan about TABLE.
y=4 -> 84+$7F <-- What mean this?
When loded , error[???] occur.
Where is reference of TABLE?
I try to translate switch-code.
Trying to load file, error occur.
But I cannot understand where errors occur.
error below;
You can create a simple table in data memory by saying "5 bytes ycur" but then you would have to store values in there and then have it backed up in EEPROM. The TABLE word does what it says and calling it returns the address of the first element from where we can index.
Now all we need to store in there are the character LCD controller values we need to address each line, they are 0, 64, 20, and 84. However we also need to $80 OR and also subtract 1 for the X parameter since it is offset from zero by one (1,1 vs 0,0 use). So why not add $80-1 to the value in the table and come up with the right value immediately?
So, I want to check TABLE ycur.
But cannot load.
I think I understand all.
Hmm, TABLE is useful.
6/13
Changed lcd_pos to Using TABLE.
Occupied memory reduced(-24bytes).
WAVE-time reduced a little (1.944sec -> 1.938sec).
According the datasheet for 24LC256 the address space is mirror'd.
From $0000 to $7FFF and again
from $8000 to $FFFF because bit 15 is dont care.
So from EXTEND.FTH line 1132: you are writting a long to $8000, but it is written to $ 0000 instead of.
I trye'd 64 == ep instead of, but it still fails.
Do I need to replace 24LC256 with a 512kb type?
There is no real need to replace the EEPROM unless you need the extra memory or also need to use the ROMS such as the high-speed UART, or F32, VGA, or others. These ROMs are binary images that are optionally loaded into cogs at runtime and originate from the Tachyon compiled source that is first loaded with the Prop tool. Although they consume hub memory they end up being moved into upper EEPROM if it is available when EXTEND is loaded. Thereafter they can be loaded by name as required from upper EEPROM into Tachyon's BUFFER area and then into the target cog using this format: Upper EEPROM is also used for the dictionary whenever COMPACT is loaded and run which is normally the case for large applications that also require EASYFILE file system and possibly EASYNET Ethernet servers etc.
I have many questions when writing Tachyon code.
I translated sw to Tachyon.
1st question
I can't find out Tachyon code same as PropForth's [fkey? swap drop].
Now sw is inifinity loop.
How does code write?
2nd question
Atached sw code; Although executed [0 lastDebounceTime !] in 'init', Why lastDebounceTime is 0?
3rd question
I try to change word to byte. Why is swState 0?
Why is lastDebounceTime 65536?
I attached file.
After executing init1 on attached code above, word-variable is re-written on data-DUMP
I have any misunderstanding?
I don't think it's bug.
I think It's specification.
I remain PropForth habit.
Btw how does [fkey? swat drop] write on Tachyon?
I want to break [BEGIN-UNTIL]loop by hitting any key.