In I2C interface,
SCL, clock line will transmit clock signals even if there are no devices on the bus?
How can we debug the I2C?
The I2C bus master does not know if there are slave devices connected to the bus.
All it can do is to initiate communication with a certain device by sending the slave's address to the bus (it can be a read or write operation). If the master receives an ACK, acknowledge, then that means the slave is ready (and presented on the bus) to communicate. A NACK, not acknowledge can mean that the slave is not ready. If the request time outs that means, there is no available devices on the bus with the specific address.
Now, back to your question:
SCL, clock line will transmit clock signals even if there are no devices on the bus?
Yes, the clock line will be driven when the master initiates the communication, even if there are not any slaves. The clock is used, as there are data on the bus, the slave device address.
It looks like in the image below, the only difference that the ACK won't be there if there are no slave device on the bus (with that address).
Now as for the debug, the best would be if you could buy a logic analyzer, (cheaper versions are available on eBay or aliexpress) to capture what is going on actually on the bus. The image above has been made using one.
Related
I have one micro controller and 4 slave devices are attached with micro controller I2C bus. I have one doubt regarding data reading from I2C bus. When master initiates any transmission it will write device address on the I2C bus, but i want to know how slave devices will identify in I2C bus, data belongs to them or not.
Slave devices have an address, either a fixed one or often an address where one or two bits can be configured by hardware (pulling certain pins of the chip to ground or VCC). Each slave knows its own address.
The slaves listen to all I2C communication. If an I2C transaction contains their address at the start, they will interact in the transaction. Otherwise they will ignore the transaction.
I'm trying to understand why I am seeing RX interrupts when tying RX to TX of my SAMR34 but not when I connect it to the transmitting device. The transmitting device notes the following restrictions:
Serial hardware flow controls (RTS/CTS and DTR/DSR) are not used and will be ignored. In addition, the receiver must not use software flow control (XON/XOFF)
I do see data from the transmitter when I poll. Does interrupt driven UART require support from the transmitter? Should I switch to DMA to resolve this issue? Here is my setup
A UART receiver doesn't need support from the transmitter to generate a RX interrupt. A RX interrupt can be enabled and will generate a RX interrupt when a new data unit (7/8/9 bits depending on settings) is received by the UART.
Serial flow control RTS/CTS and DTR/DSR are in most situations not used and can mostly be ignored/disabled. They have some merit in some situations as noted by Peter Smith here on electronics.stackexchange.
You are probably seeing data when you do a loopback because it is doing everything sequentially and as such will do a transmit -> receive -> transmit -> receive. When connecting to an external device the pattern will look like this when transmitting is done in a blocking manner:
transmitter: Transmit Transmit Transmit Transmit Transmit
receive transmitter: Receive->Transmit Receive->Transmit Receive->
This will at least result in missing data because the CPU is busy waiting for the transmit to complete before trying to receive another byte.
DMA is used to move data around without involvement of the CPU. And can be used to transfer incomming data from the IDR to ODR. (Incoming Data Register and Outgoing Data Register)
Another solution would be to have the RX interrupt write the data to a buffer and manage how much of the buffer is used. The TX can then be done on the data without blocking the RX.
My requirement is as follows:
I need to send Proximity Sensor (Reed Switches/Magnetic Sensor) reading (On/Off) from two Input Pins to a central PC.
I need to use coin cell. So basically the app should be in sleep mode and once there is any interrupt on any of these two pins it should wake up to send its state to the central PC.
I have DA18450 chip and development board (murata ZY type) with me.
Dialog Semiconductor 18450
Murata Bluetooth Smart Development Board
I am a beginner to bluetooth technology and started reading about it just a week back.
Could someone guide me about the most apt Profile/Service suitable for my application?
If you want the device to actually sleep then it'd probably be best for it to just transmit data via advertising packets when the device awakens. Otherwise you have to maintain a connection which requires staying awake at some level. However, advertising packets are broadcast and the device can't know if anything received those packets (you could have it broadcast several times for a fixed period of time or have it constantly broadcast while the proximity alert is valid). Also, on the receiving end, with no connection there's no way of knowing the transmitting device is even there when nothing is being transmitted.
The advertising packets have a section for limited information and that's where you'd transmit data if you don't want to establish a connection.
I am trying connect multiple Arduino Mega Boards via their Serial pins to allow communication between the boards. I want to be able to connect an arbitrary amount of arduinos by daisy-chaning them and I want one board to be the master, taking control over the actions of the other boards. The master should be determined dynamically by the boards. I am aware that the daisy chaining method introduces delays to the communication due to the forwarding of packets, but so far I am planning on connection 4 boards at most. In the future this might increase to maybe 10 boards. My boards all have a separate power source, since they are connected to some other hardware which has its own power source.
My idea was to connect the boards in such a way, that the master would be determined by the wireing of the boards. I thought about having the "Serial" port as 'To-Master' serial port and the "Serial1" port as "To-Child" serial port. The boards send hello messages on the "To-Master" serial port and the master replies if it received such a message on the "To-Child" serial port. If no answer is received after some seconds, the board determines itself to be the master.
I wired the boards up by connecting the ground pins, and wiring RX1 of the master to TX0 of the child and TX1 of the master to RX0 of the child:
Basically my setup is working, since the boards do detect each other and exchange hello messages and replies. There is however a significant amount of packet loss or corruption which I would like to eliminate.
As a simple measure of packet verification, I begin each packet with a "magic number". The receiving board looks for this byte and only tries to read a packet after receiving this byte. Any other bytes received are simply discarded.
As it seems, it happens quite often that something is received on either serial port that does not start with the magic number and is therefore discarded. The timestamps of these events are however consistent with the timestamps of sending of the other board meaning that the packet was at least partially transmitted but somehow the magic byte got corrupted or discarded.
Is this a known problem with the arduinos serial ports?
Can it be related to my wiring?
Are there any measures I can take to ensure a save delivery of the packets?
Can it be a problem of the boards not reading the signal at the correct time (I used a baud rate of 9600)?
I also looked into I2C communication, but I did not find any resource or information if it is possible to dynamically choose the master for this type of communication. Also in the documentation it stated, that it is important that all devices share a common power source which is not possible in my scenario. However, the basic master-slave principle of this I2C conforms with my requirements, as I have a master that sends commands to all other boards. Could I2C be utilized in my case?
Thank you for your thoughts!
Here is a discussion about multi-master I2C topology of Arduinos, seems that it is supported (haven't tested it myself). - http://forum.arduino.cc/index.php/topic,13579.0.html
You can test SPI as well, here is a comparison between the two - http://components.about.com/od/Theory/a/Selecting-Between-I2c-And-Spi.htm.
Slave might be selected with generic GPIOs
I don't know any known implementation of multi-clients on top of Serial bus (usually it is intended for peer2peer communication only) - even though, your configuration seems reasonable, I would be considering other options.
BTW, from your comment about different power sources, I assume your boards are away from each-other. Have you considered very cheap ($2) RF modules, such as nRF24L01+ (http://maniacbug.wordpress.com/2011/11/02/getting-started-rf24/). THere is a library for networking those in multi-node network
Might be better off with I2C or SPI like people have suggested here.
However, to address your question directly, it is most likely wiring. I am assuming you are using cheap jumper wires to plug directly into the Arduino Headers. Noise on this connection is the most likely problem or garbled serial messages. Try implementing with twisted pair cables and connecting directly to the board.
SPI or I2C might have better error correction than your customer serial protocol. I would see the other answers for that.
How can i tell if the unit connected to serial port is powered on?
Does serial communication have any means of acknowledging that a command has been received that i can check for?
or is it entirely dependent on whatevers plugged into the serial port?
Most RS232 devices (such as modems) will raise the DSR (data set ready) line when they are powered on and ready to work. You can query the status of this line in software.
In a similar fashion, computers generally raise DTR (data terminal ready) to tell the modem (or whatever device) that they are ready. You can control this line from software.
Acknowledgement is not specified by RS232 and varies from one device to another, but many devices do indeed use hardware handshaking to indicate willingness to receive data. Specifically, they will raise CTS (clear to send) when they are ready. If the device is powered on, but can temporarily not receive data, it will leave DSR high, but will clear CTS.