0
\$\begingroup\$

So, I am implementing a custom protocol over UART (data field in the packet is fixed at 8 bytes + contains a len field). If the data len is less than 8 bytes, 0xFF is being used for padding. I developed this idea of padding 0xFF from my experience with SPI NOR Flash memories.

However, from the POV of UART, won't this lead to additional power consumption? For example, if I am sending a single byte of data, for the next 7 bytes(garbage) the TX pin will be at logic HIGH.

Won't 0x00 for padding be a better option?

No hardware flow control or interface is being used, and this particular UART line will be connected via 0-ohm jumper resistor to an FTDI chip (FT232RL).

\$\endgroup\$
8
  • \$\begingroup\$ Over what interface / line signaling? \$\endgroup\$ Commented Jul 2 at 16:31
  • \$\begingroup\$ @TimWilliams No h/w flow control or interface is being used \$\endgroup\$
    – dsoham
    Commented Jul 2 at 18:38
  • \$\begingroup\$ No... what is the signal physically going over. GPIO pins? Load resistors? RS-232? The MCU itself will contribute approximately zero current draw, what's attached to it is what matters. \$\endgroup\$ Commented Jul 2 at 18:49
  • 1
    \$\begingroup\$ What makes you believe that 0xFF will be worse for power consumption than 0x00 (or 0xA5 or whatever else)? \$\endgroup\$
    – brhans
    Commented Jul 2 at 19:12
  • 1
    \$\begingroup\$ @dsoham CMOS logic works with voltage. Not current. In ideal case, no current flows when signal is high or low, only when state is changed because there is capacitance. The load is not a resistor. Having said that, often and in this case too, the FT232RL has internal 200kohm pull-up resistors to it's supply, so assuming 3.3V VCCIO, pulling the data input pin low consumes 16 microamps of current and pushing the data input pin high consumes virtually no current. So in your case, sending low state to FTDI consumes more current, if you only look at that single wire. \$\endgroup\$
    – Justme
    Commented Jul 3 at 5:36

2 Answers 2

0
\$\begingroup\$

Generic logic pins today are CMOS type.

The MCU output will drive very close to GND/VCC, with a Thevenin equivalent resistance in the 30-70Ω range -- what range exactly depends on state (typically, PMOS is a little weaker), what the specified drive strength is (VOH/VOL at IOH/IOL) and manufacturing variation (the transistor size varies modestly from chip to chip).

The FTDI input pin will be essentially a capacitance; there are clamp diodes to limit excessive voltages (such as during ESD), then MOSFET gates. From the datasheet:
FT232R

enter image description here

The pin types are defined for these pins on p.10.

enter image description here

Voltage ratings, p.15. Specs continue on pp.15-17 showing characteristics at various supply voltages.

Unfortunately they do not give an equivalent pin circuit, and input leakage current is not specified, but note 3 is most relevant here.

Therefore a mostly-high (0xff) padding will draw the least current through the internal pull-up resistors.

After static current, there is dynamic current. When the pin changes state, capacitances are discharged through transistor resistance, and power dissipated. Typically the energy is constant per switching edge, and power / current consumption is proportional to rate. Eliminating transitions entirely is preferable -- using a variable-length packet for example -- but the next best is a value with few transitions, like 0x00 or 0xff. Again we prefer 0xff.

Most likely, the current draw due to pin changes is negligible in comparison to internal operating current draw by the MCU and FTDI themselves.

\$\endgroup\$
4
  • \$\begingroup\$ Indeed. If you really want to minimize the current consumptiom, many other things should be considered as well - if the padding data is 0xFF which consumes least current via FTDI pull-up, it will end up being longer USB packets due to USB bit-stuffing needed to break sequences longer than six one bits. Again negligible. \$\endgroup\$
    – Justme
    Commented Jul 3 at 8:01
  • \$\begingroup\$ thanks for the explanation. Handling such innocuous topics while working on firmware is extremely tedious. I was wondering if there are any resources to learn these things(analog stuff) bottom-up, for someone from CS background? \$\endgroup\$
    – dsoham
    Commented Jul 3 at 18:22
  • \$\begingroup\$ @Justme thanks, will look into it :D \$\endgroup\$
    – dsoham
    Commented Jul 3 at 18:24
  • \$\begingroup\$ I don't know what goes for resources these days; appnotes have always been awful, but there are some possibilities to look for. Logic family guides/docs/appnotes, often older, usually explain the construction and characteristics in good detail. Going back further, databooks from the 70s to 90s are a good combination of broad information, appnotes, and datasheets (not that you'd need the datasheets when individual parts are readily found today). Building them up from basic concepts (transistors) is reasonable enough, but maybe lower level than you are looking for right now. \$\endgroup\$ Commented Jul 3 at 18:53
1
\$\begingroup\$

It is likely that there is no detectable difference regarding what you transmit from the UART point of view.

Sending 0xFF or 0x00 has equal amount of data transitions anyway.

Unless you know that your physical interface circuit consumes more current in some specific state, like if you have pull-ups or are driving optocoupler inputs.

Edit: Now that it is known that MCU TXD connects to FT232RL RXD, the FT232 has internal weak (200k) pull-ups to VCCIO supply to keep the line idle high when nothing is driving it, so sending 0x00 does consume more current than 0xFF, but it is consumed from the FTDI, not from the MCU, so in the end it may come from PC or whatever is powering the FTDI (it supports being powered from PC USB or locally).

However, if you really need to consider current consumption at this level, you might then want to look at the protocol itself because every byte you send will also consume some amount of current so why send 16-byte blocks if less is needed, and also all other hardware and software should be overhauled to consume the least possible amount of energy in all situations.

Or simply realize that in this case it may be irrelevant if you send 0x00 or 0xFF or any other character as the dummy idle filler character.

\$\endgroup\$
3
  • \$\begingroup\$ Fair enough. However, I read somewhere that the change of state would consume the most power. Padding like 0b10101010 would be more damaging than xFF or x00. \$\endgroup\$
    – dsoham
    Commented Jul 2 at 18:45
  • \$\begingroup\$ @dsoham Actually padding with 0b01010101 would be even worse than your suggestion of 0b10101010. \$\endgroup\$
    – Justme
    Commented Jul 2 at 18:51
  • \$\begingroup\$ somehow SX had given me right alligned text with the cursro on the left side. but anyway. 0x00 and 0xFF both have the same number of transitions. and 0x55 is pathologically the worst - making "UUUUUU" a good test code \$\endgroup\$ Commented Jul 3 at 0:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.