Your words... My mentor was an old-school character actor named Cliff Osmond. He was discovered by the legendary director, Billy Wilder, and did several movies with Walter Matthau and Jack Lemmon (who sponsored him into the Academy). Cliff was a very smart man, which lead him to teaching (acting). One of his admonitions was, "Always go for simplicity, because simplicity is elegance, and elegance is best."
Again, I'm not a C programmer (though I understand the C syntax), so I might translate my SPI connections to the P2 flash like this (not tested).
_pinh(SF_CS);
m = P_SYNC_RX | (((SF_SCK-SF_MISO) & 0b111) << 24);
x = 0b000000 | (8-1);
_pinstart(SF_MISO, m, x, 0);
_pinf(SF_MISO);
m = P_SYNC_TX | P_OE | (((SF_SCK-SF_MOSI) & 0b111) << 24);
x = 0b000000 | (8-1);
_pinstart(SF_MOSI, m, x, 0);
_pinf(SF_MOSI);
m = P_PULSE | P_OE;
x = _clockfreq() / spiFreq;
if (x < 2) {
x = 2;
}
else if (x > 0xFFFF) {
x = 0xFFFF;
}
x |= (x >> 1) << 16;
_pinstart(SF_SCK, m, x, 0);
I know that my code is verbose -- my goal is clarity. Note that I de-activate (reset) the SPI MOSI and MISO pins until they're used.
I sometimes tend to over-engineer things, unfortunately. I agree simpler the better
to clear a pin of any smart pin (and other) settings. This will let it behave like a normal tristate IO pin. I've written code that uses smart pin serial input but want to look for an idle state between packets (i.e., read the pin like a normal input). I use wrpin to clear the smart mode (m register), then write the smart mode back when needed. The good news is that the x and y registers are not affected, so I don't have restore my bit timing settings.
Note: If the "wait for low between frames" seems confusing that's because the is an S.BUS receiver, and S.BUS uses inverted serial so the idle state is low.
I sometimes tend to over-engineer things, unfortunately. I agree simpler the better.
Most of us do, and some will say -- rightly -- that it's best to avoid early optimization.
I agree completely. I usually go back when I figured out what I am doing and improve the code for speed and size. I'm not the greatest programmer but make do with what I know and if I don't know something then I google it or ask the great programmers here . I am so used to using structures and unions for almost anything that requires data manipulation.
to clear a pin of any smart pin (and other) settings. This will let it behave like a normal tristate IO pin. I've written code that uses smart pin serial input but want to look for an idle state between packets (i.e., read the pin like a normal input). I use wrpin to clear the smart mode (m register), then write the smart mode back when needed. The good news is that the x and y registers are not affected, so I don't have restore my bit timing settings.
Note: If the "wait for low between frames" seems confusing that's because the is an S.BUS receiver, and S.BUS uses inverted serial so the idle state is low.
I tried the _wrpin(0, 0); And it didn't seem to make any difference. Would using the _OUTB cause weird behavior on the _OUTA data? I write to bits 32 to 39 as a bus of 8 outputs to toggle depending on the data being sent out.
Is the pin staying high or low? A second Cog also setting the pin high could hold it high, overriding all other Cogs. That's the way the sharing works.
@enorton said:
I screwed the pooch on pin 0 somehow or somewhere in the code it's being held low somehow but I looked and cannot find it errrgh. Pins 1 through 7 work fine which is really weird...
Check the reset state of the pin, all pins should float during reset.
You can also check the pulldown strength, relative to a known good pin. A damaged pin is likely to have a different ON resistance.
Huh, I missed that post. Looking like it's electrically broken alright. Yeah, I'd expect to see different resistances when broken ... my own Eval Board ... Power off, multimeter positive probe on GND pins - Negative probe on good pins are about 350 kR. Diode test of same polarity is 0.73 V.
Different broken pins vary from 200 R to 1 MR to completely open circuit.
And, I think maybe some of my earlier suspect pins might be alright but I'd written them off as part of a group ...
EDIT: Yeah, across three accessory headers, I've got one group of 8 pins dead (1 MR) and pair of pins dead (open circuit) and a single dead pin (200 R jammed high at 2.5 V, which I guess means it's pulling a constant 11 mA from the LDO).
No idea how the group was killed but I have a fair idea the open circuit pair were the ones I tested with up to 100 uA pull-up at 7 Volts. They were fine at a lower current from memory but the later higher current testing destroyed them I think. I gave up on that test when the low temperature testing gave weird readings. In hindsight, those pins were likely busted by that stage.
PS: This was one of the gifted Engineering Sample boards Chip sent out early on. I have another good board I haven't yet damaged.
Comments
Do try with an otherwise blank program.
I sometimes tend to over-engineer things, unfortunately. I agree simpler the better
You can use
to clear a pin of any smart pin (and other) settings. This will let it behave like a normal tristate IO pin. I've written code that uses smart pin serial input but want to look for an idle state between packets (i.e., read the pin like a normal input). I use wrpin to clear the smart mode (m register), then write the smart mode back when needed. The good news is that the x and y registers are not affected, so I don't have restore my bit timing settings.
Note: If the "wait for low between frames" seems confusing that's because the is an S.BUS receiver, and S.BUS uses inverted serial so the idle state is low.
Most of us do, and some will say -- rightly -- that it's best to avoid early optimization.
I agree completely. I usually go back when I figured out what I am doing and improve the code for speed and size. I'm not the greatest programmer but make do with what I know and if I don't know something then I google it or ask the great programmers here
. I am so used to using structures and unions for almost anything that requires data manipulation.
I tried the _wrpin(0, 0); And it didn't seem to make any difference. Would using the _OUTB cause weird behavior on the _OUTA data? I write to bits 32 to 39 as a bus of 8 outputs to toggle depending on the data being sent out.
Is the pin staying high or low? A second Cog also setting the pin high could hold it high, overriding all other Cogs. That's the way the sharing works.
Check the reset state of the pin, all pins should float during reset.
You can also check the pulldown strength, relative to a known good pin. A damaged pin is likely to have a different ON resistance.
Huh, I missed that post. Looking like it's electrically broken alright. Yeah, I'd expect to see different resistances when broken ... my own Eval Board ... Power off, multimeter positive probe on GND pins - Negative probe on good pins are about 350 kR. Diode test of same polarity is 0.73 V.
Different broken pins vary from 200 R to 1 MR to completely open circuit.
And, I think maybe some of my earlier suspect pins might be alright but I'd written them off as part of a group ...
EDIT: Yeah, across three accessory headers, I've got one group of 8 pins dead (1 MR) and pair of pins dead (open circuit) and a single dead pin (200 R jammed high at 2.5 V, which I guess means it's pulling a constant 11 mA from the LDO).
No idea how the group was killed but I have a fair idea the open circuit pair were the ones I tested with up to 100 uA pull-up at 7 Volts. They were fine at a lower current from memory but the later higher current testing destroyed them I think. I gave up on that test when the low temperature testing gave weird readings. In hindsight, those pins were likely busted by that stage.
PS: This was one of the gifted Engineering Sample boards Chip sent out early on. I have another good board I haven't yet damaged.
My eyes...
Thanks!
Yep. I know what you're talking about.