Shop OBEX P1 Docs P2 Docs Learn Events
TAQOZ - Tachyon Forth for the P2 BOOT ROM - Page 17 — Parallax Forums

TAQOZ - Tachyon Forth for the P2 BOOT ROM

1141517192038

Comments

  • MJBMJB Posts: 1,235
    twm47099 wrote: »
    Peter,
    I am going to experiment with an MCP3202 ADC. While I intend to eventually use the Smart Pin SPI mode, I wanted to first bit bang it as a way learn some more about forth and the P2ES. It is something I've done with other languages and the P1.

    I hope to eventually use the ADC Smart pin mode instead of the 3204.

    Tom

    search for SPI in TAQOS.SPIN2 for the bitbanged SPI routines
  • twm47099 wrote: »
    Peter,
    I am going to experiment with an MCP3202 ADC. While I intend to eventually use the Smart Pin SPI mode, I wanted to first bit bang it as a way learn some more about forth and the P2ES. It is something I've done with other languages and the P1.

    I hope to eventually use the ADC Smart pin mode instead of the 3204.

    Tom

    There are SPI instructions that will write up to 32 bits in 2us @180MHz so these are instructions you could look at later on as well as the Smart pin modes, which aren't very well documented so I haven't tried them yet.

    Bit banging serial at the low level usually involves shifting data one bit at a time, testing a bit, and setting an output then clocking it etc. Here's a simple send serial method that can transmit just the number of bits you need. Reading involves the reverse where you read data and assemble while clocking, and justify and flip msb/lsb if needed at the end (sending will justify and flip at the start).

    This is about the most basic as it gets method and takes about 22us to send 4 bits @180MHz.
    --- define SPI pins
    0   := *SCLK    1   := *MOSI    2   := *MISO    3   := *SS
    
    --- Send n bits of data over SPI bus and leave chip selected
    pub SEND ( data bits -- )  
    --- reset/idle          select   justify & flip msb<>lsb 
        *SS HIGH *SCLK LOW *SS LOW SWAP 32 3RD - << REV ( bits flipdata ) SWAP 
          FOR 
    ---     set MOSI high or low according to next bit of data
            *MOSI OVER 1 AND IF HIGH ELSE LOW THEN    
    ---     clock data
            *SCLK HIGH *SCLK LOW
    ---     shift data (actually performs a SHR)
            2/
          NEXT
        DROP
        ;
    

  • twm47099twm47099 Posts: 867
    edited 2019-01-01 03:45
    Peter,
    Thanks for the information. I had tried writing the section that would take the command and transmit it to a pin MSBFIRST. I originally wrote it so the program would print each bit (1s and 0s) to the terminal and flash 2 LEDs for each bit (one if HIGH and the other if LOW) so I could see if it worked. I tend to use a lot of variables, but see how you use constants where appropriate. I modified the original code to remove the prints & flashing LEDs and this is what I have so far:
    0   := *SCLK    1   := *MOSI    2   := *MISO    3   := *SS     \ As used by PJ
    long numbits
    
    : sendcmd  ( data numbits )
    32 swap -  ( data numbits -- data 32-numbits )
    << dup  (  -- data shifted to MSB ) 
    numbits @  0 DO 
         1 rol dup 1 AND  
          if *MOSI high 
            else *MOSI low 
            then 
    ---     clock data  from PJ
            *SCLK HIGH *SCLK LOW
    loop  drop ;
    
    
    I did not test the modified code yet, and I want to make sure I understand how yours works.
    Thanks again,
    Tom
  • Hi Tom,

    Stack notation does not set anything, it is only a comment. So ( data numbits ) is totally ignored therefore "numbits @" will simply read the default 0 since nothing has been stored to it. Better to preserve the numbits on the stack, using a copy (in my case with the 3RD word) to calculate the left justification and then I SWAP the stack and use FOR since there is no need for a more complex ADO LOOP. Using REV is a quick way of flipping all the bits at once where bit31<->bit0 and bit30<->bit1 etc.

    Since there are only two parameters it doesn't make any sense to use variables, just move then around the stack as needed. It's very rare that you need variables inside a function especially if you have factored the code in such a way that makes it easy for each function to manipulate the stack.

    My sequence with SWAP 32 3RD - << REV ( bits flipdata ) is a quick and efficient way of doing that for instance as you can see from this sequence:
    ( data bits ) 
    SWAP ( bits data ) 
    32 ( bits data 32 ) 
    3RD ( bits data 32 bits ) 
    - ( bits data 32-bits ) 
    << ( bits data_left_justified ) 
    REV ( bits data_flipped )
    

    BTW, There is also the 1& word which is equivalent to 1 AND but much faster.
  • Peter,
    Thanks for catching the numbits error. I sometimes get in trouble when I change from test code (with printing & other debug features). That's what happened this time. When I was debugging, after I defined sendcmd, I used the following to call it (pinnum was a variable in the earlier version, 26 was the "data")
    5 numbits ! 2 pinnum ! 26 numbits @  sendcmd
    

    That way I could test the code on different numbers of bits & data,
    One problem I have is being too verbose. A lot of my forth code looks more like Reverse Polish BASIC :smile: I'm trying to carefully follow your programs since they are much more efficient.
    Thanks for the info on 3rd and 1&. There are a lot of TAQOZ words that I don't know yet.
  • Tom, The SEND example I gave takes two parameters just so you can specify exactly the number of bits you need to send.

    What helps I find is using a comment row rather than a column since I tend to cram a few words together on the one line, especially if they are closely related and having the line above allows me to spell it all out if it need be. But we are always encouraged to factor into smaller words that are easily understood. Another benefit of factoring wisely and after choosing an appropriate name is that you hardly need comments:
    --- define SPI pins
    0   := *SCLK    1   := *MOSI    2   := *MISO    3   := *SS
    
    pri SENDBIT ( data -- data/2 )			*MOSI OVER 1 AND IF HIGH ELSE LOW THEN 2/ ;
    
    pri CLOCKBIT   					*SCLK HIGH *SCLK LOW ;
    
    pri SENDBITS ( data bits -- ) 			FOR SENDBIT CLOCKBIT NEXT DROP ;
    
    pri START       				*SS HIGH *SCLK LOW *SS LOW ;
    
    pri FIXBITS ( data bits -- data2 bits )		SWAP 32 3RD - << REV SWAP ;
    
    --- Send n bits of data over SPI bus and leave chip selected
    pub SEND ( data bits -- )			START FIXBITS SENDBITS ;
    
  • twm47099twm47099 Posts: 867
    edited 2019-01-01 05:17
    Peter,
    Your last example is very readable and is the classic method of defining small bite size words and then defining the one word that ties them together. Is there a disadvantage in performance or memory use (thinking about the P1 or the P2 ROM) from factoring that way? And I see the advantage of line comments.

    Tom
  • Tom, there is always a decrease in speed but not by much. The only real test is a real test, so I ran both with 4 bits of data and compared the results.

    The original all-in-one
    TAQOZ# 0 4 LAP SEND LAP .LAP 4,041 cycles= 22,450ns @180MHz ok
    

    The factored code
    TAQOZ# 0 4 LAP SEND LAP .LAP 4,737 cycles= 26,316ns @180MHz ok
    

    But with one very minor change where we let SENDBIT fall through to CLOCKBIT by removing the ; and then only using SENDBIT in the FOR NEXT loop:
    TAQOZ# 0 4 LAP SEND LAP .LAP 4,457 cycles= 24,761ns @180MHz ok
    

  • Well I'm embarrassed, but I've learned a lot. Running my "Reverse Polish Basic" version with variables it is over twice as long.
    4 numbits ! 11 numbits @  lap sendcmd lap .lap 4193 cycles = 52.412us  ok
    

    My number of cycles is actually less than your longer versions, but the time is twice as long. Is that due to the delays in fetching the variable?

    Tom
  • This is a quick test with the .LAP word in EXTEND as the ROM built-in one might not be reporting correctly.
    TAQOZ# 4 numbits ! 11 numbits @  lap sendcmd lap .lap 4,169 cycles= 23,161ns @180MHz ok
    TAQOZ# 8 numbits ! 11 numbits @  lap sendcmd lap .lap 7,561 cycles= 42,005ns @180MHz ok
    

    So it still takes longer than the non-factored stack version which takes 4041 cycles vs the 4169 for the one that uses variables although the critical timing is the loop itself. But there is no real reason to use variables unless you want to set and forget like this:
    : SBITS  numbits ! ;
    4 SBITS
    $0C SEND
    $03 SEND
    etc
    
    But having to store to a variable when it is much easier to manipulate the stack isn't very practical.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-01-06 00:14
    The latest version of TAQOZ is coming together and will be stored as a binary image in the ROM to be decompressed into RAM so we can cram a lot more into there. Since it no longer needs to be compiled along with Chip's and Cluso99's boot code, it no longer needs to be the mix of P2ASM code and data structures that it had to be. So now I have stripped out sections of the Forth code so that I have a minimal kernel which can then run on the P2 and then compile Forth source code through the terminal.

    This memory image can then be compressed and the only P2ASM code I need to integrate into the boot ROM is the decompression routine which may only use 100 longs or less.

    I'm thinking too that I can write an SD format and general disk utility tool that can be pasted in as needed but if we had a larger ROM than anything including a P2 assembler is possible to have just built into the P2 itself.
  • Sounds very good Peter. So far, roughly how much extra space did you manage to free up using the decompression routines you have been playing with? And what extra features have you been able to, or hope to, add to TAQOZ to make use of this larger space?
  • Cluso99Cluso99 Posts: 18,066
    Nice progress Peter! Cannot wait to see what you've done :smiley:
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-01-06 08:41
    I'm shooting from the hip here but I figure if I make it compelling enough with a built-in assembler that handles standard P2ASM, AND includes disk tools and formatting, AND can talk via the serial console OR via VGA and keyboard, then maybe a larger ROM is something that Chip would consider since he already said that it is possible. This is not to say that PC tools don't have their place, but the thing is that they do have their place, and there is room for other kinds of tools that can reside on the P2 or mobile devices. Having tools on the P2 makes it easier to develop tools on other platforms, including PCs.
  • Cluso99Cluso99 Posts: 18,066
    I'm shooting from the hip here but I figure if I make it compelling enough with a built-in assembler that handles standard P2ASM, AND includes disk tools and formatting, AND can talk via the serial console OR via VGA and keyboard, then maybe a larger ROM is something that Chip would consider since he already said that it is possible. This is not to say that PC tools don't have their place, but the thing is that they do have their place, and there is room for other kinds of tools that can reside on the P2 or mobile devices. Having tools on the P2 makes it easier to develop tools on other platforms, including PCs.
    +1
    But, there may not be space anymore, with all the added ADC logic :(
  • Cluso99 wrote: »
    +1
    But, there may not be space anymore, with all the added ADC logic :(

    Well I just want to see the equivalent microphone to VGA demo that they ran so "easily" on the P1 :)
    I'm sure with the P2's versatile ADC modes it could probably detect sound vibrations directly in the silicon itself, or at least with a bit of wire :)


  • I'm shooting from the hip here but I figure if I make it compelling enough with a built-in assembler that handles standard P2ASM, AND includes disk tools and formatting, AND can talk via the serial console OR via VGA and keyboard, then maybe a larger ROM is something that Chip would consider since he already said that it is possible. This is not to say that PC tools don't have their place, but the thing is that they do have their place, and there is room for other kinds of tools that can reside on the P2 or mobile devices. Having tools on the P2 makes it easier to develop tools on other platforms, including PCs.

    Sounds awesome. Really hope you can get an assembler in there with VGA/kbd, would be amazing to have that built in.
  • zappmanzappman Posts: 418
    edited 2019-01-07 00:27
    Can / could TAQOZ support "DS1302 Real Time Clock Modules"?

    There has been a lot of talk about which 'SD Cards" TAQOZ will support and how TAQOZ might format them.

    I think it would be a great, if TAQOZ could use the correct time and date from a "DS1302 Real Time Clock Module" or a similar part, when "writing to" or "formatting" a SD Card.

    A "DS1302 Real Time Clock Module" is one of the first things I plan to put on my "64006-ES(e) - Mini-Prototype board"
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-01-07 01:05
    zappman wrote: »
    Can / could TAQOZ support "DS1302 Real Time Clock Modules"?

    There has been a lot of talk about which 'SD Cards" TAQOZ will support and how TAQOZ might format them.

    I think it would be a great, if TAQOZ could use the correct time and date from a "DS1302 Real Time Clock Module" or a similar part, when "writing to" or "formatting" a SD Card.

    A "DS1302 Real Time Clock Module" is one of the first things I plan to put on my "64006-ES(e) - Mini-Prototype board"

    RTC support for sure, DS1302 maybe not. Why? Well I used those chips around 20 years ago but I favor I2C bus devices and DS3231M style chips even more since they don't need a crystal and are more accurate. Anything SPI bus requires dedicated pins whereas I2C can be shared among many devices. At present I am checking to see whether P58 and P59 of the boots pins can be used since that would not require any other dedicated pins.

    The RTC routines in TAQOZ V2 include a background timer function that tracks milliseconds from which time stamps and time and date are read without having to access the slow and awkward RTC chip. The RTC chip itself is read on boot and the time converted to milliseconds. At midnight the millisecond timer resynchronizes with the RTC and thereby also updates the date and day info. Reading a global variable for timestamp is way faster than trying to serially read a chip with archaic BCD registers.
  • zappman wrote: »
    Can / could TAQOZ support "DS1302 Real Time Clock Modules"?

    There has been a lot of talk about which 'SD Cards" TAQOZ will support and how TAQOZ might format them.

    I think it would be a great, if TAQOZ could use the correct time and date from a "DS1302 Real Time Clock Module" or a similar part, when "writing to" or "formatting" a SD Card.

    A "DS1302 Real Time Clock Module" is one of the first things I plan to put on my "64006-ES(e) - Mini-Prototype board"

    RTC support for sure, DS1302 maybe not. Why? Well I used those chips around 20 years ago but I favor I2C bus devices and DS3231M style chips even more since they don't need a crystal and are more accurate. Anything SPI bus requires dedicated pins whereas I2C can be shared among many devices. At present I am checking to see whether P58 and P59 of the boots pins can be used since that would not require any other dedicated pins.

    The RTC routines in TAQOZ V2 include a background timer function that tracks milliseconds from which time stamps and time and date are read without having to access the slow and awkward RTC chip. The RTC chip itself is read on boot and the time converted to milliseconds. At midnight the millisecond timer resynchronizes with the RTC and thereby also updates the date and day info. Reading a global variable for timestamp is way faster than trying to serially read a chip with archaic BCD registers.

    Cool :cool: , so a Clock Board that uses a DS3231, like say Adafruit DS3231 Precision RTC Breakout or ChronoDot - Ultra-precise Real Time Clock should work?
  • zappman wrote: »
    zappman wrote: »
    Can / could TAQOZ support "DS1302 Real Time Clock Modules"?

    There has been a lot of talk about which 'SD Cards" TAQOZ will support and how TAQOZ might format them.

    I think it would be a great, if TAQOZ could use the correct time and date from a "DS1302 Real Time Clock Module" or a similar part, when "writing to" or "formatting" a SD Card.

    A "DS1302 Real Time Clock Module" is one of the first things I plan to put on my "64006-ES(e) - Mini-Prototype board"

    RTC support for sure, DS1302 maybe not. Why? Well I used those chips around 20 years ago but I favor I2C bus devices and DS3231M style chips even more since they don't need a crystal and are more accurate. Anything SPI bus requires dedicated pins whereas I2C can be shared among many devices. At present I am checking to see whether P58 and P59 of the boots pins can be used since that would not require any other dedicated pins.

    The RTC routines in TAQOZ V2 include a background timer function that tracks milliseconds from which time stamps and time and date are read without having to access the slow and awkward RTC chip. The RTC chip itself is read on boot and the time converted to milliseconds. At midnight the millisecond timer resynchronizes with the RTC and thereby also updates the date and day info. Reading a global variable for timestamp is way faster than trying to serially read a chip with archaic BCD registers.

    Cool :cool: , so a Clock Board that uses a DS3231, like say Adafruit DS3231 Precision RTC Breakout or ChronoDot - Ultra-precise Real Time Clock should work?

    Support for this is not in the current ROM but of course you can paste in the code for it as soon as I make it available but the next ROM should automatically detect if it is connected and use those settings, very much like it does now in Tachyon for the P1.

    A lot of those boards are huge whereas I just use a small 8-pin SOIC chip with a small supercap, so much simpler and no lithium safety worries or dead battery.

  • Like a few others have mentioned, I am having a hard time picking up Forth/TAQOZ. Fundamentally, Forth is pretty straight forward, but I am finding that I'm having two recurring problems:

    1. The vocabulary (words?) are not intuitive to me. I'm guessing this is because it doesn't follow naming patterns I've become accustom to in other languages. I'm also assuming this is somewhat like learning any other language's support library APIs. That said, since it looks like TAQOZ is here to stay, Parallax needs an official page that documents all of the built-in words. I think Peter already has one you can start from. Secondly, there needs to be a HELP (or similar) word that tells the user where to find that documentation.

    2. I'm finding Forth to be a write-only language. When I am thinking through the steps to write a snippet, I find it fairly straight forward (barring issue #1). However, when I read other people's snippets, I find it very slow and cumbersome. This is particularly the case when trying to divine one-character words, which are incomprehensible without external documentation. Again, I admit this may just be a matter of familiarity. I don't even know how many of these words are "standard Forth" (assuming that's even a thing).

    If anyone has suggestions on how to overcome these two problems, I'm all ears!

    Apart from that, the other reason I mention all this is that I am concerned about how TAQOZ will be perceived by the broader user base. I think Parallax needs to be really careful how it markets this feature. If people perceive TAQOZ as an integral part of the P2 and find it to be difficult to learn, then they will likely perceive the entire P2 as difficult to learn. I suspect the most effective way to market it is to not market it at all. Instead, consider it a "pseudo-hidden feature". It's there, but it's not the primary way the P2 is intended to be used. I'm certain that those who know Forth and those who want to hack on the P2 without needing anything else will "find" TAQOZ and use it.
  • RaymanRayman Posts: 13,800
    edited 2019-01-07 18:03
    I agree with a lot of what Seairth just said.
    I'd market as an expert diagnostic tool.
    It is very useful for seeing if your P2 is alive and well...
    But, there needs to be better help...
  • potatoheadpotatohead Posts: 10,253
    edited 2019-01-07 19:13
    Definitely "advanced" user feature.

    Honestly, the way I would frame it, is as a learning tool, but only those people who are interested in bootstrapping or bringing Hardware from ground zero, or interested in other low-level type of operations.

    A few people are going to end up like Peter, very adept, and they'd use it for all sorts of things.

    Given smart docs, a fair number of people would be one or few liners. Assemble, power up, test...

    I think having it there can speak to just how potent FORTH can be for early, bootstrapping type tasks. Anyone interested in all of that can definitely benefit from TAQOS. Great skill to have.

    One could build up a little forth in a kb or two of assembly, then throw a dictionary at it and be up and running pretty darn quick. We all saw Peter do exactly that on P2.

    Frame it that way, and those who are interested, or could be interested, know it is there and why.

    Others can move on with no worries.

    My .02

    Re: write only

    Yeah, one has to take the time to look at the words others have defined. Forth itself is tiny. It is what people do with it that takes time and skill to understand.

    It literally becomes a language to solve a task, IMHO. There are always "core" words, those shipped with the system.

    From there, people can, will define whatever they want.
  • jmgjmg Posts: 15,140
    Seairth wrote: »
    ...
    2. I'm finding Forth to be a write-only language. When I am thinking through the steps to write a snippet, I find it fairly straight forward (barring issue #1). However, when I read other people's snippets, I find it very slow and cumbersome. This is particularly the case when trying to divine one-character words, which are incomprehensible without external documentation. Again, I admit this may just be a matter of familiarity. I don't even know how many of these words are "standard Forth" (assuming that's even a thing).
    ...
    Very short words are likely driven by the hard ROM ceiling.

    Maybe this needs a 'helper gui/terminal', that accepts longer words, but strips them when composing a TAQOZ line ?
    Or, perhaps TAQOZ could even become 'word length tolerant', when it has a unique match, any following characters are skipped until a space ?
    (tho that may also bump into the hard ROM ceiling..)

  • What would be a technical argument against BlocklyProp outputting Forth/TAQOZ (instead of or perhaps in addition to C/C++)?
  • Hello Everyone
    I created a word to calculate Fibonacci numbers, it is non-recursive. so I thought I would show everyone the code and the output.
    I recently purchased a book called "STARTING FORTH" by Leo Brodie on Amazon.com for over $7.00. My new book has really helped me out in learning Forth.

    HydraHacker



    JB%20Fourth%20FIBO.jpg
    1366 x 768 - 108K
  • jmgjmg Posts: 15,140
    octetta wrote: »
    What would be a technical argument against BlocklyProp outputting Forth/TAQOZ (instead of or perhaps in addition to C/C++)?

    Quite a few... I'd imagine.
    BlocklyProp already outputs well supported C
    TAQOZ is very compact, and has limited libraries and would need a lot of upstream buy-in.
    So it's not TAQOZ any more, but some loaded firmware variant, and you need to keep the loaded variant, and BlocklyProp in phase...

    The most streamlined path for BlocklyProp on P2, would be to have fastspin made good enough to accept the BlocklyProp C language subset.
    Progress on fastspin seems very rapid and it supports 3 high level languages.
  • octettaoctetta Posts: 123
    edited 2019-01-07 21:45
    jmg wrote: »
    octetta wrote: »
    What would be a technical argument against BlocklyProp outputting Forth/TAQOZ (instead of or perhaps in addition to C/C++)?

    Quite a few... I'd imagine.
    BlocklyProp already outputs well supported C
    TAQOZ is very compact, and has limited libraries and would need a lot of upstream buy-in.
    So it's not TAQOZ any more, but some loaded firmware variant, and you need to keep the loaded variant, and BlocklyProp in phase...

    The most streamlined path for BlocklyProp on P2, would be to have fastspin made good enough to accept the BlocklyProp C language subset.
    Progress on fastspin seems very rapid and it supports 3 high level languages.

    Good points. All of which caused me to take a much closer look at fastspin and its kin. Is there a clear way to make functions and/or objects developed in fastspin usable inside TAQOZ?
  • jmgjmg Posts: 15,140
    octetta wrote: »
    Good points. All of which caused me to take a much closer look at fastspin and its kin. Is there a clear way to make functions and/or objects developed in fastspin usable inside TAQOZ?

    Not so much a 'clear way'. TAQOZ is intended to load from ROM, and operate standalone.
    The issues with external calls are mainly housekeeping ones : somehow, you need to collect final physical address, and physical address and sizes of any parameters, and manually pass all of that information to TAQOZ
    If you make a mistake in any of that, how should TAQOZ report errors ?


Sign In or Register to comment.