Tachyon - external SPI SRAM addition - a viable option ? (answered)
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 ?
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
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.
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.
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 ;-)
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
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.
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
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 :-)
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!
Well, I'm so late to the game and there is a lot for me to learn and I'd better be quick
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.
This is one of the scripts I would use but you can find it in the V5 folder.
So that ends up running like this:
You, guys, have answers to every question I might have. I must not abuse that ability of yours. Thanks a lot.
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
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 ?
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.
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."
This thread has been moved from the P1 category to ForthSpace and will continue here.