• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 373 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294NCPDT: Need help in finalizing protocol and microcontroller

Ashish Maheshwari
Intellectual 670 points
Part Number: TM4C1294NCPDT


Dera Team,

Currently we are working on new project which is a rack based system

Rack consists of following components

1) Each rack has 18 cards

2) Out of th 18 cards 16 are Input/output card (each input/output card has their own microcontroller) and 2 are communication card (to manage the redundancy)

3) All cards work independently and are hot swappable

4) Distance from the first card to last card is 1.8 meter

5) Data size per I/O card : 50 bytes in an interval of 25 msec, so 50 bytes * 16 cards

Requirement:

1) Each communication card need to fetch process data from all 16 I/O cards

2) Time interval of data fetching is 25 msec (complete cycle from communication card to all 16 I/O card)

Require suggessions

1) Which protocol we should use within rack (spi, ethernet, i2c, uart, usb) we say it as internal communication?

2) Which microcontroller we should use?

Regards,

Ashish

  • 0
    Guru 117855 points

    Greetings,

    Arrives now a 'mix' of questions/concerns & suggestions.

    Ashish Maheshwari said:
    2) Time interval of data fetching is 25 msec (complete cycle from communication card to all 16 I/O card)

    The quote above (may) benefit from a 'wording tweak' - is not "(complete cycle from communication card to [any one] of all 16 I/O cards.")  a better representation of your objective?    This is noted as meeting that '25mS' objective - which must include:

    • 800 data bytes (50 byte exchange between 16 boards)
    • 3- (possibly 5) 'Command/Control bytes' so each board can determine if 'it' is being addressed
    • 'some' delay time to minimize (ideally prevent) 'data collisions'

    This can be resolved by the, 'Presentation of your calculations - which arrived at that '25 mS' (complete cycle) objective.

    Now we have implemented a (somewhat) similar design - and found that, 'Placing the Communication Boards w/in the 'middle' of the (assumed) linear array of boards' - reduced the separation distance between boards.   Further - by placing each Communication Board - 1/3 of the way from 'each end of the board array' - the 'Separation between Communication & I/O Board was (even) further reduced.   (this is advantageous as it potentially enables the use of I2C, SPI, or 'MCU-Level' UARTs - which normally would be challenged by such 'distance.'     (see the model below - for clarity.)

    Model:  C = Commo board, O = I/O board.      O O O O O C O O O O O C O O O O O     (15 I/O (O) boards shown - ideally 'C' boards can inter-communicate - thus 'NEVER' is there beyond a 5 board separation!    [which proves ideal for 'Restricted Range' Serial Signaling]...)

    In a subsequent (even faster speed design) we employed a, 'Circular rather than Linear Array of I/O boards.'    In this manner - the distance between (the center/inside) 'C' boards & (perimeter/outside) 'O' boards - was further reduced and 'held constant!'     (of course client 'loved' such inspired design...)

    Unstated is:

    • will only, 'One Board to One Board' communication occur at any one time?
    • if that proves the case - can that be considered (properly) efficient?
    • should 'multi-board' communication be desired - how will 'Collision Avoidance' be achieved?    (indeed this is likely to 'Direct your choice of Serial Protocol' - is that not so?)
    • from experience - that 50 byte 'data size' is almost certain to, 'GROW!'    What will you do then?

    Is this not (more) of a, 'System Design/Configuration' Issue - rather than one overwhelmingly, 'Focused upon the MCU?'

    TAG: 'Teasing Design Info' where the MCU (likely) serves as 'cover.'

  • 0
    TI__Guru 72500 points

    You might consider using CAN with 11 bit identifiers at 500K baud. The hardware simplifies arbitration, error detection and re-transmission. That will help with the requirement for hot-swap-able. You will need CAN transceivers for every node and termination resistors at both ends of the bus. As CB1 suggested, you might design for a 1Mb bus speed to support future higher data rate requirements. All of the TM4C123 and TM4C129 devices support CAN. 

  • 0 in reply to Bob Crosby
    Guru 117855 points

    Hello Bob,

    'CAN' proved a 'high-candidate' to my group too - yet this (likely) student poster/team  needs to perform (some) key analysis themselves.

    The termination resistors - so many - and in such proximity - may introduce complications - don't you agree?   

    And - as each 'I/O board'

    • contains an MCU
    • and CAN Xcvr

    Might poster's 'need' for 'TWO Communication Boards' be (at least somewhat) muted?

    Note too - the 'Imposition of those Communication Boards is expected to, 'Reduce the effective communication by 'ONE-HALF' (at minimum) as each message must travel to the 'Communication Board first' - and only (then) be relayed (i.e. 'Sent AGAIN')  to the I/O board selected!

    *** Digikey just called - they 'fear' a, 'Run on CAN Xcvrs' ... yet 'not so much' on termination resistors...

  • 0 in reply to cb1_mobile
    TI__Guru 72500 points

    Hi CB1,

    I think they can get by with just putting the termination resistors on both ends of the bus on the rack. The application report cited above (http://www.ti.com/lit/an/sloa101b/sloa101b.pdf) suggest an un-terminated stub length of no more than 0.3 meters. That should be much more than sufficient in getting the traces from the CAN transceiver to the rack back-plane. Of course keeping the transceiver close to the connector will help minimize that stub length.

    I am not aware of any anticipated shortage of transceivers. Currently TI has ample supply. This application can stay with the traditional transceiver as opposed to the newer CAN FD. Something like: http://www.ti.com/product/SN65HVD232

  • 0 in reply to Bob Crosby
    Guru 117855 points

    Bob Crosby said:
    Of course keeping the transceiver close to the connector will help minimize that stub length.

    That's excellent - and may be 'borrowed' for the 'JTAG/SWD' routings as well.

    (comment: 'RUN on CAN Xcvrs' was (intended) as a joke - SO Many Xcvrs deployed here...   Humor-lite staff suggests that, 'I keep my day job...')