With regards to Arduino EEPROM when writing and reading to certain EEPROM devices it asks for a transmission of the following format:
Wire.beginTransmission(ADDR);
Wire.write(highADDR);
Wire.write(lowADDR);
Wire.write(data);
Wire.endTransmission();
What do the high address and low address mean? Why can I not just tell it to write to the byte at address 4. Why do I need to prove a high and low?
It looks to me like you are using I2C, I am going to make that assumption and base my answer off of it. Perhaps you should clarify which EEPROM you are using.
The way I2C works is that you can have one master (your Arduino) communicate with multiple slaves (your EEPROM for example) on the same I2C bus. Since it is possible to have multiple slaves connected on the same bus, I2C protocol requires you to specify what slave device you are communicating with. This is what Wire.beginTransmission(ADDR) does. It is selecting which device it wants to initiate communication with. If you want to communicate with your EEPROM you will need to send the address of your EEPROM (you should be able to find the address in the EEPROM datasheet).
Next, you need to specify the memory location inside your EEPROM where you want to access. This is done using the two bytes highADDR and lowADDR. If for instance you wanted to access the address 0x01AB, then set highADDR to 0x01 and lowADDR to 0xAB.
The rest is fairly simple. You send your data then end the transmission.
To Summarize:
Select device to communicate with (Select your EEPROM)
Wire.beginTransmission(ADDR);
Tell your EEPROM what memory address you want to write to
Wire.write(highADDR); // Send the most significant address bits
Wire.write(lowADDR); // Send the least significant address bits
Send data to write.
Wire.write(data);
End the transmission
Wire.endTransmission();
I strongly recommend reading more about how the I2C protocol works. http://en.wikipedia.org/wiki/I%C2%B2C#Message_protocols
Related
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.
I will have several devices with atmel microcontrollers which Im going to connect to PC using COM. Is there any way to connect several devices into one COM? (Let's assume COM can handle amounts of data I need to transmit and I can choose the way of sending data using COM)
Sure, chain the ATmegas together via serial, and use a single USB-serial device. Combine all the data you need to send, and send it out of the single serial port. In each ATmega, you can either relay all the data to the next one, or use a little more intelligent scheme and only forward data meant for other ATmegas.
The standard RS232 COM port does not allow to connect several devices to one port. Because parallel connection of several devices may change electrical signal characteristics such as voltage levels. You may build a chain of ATmegas as uint128_t suggested or change the physical interface type to RS485.
RX pins: you can connect more RX pins together.
TX pins: you can connect more TX pins together if you ensure that only one is active at any time. Others pins must be configured as input or high impedance. This can be done with a suitable protocol.
The parasitic capacitances of pins connected together sum up - this can eventually limit the transfer speed.
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.
I have a processing sketch that pumps out basic serial commands to an xbee.
Then I have two (soon to be 3, maybe 4) arduino's with their own xbee's who receive the data and do stuff.
Thing is each Arduino has it's own purpose, and therefore it's own data packet.
So, to implement this. Is there a way to send a message to a particular xbee? I.e. can I assign the xbee an index or channel of some sort, then get the broadcasting xbee to send data to whatever index or channel it needs to?
Or, will this need to be implemented in the Arduino software?
i.e. Processing prefix the data packet with an index/identifier and the arduino ignore incoming messages with that prefix?
Or is there another option entirely :P
Thanks in advance for your advice.
While not a specific answer to your question, with this type of communication some packet error checking would be beneficial. Send the data using a crc error checking algorithm. Packet structure could look something like:
0x7F 0x02 (Address Bytes) (Command Bytes) (CRC bytes) 0x7F 0x03
Where 0x7F is the DLE character used to indicate either a start byte will follow, and end byte will follow, or a data byte with the value of DLE will follow. This means any DLE character that is part of the address or command should be preceded by a 'Stuffed' DLE character. The CRC is calculated from the address and command bytes and used to check the integrity of the data that is received. The CRC check bytes are included in each packet.
This type of communication will prevent packets going to the wrong source from being used, and also packets that are in error from being used.
To read more on serial framing here is a good place to start: http://eli.thegreenplace.net/2009/08/12/framing-in-serial-communications/.
To what i understood is that you want to be able to tell the diffrence to what Xbee you are sending data to. You can do this by using IP adresses. If you have for example two Xbees with the IPs:
Xbee1 - 192.168.80.50
Xbee2 - 192.168.80.51
Xbee3 - 192.168.80.52
You can send information between them by just connecting the Xbee that will start the communication to the Xbee that will receive it. If you want to have any kind of communication over the wireless network (or ethernet) you must have an IP assigned to every Xbee.
EDIT:
If you have a server on a computer that you have made yourself in for example Java. You can connect the Xbees to that and connect of them to the computer server. Then you can set up the server to receive and send data to the diffrent Xbee clients.
I did something similar to this: Maintaining communication between Arduino and Java program , but i didn't use a Xbee, i used the official WiFi shield.
Hope this helped!
-Kad
I'm building a project that uses an HID OEM75 as the access point for a locking mechanism. We're doing our control through an Arduino Duemilanove (ATmega328). We're working with SPI for the security and (apparently) support. (I realize that any RFID chip has pretty weak security.)
I'm currently struggling with receiving bytes via SPI from the card reader.
The card reader is in autonomous read mode, meaning it reads a card, sends a signal to the Arduino (via a card present line, separate from SPI), which tells the Arduino to pull the Slave Select line high to activate the transfer cycle from the card reader. This is where I run into trouble, I can't understand how I can get the Arduino to simply read the bytes coming in from the card reader without sending any command bytes to the card reader?
The default command structure, SPI.transfer(0x00), sends a byte (in this case the dummy byte 0x00) and then accepts a byte from the source, but because our source is operating autonomously, it won't accept the dummy byte (and that will actually mess up its operation).
To word it simply: how can we accept a string of bytes from the slave source without sending bytes from the Master Source, using Arduino's SPI library?
If I am not wrong, using the SPI bus as a master is like shifting a dummy byte to the slave while reading the incoming byte in reverse.
USB HID Host driver for Windows from embedded24.net
Well it's a little late, but hey, it'll help someone out there.
First off:
which tells the Arduino to pull the Slave Select line high to activate
the transfer cycle from the card reader.
This is SPI, you pull the Slave Select low to activate the slave, not high. You put it high to tell it to shut up while others are talking.
I can't understand how I can get the Arduino to simply read the bytes
coming in from the card reader without sending any command bytes to
the card reader?
That's because you don't. In SPI, the master (which the arduino is set up as and the SPI.h library assumes) initiates communication. It sends out data on the MOSI line and the slave responds on the MISO line. If you have nothing to say to the slave, just send 0xFF or whatever dummy bytes and then check what came in on the MISO. On the arduino, I believe that gets stored in the SPDR, SPI data register. Or use whatever the spi library gives you.
but because our source is operating autonomously, it won't accept the
dummy byte (and that will actually mess up its operation).
If the case is that you really can't send data to the SPI slave device without it screwing up, then it's not actually implementing SPI, and the arduino SPI library won't help you. You'll have to hack out your own solution. The SPI standard is actually pretty loose and all sorts of people do it their own special way. Which is vastly annoying. I've seen devices use the SS line to initiate clock synching. Which means you can't just tie it to ground to have that slave always be on.
Before you write it off though, I'd suggest investigating why it won't accept the dummy byte. You might be using "3-wire" SPI which combine MOSI and MISO and turn it from full duplex into half duplex, and you'll have to get the timing right so you don't trample everything.
When getting into the nitty gritty of SPI, an oscilloscope works wonders for seeing what actually happened vs what you think should have happened.