Hi,
I was reading over on the sigrok website that the OLS is effectively an abandoned project. Is this the case? If not, is anyone working on adding additional capture RAM to the board or enabling continuous capture? Is there anything I could help with along these lines?
I'm trying to capture a rather long i2c transaction that will just not fit in the OLS capture buffer.
Regards,
David
[quote author="webshed"]Hi,
I was reading over on the sigrok website that the OLS is effectively an abandoned project. Is this the case? If not, is anyone working on adding additional capture RAM to the board or enabling continuous capture? Is there anything I could help with along these lines?
I'm trying to capture a rather long i2c transaction that will just not fit in the OLS capture buffer.
Regards,
David[/quote]
Abandoned probably isn't the right word for it. Perhaps "mature" is more accurate. At this point, the OLS does what the developers set out to make it do. There isn't any current work to change the hardware design, though there was a user that tweaked the core to add simple edge trigger capability, not so long ago. The main client program to configure the OLS and display captured traces, is stable at this point. It does what it does acceptably. There are several alternative client programs around with various capabilities.
As for modifications to add more capture depth, I'm sure that the goal of the original development, was to keep the price in reach of the most people. As such, I don't quibble with the choice to use only the internal ram, as limited as it may be. The core has been modified and put onto a Spartan6 along with 64MB of dram. See:
http://saanlima.com/forum/viewtopic.php ... 8&start=11 (http://saanlima.com/forum/viewtopic.php?f=9&t=8&start=11)
The price is triple what the OLS goes for and availability can be spotty.
Depending on how dense the i2C traffic you're trying to capture, you may find that the RLE mode of the OLS can actually cover a really long period of time with adequate sample rate.
Many thanks - I've had a look at some of the RLE documentation, I see that I may well be able to capture the whole transaction. I'll have some time to try this weekend.
I'm glad to know the hardware isn't abandoned, I understand that larger capture depth would have made it much more expensive.
David
[quote author="webshed"]Many thanks - I've had a look at some of the RLE documentation, I see that I may well be able to capture the whole transaction. I'll have some time to try this weekend.
I'm glad to know the hardware isn't abandoned, I understand that larger capture depth would have made it much more expensive.
David[/quote]
One thing that can be hard to grasp about the OLS RLE implementation, is that there is a very non-obvious tradeoff between channels captured and idle time storage. It goes something like this; if you configure for 1 MHz basic sample rate and 8 channels (8,16,24,32 are the only choices), if there were no transitions on those 8 lines, a sample is taken every 128 us even with no change. This is because there are only 7 bits of timestamp available. That is, whenever the OLS sees a transition on a line, it records the timestamp of when it happened. At a 1 MHz sample rate, the timestamp timer increments every 1 us and there is only 7 bits available for the timer. The 8th bit of sample memory is used as the timestamp timer rollover indication. So, with a total of 24KB of memory available, OLS would use 1 byte per 128 us and memory would be completely used up in just 3 seconds total, even with no changes actually recorded. Of course, if there are transitions that get recorded, all of the sample memory will be used up even faster.
If you move to 16 channel capture, it would seem to follow that you'd get even less total captured time, but it may not be the case for sparse data captures. In 16 channel mode, again 1 channel is used as the rollover bit, but this now leaves 15 bits for the timestamp timer. So, at the same exact 1 MHz sample rate, you only burn 16 bits of sample memory every 32768 us. On the other hand, we now have only 12K of samples that can be captured. Still for a completely idle capture, 12K samples would be consumed after some 393 seconds. Again, if there are actual transitions recorded, the total capture time is less.
Similar for 32 channel mode. Samples captured drops in half, but the timer is now 31 bits and can capture very long periods of idle time at the expense of actual transitions captured.
The tradeoff is between idle time capture and actual transtions captured. You need to experiment a bit to get a feel for it. If you're not getting enough capture time and there are long idle times, then increasing the number of channels in the capture, will help. If you're not getting enough capture time and transitions are fairly dense, decreasing channels captured will help extend the capture time.