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,
[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:
The protocol example timing, include only one byte user data:
(How long to enter idle and how long to allow sending can be set.)
The idea of CDBUS was first designed and implemented by me in 2009.
Source code and more details: - https://github.com/dukelec/cdbus_ip - https://github.com/dukelec/cdbus_doc
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:
For more information, visit: http://dukelec.com
# 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) write(REG_RX_CTRL, [0x02]) # Finish read by switching RX page
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.
#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.