EK-TM4C1294XL: i need to make 8 hardware UART connections simultaneously.

hariram rajagopalan said:

I need to make 8 hardware UART connections simultaneously ...  send hex commands  ...  receive response - and view it on the PC's serial monitor.

Which "ONE" of those 8, simultaneous UART connections, do you seek to view?     (on the assumed - single PC serial monitor)

Classically it proves "difficult" to coerce the MCU to execute more than one code block - at the same time.    (µDMA may allow such - but proves doubtful over 8 channels - simultaneously)

Why is "simultaneous" operation required?       Surely your "ultrasonic sensor" does not provide, "8 such UART channels" - which suggests that you seek to accommodate, "8 such sensors" - is that correct?

It proves "more likely" that you can service 8 UARTs w/in a "Round-Robin" process (one at a time - in sequence) yet this method forces each sensor to be "blind" during the interval in which it is unaddressed...

Your requirement is (now) far clearer - and indeed (depending upon performance specs) quite possible - thank you.

Knowing your intended application - it DOES appear that, "Round-Robin/Sequential" UART transactions MAY succeed.     (again - depends upon specs)

As firm/I have (some) familiarity w/Autonomous Auto - it appears that you (likely) employ "2 sensors (each) @ front, rear, each side" of the vehicle. And - as the MCU is most likely to "know" the direction of movement (while parking) - you may be able to, "reduce the number of sensors (actively engaged/transacting) during the parking process!"   (i.e. while "backing into a parking spot" - the "need" for "front aiming sensors" declines.)    

You ask for "help" and just like: 

• our clients
• multiple, past bosses
• certain investors

you proclaim the job as "Easy!"     And that - most never - proves true.     What IS "true" is that the "devil is always w/in the details" - and those (pesky) details have yet to arrive.     (although we are assured that they're "easy.")      From our "real world" experience w/in "Autonomous" - those sensors are distant from your MCU - thus "line drivers/level shifting" prove likely - and may "apply the brakes" to the MCU's hi-speed UART capability!

Thus the verdict of "easy" may prove premature - even incorrect  - and hinges upon your "real" specifications...    (2 quick/obvious ones: number of bytes transferred during "command & response" and the "maximum (desired) response time" - enforced upon each/every such "UART Transaction, and nicely justified/documented."     (i.e. beyond guess and/or opinion)    

And that's indeed "easy" - yet lacking - why is that?

Sorry for mentioning the word "easy" What i meant "easily" was ,it won't take much of your time .Don't mis-understand me.And if you can extend your support on this, it will be helpfull for us .

hariram rajagopalan said:

I use tida-00151 texas instruments ultrasonic sensor which could be interfaced through uart,spi and lin.

hariram rajagopalan said:

I pereferd to use the uart communication between the sensor and the tm4c1294 only because tiva c series had 8 uart pins.

Whereas it doesn't have 8 spi or 8 lin.

While those statements are true, I think they overlook valuable alternatives.

There may not be 8 SPI but one SPI and 8 chip selects (4 pins would do that) will do the same job. I would not, however, use SPI off board and I think you are likely doing that.

LIN is another possibility. It's just a UART based protocol. It's an addressable protocol so, assuming you can change the address of your sensors, one UART will serve multiple sensors.

Final note: Although the 1294 is listed as supporting 8 UARTS you should check that all 8 can be used in your configuration. It's not unusual for there to be configurations that do not allow using all of them and there have been devices where despite having n UARTS available there was not a hardware configuration that allowed all of them to be used.

Robert

Robert Adsett said:

Although the xyz (No free advertising)  is listed as supporting 8 UARTS you should check that all 8 can be used in your configuration.

Just a GREAT point - in fact I'd argue that the ability to effectively use ALL such common Peripherals - proves unlikely.     As you note - Peripheral's "presence" does not insure "simultaneous" usage capability!

I would "bet the farm" that all 8 sensors are NOT "near" the MCU - not a chance - thus SPI/I2C - proves 'not an option."

Clearly there IS distance involved - and the required UART line drivers will challenge - "The NEED for SPEED."   (you & I both made past mention of this unfortunate fact...)

cb1_mobile said:

Clearly there IS distance involved - and the required UART line drivers will challenge - "The NEED for SPEED."   (you & I both made past mention of this unfortunate fact...)

Indeed. The application seems to call out for CAN (with a simple periodic update from each sensor). But LIN might work. It is an automotive network but designed to be inexpensive rather than fast. Still you might mange a few sensors on a UART depending on the needed update rate.

Robert

Like an iceberg, the details that will trip you are masked the apparently simple surface complexity.

Robert Adsett said:

Like an iceberg, the details that will trip you are masked by the apparently simple surface complexity.

And - such proves especially true - even when - and especially when - that "simple surface" is "too late" detected!      (i.e.   while (iceberg unseen)  {forward_speed ++;}

Can - while "top dog" - may not be present w/in poster's sensor...      

Robert Adsett said:

really have nothing more than vague suggestions.

Yet - are not (those) a vast improvement - especially appropriate for the, "Does Not Work" crüe?      (which does NOT describe this thread's o.p.)