TACHYON V3 - planned features plus what would you like to see?
Peter Jakacki
Posts: 10,193
I'm getting ready to launch V3 of Tachyon and already have code and ideas for certain features but while I'm at it are there any reasonable requests for features that you would like to see in V3? Bear in mind that the philosophy with Tachyon is to make Forth fast and make it small without having to include assembler in the source. The few exceptions that require assembler are better handled by LOADMOD/RUNMOD and are compiled in the Spin tool. I may introduce a Maths cog that adds floating point (yuck) and trig functions etc but I need to finalize how to make it work seamlessly with the application. V3 will also allow cogs to be loaded with PASM from Flash/SD as well as compiling source direct from such memory, so a lot of the features may depend upon something as simple as a $1 serial Flash chip which will only require two extra I/O to add to existing systems.
Latest: At present there is a TIMING task which does some background stuff including maintaining countdown timers. This will be reutilized as the coprocessor cog in that it hosts Maths, SPI, I2C, timing, and dictionary search functions. So during a build the console task passes the words it finds to the coprocessor which uses it's SPI and I2C routines to search the dictionary and return with the name field address and also the code field. As new words are added to the dictionary they are passed to the coprocessor to append to the dictionary file where-ever that may be in EEPROM, SPI Flash, or SD. This division of labor is logical and possible for the Propeller and it's unique architecture. So the main application cog doesn't have to worry about maintaining or searching the dictionary not have it's precious 32K hub RAM taken up by it either. There will be a general-purpose buffer that the coprocessor uses of around 2K that includes Flash/SD blocks and dictionary caches. I think I could refer to this cog as the Auxiliary Processing Cog or APC.
There's also this (quote from another post)
Features:
Latest: At present there is a TIMING task which does some background stuff including maintaining countdown timers. This will be reutilized as the coprocessor cog in that it hosts Maths, SPI, I2C, timing, and dictionary search functions. So during a build the console task passes the words it finds to the coprocessor which uses it's SPI and I2C routines to search the dictionary and return with the name field address and also the code field. As new words are added to the dictionary they are passed to the coprocessor to append to the dictionary file where-ever that may be in EEPROM, SPI Flash, or SD. This division of labor is logical and possible for the Propeller and it's unique architecture. So the main application cog doesn't have to worry about maintaining or searching the dictionary not have it's precious 32K hub RAM taken up by it either. There will be a general-purpose buffer that the coprocessor uses of around 2K that includes Flash/SD blocks and dictionary caches. I think I could refer to this cog as the Auxiliary Processing Cog or APC.
There's also this (quote from another post)
V3 will allow more memory to be free because it will maintain most of the names in EEPROM/Flash but when it comes to creating a "build" during which time the system is not normally running an app it will use another cog to cache from EEPROM/Flash and search the dictionary etc. This way the runtime Tachyon cog(s) can have a few more goodies loaded as there are 24 longs taken just by the CMPSTR instruction and it's really only needed for fast loads. V3 will also introduce some other enhancements including compile-time-only headers and code (discarded at the end of a build). Seeing that serial Flash is so cheap and small it makes sense to allow source modules to be loaded from serial Flash or SD so that a build would only need user code loaded through the console and it could just ask to "include L6470.fth" for instance. If Flash or SD exists it makes sense to save new source code to that first and then compile which should be a far more efficient way of doing things. I've got some 8M byte SPI chips as well as the 1M byte ones ready for P2 and many of my systems include serial Flash as well as SD memory. To add SPI Flash to existing systems only requires 2 I/O as I frequently safely double-duty the I2C bus lines for SCK and MOSI. Then there's the P2 version which is not so restricted.....
Features:
- Compile-time only headers (more runtime memory available)
- Compile-time only dictionary (leaves dictionary in EEPROM or Flash normally)
- Indexed LOADMOD/RUNMOD PASM modules (more than one)
- Load source or cog images direct from Serial Flash/SD (includes images for serial coms, video, etc)
- Kernel support for Flash file storage (EEPROM/SPI Flash/SD)
- BACKUP/RESTORE to Flash
- APC - Auxiliary Processing Cog - handles Maths, SPI, I2C, timing, and dictionary.
- <more to come>
Comments
I wouldn't have a problem with using a serial Flash chip either - pity that the activity board doesn't have a socket for one, but wiring one up isn't a big deal. I plan to order some of these based on a pointer from "jazzed" (is it what you are using?) - http://www.digikey.com/product-detail/en/W25Q80BVDAIG/W25Q80BVDAIG-ND/2208452
I would like to try out Tachyon on a simple robot sometime this year. Sometime could you discuss your forth development process? Maybe it will change with V3 based on having a local filesystem. But I would like to understand how you make use of the REPL for experimentation, then do your edits on a host, and redownload and test,... It seems easy to get mixed up this way, so I'm interested in the process that you've developed.
I use the same Flash chip as well as that is the one we would use for P2. There's also the 64M bit chip that's a wider package but will still fit on the same footprint if needed.
As for trying out Tachyon it really is a matter of trying it out since it is so easy to do so. Forth allows you to "try out" stuff interactively and hone the process rapidly so when you design your program top down you know what will work and what won't before you paint yourself into a corner. The other thing is that in the process you just work out much better ways of doing things. The edits on the host are mainly when you are incorporating your "tests" into the main body of code or simply doing copy and paste of snippets. So, go on, hookup some motors or sensors to a board and load Tachyon onto it then connect your serial terminal and start playing.
EDIT: added a link to the Tachyon Dropbox folder, just go into the binaries folder and grab a binary image to suit 5 or 10MHz set for 115,200 baid (easy to change)
I usually have sd cards on my boards... :-)
Just a question:
If it is possible to load pasm code it means it will be possible to load pasm object (dr Acula's cogjets style)? Would in this case a float support come from F32?
Massimo
Just had a look at F32 so if it is complete then I might just launch it in it's own cog then as there wouldn't be much room left for anything else. This might be one of the first objects to be integrated into V3.
I'm not sure what cogjets are though but I will be more open to running pasm objects with this Flash memory approach as Flash is fast to load.
http://forums.parallax.com/showthread.php/130537-Cogjects-load-cog-code-from-SD-and-save-hub-ram
Anyway the possibility to adapt existing pasm objects and run them in tachyon wold be a great opportunity. More so if we could be able to do that and contribute to a pool of tachyon objects requiring little or no intervention on your side.
Massimo
Since the APC will handle the dictionary searches which are for the moment confined to hub RAM it can do so very quickly because it is totally in PASM, all the calling cog has to do is pass the command and address of the string it wishes to find after which the APC will return with a result. Initially I will leave the dictionary management to the Tachyon VM cog but once the APC becomes responsible for managing a virtual dictionary space which can exist in serial Flash or SD then extra commands will be added to allow words to be added or deleted from the dictionary. Some trig and float functions will be added for testing and this may also lead to the RUNMOD functions being moved across to the APC, especially serial Flash and SD.
Besides the console output, dictionary, timing, and maths functions it also makes sense for the APC to compare port pins against a mask on every internal loop and use this to debounce and latch/count button or pulse inputs.
I can also see that additional APCs or GPUs etc can be employed that monitor the same command channel and pick off the commands that they can handle which the main APC would ignore. I think that the multichannel UART object would be adapted to work through this channel as well so it's only necessary for a calling cog to know the address of the command channel which will be fixed in memory.
This approach offloads these dedicated functions from the pure Tachyon Forth CM cog(s) allowing them to handle the application at high speed with the minimum of fuss and with a small hub RAM footprint. It's only on a multicore architecture that this approach makes any sense and is superior but it's also necessary because of the small amount of memory for each cog.
How about a BS2 lexicon extension that might allow those that have held on to PBasic to migrate all the way up to the Propeller2. I think you already have a lot, but it might need some minor renaming to be consistent with what the PBasic users are familiar with.
I suspect that there is a group of BS2 users that were put off by Spin and just hung back. And they may not really want a Basic on the Propeller. But the fact that Forth is interactive may lull them over.
Maybe I am dreaming... maybe not. I just still think there is more market potential in new users than expert microcontroller programers. Arduino showed that most people that buy microcontroller for fun, just want a warm and fuzzy programing environment.