@evanh said:
You've forgotten. That's only for Command and Address. And that streamer mode, X_IMM_8X4_LUT, will drive 32 consecutive pins if its data says so.
Oh yeah, you are right. LUT streaming output modes do drive 32 pins.
' 1 x 4-bit: $0000,$0001,$0002,$0003,$0004,$0005,$0006,$0007,$0008,$0009,$000a,$000b,$000c,$000d,$000e,$000f
' 1 x 4-bit: $0000,$0010,$0020,$0030,$0040,$0050,$0060,$0070,$0080,$0090,$00a0,$00b0,$00c0,$00d0,$00e0,$00f0
' 2 x 4-bit: $0000,$0011,$0022,$0033,$0044,$0055,$0066,$0077,$0088,$0099,$00aa,$00bb,$00cc,$00dd,$00ee,$00ff
' 4 x 4-bit: $0000,$1111,$2222,$3333,$4444,$5555,$6666,$7777,$8888,$9999,$aaaa,$bbbb,$cccc,$dddd,$eeee,$ffff
Well, I've improved the tester error checking so that a bunch of the bordering 100% readings are now 99% instead. A single bit error of the whole 100 kBytes/chip tested will produce a 99% result. Basically, the scoring always rounds down now. Previously, it was actually a logical flaw that counted any score for a block as a percentage success, which should have been only for perfect scores ... Oops. It now sums all the individual block scores first.
@evanh said:
This is rearing its head mostly now because I'm trying to move to doing the 16-bit wide bus. And what's changed is the defined constant for the 16 data pins. It now has an ADDPINS 15 so it exceeds the 9-bit limit of a single # immediate. This has had catastrophic repercussions on timing when compiling with Flexspin.
And there is another issue, actually even worse, where a local register variable will be used if the passed in constant is non-zero. But if it's zero then the optimiser will generate an immediate operand with ## instead. This one occurs when selecting individual chips in SPI interface mode.
Would some compiler control help here ?
I've seen compilers that allow in-line control of optimize levels, (so you disable then enable again past the critical section) ?
Those problems have gone away. I hadn't actually proven my ideas either, sorry. So it can't have been as bad as I was thinking. I've used many more local variables, replacing all ## immediates, to work around the original issue and that seems to clean it up.
Aside, because it's Spin, I also want the source code to be 100% compatible with Pnut/Proptool as well. So far so good. The current release is working as expected and doing a great job of what I set out to do. ... Ha, forgot to date the release last night ... done.
Comments
You've forgotten. That's only for Command and Address. And that streamer mode,
X_IMM_8X4_LUT
, will drive 32 pins if its data says so.Oh yeah, you are right. LUT streaming output modes do drive 32 pins.
Here's all four possible tables:
I don't use the LUT in 4 bit modes as Immediates can be used instead.
I suppose that involves skip patterns. Oh, of course, you've got separate drivers.
Well, I've improved the tester error checking so that a bunch of the bordering 100% readings are now 99% instead. A single bit error of the whole 100 kBytes/chip tested will produce a 99% result. Basically, the scoring always rounds down now. Previously, it was actually a logical flaw that counted any score for a block as a percentage success, which should have been only for perfect scores ... Oops. It now sums all the individual block scores first.
So, the reports are even gnarlier now. Although, with both data registration states now included in the single report, it make it look smoother. Comparing Rayman's 96 MB add-on from the prior report - https://forums.parallax.com/discussion/comment/1541329/#Comment_1541329
Latest source code for above:
Would some compiler control help here ?
I've seen compilers that allow in-line control of optimize levels, (so you disable then enable again past the critical section) ?
Those problems have gone away. I hadn't actually proven my ideas either, sorry. So it can't have been as bad as I was thinking. I've used many more local variables, replacing all ## immediates, to work around the original issue and that seems to clean it up.
Aside, because it's Spin, I also want the source code to be 100% compatible with Pnut/Proptool as well. So far so good. The current release is working as expected and doing a great job of what I set out to do. ... Ha, forgot to date the release last night ... done.
Finally got round to optimising the compare routine so it runs pretty close to same speed compiled with Pnut now. Above attachment is updated.
I've done a limited write-up of how the critical timing works. It doesn't cover the rx turnaround at all but plenty can still be understood educationally from it - https://forums.parallax.com/discussion/comment/1542073/#Comment_1542073
More here - https://forums.parallax.com/discussion/comment/1543542/#Comment_1543542