For starts - thank you to TINYCLR for providing these products and support. I am not stuck on an issue, just have a question on if something is possible.
The Panda II has 2 SPI ports and I am using them both. I could use more SPI ports due to a limit on how fast I can feed some external chips. Bit bang is too slow of course so I wonder if there is any way to map / use UART - I2C - anything to create a SPI emulation / implementation? I only need for MOSI and CLK.
If not, I am fine with that. After trying to find out via a search to no avail - time to ask the experts. Knowing I can not do it - don’t waste the time trying is great to know. If there is a way - a pointer in the right direction is all I should need. I’ll come back with specifics as needed.
The way SPI works, theoretically speaking, you can have hundreds of devices connected on the same SPI bus. So you actually do not even need 2 buses but FEZ gives you 2 of them anyways.
There are two reasons I can not use the standard SPI multiple device mechanism:
I am currently doing a constant stream keeping the SPI port in constant use. Attempting to use the same port that is in full use now does not seem like it would help in this case.
The chips I am feeding via the SPI ports are the 2 pin variety with clock and data only. Since there is no pin to disable / re-enable SPI on the external chips - whatever I send from that port goes to the chips. Each SPI port has to be dedicated for that reason as well.
Note: I could potentially add my own pin switching hardware potentially to allow the chips to be used like other devices but seeing how I am pretty much maxing out the SPI port as it is - not sure that would help and/or keep up with the stream.
I am already getting really good speed even feeding 500 chips per port. That said if I can create more pipes to the chips - I can feed them faster and hence go overall faster. So if there was a way to simulate the very fast clock/data interactions of the SPI mechansim using other ports - my chips would be just as happy as they work bit-banged.
Again if not possible - that is fine. Panda II already works perfectly and the speed already surpasses my greatest expectations - call me greedy to want more speed out of these external chips :).
However, having it done in managed code made it not as fast as you need
RLP might help !
However, I think you still can consider to use multiple device SPI bus.
Managed code is quite slow… compared to the SPI bus speed.
You will run out of CPU ressource way before filling the bandwidth of a single hardware SPI bus !
Correct - managed side code will be too slow for this use.
Not sure how I can use multiple device SPI bus if my external chip reads everything connected to those pins with no disable option at the chip level. I’ll go multi-board if external components are required for switching as I think the overhead would kill the benefits and it would add points of failure.
Thanks to all for the input. I’ll post updates here if I have questions or make a breakthrough.
I see Panda II supports RLP. Using this approach I would use C or assembler to create bit-bang like processing - which happens at the super fast sub-layer?
So the “factor of 10” statement is telling me I should get about 10 times the speed of managed code for a bit banging approach by using RLP? Just want to understand and not get an important point due to “thinking” I understand :). Thanks for your patience.
I’ll try this approach and see how fast of an update I can muster up. I may not have time to do this immediate as the double SPI solution is fast enough for my current needs. That said when / if I make headway in this direction I’ll post an update.
Thank you all for your time and input. Great direction and I learned what RLP is for future needs if not for this one.
Great group and platform, looking forward to porting over my systems
Gus - good points. This was all theory / learning anyway. I would most likely hit a processor and data feed limit pretty quick, even with a gate on the pins. So if I really have to have more speed - I will most likely just use more boards and sync at the board and/or PC level.
BTW Gus - your chat and online support is second to none.
[quote]Gus - good points. This was all theory / learning anyway. I would most likely hit a processor and data feed limit pretty quick, even with a gate on the pins. So if I really have to have more speed - I will most likely just use more boards and sync at the board and/or PC level.
[/quote]
If speed is a problem in your application then “software SPI” will not solve your problem.
In worst case, you can write an RLP driver to use SPI directly to utilize it to the fullest.
