Tachyon cog registers used to be in the second 256 longs of a cog in V3 and used COGREG to address them but with V4 I could place them right at the start after the first jump instruction so that they were in a fixed spot starting from address 1 so that therefore they really didn't need a special COGREG instruction.
Location 16 is the clock delay used by CLKOUT, CLKIN, and CLOCK which are called by the I2C routines. Setting it to zero means no delay at all but the value is the number of cycles of "djnz X,$" that it will delay for on "one half of the clock pulse". 320 would result in 320x50ns @80MHz which would be 16us extra per half-cycle which is way too slow taking into account other overheads. A 100kHz I2C bus has 5us clock high time so the clock delay would be the extra time necessary to slow it down to that speed. I will hook up a scope and check my value for 100kHz shortly.
EDIT: I2C100 has been amended to
pub I2C100 CLKMHZ ~D ;
which produces a nice 100kHz signal. That's a value of 80 for an 80MHz system.
TACHYON.SPIN Line 5576
org 0
RESET jmp #InitIP
' 170307 V4.2 Moved all "COGREGs" to fixed locations - removed COGREG reference and index from 1 onwards
' COGREG - Registers used by PASM modules to hold parameters such as I/O masks and bit counts etc
'COGREGS
REG1 long 0
REG2 long 0
REG3 long 0
REG4 long 0
'AREG
REG5 long 0 ' CLOCK mask
' REG6
txticks long (sysfreq / baud ) ' set transmit baud rate
txmask long |<txd ' change mask to reassign transmit
' REG8 = TASK REGISTER POINTER
regptr long registers ' used by REG
unext long doNEXT ' could redirect code if used
' REG10
' SPIPINS - pin masks for SPI operations
spisck long 0 ' I/O mask for SPI clock
spiout long 0 ' I/O mask for SPI data out (MOSI)
spiinp long 0 ' I/O mask for SPI data in (MISO)
spice long 0 ' I/O mask for SPI CE (not really required unless we use CE instr)
spicnt long 0 ' bit count for variable size Kernel SPI
' REG15
clockpins long 0 ' I/O mask for CLOCK instruction
clkdly long 0
' I2C support
' CLKOUT ( iomask dat -- iomask dat2 ) REG6=iomask ) Shift msb bit out, clock high, clock low
CLKOUT andn OUTA,tos+1 ' ensure output will be active low
andn OUTA,clockpins
shl tos,#1 wc
muxnc DIRA,tos+1 ' make it an output if it is a low else float
' CLOCK ( REG6=iomask ) Toggle multiple bits on the output)
CLOCK xor OUTA,clockpins
tjz clkdly,unext
mov X,clkdly
djnz X,$
jmp unext
' CLKOUT ( iomask dat -- iomask dat2 ) REG6=iomask ) Shift msb bit out, clock high, clock low
CLKIN andn DIRA,tos+1
test tos+1,INA wc
rcl tos,#1
jmp #CLOCK
pub SAVEROMS
ep 64 > 0EXIT
\ " ROMS" U@ roms E@ <> 0EXIT
\ roms $1F00 $FF EFILL
--- search for ROMS string between end of kernel at TACHYON and start of dictionary
" ROMS" U@
' TACHYON 6000 + 3 ANDN ROM ( src )
@NAMES 3 ANDN OVER - 2/ 2/ 4 BY ( src lcnt )
FOR I E@ OVER = --- found a match for "ROMS"
IF I 8 + E@ OVER = --- Yes but verify for additional ROMS sig
IF
CR 20 SPACES PRINT" COPY ROMS from $" I .WORD
PRINT" for " I 4+ E@ DUP .DECX SPACE CR
--- Copy ROMs from old EEPROM location to upper EEPROM
I roms ROT romsz MIN ECOPY
--- erase original ROMs
\ I 8 4 DOFOR 0 I E! LOOP
LEAVE
THEN
THEN
NEXT
DROP
;
@frida - thanks, that must have happened when I was fixing it up the other day as I checked an earlier version and it was still FROM my bad
The 0n ??? might be an artifact of the ANSI enquiry sequence if you are using a non-ANSI terminal. All the terminals I use on Linux and Windows and ANSI compatible, even Blueterm on Android is too. Since I have added color and attribute to some words I have also allowed for simple ASCII terminals by testing for ANSI response on reset and if there is none then all further ANSI escape sequences are suppressed. However it may be part of the esc[0n response that has come in late from a slow terminal as I only wait 20ms but I guess it could be increased a little to 30ms which I have also done.
EDIT - if that doesn't work try changing the value yourself. Waiting for a response may be problematic at low baud rates however.
Line 617:
--- res = 1B5B.306E
pub ?ANSI ( -- ) _ansi ~~ '5' ESCB 'n' EMIT 30 ms 0 4 FOR 8 << KEY OR NEXT _ansi ! ;
The RTC routines have been updated in EXTEND to merge both the soft RTC and any hardware I2C RTC detected. At boot it synchronizes the soft RTC by reading the hardware RTC and then maintains the time in milliseconds thereafter only converting it to HHMMSS when required whereas the date is a static value that only gets updated thereafter when the soft RTC reaches midnight where it performs another synchronization again.
So any routines that need date and time such as time stamps for logging won't need to access the relatively slow hardware RTC. Reading the date takes around 5us but reading the time as HHMMSS requires conversion from milliseconds but still only takes 88us which I might improve upon. However the 32-bit milliseconds of the day can simply be used for time stamps with high resolution without incurring any delays other than reading a variable. I may encode the day of the month in with the milliseconds for a general timestamp or combine the month as well and use 1/100th of a second resolution instead.
Such comparisons are totally irrelevant, for instance Fortran is in 28th place. Fortran!, Really?
When it comes to actual "embedded" languages we have:
#2 C
#4 C++
#11 Arduino (is that a language?)
#13 Assembly
#25 Haskell (can it be embedded without an O/S?)
#29 D (hedge fund and informations systems?)
#30 VHDL (it is a language, but...)
#33 Labview (ditto)
#34 Verilog (ditto)
#36 Erlang
#37 Ada
#43 TCL
#47 Ladder Logic
#48 Forth
Of these we can see that there is really only C, C++, assembly, and Forth that are true embedded languages that run on a very wide range of architectures without the need for s supporting O/S or PC only environment etc.
The writer does say though:
(And although it just barely clears the threshold for inclusion in our rankings, I’m pleased to see that my personal favorite veteran language—Forth—is still there in 47th place)
Where's Basic? I only see Visual Basic on the list and I know Basic is still used for embedded applications. So it seems that despite the effort that Spectrum went through that they still don't have a good idea what the "Top Programming" languages are either. However when it comes to the Propeller chip even though we have a lot of emulated languages there are very few that are useful. We have Spin, PASM, C, Basic, and Tachyon Forth (since no one seems to use the other Forths). Even if I ranked Forth as under Spin, PASM, and C, it would still come "4th"
pub DAY@ ( -- day ) --- read the day of the week as 0-6
@day C@ 1 MAX
;
comment and code/use seem to be inconsistent.
@day is directly stored as 1..7
and used in .DAY as 1..7
the '1 MAX' seems to be redundant as well,
but .DAY does not trust it and does a 1 7 LIMIT ...
and the DS3231 gives day as 1..7 as well
the datasheet of DS3231 states temp is in °C,
so directly reading the RTC bytes would give °C,
which then can be converted to °F ...
as
pub 'F ( -- 'F*100 ) 9 * 5 / #3200 + ;
Thanks for checking this code.When there is no hardware RTC and the soft RTC is not set the 1 MAX in DAY@ prevents an invalid day from being read as a similar thing is done with the date too in that it will read 1/1/1 rather than 0/0/0. However I may use the new !RTC routine to set some defaults for a soft RTC if no hardware is present.
Regarding reading the temperature I'm a little puzzled as to what happened there as 'C is the default according to the datasheet. Funny thing though is that I hadn't noticed any problems but I will fix it. I have used it properly at one time so I'm guessing something got typo'ed. Maybe I will make !RTC set a default of zero as well.
Australia converted to decimal currency in 1966 and metric units from 1971 and I am so glad we did (both). The old arbitrary imperial units were an awkward legacy of British colonialism although it seems that some countries still can't seem to shake it off Looks like the U.K. has a foot in both camps, even more of a mess!
.....
Australia converted to decimal currency in 1966 and metric units from 1971 and I am so glad we did (both). The old arbitrary imperial units were an awkward legacy of British colonialism although it seems that some countries still can't seem to shake it off Looks like the U.K. has a foot in both camps, even more of a mess!
Me too.
When I was in the UK recently, I was amazed they still use MPH on the road, you buy in lbs, measure mostly in inches/feet/yards, yet their temp in in 'C and they have decimal currency. At least their car speedos must have both MPH and KPH. Oh, and they don't have cruise control (not sure if this is mandatory or a we don't need it).
They have better child car seat restraint connections although children up to 12y must be in an approved child/booster seat. Might be a bit overboard.
@cluso99 - We have a lot of Samoans as well as many other cultures here in Australia, I chuckle when I visualize a 12yo Samoan "child" trying to fit into one of those seats
Just goes to show that although laws are supposed to be based upon principles, that all too often the law doesn't always fit into that kiddies seat that it tries to squeeze everyone else into.
@MJB - fixed and tested the DS3231. That probably explains some of the weird readings I'd get
My experience in the UK is that most people use kg and metres/cm/mm a lot of the time - the imperial
units persist for peoples heights/measurements, but are gradually dropping out of use. We never changed
the road signs so road speeds and distances are usually in miles (but most people understand km just fine).
Education leads the way of course, metric measures have been taught since the 70's. No-one enjoys
long-division in a mixture of bases, one consequence is that ounces are mainly replaced by kg/grams.
Rulers/tape measures/measuring jugs and bathroom scales have been dual metric/imperial since the 70's too so
everyone sees both sets of units routinely.
People naturally chose decimal units when calculating, which is why metric is inexorably taking over (as it
should!). In colloqial speech units are both metric and imperial are used, pretty much at random I think. Of course
the basic imperial units won't dissappear completely as they feature in centuries of literature.
Anyone who's studied any science subject will have used SI units pretty much exclusively there.
Don't get me started on the nonsense of things like 7/16th of an inch or wire guages!!
@peter can you help patch this code from V3 plz, I don't see .TIMERS in latest V4.5 extend.fth
\ List the timers and their status
pub .TIMERS
SPACE CLKFREQ ttint / ." ticks = 1/" 0 PRINTDEC
timers W@
BEGIN
DUP $FF >
WHILE
CR DUP .WORD ." : "
DUP 1- PFA>NFA DUP PRINT$ LEN$ #20 SWAP - SPACES
DUP @ 6 PRINTDEC ." ms "
." =" DUP @ .LONG
." L" DUP 6 + W@ .WORD
SPACE DUP 4 + W@ IF ." ALARM=" DUP 4 + W@ PFA>NFA PRINT$ THEN
6 + W@ --- fetch the link to the next timer
REPEAT
DROP
;
D.P. - that NFA thing is annoying me. What do I call the field in my header that used to be the bytecode field and now is the wordcode field that either points to the code or is a constant? I think maybe CFA should be the actual address of the code so maybe I should call the pointer "CPA" or something like that.
I will check and add .TIMERS which I think need CFA>NFA since PFA is probably not the correct term for this type of threading.
@D.P - I get caught sometimes too even with minicom as sometimes i inadvertently change the parity when the coms parameter menu is up. The characters echo fine afterwards but I get errors. However I will check Teraterm to make sure.
I'm putting together a Tachyon Demonstrator showing what can be done simultaneously with a single Propeller chip without the need for memory expansion etc other than using a normal 64kB EEPROM. Besides incorporating the typical Tachyon setup along with FAT32 and WIZnet W5500 HTTP/FTP/TELNET servers I also will have VGA and keyboard running from the same chip along with stepper motors, ping sensors, RS485 networking, WS2812 LED strips, 1-wire temperature network, RTC, A/D, wave file player, DHT22 etc. All 32 I/O will be fully utilized for this demonstration which will test the limits of the Propeller and Tachyon and give me a test-bed for further development. All these functions are currently working, it's simply a matter of putting the hardware together and stitching it all up. There's also the F32 ROM that gets loaded into a cog at runtime that I'd like to tie in as well.
These are the pins required for hardware tests.
8 - VGA (32x15 color text at least)
4 - SD CARD (FAT32)
4 - WIZNET (HTTP/FTP/TELNET)
2 - PS/2 KEYBOARD
1 - PING (trig from 1W)
1 - AUDIO OUT
4 - Stepper (direct or L6470) - lead screw + baffle to ping sensor
When I am done anyone can access this demonstrator from the Internet at tachyonforth.com and in the process I'd like to develop some active webpages to control and show the hardware. Any volunteers to help with the active controls?
This sounds great Peter. I was thinking it would be rather cool if this demonstration was also able to target the original Parallax ProtoBoard which also has a 64kB EEPROM. I guess based on your peripheral set above it should be able to assuming the I/O pins are customisable. Only real difference is the mouse port but if this port get reused as your multi drop RS485 intercom network instead I imagine everything else should pretty much fit together with the existing board design once the appropriate connectors are added for the various IO devices.
Of course if you are planning to do this in order to sell custom boards with this particular setup then that may possibly defeat the purpose slightly, but if not it may let people experiment with it themselves too if they already have this board or something similar.
@rolgloh, a target board will need a wiznet 5500 chip/magnetics for the ethernet/IP stuff and a 485 transceiver. I hope Peter is using an IOT5500 on a motherboard with all these goodies, maybe offer as a kit. Nice hardware to validate new Tachyon builds.
@Peter what do you have in mind for the web IO pages? The ajax/forth html replacement that MJB had running on V3 and the wiznet 5000 chip was really neat.
@rogloh
I could do a board with all this stuff and more on it for sure and some of it will be quite modular of course such as the IoT5500 module etc however I never set out to do this, I simply wanted a setup where I could exercise all this hardware. All too often though I see complaints that the Prop "runs out of memory" just doing simple things, and I intend to set the record straight in this regard. As they say, it's not how much you've got, it's how you use it.
The pinouts can be changed on the fly easily and normally the user passes a long which holds up to 4 pin numbers for the SD card and WIZnet interface etc. These normally lock themselves into EEPROM as well.
@D.P - I never really got to play with the ajax/forth commands but that was what I had in mind, to check them out, and enhance whatever needed to be enhanced.
The RS485 intercom software works just as well with a single direct I/O line which means you could interconnect multiple Props (or other chips) over several meters without worrying about RS485.
A serial Flash in standard SPI mode could also be substituted for the SD card.
Regarding the PS/2 port I'm even thinking of implementing the Logitech protocol which uses the nRF24L01 so that I can interface wireless keyboard and mice. Perhaps I should interface ESP modules too.
@D.P - I never really got to play with the ajax/forth commands but that was what I had in mind, to check them out, and enhance whatever needed to be enhanced.
I had it working with Tachyon 2.7 and Spinneret
but then Tachyon made some leaps was a moving target.
I tried some attempts to port but then did not have the time to follow it through.
It is not that complicated and with a little help from Peter_Jakacki we should get it to run again.
Actually I was having a look again just recently. And this gives some more motivation
moving it into mainstream.
Peter_Jakacki I'll have a look and prepare and then maybe we do a skype/google-docs session together
so you understand what I am doing and you can add your enhancements.
And include the code into EASYNET.fth
Regarding the PS/2 port I'm even thinking of implementing the Logitech protocol which uses the nRF24L01 so that I can interface wireless keyboard and mice. Perhaps I should interface ESP modules too.
of course ESP - Wireless would be great,
and I still have some nRF24L01 in my box waiting for some use ;-)
so the standalone Tachyon computer is almost there ...
but for practical development I will still prefer a 'real' computer ...
Comments
seems to be a bug in the forum software
1 AND is unnecessary
- or it should be in both places
EDIT: wow - this was fast - you already changed it.
but if you really want to keep the 1AND
then you can do ;-)
personally I would remove the 1 AND ... but you are the boss ;-)
pri .ES ??
I use Tachyon "Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170712.0020".
What is "16 COG!"?
CLKFREQ 1000000 is 80ticks(1usec). 100kHz is 10usec.
What mean this?
How is speed for "320 16 COG!"?
Wii-nunchuk don't operate at "288 16 COG!".
Location 16 is the clock delay used by CLKOUT, CLKIN, and CLOCK which are called by the I2C routines. Setting it to zero means no delay at all but the value is the number of cycles of "djnz X,$" that it will delay for on "one half of the clock pulse". 320 would result in 320x50ns @80MHz which would be 16us extra per half-cycle which is way too slow taking into account other overheads. A 100kHz I2C bus has 5us clock high time so the clock delay would be the extra time necessary to slow it down to that speed. I will hook up a scope and check my value for 100kHz shortly.
EDIT: I2C100 has been amended to which produces a nice 100kHz signal. That's a value of 80 for an 80MHz system.
TACHYON.SPIN Line 5576
' I2C support ' CLKOUT ( iomask dat -- iomask dat2 ) REG6=iomask ) Shift msb bit out, clock high, clock low CLKOUT andn OUTA,tos+1 ' ensure output will be active low andn OUTA,clockpins shl tos,#1 wc muxnc DIRA,tos+1 ' make it an output if it is a low else float ' CLOCK ( REG6=iomask ) Toggle multiple bits on the output) CLOCK xor OUTA,clockpins tjz clkdly,unext mov X,clkdly djnz X,$ jmp unext ' CLKOUT ( iomask dat -- iomask dat2 ) REG6=iomask ) Shift msb bit out, clock high, clock low CLKIN andn DIRA,tos+1 test tos+1,INA wc rcl tos,#1 jmp #CLOCKIN EXTEND.FTH:
A little fault at line: changed to:
What does 0n mean after a reset?
The 0n ??? might be an artifact of the ANSI enquiry sequence if you are using a non-ANSI terminal. All the terminals I use on Linux and Windows and ANSI compatible, even Blueterm on Android is too. Since I have added color and attribute to some words I have also allowed for simple ASCII terminals by testing for ANSI response on reset and if there is none then all further ANSI escape sequences are suppressed. However it may be part of the esc[0n response that has come in late from a slow terminal as I only wait 20ms but I guess it could be increased a little to 30ms which I have also done.
EDIT - if that doesn't work try changing the value yourself. Waiting for a response may be problematic at low baud rates however.
Line 617:
The RTC routines have been updated in EXTEND to merge both the soft RTC and any hardware I2C RTC detected. At boot it synchronizes the soft RTC by reading the hardware RTC and then maintains the time in milliseconds thereafter only converting it to HHMMSS when required whereas the date is a static value that only gets updated thereafter when the soft RTC reaches midnight where it performs another synchronization again.
So any routines that need date and time such as time stamps for logging won't need to access the relatively slow hardware RTC. Reading the date takes around 5us but reading the time as HHMMSS requires conversion from milliseconds but still only takes 88us which I might improve upon. However the 32-bit milliseconds of the day can simply be used for time stamps with high resolution without incurring any delays other than reading a variable. I may encode the day of the month in with the milliseconds for a general timestamp or combine the month as well and use 1/100th of a second resolution instead.
Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170715.1415 *** MODULES *** Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170715.1415 1B00: EXTEND.fth Primary extensions to TACHYON V4.5 kernel - 1707025-1730 AUTORUN BOOT FREQ = 96.0MHz *** INITS *** Loading cog 3 E50A F32 *** ROMS *** 0,848 VGA32x15 0,392 HSUART 1,900 F32 *** I2C *** $A0 EEPROM $D0 RTC I/O = 31:UHUU 27:~~~~ 23:~~~U 19:~~~~ 15:~~~~ 11:~DUD 7:UDUD 3:UDUD INTERCOM: &00.00.00.00 @2,000,000 CODE:$36A6 =13478 bytes NAME:$5950 =6832 bytes DATA:$770C =252 bytes =8874 bytes free Data Stack (1) $0002.9AE5 - 170725 2017/07/25 TUE 18:15:16 -------------------------------------------------------------------------------- ..We are 47th!
Such comparisons are totally irrelevant, for instance Fortran is in 28th place. Fortran!, Really?
When it comes to actual "embedded" languages we have:
#2 C
#4 C++
#11 Arduino (is that a language?)
#13 Assembly
#25 Haskell (can it be embedded without an O/S?)
#29 D (hedge fund and informations systems?)
#30 VHDL (it is a language, but...)
#33 Labview (ditto)
#34 Verilog (ditto)
#36 Erlang
#37 Ada
#43 TCL
#47 Ladder Logic
#48 Forth
Of these we can see that there is really only C, C++, assembly, and Forth that are true embedded languages that run on a very wide range of architectures without the need for s supporting O/S or PC only environment etc.
The writer does say though:
Where's Basic? I only see Visual Basic on the list and I know Basic is still used for embedded applications. So it seems that despite the effort that Spectrum went through that they still don't have a good idea what the "Top Programming" languages are either. However when it comes to the Propeller chip even though we have a lot of emulated languages there are very few that are useful. We have Spin, PASM, C, Basic, and Tachyon Forth (since no one seems to use the other Forths). Even if I ranked Forth as under Spin, PASM, and C, it would still come "4th"
pub DAY@ ( -- day ) --- read the day of the week as 0-6 @day C@ 1 MAX ;comment and code/use seem to be inconsistent.@day is directly stored as 1..7
and used in .DAY as 1..7
the '1 MAX' seems to be redundant as well,
but .DAY does not trust it and does a 1 7 LIMIT ...
and the DS3231 gives day as 1..7 as well
EDIT: temperature the datasheet of DS3231 states temp is in °C,
so directly reading the RTC bytes would give °C,
which then can be converted to °F ...
as
pub 'F ( -- 'F*100 ) 9 * 5 / #3200 + ;
you are using °C in Australia - don't you?
Thanks for checking this code.When there is no hardware RTC and the soft RTC is not set the 1 MAX in DAY@ prevents an invalid day from being read as a similar thing is done with the date too in that it will read 1/1/1 rather than 0/0/0. However I may use the new !RTC routine to set some defaults for a soft RTC if no hardware is present.
Regarding reading the temperature I'm a little puzzled as to what happened there as 'C is the default according to the datasheet. Funny thing though is that I hadn't noticed any problems but I will fix it. I have used it properly at one time so I'm guessing something got typo'ed. Maybe I will make !RTC set a default of zero as well.
Australia converted to decimal currency in 1966 and metric units from 1971 and I am so glad we did (both). The old arbitrary imperial units were an awkward legacy of British colonialism although it seems that some countries still can't seem to shake it off
When I was in the UK recently, I was amazed they still use MPH on the road, you buy in lbs, measure mostly in inches/feet/yards, yet their temp in in 'C and they have decimal currency. At least their car speedos must have both MPH and KPH. Oh, and they don't have cruise control (not sure if this is mandatory or a we don't need it).
They have better child car seat restraint connections although children up to 12y must be in an approved child/booster seat. Might be a bit overboard.
Anyway, back to Tachyon...
Just goes to show that although laws are supposed to be based upon principles, that all too often the law doesn't always fit into that kiddies seat that it tries to squeeze everyone else into.
@MJB - fixed and tested the DS3231. That probably explains some of the weird readings I'd get
units persist for peoples heights/measurements, but are gradually dropping out of use. We never changed
the road signs so road speeds and distances are usually in miles (but most people understand km just fine).
Education leads the way of course, metric measures have been taught since the 70's. No-one enjoys
long-division in a mixture of bases, one consequence is that ounces are mainly replaced by kg/grams.
Rulers/tape measures/measuring jugs and bathroom scales have been dual metric/imperial since the 70's too so
everyone sees both sets of units routinely.
People naturally chose decimal units when calculating, which is why metric is inexorably taking over (as it
should!). In colloqial speech units are both metric and imperial are used, pretty much at random I think. Of course
the basic imperial units won't dissappear completely as they feature in centuries of literature.
Anyone who's studied any science subject will have used SI units pretty much exclusively there.
Don't get me started on the nonsense of things like 7/16th of an inch or wire guages!!
@peter can you help patch this code from V3 plz, I don't see .TIMERS in latest V4.5 extend.fth
\ List the timers and their status pub .TIMERS SPACE CLKFREQ ttint / ." ticks = 1/" 0 PRINTDEC timers W@ BEGIN DUP $FF > WHILE CR DUP .WORD ." : " DUP 1- PFA>NFA DUP PRINT$ LEN$ #20 SWAP - SPACES DUP @ 6 PRINTDEC ." ms " ." =" DUP @ .LONG ." L" DUP 6 + W@ .WORD SPACE DUP 4 + W@ IF ." ALARM=" DUP 4 + W@ PFA>NFA PRINT$ THEN 6 + W@ --- fetch the link to the next timer REPEAT DROP ;I will check and add .TIMERS which I think need CFA>NFA since PFA is probably not the correct term for this type of threading.
Just working through basic examples in EXTEND are failing for me.
What is wrong with the STRING word?
Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400 *** MODULES *** Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400 1B40: EXTEND.fth Primary extensions to TACHYON V4.5 kernel - 1708030-1000 AUTORUN BOOT FREQ = 80.0MHz *** INITS *** Loading cog 3 E50A F32 *** ROMS *** E01C: VGA32x15 848 E37C: HSUART 392 E514: F32 1900 F298: MONO16 196 F36C: F32 1900 *** I2C *** $A0 EEPROM I/O = 31:UHUU 27:~~~~ 23:~~~~ 19:~~~~ 15:~~~~ 11:~~~~ 7:~~~~ 3:~~~~ INTERCOM: &00.00.00.00 @2,000,000 CODE:$37F6 = 13814 bytes NAME:$5934 = 6860 bytes DATA:$770C = 252 bytes FREE: = 8510 bytes Data Stack (0) 2001/01/01 MON 00:00:00 -------------------------------------------------------------------------------- .. " HELLO" 0 STRING A$ ??? ok .. " Hello" 10 STRING A$ ??? ok ..with latest version seems to work here
Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400 *** MODULES *** Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400 1B40: EXTEND.fth Primary extensions to TACHYON V4.5 kernel - 1708030-1000 AUTORUN BOOT FREQ = 80.0MHz *** INITS *** Loading cog 3 E50A F32 *** ROMS *** E01C: VGA32x15 848 E37C: HSUART 392 E514: F32 1900 *** I2C *** $42 I/O PORT $A0 EEPROM I/O = 31:UHUU 27:DDUD 23:~UDD 19:~~~~ 15:DU~~ 11:~~~~ 7:~D~~ 3:~D~U INTERCOM: &00.00.00.00 @2,000,000 CODE:$37F6 = 13814 bytes NAME:$5934 = 6860 bytes DATA:$770C = 252 bytes FREE: = 8510 bytes Data Stack (0) 2001/01/01 MON 00:00:00 -------------------------------------------------------------------------------- ok" HELLO" 0 STRING A$ .. a$ . 14328 ok .. A$ . 14328 ok .. A$ PRINT$ HELLO ok ..Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400 *** MODULES *** Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400 37F6: EASYFILE.fth SDHC card + FAT32 Virtual Memory Access File System Layer V1.2 170705-1120 1B40: EXTEND.fth Primary extensions to TACHYON V4.5 kernel - 1708030-1000 AUTORUN � FREQ = 96.0MHz *** INITS *** INIT#0 3D6E Loading cog 3 E50A F32 *** ROMS *** E01C: VGA32x15 848 E37C: HSUART 392 E514: F32 1900 *** I2C *** $A0 EEPROM $A2 EEPROM I/O = 31:UHUU 27:U~~U 23:D~~D 19:~~~~ 15:U~~U 11:~~~~ 7:UDUD 3:U~U~ INTERCOM: &00.00.00.00 @2,000,000 CODE:$4A38 = 18488 bytes NAME:$6FFE = 1026 bytes DATA:$7AF0 = 1248 bytes FREE: = 9670 bytes Data Stack (0) 2001/01/01 MON 00:00:00 Mounted F959.C01F-83AD.B80C mkfs.fat PBJ32C FAT32 31,910MB (16,384/cluster) -------------------------------------------------------------------------------- .. " HELLO" 0 STRING A$ .. A$ PRINT$ HELLO ..Thanks for checking.
I'm putting together a Tachyon Demonstrator showing what can be done simultaneously with a single Propeller chip without the need for memory expansion etc other than using a normal 64kB EEPROM. Besides incorporating the typical Tachyon setup along with FAT32 and WIZnet W5500 HTTP/FTP/TELNET servers I also will have VGA and keyboard running from the same chip along with stepper motors, ping sensors, RS485 networking, WS2812 LED strips, 1-wire temperature network, RTC, A/D, wave file player, DHT22 etc. All 32 I/O will be fully utilized for this demonstration which will test the limits of the Propeller and Tachyon and give me a test-bed for further development. All these functions are currently working, it's simply a matter of putting the hardware together and stitching it all up. There's also the F32 ROM that gets loaded into a cog at runtime that I'd like to tie in as well.
These are the pins required for hardware tests.
8 - VGA (32x15 color text at least)
4 - SD CARD (FAT32)
4 - WIZNET (HTTP/FTP/TELNET)
2 - I2C ( RTC, EEPROM, MCP3208, SAA1064 @ 100kHz, 400kHz, and FAST)
2 - SERIAL CONSOLE (921600 baud default)
2 - RS485 INTERCOM NETWORK (master > slaves)
1 - 1-WIRE NETWORK (Multiple DS18B20 and A/D)
1 - WS2812 RGB STRIPS
2 - PS/2 KEYBOARD
1 - PING (trig from 1W)
1 - AUDIO OUT
4 - Stepper (direct or L6470) - lead screw + baffle to ping sensor
When I am done anyone can access this demonstrator from the Internet at tachyonforth.com and in the process I'd like to develop some active webpages to control and show the hardware. Any volunteers to help with the active controls?
So, what have I left out?
Of course if you are planning to do this in order to sell custom boards with this particular setup then that may possibly defeat the purpose slightly, but if not it may let people experiment with it themselves too if they already have this board or something similar.
Roger.
@rolgloh, a target board will need a wiznet 5500 chip/magnetics for the ethernet/IP stuff and a 485 transceiver. I hope Peter is using an IOT5500 on a motherboard with all these goodies, maybe offer as a kit. Nice hardware to validate new Tachyon builds.
@Peter what do you have in mind for the web IO pages? The ajax/forth html replacement that MJB had running on V3 and the wiznet 5000 chip was really neat.
I could do a board with all this stuff and more on it for sure and some of it will be quite modular of course such as the IoT5500 module etc however I never set out to do this, I simply wanted a setup where I could exercise all this hardware. All too often though I see complaints that the Prop "runs out of memory" just doing simple things, and I intend to set the record straight in this regard. As they say, it's not how much you've got, it's how you use it.
The pinouts can be changed on the fly easily and normally the user passes a long which holds up to 4 pin numbers for the SD card and WIZnet interface etc. These normally lock themselves into EEPROM as well.
@D.P - I never really got to play with the ajax/forth commands but that was what I had in mind, to check them out, and enhance whatever needed to be enhanced.
The RS485 intercom software works just as well with a single direct I/O line which means you could interconnect multiple Props (or other chips) over several meters without worrying about RS485.
A serial Flash in standard SPI mode could also be substituted for the SD card.
Regarding the PS/2 port I'm even thinking of implementing the Logitech protocol which uses the nRF24L01 so that I can interface wireless keyboard and mice. Perhaps I should interface ESP modules too.
We know the P1 is capable of this, but many others just don't believe it's possible
but then Tachyon made some leaps was a moving target.
I tried some attempts to port but then did not have the time to follow it through.
It is not that complicated and with a little help from Peter_Jakacki we should get it to run again.
Actually I was having a look again just recently. And this gives some more motivation
moving it into mainstream.
Peter_Jakacki I'll have a look and prepare and then maybe we do a skype/google-docs session together
so you understand what I am doing and you can add your enhancements.
And include the code into EASYNET.fth
of course ESP - Wireless would be great,
and I still have some nRF24L01 in my box waiting for some use ;-)
so the standalone Tachyon computer is almost there ...
but for practical development I will still prefer a 'real' computer ...