my current best guess is that the rolloff happens because it turns off high side drivers while idle and relies on pull resistors to maintain the level; but it's still a CMOS output because it has fast rising/falling edges not sure why though, lower static power?
-
Show this thread
-
you can see it in the waveform but I should mention it explicitly too: this is -supposed- to be a completely ordinary 3.3 V TTL UART, it does -not- have a charge pump anywhere, or at least isn't supposed to. this is -not- RS-232
3 replies 0 retweets 9 likesShow this thread -
whitequark Retweeted Muzaffer Kal @ 🏡 🇺🇸
the best hypothesis so far is that the chip designers went for a multidrop UART that would only exhibit a bus conflict for a very short time, though I couldn't find any explicit mention of anything like that feature, or even any mention of half-duplexhttps://twitter.com/DSPonFPGA/status/1264739607180005378 …
whitequark added,
Muzaffer Kal @ 🏡 🇺🇸 @kal_muzafferReplying to @whitequarkis there any chance this is supposed to be a shared line? It's a standard trick where each side drives the line for a very short time then floats so if there is any conflict, it's very short. It might just be a bug which didn't get detected with IOs with lower leakage.2 replies 0 retweets 12 likesShow this thread -
This Tweet is unavailable.
-
Replying to @chrisfreder
thank you! brilliant find. I thought of looking at similar CPUs but missed this one
2 replies 0 retweets 2 likes -
Replying to @whitequark @chrisfreder
Isn't that for the synchronous serial controller though, not the UART? I don't see anything there related to this kind of feature for the UART.
1 reply 0 retweets 3 likes -
This kind of drive is used in smart cards readers. The IO line of a smart card is open drain but for high data rates like f/d= 16 or 8, a pullup is not enough, so iso7816 drivers go push pull for a short time before letting it open drain. If not implemented right, can be a mess.
1 reply 0 retweets 7 likes -
Consistent with the fact that the doc shows a bidir IO line.
1 reply 0 retweets 0 likes -
TxD2 is not bidir though, but it is listed as hi-z during reset and the like, so clearly the "bidir" marking in the doc doesn't have much relevance to whether the driver has a high-z mode or not. TxD1 is bidir because it is shared with a GPIO.
1 reply 0 retweets 2 likes -
This Tweet is unavailable.
Oh, missed that detail. Anyway yeah, it would have it due to the reset behavior either way. I wonder why the UART behaves like that though.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.