Duke's Blog

Learning is a life long journey.

Subscribe

CDBUS makes RS485 automatically avoid conflicts

  1. CDBUS Protocol
  2. CDBUS IP Core
  3. Ready To Use Devices
  4. Code Examples
  5. License

CDBUS Protocol

CDBUS is a protocol for Asynchronous Serial Communication, it has a 3-byte header: [src_addr, dst_addr, data_len], then user data, and finally 2 bytes of checksum.

It's suitable for one-to-one communication, e.g. UART or RS232. In this case, the address for each side are usually carefully selected and fixed, e.g: [0x55, 0xaa, data_len, ...], and the backward is: [0xaa, 0x55, data_len, ...].

The CDBUS protocol is more valuable for bus communication, e.g. RS485 or Single Line UART. In this case:

  • It introduces an arbitration mechanism that automatically avoids conflicts like the CAN bus.
  • Support dual baud rate, provide high speed communication, maximum rate ≥ 10 Mbps.
  • Supports unicast, multicast and broadcast.
  • Max payload data size is 253 byte. (you can increase it to 255 byte, but not recommended)
  • Hardware packing, unpacking, verification and filtering, save your time and CPU usage.
  • Backward compatible with traditional RS485 hardware. (still retains arbitration function)

The protocol example timing, include only one byte user data:
(How long to enter idle and how long to allow sending can be set.)

protocol

Arbitration example:

arbitration

The idea of CDBUS was first designed and implemented by me in 2009.

CDBUS IP Core

Source code and more details: - https://github.com/dukelec/cdbus_ip - https://github.com/dukelec/cdbus_doc

Block Diagram

block_diagram

Operation

operation

Ready To Use Devices

The CDCTL controller family uses the CDBUS IP Core, which provide SPI, I2C and PCIe peripheral interfaces.
E.g. The tiny CDCTL-Bx module support both SPI and I2C interfaces:
cdctl_bx cdctl_bx

For more information, visit: http://dukelec.com

Code Examples

    # Configuration

    write(REG_SETTING, [0x01])                  # Enable push-pull output


    # TX

    write(REG_TX, [0x0c, 0x0d, 0x01, 0xcd])     # Write frame without CRC
    while (read(REG_INT_FLAG) & 0x10) == 0:     # Make sure we can successfully switch to the next page
        pass
    write(REG_TX_CTRL, [0x02])                  # Trigger send by switching TX page


    # RX

    while (read(REG_INT_FLAG) & 0x02) == 0:     # Wait for RX page ready
        pass
    header = read(REG_TX, len=3)
    data = read(REG_TX, len=header[2])
    write(REG_RX_CTRL, [0x02])                  # Finish read by switching RX page

License

This Source Code Form is subject to the terms of the Mozilla
Public License, v. 2.0. If a copy of the MPL was not distributed
with this file, You can obtain one at https://mozilla.org/MPL/2.0/.
Notice: The scope granted to MPL excludes the ASIC industry.
The CDBUS protocol is royalty-free for everyone except chip manufacturers.

Copyright (c) 2017 DUKELEC, All rights reserved.

Comments:

#1, Thursday, April 23, 2020, Madi <me.fa~@ya~.com> wrote:

Dear, I'm interested in the idea of CDBUS and wish you the best. Just have a question about the PHY layer - RS485. The receiver in RS485 transceiver chip is always enabled as it is connected to the ground. but the transmitter enable pin is controlled by controller. could you please let me know if it is really controlled or not. In other word, is it possible to connect it to the VCC?

#1.1, Sunday, June 28, 2020, Duke <~@d~.io> wrote:

Transmitter enable pin is controlled by controller and can't connect it to the VCC. If you connect the DE pin to the VCC, you can only receive data from the local DI pin.


Please visit the original link: /cdbus