What do you mean? Are you asking about input pins or output pins?
Input pins are set high or low by whatever circuit you connect to do that. Could be a switch to 3.3v and 0v. Could be some kind of logic chip. Could be an op amp, but be sure not drive the pin higher than 3.3v or lower than 0v.
Output pins are set high or low by your software. That's all you need to know. No doubt there is a complementary pair of MOS transistors connected to the pin and then to 3.3 and 0v internal to the Propeller chip to drive the pin. Then there will be protection diodes etc.
Are you asking: "What does the I/O stage look like, in terms of the circuit that drives the output?"
If so, then you will need to advise the specific device of interest, as it will likely affect the answer.
If you are asking something else, then perhaps more clarification would be helpful.
within the propeller chip, I know that you can have an op-amp act like a pin on the prop, it's low below 1.4 and high above 1.4V so I was wondering if the prop chip has op-amps within?
There are no op-amps in the Prop. Look at this article about CMOS digital output stages for an explanation of what you're seeing. The actual Prop I/O pin circuitry is more complex since it includes an input buffer as well as some diodes for protection from static discharge, but that doesn't significantly change the above discussion.
The input buffer, like most CMOS input gates, has a switching threshold of about 1/2 Vdd (somewhere between 0.3 Vdd and 0.6 Vdd). The threshold varies somewhat with supply voltage and operating temperature and varies in that range from chip to chip as well.
C'mon guys: Franny deserves the truth about what makes pins high and low. It's the magic smoke wafting randomly about within the chip's internal ether, ferrying electrical charge demons from pin to pin. That tricky smoke pretends to be a predictable obedient servant, but it's constantly on the lookout for any possible escape route.
C'mon guys: Franny deserves the truth about what makes pins high and low. It's the magic smoke wafting randomly about within the chip's internal ether, ferrying electrical charge demons from pin to pin. That tricky smoke pretends to be a predictable obedient servant, but it's constantly on the lookout for any possible escape route.
So you are saying that this "magic smoke" makes the pins "high"? So when a pin is deprived of this then it ends up in a "low" state. Hmmmm......using my excellent powers of deduction I can only surmise that the chip packagers tried to save money by employing doped out students and now this is the result!?
That was original try-state because the smoke was just floating and they would try to make it go high or low but they couldn't so they decided to turn a bug into a feature. Since floating this idea of labelling a bug as a feature instead, the magic smoke industry hasn't looked back.
Since floating this idea of labelling a bug as a feature...
I have heard this little bug/feature joke around the net for decades now. I wonder where it comes from.
I have actually seen it for real. Round about 1980 the Intel data sheet on the 8059 interrupt controller had a note on how an interrupt pulse that was too short would end up being registered as interrupt 7, no matter what pin it came in on. They even had a code example as a work around. And referred to it as a "feature".
Anyone have any other examples of the "bug as feature" thing in real documentation?
With only one smoking core, data rates are marginal, with a single binary state, being typical for any one core.
With multiple cores, many additional states are possible, which very significantly improves overall comms, at the expense of additional cores and either an operator skilled at releasing the smoke, or a group working together.
Given sufficient cores, it is possible, at considerable expense, to support continious, streaming smoke comms as there is time to resupply all cores with fresh smoke and cycle worn operators.
Doping can be used to support asynchronous and bidirectional comms, and improve op eat or smoke release efficiency, or to support signal identification in high traffic environments.
Franny
Posts: 127
Comments
Input pins are set high or low by whatever circuit you connect to do that. Could be a switch to 3.3v and 0v. Could be some kind of logic chip. Could be an op amp, but be sure not drive the pin higher than 3.3v or lower than 0v.
Output pins are set high or low by your software. That's all you need to know. No doubt there is a complementary pair of MOS transistors connected to the pin and then to 3.3 and 0v internal to the Propeller chip to drive the pin. Then there will be protection diodes etc.
Are you asking: "What does the I/O stage look like, in terms of the circuit that drives the output?"
If so, then you will need to advise the specific device of interest, as it will likely affect the answer.
If you are asking something else, then perhaps more clarification would be helpful.
The input buffer, like most CMOS input gates, has a switching threshold of about 1/2 Vdd (somewhere between 0.3 Vdd and 0.6 Vdd). The threshold varies somewhat with supply voltage and operating temperature and varies in that range from chip to chip as well.
You can't use a Propeller pin as an OPAMP if that is your intention.
Andy
So you are saying that this "magic smoke" makes the pins "high"? So when a pin is deprived of this then it ends up in a "low" state. Hmmmm......using my excellent powers of deduction I can only surmise that the chip packagers tried to save money by employing doped out students and now this is the result!?
Of course everybody knows the magic smoke is what makes the pins work. It's when that smoke gets exposed to the air that is the problem.
Laugh all you want, Beau. Now when do I get my 4.3 million?
One nano second later the price of a hamburger would be a billion dollars.
Everyone would be as poor as they were before.
Note: Numbers rounded for hand waving purposes.
Perhaps Beau has a point.
I have actually seen it for real. Round about 1980 the Intel data sheet on the 8059 interrupt controller had a note on how an interrupt pulse that was too short would end up being registered as interrupt 7, no matter what pin it came in on. They even had a code example as a work around. And referred to it as a "feature".
Anyone have any other examples of the "bug as feature" thing in real documentation?
Another comm question: What is the optimum baud rate, parity and transmission line length for magic smoke signals?
https://en.wikipedia.org/wiki/Smoke_signal
With only one smoking core, data rates are marginal, with a single binary state, being typical for any one core.
With multiple cores, many additional states are possible, which very significantly improves overall comms, at the expense of additional cores and either an operator skilled at releasing the smoke, or a group working together.
Given sufficient cores, it is possible, at considerable expense, to support continious, streaming smoke comms as there is time to resupply all cores with fresh smoke and cycle worn operators.
Doping can be used to support asynchronous and bidirectional comms, and improve op eat or smoke release efficiency, or to support signal identification in high traffic environments.