I'm a tachyon newbie but I don't how know often I C-a t d ed in minicom copied forth code pasted it and so on.
I'm dreaming of feeding forth files to a tachyon kerneled system via command line. Maybe this could be done via x/y/zmodem or such a 30 years old technology. This manual fiddling is time consuming and retracts me from really interactive working with tachyon.
I set up a build system for TeraTerm a while ago, but do not use it a lot.
; save file with *.ttl extension (TeraTerm Language)
; Tachyon build file for TeraTerm
;
; Spinneret build file 2014-10-31
;
show 1
clearscreen 1
; line delay setting is important, so we load custom ini file
restoresetup 'SPINNERET.ini'
getdir dir
strconcat dir '\'
;messagebox dir 'DIR'
getttdir ttdir
;messagebox ttdir 'TTdir'
; sendfile needs full path
; set build directory
; setdir 'D:\Tachyon\Spinneret 2014-10-23\'
lf = dir
gettime timestr "%Y-%m-%d--%H-%M-%S"
strconcat lf 'build '
strconcat lf timestr
strconcat lf '.log'
logopen lf 0 0 0 1 1
; assume a plain Tachyon base image
; sendln 'COLD'
; pause 20
; or load kernel via propellent
dispstr 'loading Kernel'
disconnect 0
pause 1
; D:\Markus\Georg\downloads\Propeller\Propellent\Propellent.exe /eeprom "D:\Markus\Georg\downloads\Propeller\Forth\Tachyon\GoogleDocs\TACHYON V24 2014-12-20 02-40.spin"
execstr = 'D:\Markus\Georg\downloads\Propeller\Propellent\Propellent.exe /eeprom '
strconcat execstr #$22
strconcat execstr dir
strconcat execstr 'TACHYON V24 2014-12-20 02-40.spin'#$22
;messagebox execstr 'Load Tachyon'
exec execstr
pause 50
; connect to COM5
connect '/C=5'
dispstr 'done loading Kernel'
;messagebox 'done loading Kernel' 'done load'
pause 1
sendbreak
pause 10
fn = dir
strconcat fn 'EXT_LOAD 2014-10-27 07-28.fth'
messagebox fn 'loading'
sendfile fn 1
pause 20
fn = dir
strconcat fn 'EXTEND 2014-12-27 10-40.fth'
messagebox fn 'loading'
sendfile fn 1
pause 20
fn = dir
strconcat fn 'EEWORDS 2014-12-22 13-55.FTH'
messagebox fn 'loading'
sendfile fn 1
pause 20
; for debug we want to see all
; sendln 'pub [~ ; '
fn = dir
;
;strconcat fn 'EPRINT 2014-07-03 18-13.fth'
;messagebox fn 'loading'
;sendfile fn 1
;pause 10
fn = dir
strconcat fn 'SPINNERET 2013-12-04 12-00.fth'
messagebox fn 'loading'
sendfile fn 1
pause 10
sendln '?BACKUP'
pause 20
fn = dir
strconcat fn 'SDCARD 2014-12-09 03-44.fth'
messagebox fn 'loading'
sendfile fn 1
pause 20
fn = dir
strconcat fn 'EASYFILE 2014-12-11 01-54.fth'
messagebox fn 'loading'
sendfile fn 1
pause 20
; fn = dir
; strconcat fn 'SDWORDS 2014-12-10 06-55.fth'
; messagebox fn 'loading'
; sendfile fn 1
; pause 30
; sendln '?BACKUP'
;pause 30
sendln 'COMPACT'
pause 50
sendln '?BACKUP'
pause 30
sendln 'EEWORDS '
; end
pause 30
fn = dir
strconcat fn 'W5100 2014-11-25 00-52.fth'
messagebox fn 'loading'
sendfile fn 1
pause 20
sendln '?BACKUP'
pause 30
fn = dir
yesnobox 'load EASYNET' 'EASYNET'
if result then
strconcat fn 'EASYNET 2014-12-27 03-35.fth'
else
yesnobox 'load MJBHTTP' 'MJBHTTP'
if result then
strconcat fn 'MJBHTTP 14.fth'
else
end
endif
endif
messagebox fn 'loading'
sendfile fn 1
pause 20
; sendln 'COMPACT'
; pause 30
sendln '?BACKUP'
pause 30
sendbreak
pause 10
sendln 'EEWORDS '
pause 30
logclose
Scriptable tachyon would be such an improvement!
Tachyon is already scriptable ...
and you do not need a xyz-modem SW file transfer is already possible -
just send the characters like paste does
you just need a scriptable PC side like above TeraTerm provides,
other systems might do this as well.
Just as MJB says, here is an older build script of mine on teraterm, it even launches the system at the end!
Launch and it's time for tea and a crumpet.
You may have noticed that I have cleaned up the Dropbox files somewhat to reduce the clutter so that I have placed all the sub-folders into "more" and then further reduce the base code files by merging six files into three, the three Es - EXTEND, EASYFILE, EASYNET plus the kernel and VGA.
The only time you should be doing lots of copy and pasting is when you are building a system. During development and testing much of the work is interactive with the occasional copy from terminal back into editor. The interactive part allows you to test out methods and ideas and thereby simplify the code and have fun at the same time discovering new and simpler ways of doing things. It is quite usual too to copy&paste the app code but this is usually just a single file and the whole process takes but a few seconds so I don't really see the need for file transfer software. What I would like to see though is either a terminal with functions linked to scripts to paste files, but we have to remember that Tachyon is the compiler, not the PC.
You are absolutely right! On the other side obviously other tachyon infected people (MJB, D.P others?) also tried to automate the process of building a system. And they seem to have given up this intention. Why? BTW I also gave up this (some time ago see an earlier post linked in my last post).
If I think about a more complex system where more than one propeller with Tachyon and different setups for different subsystems are in use, one has to juggle with different builds by hand this can be a very error prone task.
Further more there is the need for a documented build of tachyon propeller systems. If you have to build a small series there will be a lot of copy and pasting C-a T D ing and so on. Don't think about a large series.
There is also the problem of guiding a not so experienced person maybe a customer through the build. If you don't have direct access to a system you have to "remote direct" a person via telephone how to do the build. How easy would this be just telling "make kernel" or "make iot5500" or "make gardencontrol" and the rest is automated.
The manual operations to build a system are a waste of time. This waste is multiplied by a growing group of users. This time is lost for real value creating tachyon work.
Maybe we could implement a small tool in c or c++ running on the host to feed tachyon and return an error code if something is going wrong. Although this is a sidetrack of concentration on working with tachyon. Using an existing tool (yxzmodem or similar - do you know an open source basis) and equipping tachyon to support this seems to be a solution I would invest my time for.
There is also the problem of guiding a not so experienced person maybe a customer through the build. If you don't have direct access to a system you have to "remote direct" a person via telephone how to do the build. How easy would this be just telling "make kernel" or "make iot5500" or "make gardencontrol" and the rest is automated
Wouldn't it make more sense just to give customers and such a binary and something to load the top 32K of EEPROM if necessary instead of making them rebuild the system?
I expected this answer. But if you have to go step by step "make step1" try this at tachyon console, then "make step2" would be helpful for guiding an inexperienced user through a problem situation.
If someone wants to learn they will make the effort I've found. This list sparkles. I struggled with Tachyon at first granted. But I will always try to help a newbie in parallax land where I can, many others will too. C++ is an expected answer here too, it's the body revolting RPN syntax and having withdrawal from not enough ** -> & { }, this will pass
And they say FORTH is weird
int i = 88;
double d = 55.66;
int * iPtr = &i; // int pointer pointing to an int value
double * dPtr = &d; // double pointer pointing to a double value
iPtr = &d; // ERROR, cannot hold address of different type
dPtr = &i; // ERROR
iPtr = i; // ERROR, pointer holds address of an int, NOT int value
int j = 99;
iPtr = &j; // You can change the address stored in a pointer
I'm still not sure why building Tachyon is a problem as this should occur very infrequently really with most of the effort elsewhere in developing applications. I know though that I do a lot of this building myself but that is understandable since I am constantly improving and testing the kernel and extensions but otherwise I can pick up a board with V2.4 still sitting on it and start working with it.
As for deploying Tachyon builds over multiple units that is easily handled a few different ways, one being that I do a DUMPROM (copy, paste from extras, run, then forget) which produces an Intel hex file that I then hex2bin and rename to a .binary so that any Prop loader can use it. Another way is I SAVEROM to SD card if the system has it and if it is connected on FTP I just grab the file straight from the PC's browser. Otherwise I clone the EEPROM directly from my 8-pin serial port (includes I2C) so that the dongle can then be inserted into other production boards and automatically load that boards EEPROM. For this I just use any one of my small boards, even a P8 with a large enough EEPROM or serial Flash or SD card to hold the 64k image to be cloned. Have a look at EEPROG in extras as this is a version I have used before for field upgrades, just plug it in, the LED says it's busy for a couple of seconds, and then it is done.
edit: I almost always use shortcut keys to increase productivity, none of this moving the mouse around and around. My wife knows how annoyed I get watching her trying to change some settings while using the mouse to click the default "OK" !#@$@! At the very very very least, please press Enter. So ^A for select all, ^C for copy and then the shortcut for paste into the terminal, that's three key strokes and it's all done.
btw, I never understand why Parallax boards don't include the extra row of 4 pins besides the Prop plug as I do as the board can be powered from the USB and there is direct access to the i2c bus as well for direct programming. I even use this connector in reverse to power and communicate with external modules.
Hi there, I'd like to clarify some things in my last posts regarding scripting tachyon. First and important I'm no native english speaker so expressing what I want to say is sometimes difficult or fails. I even sometimes do not completely understand your answers, so please be patient with me:-) as you have always been.
Second the scripting I'm speaking of is scripting in a unix way like piping to /dev/ttyUSB0 and redirecting the answer to stdout. Nobody else seems to prefer this method, so I want to apologize for this proposal. I'll try to continue the work on this and if I'm getting forther upps further I will report here.
The problem I'm facing is using a serial interface on a linux pc especially the line delay we need in order to speak with Tachyon is a problem. I couldn't find out wether this is configurable in linux via stty or has to be implemented on application level as in minicom. I'll dive into minicom sources to find out this. May the forth be with you.
Second the scripting I'm speaking of is scripting in a unix way like piping to /dev/ttyUSB0 and redirecting the answer to stdout. Nobody else seems to prefer this method, so I want to apologize for this proposal. I'll try to continue the work on this and if I'm getting forther upps further I will report here.
can you give a real example of what you want to do in Tachyon?
actually there are kind of 'pipes' implemented which allow redirection of standard code writing to the console redirected to a LCD, VGA, TFT, File, NW, ... and also reading instead from the console from NW, another serial, ext. KBD, File, .....
can you give a real example of what you want to do in Tachyon?
actually there are kind of 'pipes' implemented which allow redirection of standard code writing to the console redirected to a LCD, VGA, TFT, File, NW, ... and also reading instead from the console from NW, another serial, ext. KBD, File, .....
all handled by vectored EMIT and KEY
a very powerful feature
Hi MJB, there is a misunderstanding. I didn't intend to "pipe" inside Tachyon. My intention was to send *.FTH files from a linux shell (bash, zsh) to Tachyon. Here an example:
1. To be able to do communicate via the serial interface the interface has to be configured like this:
stty -F /dev/ttyUSB0 115200 nl1 -hupcl
2. Then you can redirect the output of the command `cat' that's what normally is copy/pasted to minicom/teraterm to the serial device /dev/ttyUSB0 like this:
cat ./EXTEND.FTH > /dev/ttyUSB0
This failed until now every time I tried. I think it fails because Iwasn't able to set the line delay (at the linux side) to the needs of Tachyon. This is normally done with the `stty' option nl1, but the documentation regarding line delay is very poor and `cat'ting EXTEND.FTH fails erverytime.
So this is not really a Tachyon feature but a linux question. Maybe I'm in the wrong forum with this problem and I have to ask in an another forum. I'will try to find a place where I can ask how to configure the linux serial interface.
@ proplem
This is all you need to know stty in depth
@ D.P - Thanks for the link. Serial interfacing in Unix is black magic. No wonder why modem has died. Studying and (worse) applying the stuff in that link will surely affirm my decision of using Tachyon.
Who is able to configure a serial interface on unix is of course able to learn FORTH :-))
What about using a little script that adds a pause?
With perl there is the usleep that pauses for given microseconds.
Perl is good at reading line by line, maybe is not elegant but it should solve the issues.
What about using a little script that adds a pause?
With perl there is the usleep that pauses for given microseconds.
Perl is good at reading line by line, maybe is not elegant but it should solve the issues.
Bash has sleep too.
Massimo
Hi Massimo, thanks for the idea. Yesterday I had the similar thought (cat | while read ) and tried it today with only a few success because of permanently misconfiguring the interface. Sometimes without being aware of what having done wrong. Configuring via stty is a pain.
BUT: now I found in the good old minicom package the tool ascii-xfr which is my new best friend.
ascii-xfr -s -l 20 EXTEND.FTH > /dev/ttyUSB0
is what Tachyon needs. I did some tests, looks good.
After my excursion of automating the build process I would like to bring the new Tachyon V3 to an IOT5500. Can anybody give me a hint which files and commands/WORDS in which order have to be given to generate an IOT5500 binary?
@proplem - I still don't know why you need to automate the download process unless you are modifying the kernel and extensions constantly. If I am working on an application the most I need to do is a ctrl+A to select all and then a shift+ctrl+V to paste in minicom. If PCs properly supported soft handshaking then I would be using it but unfortunately we make do with line delays. WIth the P2 I can run at 1M baud without any delays at all in TeraTerm since we can have such large buffers.
However....
Build sequence for an IoT5500 is:
* Kernel
* EXTEND
* P8 in more/hardware headers/
* EASYFILE (combined SDCARD + EASYFILE)
* COMPACT
* BACKUP
* EASYNET (combined W5500 + EASYNET)
The dependencies are that networking requires filesystem which requires hardware definitions P8 which all requires EXTEND. By the time you have loaded EASYFILE you need to do a COMPACT to free up more hub memory and if you need more memory after EASYNET then do another COMPACT and BACKUP as well.
We used to do a INCLUDE before EXTEND but the default EXTEND is setup now to build a smaller system
Hi Peter, I don't `need' an automated build process. It's my way of thinking/working: "If you have a script you have a process." If my script fails my process fails. A failing script points me to the next problem on my way to a robust development. That's it. A script/makefile has also the advantage of reminding me how everything is depending on each other. My head is full of things and Tachyon/FORTH has not yet come to my longtime memory (this becomes more and more difficult it seems) so a script or a makefile is also something like a documentation I can look into without calling the forum. Last but not least I can tell someone to look at the script: "Read the source!" (You could say: "Read the FORTH!" and leave me alone, but please don't).
Here is the output of my makefile:
Again this points me to the next problem in the process:
The command ascii-xfr -s -l 20 ./P8.FTH > /dev/ttyUSB0 should return an error code what it doesn't it writes bytes to a serial interface without respect to any answer. And here we are with the soft handshake you mentioned above. I don't yet know how this could be solved. But it has to be solved. If it's not automatable it is not yet right.
By the way: the build done like this fails. Also doing the steps manually fails. It looks like the git sources I'm using aren't up to date (P8.h != P8.FTH). I have to check this tomorrow, it's late now. Thanks for your support.
I have built the lot but not with P8.FTH. All these files were updated and I have removed any reference to .H files. I just noticed that P8 still referred to PINCLR/PINSET/PININP but these names were dropped in favor of the the more familiar LOW/HIGH/FLOAT words, so I updated P8.FTH.
Your script doesn't allow for BACKUP and COMPACT delays which can be several seconds so the script will fail as it tries to download to a small buffer while the Prop is still tied up not able to process it.
Speaking of builds, can someone remind me how to include / exclude individual modules from extend? I need small with all the tasking stuff in it please.
Speaking of builds, can someone remind me how to include / exclude individual modules from extend? I need small with all the tasking stuff in it please.
Thanks so much
just set the include mask you need
{
( general set of includes when building an expanded TF with filesystem. )
: INCLUDE
\ .......TICASS.ARR.MSSNHP_PCLOM.....
\ .......ETNDAT.NET.APEUEW-IHORA.....
\ .......RCTCNR.SPC.PRRMXM_NRCGT.....
\ 33_2222222222_1111111111_0000000000
\ 10_9876543210_9876543210_9876543210
%00_0000101001_1110010100_1101100000
;
}
}
{ INCLUDE MODULE NOTES
typical inlcude for larger systems
: INCLUDE
\ .......TICASS.ARR.MSSNHP_PCLOM.....
\ .......ETNDAT.NET.APEUEW-IHORA.....
\ .......RCTCNR.SPC.PRRMXM_NRCGT.....
\ 33_2222222222_1111111111_0000000000
\ 10_9876543210_9876543210_9876543210
%00_0000101001_1110010100_1101100000
;
current list of modules
#0
#1
#2
#3
#4
#5 MODULE: MATHS_FUNCTIONS
#6 MODULE: FIXED_POSITION_VARIABLES
#7 MODULE: LOCAL_VARIABLES
#8 MODULE: CHARACTER_OUTPUT
#9 MODULE: PIN_I/O_OPERATIONS
#10 MODULE: PWM
#11 MODULE: HEX FILE LOAD & DUMP
#12 MODULE: NUMBER_PRINT_FORMATING
#13 MODULE: PBASIC_STYLE_SERIAL_I/O
#14 MODULE: EXAMINE_SPECIAL_PURPOSE_REGISTERS
#15 MODULE: Memory Map Reporting
#16
#17
#18 MODULE: COMPILER REPORTING
#19 MODULE: ANSI_TERMINAL
#20 MODULE: STRINGS
#21 MODULE: SAN_FILTER
#22 MODULE: MCP3208_8_channel_ADC
#23 MODULE: COUNTERS
#24 MODULE: INTERTASK_COMMUNICATIONS
#25 MODULE: TERSE COMMAND MODE
#26
#27
#28
#29
#30
#31
}
be sure you have all the depencencies included as well, which is not trivial, but may need some trial and error.
If you include a module that needs another module you will get compilation errors and then add the other module as well.
I tried to set up another mechanism, which is based on a dependency table, but Peter prefered his more concise approach.
Good, sounds like you had success then. Sorry about the typo.
No I didn't - regrettably there is still something else going wrong I couldn't work out exactly. The kernel compiles and runs, EXTEND.FTH ok, P8.FTH ok and then ... ? I will investigate and report as soon as possible.
Edit: I'm speaking of building the iot5500 Tachyon.
Good, sounds like you had success then. Sorry about the typo.
No I didn't - regrettably there is still something else going wrong I couldn't work out exactly. The kernel compiles and runs, EXTEND.FTH ok, P8.FTH ok and then ... ? I will investigate and report as soon as possible.
Edit: I'm speaking of building the iot5500 Tachyon.
if you get it running I am interrested in the image ...
Are you having a problem getting a build???? This should be 123 but since you have having problems I will do a video or screenshots perhaps of a build for the IoT5500 tonight.
I would like to use this EEPROM from microchip 24C32
Explorer shows this
Fast EEPROM or RTC #0 at $A1: 0F 07 57 41 49 54 4B 45 59 82 C3 68 03 64 61 79
Fast EEPROM or RTC #7 at $AF: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Fast RTC/ADC? #0 at $D1: 00 00 00 00 00 1C 88 00 16 40 35 46 22 04 18 08k
Okay $A1 is the 64K Prop EEPROM, $D1 is the RTC so $AF is the 24C32.
To address this second EEPROM I should use @EE but how is this done? Looking at the source I'm clearly missing something because I always get $A0 in eeadr no matter how I have attempted to use @EE ?
I would like to use this EEPROM from microchip 24C32
Explorer shows this
Fast EEPROM or RTC #0 at $A1: 0F 07 57 41 49 54 4B 45 59 82 C3 68 03 64 61 79
Fast EEPROM or RTC #7 at $AF: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Fast RTC/ADC? #0 at $D1: 00 00 00 00 00 1C 88 00 16 40 35 46 22 04 18 08k
Okay $A1 is the 64K Prop EEPROM, $D1 is the RTC so $AF is the 24C32.
To address this second EEPROM I should use @EE but how is this done? Looking at the source I'm clearly missing something because I always get $A0 in eeadr no matter how I have attempted to use @EE ?
No need to use @EE directly as the chip is in the EEPROM address space and being the 7th device (%111x = $AE ) vs the 0th device (%000x) just use an address of $7.0000 to $7.0FFF to address the 8k memory.
No need to use @EE directly as the chip is in the EEPROM address space and being the 7th device (%111x = $AE ) vs the 0th device (%000x) just use an address of $7.0000 to $7.0FFF to address the 8k memory.
Yup, trying to out think myself again, thanks, you couldn't make it easier, now back to my problem because you made the Tachyon tools simple to use and regular.
$7.0000 31 ADO I $FFFF AND I EC! LOOP ok
ok
$7.0000 31 ADO I EC@ . CR LOOP 0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
ok
No need to use @EE directly as the chip is in the EEPROM address space and being the 7th device (%111x = $AE ) vs the 0th device (%000x) just use an address of $7.0000 to $7.0FFF to address the 8k memory.
Yup, trying to out think myself again, thanks, you couldn't make it easier, now back to my problem because you made the Tachyon tools simple to use and regular.
[code]
$7.0000 31 ADO I $FFFF AND I EC! LOOP ok
ok
$7.0000 31 ADO I EC@ . CR LOOP 0
Good, and the $FFFF AND is redundant of course since a byte store with EC! will only use the least significant 8-bits and as you are aware you need a long on the stack for any "byte" data anyway
To examine EEPROM just try using the DUMP commands (DUMP, DUMPW, DUMPL, DUMPA) preceded (somewhere) by the EE modifier which btw automatically resets back to hub RAM after any DUMP. You can even do a quick dump with "$7.0000 EE QD"
Comments
I set up a build system for TeraTerm a while ago, but do not use it a lot.
; save file with *.ttl extension (TeraTerm Language) ; Tachyon build file for TeraTerm ; ; Spinneret build file 2014-10-31 ; show 1 clearscreen 1 ; line delay setting is important, so we load custom ini file restoresetup 'SPINNERET.ini' getdir dir strconcat dir '\' ;messagebox dir 'DIR' getttdir ttdir ;messagebox ttdir 'TTdir' ; sendfile needs full path ; set build directory ; setdir 'D:\Tachyon\Spinneret 2014-10-23\' lf = dir gettime timestr "%Y-%m-%d--%H-%M-%S" strconcat lf 'build ' strconcat lf timestr strconcat lf '.log' logopen lf 0 0 0 1 1 ; assume a plain Tachyon base image ; sendln 'COLD' ; pause 20 ; or load kernel via propellent dispstr 'loading Kernel' disconnect 0 pause 1 ; D:\Markus\Georg\downloads\Propeller\Propellent\Propellent.exe /eeprom "D:\Markus\Georg\downloads\Propeller\Forth\Tachyon\GoogleDocs\TACHYON V24 2014-12-20 02-40.spin" execstr = 'D:\Markus\Georg\downloads\Propeller\Propellent\Propellent.exe /eeprom ' strconcat execstr #$22 strconcat execstr dir strconcat execstr 'TACHYON V24 2014-12-20 02-40.spin'#$22 ;messagebox execstr 'Load Tachyon' exec execstr pause 50 ; connect to COM5 connect '/C=5' dispstr 'done loading Kernel' ;messagebox 'done loading Kernel' 'done load' pause 1 sendbreak pause 10 fn = dir strconcat fn 'EXT_LOAD 2014-10-27 07-28.fth' messagebox fn 'loading' sendfile fn 1 pause 20 fn = dir strconcat fn 'EXTEND 2014-12-27 10-40.fth' messagebox fn 'loading' sendfile fn 1 pause 20 fn = dir strconcat fn 'EEWORDS 2014-12-22 13-55.FTH' messagebox fn 'loading' sendfile fn 1 pause 20 ; for debug we want to see all ; sendln 'pub [~ ; ' fn = dir ; ;strconcat fn 'EPRINT 2014-07-03 18-13.fth' ;messagebox fn 'loading' ;sendfile fn 1 ;pause 10 fn = dir strconcat fn 'SPINNERET 2013-12-04 12-00.fth' messagebox fn 'loading' sendfile fn 1 pause 10 sendln '?BACKUP' pause 20 fn = dir strconcat fn 'SDCARD 2014-12-09 03-44.fth' messagebox fn 'loading' sendfile fn 1 pause 20 fn = dir strconcat fn 'EASYFILE 2014-12-11 01-54.fth' messagebox fn 'loading' sendfile fn 1 pause 20 ; fn = dir ; strconcat fn 'SDWORDS 2014-12-10 06-55.fth' ; messagebox fn 'loading' ; sendfile fn 1 ; pause 30 ; sendln '?BACKUP' ;pause 30 sendln 'COMPACT' pause 50 sendln '?BACKUP' pause 30 sendln 'EEWORDS ' ; end pause 30 fn = dir strconcat fn 'W5100 2014-11-25 00-52.fth' messagebox fn 'loading' sendfile fn 1 pause 20 sendln '?BACKUP' pause 30 fn = dir yesnobox 'load EASYNET' 'EASYNET' if result then strconcat fn 'EASYNET 2014-12-27 03-35.fth' else yesnobox 'load MJBHTTP' 'MJBHTTP' if result then strconcat fn 'MJBHTTP 14.fth' else end endif endif messagebox fn 'loading' sendfile fn 1 pause 20 ; sendln 'COMPACT' ; pause 30 sendln '?BACKUP' pause 30 sendbreak pause 10 sendln 'EEWORDS ' pause 30 logcloseTachyon is already scriptable ...and you do not need a xyz-modem SW file transfer is already possible -
just send the characters like paste does
you just need a scriptable PC side like above TeraTerm provides,
other systems might do this as well.
Launch and it's time for tea and a crumpet.
If I think about a more complex system where more than one propeller with Tachyon and different setups for different subsystems are in use, one has to juggle with different builds by hand this can be a very error prone task.
Further more there is the need for a documented build of tachyon propeller systems. If you have to build a small series there will be a lot of copy and pasting C-a T D ing and so on. Don't think about a large series.
There is also the problem of guiding a not so experienced person maybe a customer through the build. If you don't have direct access to a system you have to "remote direct" a person via telephone how to do the build. How easy would this be just telling "make kernel" or "make iot5500" or "make gardencontrol" and the rest is automated.
The manual operations to build a system are a waste of time. This waste is multiplied by a growing group of users. This time is lost for real value creating tachyon work.
Maybe we could implement a small tool in c or c++ running on the host to feed tachyon and return an error code if something is going wrong. Although this is a sidetrack of concentration on working with tachyon. Using an existing tool (yxzmodem or similar - do you know an open source basis) and equipping tachyon to support this seems to be a solution I would invest my time for.
Wouldn't it make more sense just to give customers and such a binary and something to load the top 32K of EEPROM if necessary instead of making them rebuild the system?
And they say FORTH is weird
As for deploying Tachyon builds over multiple units that is easily handled a few different ways, one being that I do a DUMPROM (copy, paste from extras, run, then forget) which produces an Intel hex file that I then hex2bin and rename to a .binary so that any Prop loader can use it. Another way is I SAVEROM to SD card if the system has it and if it is connected on FTP I just grab the file straight from the PC's browser. Otherwise I clone the EEPROM directly from my 8-pin serial port (includes I2C) so that the dongle can then be inserted into other production boards and automatically load that boards EEPROM. For this I just use any one of my small boards, even a P8 with a large enough EEPROM or serial Flash or SD card to hold the 64k image to be cloned. Have a look at EEPROG in extras as this is a version I have used before for field upgrades, just plug it in, the LED says it's busy for a couple of seconds, and then it is done.
edit: I almost always use shortcut keys to increase productivity, none of this moving the mouse around and around. My wife knows how annoyed I get watching her trying to change some settings while using the mouse to click the default "OK" !#@$@! At the very very very least, please press Enter. So ^A for select all, ^C for copy and then the shortcut for paste into the terminal, that's three key strokes and it's all done.
btw, I never understand why Parallax boards don't include the extra row of 4 pins besides the Prop plug as I do as the board can be powered from the USB and there is direct access to the i2c bus as well for direct programming. I even use this connector in reverse to power and communicate with external modules.
Second the scripting I'm speaking of is scripting in a unix way like piping to /dev/ttyUSB0 and redirecting the answer to stdout. Nobody else seems to prefer this method, so I want to apologize for this proposal. I'll try to continue the work on this and if I'm getting forther upps further I will report here.
The problem I'm facing is using a serial interface on a linux pc especially the line delay we need in order to speak with Tachyon is a problem. I couldn't find out wether this is configurable in linux via stty or has to be implemented on application level as in minicom. I'll dive into minicom sources to find out this. May the forth be with you.
actually there are kind of 'pipes' implemented which allow redirection of standard code writing to the console redirected to a LCD, VGA, TFT, File, NW, ... and also reading instead from the console from NW, another serial, ext. KBD, File, .....
all handled by vectored EMIT and KEY
a very powerful feature
1. To be able to do communicate via the serial interface the interface has to be configured like this: 2. Then you can redirect the output of the command `cat' that's what normally is copy/pasted to minicom/teraterm to the serial device /dev/ttyUSB0 like this:
This failed until now every time I tried. I think it fails because Iwasn't able to set the line delay (at the linux side) to the needs of Tachyon. This is normally done with the `stty' option nl1, but the documentation regarding line delay is very poor and `cat'ting EXTEND.FTH fails erverytime.
So this is not really a Tachyon feature but a linux question. Maybe I'm in the wrong forum with this problem and I have to ask in an another forum. I'will try to find a place where I can ask how to configure the linux serial interface.
Nevertheless thank you for replying MJB.
This is all you need to know
stty in depth
Who is able to configure a serial interface on unix is of course able to learn FORTH :-))
With perl there is the usleep that pauses for given microseconds.
Perl is good at reading line by line, maybe is not elegant but it should solve the issues.
Bash has sleep too.
Massimo
BUT: now I found in the good old minicom package the tool ascii-xfr which is my new best friend.
is what Tachyon needs. I did some tests, looks good.
So I can place my next question
However....
Build sequence for an IoT5500 is:
* Kernel
* EXTEND
* P8 in more/hardware headers/
* EASYFILE (combined SDCARD + EASYFILE)
* COMPACT
* BACKUP
* EASYNET (combined W5500 + EASYNET)
The dependencies are that networking requires filesystem which requires hardware definitions P8 which all requires EXTEND. By the time you have loaded EASYFILE you need to do a COMPACT to free up more hub memory and if you need more memory after EASYNET then do another COMPACT and BACKUP as well.
We used to do a INCLUDE before EXTEND but the default EXTEND is setup now to build a smaller system
Here is the output of my makefile:
Created with a simple Again this points me to the next problem in the process:
The command ascii-xfr -s -l 20 ./P8.FTH > /dev/ttyUSB0 should return an error code what it doesn't it writes bytes to a serial interface without respect to any answer. And here we are with the soft handshake you mentioned above. I don't yet know how this could be solved. But it has to be solved. If it's not automatable it is not yet right.
By the way: the build done like this fails. Also doing the steps manually fails. It looks like the git sources I'm using aren't up to date (P8.h != P8.FTH). I have to check this tomorrow, it's late now. Thanks for your support.
Edit: Did you try the build for the iot5500?
Your script doesn't allow for BACKUP and COMPACT delays which can be several seconds so the script will fail as it tries to download to a small buffer while the Prop is still tied up not able to process it.
Thanks so much
just set the include mask you need
{ ( general set of includes when building an expanded TF with filesystem. ) : INCLUDE \ .......TICASS.ARR.MSSNHP_PCLOM..... \ .......ETNDAT.NET.APEUEW-IHORA..... \ .......RCTCNR.SPC.PRRMXM_NRCGT..... \ 33_2222222222_1111111111_0000000000 \ 10_9876543210_9876543210_9876543210 %00_0000101001_1110010100_1101100000 ; } } { INCLUDE MODULE NOTES typical inlcude for larger systems : INCLUDE \ .......TICASS.ARR.MSSNHP_PCLOM..... \ .......ETNDAT.NET.APEUEW-IHORA..... \ .......RCTCNR.SPC.PRRMXM_NRCGT..... \ 33_2222222222_1111111111_0000000000 \ 10_9876543210_9876543210_9876543210 %00_0000101001_1110010100_1101100000 ; current list of modules #0 #1 #2 #3 #4 #5 MODULE: MATHS_FUNCTIONS #6 MODULE: FIXED_POSITION_VARIABLES #7 MODULE: LOCAL_VARIABLES #8 MODULE: CHARACTER_OUTPUT #9 MODULE: PIN_I/O_OPERATIONS #10 MODULE: PWM #11 MODULE: HEX FILE LOAD & DUMP #12 MODULE: NUMBER_PRINT_FORMATING #13 MODULE: PBASIC_STYLE_SERIAL_I/O #14 MODULE: EXAMINE_SPECIAL_PURPOSE_REGISTERS #15 MODULE: Memory Map Reporting #16 #17 #18 MODULE: COMPILER REPORTING #19 MODULE: ANSI_TERMINAL #20 MODULE: STRINGS #21 MODULE: SAN_FILTER #22 MODULE: MCP3208_8_channel_ADC #23 MODULE: COUNTERS #24 MODULE: INTERTASK_COMMUNICATIONS #25 MODULE: TERSE COMMAND MODE #26 #27 #28 #29 #30 #31 }be sure you have all the depencencies included as well, which is not trivial, but may need some trial and error.
If you include a module that needs another module you will get compilation errors and then add the other module as well.
I tried to set up another mechanism, which is based on a dependency table, but Peter prefered his more concise approach.
I found a bug in P8.FTH - hooray:
Regards, proplem
Good, sounds like you had success then. Sorry about the typo.
Edit: I'm speaking of building the iot5500 Tachyon.
if you get it running I am interrested in the image ...
Explorer shows this
Okay $A1 is the 64K Prop EEPROM, $D1 is the RTC so $AF is the 24C32.
To address this second EEPROM I should use @EE but how is this done? Looking at the source I'm clearly missing something because I always get $A0 in eeadr no matter how I have attempted to use @EE ?
No need to use @EE directly as the chip is in the EEPROM address space and being the 7th device (%111x = $AE ) vs the 0th device (%000x) just use an address of $7.0000 to $7.0FFF to address the 8k memory.
Yup, trying to out think myself again, thanks, you couldn't make it easier, now back to my problem because you made the Tachyon tools simple to use and regular.
Good, and the $FFFF AND is redundant of course since a byte store with EC! will only use the least significant 8-bits and as you are aware you need a long on the stack for any "byte" data anyway
To examine EEPROM just try using the DUMP commands (DUMP, DUMPW, DUMPL, DUMPA) preceded (somewhere) by the EE modifier which btw automatically resets back to hub RAM after any DUMP. You can even do a quick dump with "$7.0000 EE QD"