Before I dig in to make any suggestions/changes, I believe I need to get feel for why some things have been done the way they have. (PS I am not being critical here as I am in awe of what has been achieved)
* All cogs are started and those effectively unused are placed in an LMM idle loop, waiting for a flag to start the doing something useful. Was there any reason for this?
* Cogs are started by spin. The propeller boot rom requires the first program to be spin. Was there any other reason to start the other cogs in spin?
* The Tachyon kernel resides in the lower 32KB of EEPROM. Was there any reason why the base kernel does not use the upper 32KB of EEPROM (for VGA/UART etc)? For cases where only 32KB EEPROM is present? Because that is the way it developed? Anything else?
BTW I have always been impressed by Tachyon. Delving into it a little only impresses me more!
Sorry, I've been sidetracked and meant to get back to you on your earlier post.
No worries Peter. I am having fun looking at the code
In the meantime:
1 - Initially spare cogs were loaded with Tachyon and left in an idle loop so that it would be a very simple matter of handing it something to start executing which it would do immediately. Also COGINIT will only be useful if you have a copy of the Tachyon image to load, which we don't as the memory is reused for buffers. These days with V3 this could be made to happen that way though.
Yes, I understand that.
2 - I never knew any better when I coded the first few parts of the kernel but I'm guessing that if I look at the boot rom source code I will see how I can tell it to run my code directly. The Spin boot is of course only a few lines before cog 0 is loaded over with the kernel.
The boot rom must run spin first in a cog. Subsequently you can start PASM, but not directly. As you found, the spin can be extremely small.
3 - Tachyon was designed so that it would only require a simple one step F11 in Prop tool to load and besides the Prop booter only supports the first 32k anyway. I wish the boot ROM did handle >32k loads but then Prop tool would need to be able to compile to these areas too
When I first wrote Tachyon I didn't have file system stuff or Ethernet etc so I had so much memory I actually tested V1 with bitmap VGA graphics at the time. So I didn't have any need to squeeze memory or try to use upper EEPROM, that need came much later.
Thanks for your comments Ray, maybe you would like to suggest a Spinless boot method?
From my OS I can certainly run PASM code directly.
But alas, from boot at least a minimal spin cog must run which can replace it with a PASM COGINIT.
Probably best to just have at least spin start one cog which could then load all of Tachyon.
A lot depends on what you want a minimal Tachyon system to be.
* Serial, and/or screen/keyboard.
* Do you require 64KB EEPROM or is 32KB ok? If 32KB what minimal configuration?
* Do you want to require an SD card?
Before I dig in to make any suggestions/changes, I believe I need to get feel for why some things have been done the way they have. (PS I am not being critical here as I am in awe of what has been achieved)
* All cogs are started and those effectively unused are placed in an LMM idle loop, waiting for a flag to start the doing something useful. Was there any reason for this?
* Cogs are started by spin. The propeller boot rom requires the first program to be spin. Was there any other reason to start the other cogs in spin?
* The Tachyon kernel resides in the lower 32KB of EEPROM. Was there any reason why the base kernel does not use the upper 32KB of EEPROM (for VGA/UART etc)? For cases where only 32KB EEPROM is present? Because that is the way it developed? Anything else?
BTW I have always been impressed by Tachyon. Delving into it a little only impresses me more!
Sorry, I've been sidetracked and meant to get back to you on your earlier post.
No worries Peter. I am having fun looking at the code
In the meantime:
1 - Initially spare cogs were loaded with Tachyon and left in an idle loop so that it would be a very simple matter of handing it something to start executing which it would do immediately. Also COGINIT will only be useful if you have a copy of the Tachyon image to load, which we don't as the memory is reused for buffers. These days with V3 this could be made to happen that way though.
Yes, I understand that.
2 - I never knew any better when I coded the first few parts of the kernel but I'm guessing that if I look at the boot rom source code I will see how I can tell it to run my code directly. The Spin boot is of course only a few lines before cog 0 is loaded over with the kernel.
The boot rom must run spin first in a cog. Subsequently you can start PASM, but not directly. As you found, the spin can be extremely small.
3 - Tachyon was designed so that it would only require a simple one step F11 in Prop tool to load and besides the Prop booter only supports the first 32k anyway. I wish the boot ROM did handle >32k loads but then Prop tool would need to be able to compile to these areas too
When I first wrote Tachyon I didn't have file system stuff or Ethernet etc so I had so much memory I actually tested V1 with bitmap VGA graphics at the time. So I didn't have any need to squeeze memory or try to use upper EEPROM, that need came much later.
Thanks for your comments Ray, maybe you would like to suggest a Spinless boot method?
From my OS I can certainly run PASM code directly.
But alas, from boot at least a minimal spin cog must run which can replace it with a PASM COGINIT.
Probably best to just have at least spin start one cog which could then load all of Tachyon.
A lot depends on what you want a minimal Tachyon system to be.
* Serial, and/or screen/keyboard.
* Do you require 64KB EEPROM or is 32KB ok? If 32KB what minimal configuration?
* Do you want to require an SD card?
FWIW a spin compiler can be avoided as we can handcode the tiny spin stub, if that is a desired outcome.
A lot depends on what you want a minimal Tachyon system to be.
* Serial, and/or screen/keyboard.
* Do you require 64KB EEPROM or is 32KB ok? If 32KB what minimal configuration?
* Do you want to require an SD card?
really minimal: Prop + crystal + EEPROM (xtreme even just prop if you load to RAM, without crystal - don't know if Tachyon could do that - currently with the timers etc. looks like not.
would be great if nothing else is mandatory.
So currently this is minimal possible.
If the 12MHz RC oscillator were calibrated then we could always work with that, albeit slowly. Then again it is possible to autobaud too but some kind of reference is preferable, so for the speed and calibration reason we need a crystal. Other micros even like the little PIC12F1572s I use have a calibrated/trimmed 32MHz oscillator via the PLL.
But yeah, Tachyon works on just a Prop and crystal and normally at least 32k EEPROM is available but not necessary. For larger systems all that is required is the 64k EEPROM which is standard these days even for Parallax.
Hmmm, I can pack almost everything, even the high level VGA driver, the filesystem, the WIZ5500 driver, plus the SPLAT logic analyzer. The SPLAT timing shows the VGA running. These extra modules were loaded directly from a sub-directory on the SD card.
I just have to see how I can squeeze in a little more room for the network servers which normally fit without the extra baggage. So now I'm looking at a way to get even more out of the humble P1 by pushing past my previous goals. There's probably a lot of stuff I've already loaded that might never get used but I think I can manage to fit all this stuff in together at the same time and still have room for apps. There are even small apps that I compile and run directly from file too.
Seems the current build of Juno and Extend.fth is causing a system lock when I issue reboot now. I have to rebuild to get the console to respond again?
But it's only when I uncomment the DS1302 stuff to include this?
And here is the timing for DS1302.fth that works with the chip FYI.
Okay, success. With the latest files and loading my driver thus:
EXTEND
EEWORDS
run COMPACT
run BACKUP
DS1302mini.FTH
SDCARD
EASYFILE
DLVR-L30D.FTH
GARDENCONTROL.FTH
Thanks for everything.
MODULES LOADED:
5078: GARDENCONTROL.fth Garden Control 151107 1530 V0.68
4F3A: DLVR-L30D.fth DLVR-L30D PSI Sensor 151108.1400 V0.3
404F: EASYFILE.fth FAT32 Virtual Memory Access File System Layer V1.2 16
3A1C: SDCARD.fth SD CARD Toolkit - 150827.0000
39A5: P8Only.fth P8 Only HARDWARE DEFINITIONS 141118.0000
376E: DS1302mini.fth DS1302 RTC Mini 160802.2100
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 160805-0040
344A: EEWORDS.fth TACHYON EEPROM DICTIONARY 160805.2330
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730
FREQ: 96MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $63A7...74D0 for 4,393 bytes (+896)
CODE: $0930...5E37 for 21,767 bytes (+3,519)
RAM: 1,392 bytes free
BUILD: FIRMWARE BUILD DATE 160805:115105 BOOTS: 9 runtime 25,043
BOOT: ok
ok
SETDST
Setting Date: 160805
Setting Time: 120635 ok
ls
Mounted 769A.5500-EE02.CFBC NO NAME FAT32 7,944MB (32,768/cluste)
NO NAME
[SYSTEM~1] LOG0001 .TXT LOG0002 .TXT LOG0003 .TXT LOG0004 .TXT
LOG0005 .TXT LOG0006 .TXT LOG0007 .TXT LOG0008 .TXT ~1 .TRA
[TRASHE~1] [SPOTLI~1] [FSEVEN~1] FIRMWARE.ROM ok
@D.P. - the DS1302 stuff was a little incomplete but I supposed half-hearted in that I didn't really see it as a good RTC solution anyway. I did have a problem with COMPACT which turned out to be with the fact that I had renamed the "word" variable to "@word" so as not to conflict with WORD since Tachyon has performed auto-case conversion for some time now. The funny thing was that in EASYFILE immediately after "word" which was being translated to "WORD" was DUP but since WORD is immediate it created a word variable called DUP. You can imagine what havoc that played!
However I will be changing a lot of these case conflicts such as here and HERE which were fine at the time when strict case had to be observed but I found that allowing lower case in place of upper case makes it easier to type interactively.
Now there's a problem with !PCB in that once it has been COMPACTed it is not detected by the boot routine which scans the RAM dictionary so the easy way around that is just redefine it again in the RAM dictionary as ": !PCB !PCB ;"
Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch
And I have a good working DS1302.fth module now as well.
Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.
Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch
And I have a good working DS1302.fth module now as well.
Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.
Looks as if your garden control is taking up around 3.5k of code memory. Care to share the code or some project details? What we need is a Tachyon project page/wiki/blog.
Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch
And I have a good working DS1302.fth module now as well.
Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.
Looks as if your garden control is taking up around 3.5k of code memory. Care to share the code or some project details? What we need is a Tachyon project page/wiki/blog.
I agree peter! I was intrigued by D.P.'s garden control.fth program as I daydream about an semi-automated greenhouse, and would like to see what everyone is doing with your epic contribution.
Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch
And I have a good working DS1302.fth module now as well.
Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.
Looks as if your garden control is taking up around 3.5k of code memory. Care to share the code or some project details? What we need is a Tachyon project page/wiki/blog.
I agree peter! I was intrigued by D.P.'s garden control.fth program as I daydream about an semi-automated greenhouse, and would like to see what everyone is doing with your epic contribution.
+1 currently I measure only temperatures, but eventually the irrigiation system and the solar system needs to be automated as well ...
so I would be happy to offer my constructive 'critic' ;-)
Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch
And I have a good working DS1302.fth module now as well.
Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.
D.P I am wondering - there is a DS1302.fth module in Peter'S Dropbox\MISC MODULES folder ...
did you extend this or write your own? - can you share your mods...
@Peter I did not find the DS1302 word in yesterdays EXTEND.fth ?? is is somewhere else?
Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch
And I have a good working DS1302.fth module now as well.
Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.
D.P I am wondering - there is a DS1302.fth module in Peter'S Dropbox\MISC MODULES folder ...
did you extend this or write your own? - can you share your mods...
@Peter I did not find the DS1302 word in yesterdays EXTEND.fth ?? is is somewhere else?
The section in EXTEND.fth for the DS1302 needs to be un-commented and a couple text lines need to be commented for the DS1302 to be included.
Yes I did that initial code for the DS1302. Here is a more current version.
@Peter, I'm in the middle of a rewrite of GARDENCONTROL.FTH, just have a commented out version to check for compile of the new framework with Juno. Will post when I have it ported to the P8 only module, it's actually to control the EBB and FLOW cycles of a Aquaponics system offering different cycles for day and night modes. All parameters are held in the battery backed ram on the DS1302 so it recovers what it was doing during power outages, reboots and equipment failures. I wrote this long ago it seems and my forth/tachyon has improved somewhat since then.
Okay, after not using COMPACT until all of the modules are loaded (except for the one I'm working on) there is now so much memory for me to waste on my DEADC0DE I can't believe it. This is fantastic! GARDENCONTROL.FTH builds on Juno and a P8 module now so just some more integration and I will post this up for code review.
Okay, after not using COMPACT until all of the modules are loaded (except for the one I'm working on) there is now so much memory for me to waste on my DEADC0DE I can't believe it.
AFAIK you can COMPACT after each moule you load, if you like.
You only leave the modules you work on uncompacted, so you have them in RAM dictionary and can FORGET them if you want to reload them.
So even with NW loaded there is plenty of space for an application.
And with the script execution non time critical code can be loaded, executed and forgotten, not consuming any RAM permanently.
And with the script execution non time critical code can be loaded, executed and forgotten, not consuming any RAM permanently.
I timed loading a normal "script" to scan and display the background timers and to compile and run to completion took 441ms. Timing the code itself it takes 154ms to execute and sector read about 1.5ms so almost 300ms was needed to compile about 20 lines of code and forget it afterwards. Obviously a couple of lines of code will be much faster, a single line to print out all printable ASCII characters takes 44ms total.
Create a file and open it:
$8000 mk RUNME
FOPEN RUNME
Read/write access (from beginning) and insert by printing a string to the file:
RW >FILE PRINT" CR $7F $20 DO I EMIT LOOP LAP CR .LAP\r\n" CON
Manually open the file (after closing) so I can time the whole launch and execution:
LAP " RUNME" FOPEN$ IF FINPUT THEN ok
CR $7F $20 DO I EMIT LOOP LAP CR .LAP
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
44.713ms ok
10ms of 44.7ms was actually printing out so it took around 34ms for a load and compile on a single line.
With the current files in dropbox I am getting reboots initially after power on issuing the first "ls" or "DIR" ? After the reboot everything seems fine. Even if I issue a "mount" first or a
"?SDCARD" after a power reset.
Also after reboot I am getting a LONG on the stack initially, I think I missed that this was a "feature" of the Juno?
Okay not with the files you just posted 2 minutes ago.
EDIT: okay got up and plugged this project in and it works great all of a sudden, I have no clue but ignore this post UFN. But I need to find the post about the LONG after reboot
Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730
PCB: P5555 +P8 Only (5555)
FREQ: 96MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $71B0...74D0 for 800
CODE: $0930...512D for 18,429 bytes (+352)
RAM: 8,323 bytes free
BUILD: FIRMWARE BUILD DATE 160809:005659 BOOTS: 46 runtime 85
BOOT:
MODULES LOADED:
40D3: EASYFILE.fth FAT32 Virtual Memory Access File System Lay
4FCD: DLVR-L30D.fth DLVR-L30D PSI Sensor 151108.1400 V0.3
3A79: SDCARD.fth SD CARD Toolkit - 160808.1330
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 16080
37E2: P8Only.fth P8 Only HARDWARE DEFINITIONS 141118.0000
3841: DS1302mini.fth DS1302 RTC Mini 160802.2100
34B6: COMPACT.fth TACHYON COMPACT EEPROM DICTIONARY 160809.13
ROMS
0848 VGA32x15
0236 HSSERIAL
1648 SIDEMU
1940 QUADUART
0196 MONO16
1900 F32
----------------------------------------------------------------
. 1397575506 ok
ls
Mounted 769A.5500-1694.FF80 NO NAME FAT32 7,944MB (32,)
NO NAME
RUNME
WOW! I am really impressed by the video on page 1! how much memory are you running? What hardware? Do you sell the hardware preloaded so I can configure the IP and put it on my network and play from there?
Sorry, for the questions that are probably answered in the 95 pages of posts, but I wanted to give you kudos, and jump right in, if possible.
Jump on in. Peter can commit on his hardware, but you can run Tachyon on any of the Parallax Propeller boards. 64K eeprom is best. For the TCP/IP stuff you need to add a Wiznet 5500 chip and the jack of course like THIS Peter also has some nifty hardware too, but just jump right in you will find help in this thread.
If someone wants to setup github then I don't have a problem with that, I just haven't bothered myself and I can continue to just do what I do and work with Dropbox although Dropbox is kinda handy and easy.
I'll give it a go.
Gonna grab core Tachyon Files now
UPDATE:
HERE is the link to the new Tachyon P1 GitHub Repository.
Let me know if you want other files tracked. Would be nice to let me know when stuff changes somehow so I can keep the library current.
If and when you want to try to pull and commit changes to GitHub let me know and I will grant the permissions.
@D.P, I'm appreciating your initiative with githubbing tachyon and lately cloned the repository in a few seconds - this is really fine for linux users. Thanks for this base work D.P
You questioned for further files to be added - although the file organization in the dropbox seems to be grown it is (!) an organization and our super developer and we all are already used to it.
As long as the dropbox and github are coexisting, using the same structure eases exchange/copy of files and maybe is more attracting Peter to join ...
Shouldn't we implement the compatible structure?
Or should we reorganize completely as you already started?
Hi there, current dropbox version: hardware: IOT5500, tried
/usr/local/bin/bstc.linux -p 2 "./Tachyon V3.0 JUNO.spin"
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object Tachyon V3.0 JUNO
Program size is 32656 longs
Compiled 4162 Lines of Code in 0.123 Seconds
We found a Propeller Version 1
Propeller Load took 11.476 Seconds
The kernel is configured to autodetect 5MHz or 10Mhz crystals but you have to activate the 96MHz configuration by using the ' comment trick before the { block comment then remove the ' comment from the 80MHz configuration.
If someone wants to setup github then I don't have a problem with that, I just haven't bothered myself and I can continue to just do what I do and work with Dropbox although Dropbox is kinda handy and easy.
I'll give it a go.
Gonna grab core Tachyon Files now
UPDATE:
HERE is the link to the new Tachyon P1 GitHub Repository.
Let me know if you want other files tracked. Would be nice to let me know when stuff changes somehow so I can keep the library current.
If and when you want to try to pull and commit changes to GitHub let me know and I will grant the permissions.
@D.P, I'm appreciating your initiative with githubbing tachyon and lately cloned the repository in a few seconds - this is really fine for linux users. Thanks for this base work D.P
You questioned for further files to be added - although the file organization in the dropbox seems to be grown it is (!) an organization and our super developer and we all are already used to it.
As long as the dropbox and github are coexisting, using the same structure eases exchange/copy of files and maybe is more attracting Peter to join ...
Shouldn't we implement the compatible structure?
Or should we reorganize completely as you already started?
Well we could use this tool. But I wanna make sure it's okay with Peter to do this. And I don't know how we could mark the submits with appropriate comments as needed. My original goal was to submit all the core files at the same time that build together and mark the submit comment appropriately. Guess we could mark each one of these as a release. I need to think more about this and boy does Tachyon move around alot, and fast.
Well we could use this tool. But I wanna make sure it's okay with Peter to do this. And I don't know how we could mark the submits with appropriate comments as needed. My original goal was to submit all the core files at the same time that build together and mark the submit comment appropriately. Guess we could mark each one of these as a release. I need to think more about this and boy does Tachyon move around alot, and fast.
Ok I didn't know about such a tool - this could help. Hmm. I have just hobbyists knowledge of git but I think it's worth learning. And it enables to coworking with many participants. I built my own branch
git checkout -b "proplem"
and it seems to be possible to switch back to master and to merge. Are you experienced with git - maybe you could write a small handout to give direction? With that one could start and research to get further information on git.
@Peter: 96 MHz was the right tip! Now kernel and EXTEND.fth are working. Uff. I'll try to run my statemachine again ...
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.
Scriptable tachyon would be such an improvement! It would be easier to guide newcomers step by step a la "do
sz EXTEND.FTH
then
sz this.FTH
then
sz that.FTH
. The dependency problems we are facing could be solved with Makefiles as already mentioned here. We could automate all these manual steps. All these processes would be inherently documented. This would boost productivity like this:
proplem@cheetah2 ~/prj/tachyon/git/Tachyon-P1 (git)-[proplem] % make iot5500
/usr/local/bin/bstc.linux -p 2 "./Tachyon V3.0 JUNO.spin"
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object Tachyon V3.0 JUNO
Program size is 32656 longs
Compiled 4162 Lines of Code in 0.133 Seconds
We found a Propeller Version 1
Propeller Load took 11.474 Seconds
stty -F /dev/ttyUSB0 115200 nl1 -hupcl
/usr/bin/time -f 'downloaded in %e seconds' -o /dev/stdout sh -c 'cat ./EXTEND.FTH > /dev/ttyUSB0'
downloaded in 9.31 seconds
The problem with this example is that setting serial comm parameters via stty don't work (for me) otherwise I could walk forward in this manner. zmodem/sz would return a code wether the download is successful - this would be a secure process. Or does anybody have an idea to achieve this in a similar way?
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.
Comments
But alas, from boot at least a minimal spin cog must run which can replace it with a PASM COGINIT.
Probably best to just have at least spin start one cog which could then load all of Tachyon.
A lot depends on what you want a minimal Tachyon system to be.
* Serial, and/or screen/keyboard.
* Do you require 64KB EEPROM or is 32KB ok? If 32KB what minimal configuration?
* Do you want to require an SD card?
FWIW a spin compiler can be avoided as we can handcode the tiny spin stub, if that is a desired outcome.
really minimal: Prop + crystal + EEPROM (xtreme even just prop if you load to RAM, without crystal - don't know if Tachyon could do that - currently with the timers etc. looks like not.
would be great if nothing else is mandatory.
So currently this is minimal possible.
But yeah, Tachyon works on just a Prop and crystal and normally at least 32k EEPROM is available but not necessary. For larger systems all that is required is the 64k EEPROM which is standard these days even for Parallax.
I just have to see how I can squeeze in a little more room for the network servers which normally fit without the extra baggage. So now I'm looking at a way to get even more out of the humble P1 by pushing past my previous goals. There's probably a lot of stuff I've already loaded that might never get used but I think I can manage to fit all this stuff in together at the same time and still have room for apps. There are even small apps that I compile and run directly from file too.
Are you now loading the cog drivers directly from SD card now? Does this mean Tachyon now requires an SD card?
I can certainly help out here.
BTW I have thought for some time that this is the WTG for big and usable prop designs.
But it's only when I uncomment the DS1302 stuff to include this?
And here is the timing for DS1302.fth that works with the chip FYI.
EXTEND
EEWORDS
run COMPACT
run BACKUP
DS1302mini.FTH
SDCARD
EASYFILE
DLVR-L30D.FTH
GARDENCONTROL.FTH
Thanks for everything.
However I will be changing a lot of these case conflicts such as here and HERE which were fine at the time when strict case had to be observed but I found that allowing lower case in place of upper case makes it easier to type interactively.
Now there's a problem with !PCB in that once it has been COMPACTed it is not detected by the boot routine which scans the RAM dictionary so the easy way around that is just redefine it again in the RAM dictionary as ": !PCB !PCB ;"
Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch
And I have a good working DS1302.fth module now as well.
Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.
Looks as if your garden control is taking up around 3.5k of code memory. Care to share the code or some project details? What we need is a Tachyon project page/wiki/blog.
I agree peter! I was intrigued by D.P.'s garden control.fth program as I daydream about an semi-automated greenhouse, and would like to see what everyone is doing with your epic contribution.
so I would be happy to offer my constructive 'critic' ;-)
did you extend this or write your own? - can you share your mods...
@Peter I did not find the DS1302 word in yesterdays EXTEND.fth ?? is is somewhere else?
The section in EXTEND.fth for the DS1302 needs to be un-commented and a couple text lines need to be commented for the DS1302 to be included.
Yes I did that initial code for the DS1302. Here is a more current version.
@Peter, I'm in the middle of a rewrite of GARDENCONTROL.FTH, just have a commented out version to check for compile of the new framework with Juno. Will post when I have it ported to the P8 only module, it's actually to control the EBB and FLOW cycles of a Aquaponics system offering different cycles for day and night modes. All parameters are held in the battery backed ram on the DS1302 so it recovers what it was doing during power outages, reboots and equipment failures. I wrote this long ago it seems and my forth/tachyon has improved somewhat since then.
BTW, PCB$ and PCB are now predefined in EXTEND so that it can report on it, you just need to change these two instead of defining them like this:
AFAIK you can COMPACT after each moule you load, if you like.
You only leave the modules you work on uncompacted, so you have them in RAM dictionary and can FORGET them if you want to reload them.
So even with NW loaded there is plenty of space for an application.
And with the script execution non time critical code can be loaded, executed and forgotten, not consuming any RAM permanently.
I timed loading a normal "script" to scan and display the background timers and to compile and run to completion took 441ms. Timing the code itself it takes 154ms to execute and sector read about 1.5ms so almost 300ms was needed to compile about 20 lines of code and forget it afterwards. Obviously a couple of lines of code will be much faster, a single line to print out all printable ASCII characters takes 44ms total.
Create a file and open it:
$8000 mk RUNME
FOPEN RUNME
Read/write access (from beginning) and insert by printing a string to the file:
RW >FILE PRINT" CR $7F $20 DO I EMIT LOOP LAP CR .LAP\r\n" CON
Manually open the file (after closing) so I can time the whole launch and execution:
LAP " RUNME" FOPEN$ IF FINPUT THEN ok CR $7F $20 DO I EMIT LOOP LAP CR .LAP !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ 44.713ms ok10ms of 44.7ms was actually printing out so it took around 34ms for a load and compile on a single line.
"?SDCARD" after a power reset.
Also after reboot I am getting a LONG on the stack initially, I think I missed that this was a "feature" of the Juno?
Okay not with the files you just posted 2 minutes ago.
EDIT: okay got up and plugged this project in and it works great all of a sudden, I have no clue but ignore this post UFN. But I need to find the post about the LONG after reboot
Sorry, for the questions that are probably answered in the 95 pages of posts, but I wanted to give you kudos, and jump right in, if possible.
Jump on in. Peter can commit on his hardware, but you can run Tachyon on any of the Parallax Propeller boards. 64K eeprom is best. For the TCP/IP stuff you need to add a Wiznet 5500 chip and the jack of course like THIS Peter also has some nifty hardware too, but just jump right in you will find help in this thread.
You questioned for further files to be added - although the file organization in the dropbox seems to be grown it is (!) an organization and our super developer and we all are already used to it.
As long as the dropbox and github are coexisting, using the same structure eases exchange/copy of files and maybe is more attracting Peter to join ...
Shouldn't we implement the compatible structure?
Or should we reorganize completely as you already started?
Thanks, proplem
CON { *** CLOCK MODES *** } { _clkmode = xtal1 + pll8x _xinfreq = 10_000_000 ' <--- AUTOMATIC 5 or 10MHz operation change at boot sysfreq = 80_000_000 '} '{ 6MHZ CRYSTAL _clkmode = xtal1 + pll16x _xinfreq = 6_000_000 sysfreq = 96_000_000 '}Well we could use this tool. But I wanna make sure it's okay with Peter to do this. And I don't know how we could mark the submits with appropriate comments as needed. My original goal was to submit all the core files at the same time that build together and mark the submit comment appropriately. Guess we could mark each one of these as a release. I need to think more about this and boy does Tachyon move around alot, and fast.
@Peter: 96 MHz was the right tip! Now kernel and EXTEND.fth are working. Uff. I'll try to run my statemachine again ...
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.
Scriptable tachyon would be such an improvement! It would be easier to guide newcomers step by step a la "do then then . The dependency problems we are facing could be solved with Makefiles as already mentioned here. We could automate all these manual steps. All these processes would be inherently documented. This would boost productivity like this: The problem with this example is that setting serial comm parameters via stty don't work (for me) otherwise I could walk forward in this manner. zmodem/sz would return a code wether the download is successful - this would be a secure process. Or does anybody have an idea to achieve this in a similar way?
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.