Shop OBEX P1 Docs P2 Docs Learn Events
Tachyon - external SPI SRAM addition - a viable option ? (answered) — Parallax Forums

Tachyon - external SPI SRAM addition - a viable option ? (answered)

MaciekMaciek Posts: 668
edited 2021-08-06 18:49 in Forth
If I understand the AN012 from Parallax correctly , whatever RAM I'd add it will not integrate with the P1's internal RAM ("...That said, the other option to add memory to a microcontroller is external non-integrated memory that is interfaced via a driver and either a serial or parallel bus interface...").

The question is if addition of such SPI SRAM makes sense, provided I use Tachyon ? In other words, will Tachyon be able to make a good use of such additional SPI SRAM ?

Comments

  • It is very easy to create memory access words similar to fetch and store and cmove etc much like the virtual memory words for the SD card. There are other methods that could use a cog to update sector buffers etc but it begs the question: what are you trying to do.
  • I was thinking of extending my ugly P1 dev board with additional board with micro SD card (as per yours and others too) suggestions, some sort of display and, possibly spi SRAM, if the later makes sense. No particular need in terms of an application requirement now. Thanks for making this a no brainer.
  • I have an optional 8MB PSRAM chip for the P2D2 that can also be accessed QSPI fashion when part of the P2PAL module. While it is easy enough to access it, I don't have any major plans for it yet. Maybe it will be handy as a giant file buffer so I that I can insert and delete and hold undo versions in its RAM.
    But using this type of RAM for display data is awkward. Mind you, since it is serial it could be connected in such a fashion that if it were driven fast enough by a read clock setup in a counter at Hsynch time, then I suppose 4 bits could be read as RGB bits. Writing to it would have to be during Vsynch time and limited so as not to mess up the display.
    Then there is HyperRAM but it is a bit too hyper for the poor P1 to be able to use it effectively.

    Keep it simple, just add the SD card but don't use any pullups, in fact I like to add a 1M pulldown now to the SD CS line which makes it easy to detect no card as CS=0 or a card's internal pullup CS=1.
  • That's even better. Nothing to solder "ugly style" on the display board which already has SD card socket mounted. I'll pass on this SPi SRAM chip then. "Simple" rules.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2020-08-30 08:39
    Be aware that practically all SD card sockets are wired up with pullup resistors, just to be "safe", but this is faulty reasoning because the SD card already has a pullup at powerup that is in the SD card specification and so therefore in all cards. Blame the copy&paste Internet mentality for that one too.
    Anyway, you can use this to detect a card thereby doing away with any extra wiring and I/O. To make it easier to detect a high or a "not high" I use a 1M pulldown since the card pullup is around 50k IIRC. Remove the CS pullup from the display board by putting a wetted (by solder) hot iron onto the smd parts, give it a moment and you should be able to flick it off. The only inconvenience you will suffer if you leave it on though is that Tachyon will think a card is always connected.

    You know what? I just had an idea. The card detect switch is normally grounded, but opens when you insert a card. You could just wire the card detect switch to the SD CS. That way Tachyon will see a low on that line and know it is not inserted. Once you insert the card then there are both pullups active and it is not being switched to ground any longer. Simple fix!

    btw, my idea of "just to be safe" is not to make assumptions and RTM carefully, and test it out.
  • Thanks, Peter. I'm going to find that LCD board this evening and see what's on it exactly in terms of SD card pull ups. I'm not afraid of doing a small soldering job on it, if required :). Once I'm done with adding the SD card to my board I'll dive into Tachyon. I have high hopes for it and I am sure I will not be disappointed. To my understanding Tachyon is all I need to conquer that P1 chip. No spin, no C. I love it.
  • MJBMJB Posts: 1,235
    Maciek wrote: »
    ... I'll dive into Tachyon. I have high hopes for it and I am sure I will not be disappointed.
    To my understanding Tachyon is all I need to conquer that P1 chip. No spin, no C. I love it.

    welcome

    yes - Tachyon will probably give you all you need.
    And if not - then you can easily create it.

    When I discovered the Propeller was just the time Peter started to give out the first versions of Tachyon.
    So that is what I grew into.
    And reading the Tachyon kernel code is a great way to learn PASM as well.

    When I work with Tachyon I keep just all the source files (Kernel, Extend, Easyfile, Easynet ...)
    open in the editor so I can easily search for any word.
    Reading the definition and the code around it give a lot of insight how to use it
    and a better understanding of Peter's Tachyon programming style.
    Maybe except for the low comment density -- he does not need it ;-)
    a good style to copy.
    And his code is of course full of examples for every word around -
    otherwise he wound not have made the word ;-)



  • Too bad I'm like eight(?) years late to the Tachyon game but I'll catch up, hopefully. Thanks for the tips.
  • MJBMJB Posts: 1,235
    Maciek wrote: »
    Too bad I'm like eight(?) years late to the Tachyon game but I'll catch up, hopefully. Thanks for the tips.

    also has a good side

    Tachyon is very stable now.
    In the beginning it could be changing a few times - per day ;-)
    it was really hard to keep up with
    (I have a zillion of versions in my archives)

    and now there is some documentation available and people around that can help you get started
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2020-09-01 12:03
    Yes, Tachyon was only weeks old and I was using it already. It took quite some time before I started to run out of memory, and not until I had FAT32 and then WIZnet drivers and Ethernet servers running. It was becoming difficult to manage memory limits until I abandoned bytecode and created V4 DAWN with 16-bit wordcodes. That solved many of the addressing and memory problems and also ran faster.

    I also had problems with compressing the dictionary and trying to use upper EEPROM for that, but I wasn't happy with it. By putting the binaries for cog images in upper EEPROM, it freed up the hub RAM for the dictionary plus I optimized that too which brought me to V5 NEON, where we are now, and hopefully will be happy with :)

    Looking at those Lattice FPGAs which are available in small BGA packs but also in QFN72 similar in size to the P1 makes me think that if I can squeeze a P1V+ into one of those with a lot more memory, and cogs, and I/O etc, that I may have to do a Tachyon V6 turbo for it. The reason I'd use a P1 is simply because it is simpler. The P2 package is too large for some products, and may not be low power enough. Cost would be about the same though.
  • MJBMJB Posts: 1,235
    edited 2020-09-01 13:08
    ....

    Looking at those Lattice FPGAs which are available in small BGA packs but also in QFN72 similar in size to the P1 makes me think that if I can squeeze a P1V+ into one of those with a lot more memory, and cogs, and I/O etc, that I may have to do a Tachyon V6 turbo for it. The reason I'd use a P1 is simply because it is simpler. The P2 package is too large for some products, and may not be low power enough. Cost would be about the same though.

    finally a P1+ so many have been waiting for ...
    could be interesting in some cases - especially more memory and more simple pins.

    but probably still without some analog (AD/DA) -
    which makes the Arduinos so attractive to play with for many people.

    Sure DA we can duty-cycle

    AD ... like P1 or with a little HW support?

    lower power for battery op would be a plus over P2
  • MJBMJB Posts: 1,235
    edited 2020-09-01 13:05
    Yes, Tachyon was only weeks old and I was using it already. ...

    Oldest download of Tachyon I have is 2012-07-28 with version 2012-07-19 ... well ... quite some time

    and thanks again for sharing ... brings so much fun in the world :-)


  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2020-09-01 14:58
    3rd of July 2012 I announced my Tachyon idea and by the 8th I was running some code. Before long I had it compiling Forth source and running VGA graphics and 3Mbd serial! It sure was a lot of fun getting it going.
    One thing I forgot about though was that I initially implemented the data stack as 12 fixed registers that I had to ripple through every time I pushed and popped the stack. Later on I decided that while fixed registers are good, it's too much work to ripple through all of them each time, so I worked out that 4 registers would be the most I'd need to directly access, and there would be no PICK or ROLL, and the bottom register would be backed up to a fast LIFO stack in cog RAM.

    P.S. I noticed I had Tachyon for the P2 back in 2015 as "TF2 Pioneer" and I had even written a P2 assembler for it in Forth!
  • Great discussion, folks.
    Well, I'm so late to the game and there is a lot for me to learn and I'd better be quick :smile: . Now I must learn how to upload a code in bulk with minicom. I'm sure there must be an easy way for that because copy and paste is so inefficient.
    Speaking of that FPGA from Lattice jmg has mentioned, I almost pulled the trigger on an eval board for it as it sure looks very tempting.
    I must swear to myself not to engage in anything other than the Tachyon on the P1 for the time being or... I'm lost in options and achieve nothing.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2020-09-01 15:19
    Even while minicom is open you can have a Linux terminal open in the V5 folder and use ascii-xfr to send a Forth source to Tachyon.
    This is one of the scripts I would use but you can find it in the V5 folder.
    ascii-xfr -sn -l $3 Forth/$1.FTH > dev/ttyUSB$2
    

    So that ends up running like this:
    s EXTEND 0 5
    
  • I knew it !.
    You, guys, have answers to every question I might have. I must not abuse that ability of yours. Thanks a lot.
  • MJBMJB Posts: 1,235
    Maciek wrote: »
    Great discussion, folks.
    Well, I'm so late to the game and there is a lot for me to learn and I'd better be quick :smile: . Now I must learn how to upload a code in bulk with minicom. I'm sure there must be an easy way for that because copy and paste is so inefficient.
    Speaking of that FPGA from Lattice jmg has mentioned, I almost pulled the trigger on an eval board for it as it sure looks very tempting.
    I must swear to myself not to engage in anything other than the Tachyon on the P1 for the time being or... I'm lost in options and achieve nothing.

    I am on windows.
    Have Notepad++ open in one window and TeraTerm besides it.
    I write my code on NP++ and ^C click on TT mouse-right and it is in - for copy all just a ^A first - no big deal
  • jmgjmg Posts: 15,140
    Looking at those Lattice FPGAs which are available in small BGA packs but also in QFN72 similar in size to the P1 makes me think that if I can squeeze a P1V+ into one of those with a lot more memory, and cogs, and I/O etc, that I may have to do a Tachyon V6 turbo for it.

    I see they spec these typicals
    32-Bit Adder ~407 MHz
    32-Bit Counter ~303 MHz
    36 x 36 Multiplier with Input/Output Registers ~190 MHz

    So it looks like a HW MUL is feasible, and I wonder what speed a WAITCNT could operate at ?
    MJB wrote: »
    but probably still without some analog (AD/DA) -
    There is some ADC capability in those QFN72 FPGAs

    2.14.1. Analog to Digital Converters
    The Analog to Digital Convertor is a 12-bit, 1 MSPS SAR (Successive Approximation Resistor/capacitor) architecture converter. The ADC supports both continuous and single shot conversion modes.
    The ADC input is selected among pre-selected GPIO input pairs, dedicated analog input pair, the internal junction temperature sensing diode and internal voltage rails. The input signal can be converted in either uni-polar or bi-polar mode.
    The reference voltage is selectable between the 1.2 V internal reference generator and an external reference. The ADC can convert up to a 1.8 V input signal with a 1.8 V external reference voltage. The ADC has an auto-calibration function which calibrates the gain and offset.
    2.14.2. Continuous Time Comparators
    The continuous-time comparator can be used to compare a pre-selected GPIO’s input pairs or one dedicated comparator input pair. The output of the comparator is provided as continuous and latched data.

    MJB wrote: »
    lower power for battery op would be a plus over P2
    It may not be very low power, as they are large dies in a shrink process, but it does say this
    "The LFOSC runs at nominal frequency of 128 kHz. The high frequency oscillator (HFOSC) runs at a nominal frequency of 450 MHz, divisible to 2 MHz to 256 MHz by user option. The LFOSC always run, thus can be used to perform all always-on functions with the lowest power possible."

  • MaciekMaciek Posts: 668
    edited 2021-08-06 19:08

    This thread has been moved from the P1 category to ForthSpace and will continue here.

Sign In or Register to comment.