Shop OBEX P1 Docs P2 Docs Learn Events
How do I run P1 Tachyon5v7 without a terminal or SD Card? — Parallax Forums

How do I run P1 Tachyon5v7 without a terminal or SD Card?

dbpagedbpage Posts: 217
in PASM/Spin (P1)

Please point me to examples of how a spin method can pass messages to and from Tachyon5v7 on a P1 with no terminal connected. I have seen examples of reading from an SD Card, but I am interested in issuing commands between PUB/PRI methods and Tachyon5v7.

Comments

  • Mike GreenMike Green Posts: 23,101

    I'm not aware of any examples of what you're asking for. It's not impossible, but would require some sophisticated modifications to Tachyon. Can you explain a bit more just what you want to accomplish?

  • dbpagedbpage Posts: 217

    It is for an automatic portable battery operated device. The device has i2c sensors, a button, a display and an actuator.

    It would be OK for the PUB/PRI method to read Tachyon words from DAT, receive results, make decisions and issue new Tachyon words, a bit like what a user does interacting with Tachyon via a terminal.

    Peter Jakacki described using Tachyon for a data acquisition device. Once started the terminal is disconnected. I want to start/stop the device with a button press and run stand-alone for years.

  • bob_g4bbybob_g4bby Posts: 414
    edited 2022-03-24 10:42

    Hi @dbpage ,
    I guess you're more at home programming in Spin, which lacks functions that Tachyon could provide. Your best choice is the language you've most experience with. Learning forth and writing a commercial grade application straight off is not easy nor fast. I've dabbled with Forth for many years, so my choice would be to build the application in a modular fashion in forth alone:-

    1. i2c driver 1
    2. i2c driver 2 etc.
    3. button(s) driver - eventually mimic the KEY function here and revector Forth terminal input from this
    4. display driver - eventually mimic the EMIT function here and revector Forth terminal output to this
    5. actuator driver
    6. main program

    Get 1-5 going one at a time by interactive manual test from the terminal, then integrate that known working code into 6. Few 'test harnesses' are needed with Forth if you program incrementally like you should. Bugs are found earlier than in other languages that way.

    My choice of hardware would be either a P1 running Tachyon on as few cogs as are needed or a PIC running Flashforth and its multitasker. Both can be set to automatically start the user program on switch on. Communication between 'modules' could be via variables acting as mailboxes with a handshake if needed.

    Another useful platform might be an ESP32 - there is ESP32forth and other more mainstream languages like B4X or the Arduino system available. (The latter would allow you to use other peoples code and might save a lot of time)

    I recently programmed a PIC to control a stepper motor tuned magnetic loop antenna. The PIC had to listen to an interrupt driven rotary control, poll a pushbutton, drive the stepper, poll a pulsing input for a motor stall and display the system state on a 2 line LCD display. This was all written in Flashforth and has run 24/7
    Cheers Bob

  • bob_g4bbybob_g4bby Posts: 414
    edited 2022-03-24 12:59

    How do I run P1 Tachyon5v7 without a terminal or SD Card?

    Tachyon does not need an SD card to run, it is stored in flash ram. Getting a user tachyon program to autorun on switch-on:-
    Suppose our end user application is this: -
    pub TEST 0 BEGIN 1+ DUP . SPACE KEY UNTIL DROP ;
    To get that to run on switch on:-

    ' TEST +INIT
BACKUP

    When tachyon is reset, you will see TEST counting in the terminal until a key is pressed and you are returned to the tachyon system
    To remove that program:-

    FORGET TEST
!INITS
BACKUP
  • dbpagedbpage Posts: 217

    Bob,
    Thank you for the examples, this is helpful.

    My spin/pasm programming is in beta test and nearing completion. Your process pretty much describes how I developed the application, with the added layers on top of a minimally viable product.

    I am interested in demonstrating Tachyon for i/o with i2c sensors, RTC, voltmeter, display, i/o expander and interact with spin/pasm logic. I do not intend to port the logic to Tachyon, only the device i/o.

    Is it appropriate to give Tachyon all the words it needs and then have spin/pasm start/stop various pre-programmed Tachyon loops and share data through common memory locations?

  • bob_g4bbybob_g4bby Posts: 414

    I'm afraid I can't answer your question, I only use Tachyon. As has been pointed out, no Spin compatible Tachyon has been published to my knowledge.

  • dbpagedbpage Posts: 217
    edited 2022-03-24 22:10

    Deleted

  • dbpagedbpage Posts: 217
    edited 2022-03-24 22:08

    Bob
    Your examples and questions now solidify my thinking.

    I can arrange it so that Tachyon runs independently doing its thing, or not, based on signals from my spin/pasm logic. Spin/pasm runs independently making decisions and issuing signals to Tachyon. It's a bit like how two running cogs can interact, perhaps the same.

    Tachyon uses EC@ and EC! to fetch and store to/from EEPROM. I use F-RAM in lieu of EEPROM. This provides a signaling path between spin/pasm methods running on separate cogs. Of course, I can use pin registers as well.

    There must be a way to share RAM locations, but I'm not there yet.

    In my application, spin accesses sensor data. I currently use what I call a structured data array (SDA), consecutive longs defined in the main cog and the starting address passed to other cogs. If I can get Tachyon to put sensor data into the SDA, I'm all but set.

    Thank you for prompting me in meaningful ways. I remain open to your suggestions.

  • Christof Eb.Christof Eb. Posts: 1,197
    edited 2022-03-25 06:58

    To share the startadress of a buffer I would load a magic number like 1234567 into it and let the other side scan Ram for it. Not nice but should work.

  • bob_g4bbybob_g4bby Posts: 414

    Hi @dbpage ,
    That's encouraging news - a Spin based executive with a Tachyon I/O suite is certainly a novelty. If you can write up a tiny example of how to do it in the Forth section of the forum, that would be appreciated by quite a few of us, I'm sure.
    Cheers, Bob

  • msrobotsmsrobots Posts: 3,709

    old but the basics are done to integrate spin and TAQOZ on P2

    https://forums.parallax.com/discussion/170371/integrating-taqoz-with-spin2gui-fastspin-success#latest

    Mike

  • dbpagedbpage Posts: 217

    Thinking out loud...

    I see that my P1 Propeller Activity Board build of Tachyon5v7 M4 Preprocessor Build fills all available memory. There's no room left for spin, if left intact.

    A co-processor model in which one P1 runs spin/pasm and another P1 runs Tachyon defeats the purpose.

    I have yet to confirm that my target P1 app is too large to port to Tachyon, but I believe it is. My decision logic consumes over 900 longs and user dialog [text] consumes over 250 longs plus over 4000 longs for executive functions, excluding hardware i/o, i2c and timing code. I wonder how much space is available for the user applications in Tachyon.

    I learned a lot about Forth and Tachyon and I see its advantages and disadvantages. Tachyon is an amazing accomplishment. I'll keep poking at it. Eventually, I see P2 is in my future.

  • bob_g4bbybob_g4bby Posts: 414

    That's a show stopper to adopting Tachyon.
    Tachyon does occupy a large portion of Hub RAM. It also has a fair amount of irrelevant stuff inside it (as far as a user application is concerned). Removing that would still not release enough RAM for you, I think.
    Taqoz or Taqoz Reloaded on the P2 occupies a much smaller portion of total Hub RAM and is far better suited to a large user application - but a change of platform may not be an option for you.

  • dbpagedbpage Posts: 217

    To All-
    Thanks for your help. A change of platform is in our future and we'll revisit at that time.

    Thanks!
    Dennis

  • bob_g4bbybob_g4bby Posts: 414
    edited 2022-03-29 10:35

    As a postscript to this thread - cutting down Tachyon to only what you need might help. The stock version of Tachyon might only have around 6500 bytes free. My version of Tachyon is already smaller than stock - notice the EASYFILE module is missing. Here's my boot up message:-

     Propeller .:.:--TACHYON--:.:. Forth V5rÿ 570190926.2300
  *** MODULES ***  Propeller .:.:--TACHYON--:.:. Forth V5rÿ 570190926.2300
3422: EXTRAS
306E: TOOLS            DEV TOOLS
1AC0: EXTEND           Primary extensions to TACHYON V5 kernel  - 200514-0100


FREQ = 80.00MHZ
*** INITS ***
NO ROMS
*** I2C ***
$A0 EE/RTC
I/O =  31 :UHUU 27 :UU~U 23 :~~~~ 19 :~~~~ 15 :~~~~ 11 :~~~~ 7 :~~~~ 3 :~~~~
INTERCOM: &00.00.00.55 @294,967,295

CODE:$3A82 = 14466 bytes
NAME:$5B1E = 6370 bytes
DATA:$75BC = 172 bytes
FREE:      = 8348 bytes

    Memory can be recovered by 'forgetting' modules that aren't needed. So I remove EXTRAS and TOOLS:-

    TF5> FORGET TOOLS
TF5> .STATS ---
CODE:$306E = 11886 bytes
NAME:$5CDA = 5926 bytes
DATA:$75BC = 172 bytes
FREE:      = 11372 bytes

    Slightly more memory can be recovered by pruning the dictionary of all entries marked private - these are system helper words which aren't generally useful for user programs (so why keep a reference to them?):-

    TF5> RECLAIM
Removing !DEFER
Removing UNDEFER
...
Removing ulong
Removing HZCON
Reclaimed 624 bytes
TF5> .STATS ---
CODE:$306E = 11886 bytes
NAME:$5F4A = 5302 bytes
DATA:$75BC = 172 bytes
FREE:      = 11996 bytes

    The upshot of that is that my free space went from 8348 bytes to 11996 bytes, a gain of 3648 bytes by discarding bits of Taqoz that would never be used in a particular application. Probably more to be gained if the P1 was originally loaded with the stock version of Tachyon. Maybe free space would go from 6586 to 11996 bytes - a gain of 5410 bytes.

    The cut down version of Tachyon can be saved to EEPROM using the BACKUP word.

    Just a thought...

  • Christof Eb.Christof Eb. Posts: 1,197

    Hi,
    If you have a 64k eeprom, you can use 32k of it for example for source code of overlays.

  • dbpagedbpage Posts: 217
    edited 2022-03-29 12:45

    I reviewed the the P1 Tachyon memory usage and recognize that significant memory space can be recovered. Your postscript gave me specific examples from Taqoz that are most helpful.

    The target app uses a significant fraction of RAM for code that does not need to co-exist, making overlays possible. User dialog text is currently in upper 64K memory. We are trying to keep as much F-RAM available as possible for data, but overlays are a constant consideration.

    The target app in Beta test has about 350 longs FREE/STACK. The target app is less memory efficient than Tachyon for the functions to assign to Tachyon.

    Significant memory savings are available for both Tachyon and our app, according to our collective analyses.

    Thank you for your postcripts.

    Dennis

Sign In or Register to comment.