OMG.... UARTs, SPI, serial com and now HART. Have question about arduio com

OK... I used the arduino mega as a base board on a one off job. So far, its killer! But, in life, you always get a curve ball. I need to get my water tank temperature back on a remote arduino "pro micro" based tank transmitter which is set up as three wire transmitter. Soooooooo the only way to do this is to "inject" temp data on the analog output signal line which is an analog current traveling over a single wire. As this is my personal water system, I am not concerned about meeting all the requirements for a 4-20 mA transmitter.

The main level data is an analog signal created by a DAC. Temperature data needs to be HART like which means the 0s and 1s are travelling as two superimposed frequencies on the main analog current line. This is done using a AD5700 HART modem chip in conjunction with an AD5410 DAC.

The DAC is interfaced to the AT32U4 Atmel processor using the SPI bus. THe AD5700 HART chip has an old school UART interface. Last time I used it, I had a dedicated 16550 UART available.

In going over the Atmel spec sheet, I find what appears to be a single USART chip built into the processor.

Qustion #1: Does the USB controller on the 32U4 utilize this USART?

Question #2: Do the Tx and Rx lines on the Arduino "track" the USB input/ouput or is this a separate function allowing us to hook the arduino up to a dumb terminal in conjuction with our ability to use the USB port for loading and debugging use?

HART is a classic Master Slave protocol which remains idle until the master makes a request to the slave. The amount of bandwidth is actually small and my implementation is a tiny subset of the whole HART protocol. My master (aruduino mega) simply makes requests for status every once in a while and updates tank temperature data once in a while. If the temp data is updated every 5 minutes, that is more than adequate. USB connectivity to the tank transmitter is only for updateing software and for debugging use during development.

If the USART on the 32U4 is already in use for the DAC (SPI interface) and for the USB, then I may be adding a third com function to the USART, namely the HART modem chip. Do we need to reconfigure the USART each and every time we use it for these functions or are there provisions within the arduino serial lib for allowing this? It strikes me as odd that with an SPI interface to other chips, for example, that we would need to do this. Adding a dedicated UART would be hard in lieu of the pin requirements for this.

Any assistance in understanding what I can do and cannot do with the built in USART would be appreciated. Thanks. Dev

Qustion #1: Does the USB controller on the 32U4 utilize this USART?

No.

Question #2: Do the Tx and Rx lines on the Arduino "track" the USB input/ouput or is this a separate function allowing us to hook the arduino up to a dumb terminal in conjuction with our ability to use the USB port for loading and debugging use?

If the Arduino is ATmega32U4 based: No. All Arduinos based on ATmega328p or ATmega2560: Yes, because the (first in the 2560 case) UART is connected to a coprocessor (ATmega16U2) that does the USB communication.

Thanks. I have not looked into USB controllers in detail, but I often feel that the USART has to "feed" the USB modem chip. I may be very wrong here. If the USB controller interfaces directly with the CPU core, than there is no need for the USART. In the case of the 32U4, that would be ideal as I can utilize the USART for the HART chip. But I also wonder if the USART is involved with the SPI controller on the chip as well as its a USART and not an old school UART.

In the case of the mega, it makes sense as the USART has a processor to processor mode to transmit data from one core to another, in this case, the 2560 is sending serialized data to the 16U2 so that it can ship it out the back door using the 16U2 USB controller.

But I also wonder if the USART is involved with the SPI controller on the chip as well as its a USART and not an old school UART.

No, the USART is not involved in the internal SPI controller. It’s a USART but a UART is not old school in any way. Do you know the difference between the two? In all the projects I read on this forum I never saw a setup where the USART wasn’t used as a UART. So the additional functionality is almost never used (at least in the Arduino world).

In the case of the mega, it makes sense as the USART has a processor to processor mode to transmit data from one core to another

What special mode do you mean? It simply uses the standard UART mode to send data to the 16U2.

n this case, the 2560 is sending serialized data to the 16U2 so that it can ship it out the back door using the 16U2 USB controller.

I don’t see the back door here. Modern Arduinos without in-CPU USB controllers simply need a way to communicate with the PC. Older Arduinos used an FTDI chip for the conversion to the USB packets. The small AVR chips are more flexible and allow to handle more USB protocols if programmed accordingly.

It does help to read.... even the several hundred pages of the atmel docs. Yes, I do know the dif between the USART and UART. Back in the day, when we wrote code on 80188s for process, we had to use the UART to simply communicate with other "modem" chips; hence, my mindset. That is why us grey breads call the discrete 16550s "old school". You just wire them up to a maxium 232 and your in business. What atmel has done here is pretty slick. we chose the sparkfun pro micro due to its size and convenience but it turns out there are TWO ways to communicate with this guy. It was really easy to just interface the Tx and Rx lines, etc. to the HART chip without any issues with the USB interface. As I said, really slick!!!!!!! I had the whole HART command stack up and running within a day. I am blown away by the cost, convience, size, and power of this little chip.