Do really no Gpio on the SC13048 support open drain output drive mode?
Does either the SC20100 or SC20260 support open drain outputs?
Perhaps i dont have enough exposure but just about every MCU ive ever used supported open drain outputs. I kind of desigend myself into a corner having just ordering pcbs but having not confirmed this first…
What are the options of the gpiopindrivemode enum?
public enum GpioPinDriveMode {
Input = 0,
Output = 1,
InputPullUp = 2,
InputPullDown = 3,
OutputOpenDrain = 4,
}Yup. And a somewhat recent update to clean out ‘unused values’ of this enum caused me to presume theses remaining were going to be available…
That said I fully endorse keeping the value even if it would never be implemented on any internal gpio. I use in my gpio expander library where a custom gpio controller is created. It is simply required to support expanders that have it, and it is a very popular drive mode, thus my assumption it was available.
Perhaps one might suggest adding output open source as well, just to cover all l the bases.
Wondering about your Commit d961bf3e from 2/18/2020 10:25:34 AM
Where available modes went from
public enum GpioPinDriveMode {
Input = 0,
Output = 1,
InputPullUp = 2,
InputPullDown = 3,
OutputOpenDrain = 4,
OutputOpenDrainPullUp = 5,
OutputOpenSource = 6,
OutputOpenSourcePullDown = 7,
}
to what it is now:
public enum GpioPinDriveMode {
Input = 0,
Output = 1,
InputPullUp = 2,
InputPullDown = 3,
OutputOpenDrain = 4,
}
Your comment:
Remove some isn’t used
I mistakenly assumed each of the remaining modes including OutputOpenDrain were a currently used drive mode, only i haven’t been able to learn of which device(s) OoutputOpenDrain might currently be used on.
Was this perhaps just perhaps planning for future expansion?
STM32 apparently does support Output OpenDrain
STM32 GPIO exhibits the following features:
• Output states: push-pull, or open drain + pull-up / pull-down according to
GPIOx_MODER, GPIOx_OTYPER, and GPIOx_PUPDR registers settings
But if there were devices in support of it now, id like to consider those.
why is not on this order ?
public enum GpioPinDriveMode {
Input = 0,
InputPullUp = 1,
InputPullDown = 2,
Output = 3,
OutputOpenDrain = 4,
OutputOpenDrainPullUp = 5,
OutputOpenSource = 6,
OutputOpenSourcePullDown = 7,
}
I cant imagine the order is would ever be a real issue but I agree due to my OCD about the ordering things…
For the last 4, don’t you need additional components? so its just Output anyway.
@Darko could you explain. In the ‘High’ state, the push pull circuit of active driven output is very diffent than the infinite impedance of the open drain circuit.
I dont design circuitry often so I have some uncertainty, but as ive designed a circuit expecting an open drain output on a port configured as actively driven, i could easily damage the port as it might well be forced to sink current when programming is driving it to the High state. Think interfacing with a 12v circuit through an external pullup. What should happen is programming drives the port low, the circuit sinks current though to the port connected to ground. Programming drives the port high, the potential voltage difference between the pull up and the 3.3v driven port forces the port to sink current… What am i missing?
The same goes for Output Open source, it is a distinct function as well and should not be confused with a mere output. So seemingly rare, i havnt (yet) made a fuss about why it was taken out, it would be nice for the enumeration to represent all possible output types.
That said, i seem to agree with Dat removing the PullDown and PullUp values. It doesnt quite make sense to me a cpu that is Open and pulled at the same time, that must have been a typo no?
This explains it well i think. For output you either need a transistor or a mosfet. As for input, id just use MCU’s internal InputPullup or put an external pullup.
Am i missing something?
Well I understand how open collectors work, and i understand if one or the other configuration is not available one can always redesign circuitry to achieve desired function. So if you were just suggesting a work around by redesign my boads, then thank you.
Perhaps I should not be so sensitive to component count or simplification as when i worked with high volumes, we used to negotiate with customers over a half cent on parts.
But it seems to me that if the port supports the mode, it would be great if we could actually use it to simplify our circuitry. Im just trying to make sense of having to adding a few dozen mosfets to a board because you needed functionality that is already built in. 
Well, we will add them back.
You can use Marshal to change these registers, not hard if gpio.
To clarify, you are stating output open drain is currently supported using marshal?
Also to clarify You will add back all gpio modes removed?
No argument for output open source, but could you educated me to what exactly is, in regards to the mcu and tiny CLR, the distinction between output open source and output open source pull-up or output open source pull-down. It doesn’t seem to me these 2 have any place in the mode definition. They are both just output open source to the mcu.
You can use OpenDrain mode as well, default is no pull, and no need to modify anything. Current release support this feature.
The missing, I guess are OpenDrain Pullup/Pulldown, you can try to change related registers as well.
I do not think we should add the other modes. There was a reason they were removed.
Current options covers 99.9% of cases anyway.
To clarify, are you stating when creating a gpio pin, I should not set the drive mode at all and the default will be output open drain?
Even though when i check the IsDriveModeSupported method of each GpioPin of my Flea, every port reports it is NOT supported.
And if i indeed do need to use Marshal to set Output OpenDrain, exactly how is this done, the Marshal reference page is a bit thin
No, just like Output OpenSource there should be NO stipulating an output circuit is pull up or pull down and this does not belong in any definition. Unlike Input, where the OS needs to know if it should set an INTERNAL pullUp or pullDown, in the case of output it is in reference to the EXTERNAL circuit and the OS does NOT need to know this.
Otherwise I agree with Gus, the current modes take care of virtually all cases… Now if we might focus on getting all the CURRENT modes fully supported as first class citizens (ie Output Open drain is confusing if supported at all)
Bonus question.
Why does the IsDriveModeSupported method of GpioPin require you to pass its own pin number to itself? It is not static and you need to make a instance to use it anyway so why require the need to send its own pin number to itself?
This method seems misplaced as it should be part of GpioController instead.
Just checked, OutputOpenDrain doesn’t work. We will correct it.
On GitHub I see this fixed. I’m always a bit confused trying to confirm where the fix is.
In this case the bug filed against the libraries but isn’t it a firmware update?
And then how to know which version?
it is fixed in firmware and available for next release only.
We are not going to touch anything on library in near feature.