Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
What is the difference between the SPI and I²C protocols, used to program a microcontroller?
Please specify the pins used in each case.
SPI and I²C are bus protocols, and each is well defined:
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
http://en.wikipedia.org/wiki/I2c
They are very similar in how they work, but they aren't the same and the differences aren't minor.
Depending on the microcontroller, they may have either, both, multiple of each, or none. They may share pins, and they might not. Refer to the datasheet of your microcontroller.
What is the difference between the SPI and I²C protocols
SPI is a 4-wire signalling scheme with a single bus master and several slaves. There's a chip select signal (CS, or slave select SS) dedicated clock signal (SCK) and two data signals, one for reception (MISO = Master In ← Slave Out), one for transmission (MOSI = Master Out → Slave In).
Transmission starts by asserting (= pulling low) SS, then for each bit MISO and MOSI are set after a SCK high→low transition and the actual transfer happens on a SCK low→high transition. Beyond that, there's no such thing as a "standard protocol" carried over SPI beyond the transmission of groups of bits; every component with an SPI interface may define its own.
I²C is a 2-wire signalling scheme, capable of multiple bus masters. It's a lot more complex than SPI, so I suggest you read the Wikipedia article about it.
used to program a microcontroller?
No, because that depends on the microcontroller you're using. Also do you want to write a program for that microcontroller that does communication over SPI or I²C? If this is the case I can give you no answer, because it depends on the controller you're using. It usually boils down to configuring the SPI peripheral (if it got one) or implementing the bit-banging on the GPIOs (which again is specific to the microcontroller used) yourself.
Or do you actually want to program the microcontroller flash over this? If the later is the case take note that the actual programming method depends on the actual microcontroller used and may not happen over SPI at all. And I know of no microcontroller that actually uses I²C for flash programming (except if it has been programmed with a bootloader that does the talking).
SPI is used for programming the Atmel ATMega microcontrollers. But the XMega microcontrollers are programmed using an interface called PDI, which is a completely different beast (uses the reset pin for clock and as a dedicated PDI Data pin).
Most ARM microcontrollers are programmed using JTAG. Then there are interfaces like SWI (which is related to, but not the same as JTAG).
SPI and I²C are defined, see Wikipedia.
Both are master and slave based and can share at least some of the bus. Both are serial based: I²C shares the data line so it is bidirectional, and SPI there is from master and to master. In both cases, these data lines are wired or (you drive zero or let it float and the pull up resistor pulls the line high). I²C is address based, and SPI has separate chip selects for each entity on the bus.
Your question needs work. Some devices can be programmed using SPI, but we generally talk about the microcontroller being the master and using these to program someone else. SPI and I²C busses are standards, but different vendors use them in ways to make it difficult to have a generic hardware interface. SPI more often than I²C will have hardware assist, but it is a good idea to learn to bit bang either and you can always fall back on that.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
In embedded systems, we often use UART to transmit data to a serial console on a PC, and these days with a USB-to-uart serial converter showing up as a virtual com port. Why has UART become the go-to for this instead of other serial interfaces like I2C and SPI?
Because is simple, was designed to be used on longer distances (I mean meters not kilometers :)), very standard and every uC has it.
I2C & SPI are not designed to be used outside the PCB (I know that people use them on longer distances). Those interfaces are used do connect other ICs to your microcontroller.
Maximum distance of RS232 can be a few meter, I2C and SPI doesn't work well with distances longer than about 200 - 500mm (depending on pullups, speed, collector current, ...).
SPI and I2C need a master and slave(s), there is no such difference between 2 UART hosts.
You need fewer pins than SPI (when pins like DTR, DSR, RTS are omitted) or a parallel port.
You don't need to worry about where to put a pullup-resistor.
Both hosts can start a transmission asynchronous, with I2C and SPI the master needs to poll the slave before he can transmit data.
A host doesn't need to answer immediately. This can be important on a PC under load where the reaction time can be very high (50ms or so). Try to write a program for a PC that can reliable answer in less than 1ms.
Is that a possible communication between two STM32f4 devices with Profibus/Profinet Protocole. I can not find any information this question. I want to MASTER to SLAVE communication. And i want to send message/data between.
Profibus is not really designed for MCU to MCU communications. The only reason you would use it is if they are some distance apart and you had one master and multiple slaves. Profibus DP generally requires a specific Profibus IC (such as Profichip) to implement a Slave module as the timing is critical. Similarly implementing a Master is also a complex affair. It is meant to be used as a field bus (for use over entire factories or sites etc.)
I don't know that much about Profinet, but I doubt it is what you want for MCU to MCU comms.
If the processors are in the same device I2C would probably be your best bet and is physically supported by the STM32F4 (you would need a protocol on top this as well).
I am currently working on boot time diagnostic software for Beagle Board - xm it is just like POST ( power on self test ) what we have in BIOS systems , So as we know during early stage there is no driver present so that i came to know that i have to write a basic low level driver for the peripherals, but my question is what kind of test should be performed in boot time whether it is limited to basic read/write ( in case of my devices like i2c & spi) or i need to perform test for each and every functionality of the peripherals. So i just want to know what kind of tests are conducted or what kind of steps are followed for I2c & SPI during a boot time diagnosis .
Usually devices like I2C and SPI have default values of some registers according to their documentations. At boot time you can read from your diagnostic procedure all I2C/SPI peripheral devices and check obtained data. If you can read (default for reset or even better - read only constants) and determine they are correct, that means these parts are OK at this stage.
I wish to read the EUI64 address from an AT24MAC602 memory chip interfaced to an Atmega128rfa1 MCU over the Two wire interface. I tried to modify the I2C master drivers which are available for other platforms to suit my need. However, I wasn't able to carry out these modifications successfully as the program stopped responding as soon as the slave address was written to the twi bus with Write flag set. I failed to uncover the underlying reasons for the same.
As Contiki OS is quite popular, i thought someone might have already come up with contiki specific libraries for reading writing over TWI interface for Atmega128rfa1 MCU. If so, please provide pointers to the twi drivers or documentation for the same, or suggest factors that should be considered for developing such drivers. Thank you.
If you don't have any luck finding/creating a driver for the TWI peripheral, you might consider emulating it by configuring the SDA/SCL pins as general I/O and then implementing the TWI protocol yourself. If you're just doing a one-time read of a chip ID then speed probably isn't a big concern, so this could work if you get desperate. Google should throw up a few examples of emulated TWI.
I'm going to write an SPI driver for an ARM devlopment board. It is not used with Linux.
Yesterday, I read the QSPI driver that Xilinx provided and I tried it successfully. However, I would really like to write my own SPI driver.
Here are my questions:
What is the difference between QSPI and SPI on usage?
If I write a driver based on QSPI, will it work?
If I write a driver from scratch, what is the basic procedure (READ / WRITE / INITIALIZE)?
And finally, why must SPI send and receive at the same time?
Thanks everybody.
I think it may be easier to start with your last question first.
Why must SPI send and receive at the same time?
The easy answer is that it is part of the protocol. As data is shifted out on the MOSI line from the Master to the Slave, the data in the Slave's buffer is shifted to the Master on the MISO line. This allows the hardware to use a single register in each device for both the data being sent and the data being received. There is a good diagram of the process here:
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
The not so easy answer is that SPI is not a well defined standard. There are different types of implementation depending on the devices you are using. There is even a variant where the MOSI and MISO lines are combined and used in a bi-directional manner (3-wire SPI). However, most of the implementations I have dealt with send and receive over two different lines and that tends to be the standard methodology.
What is the difference between QSPI and SPI on usage?
QSPI or Quad SPI actually does not adhere to the standard methodology and breaks the concept of sending and receiving at the same time. It utilizes four bi-directional I/O lines to send and receive data and is often used for memory applications (because it is faster than SPI). With QSPI you are not sending and receiving at the same time.
If I write a driver based on QSPI, will it work?
Certainly! You just have to familiarize yourself with the hardware that you are using. Again, SPI is very different from Quad SPI and you can often find hardware implementations that make it very easy to use QSPI. For example, your Zynq 7000 has a QSPI Controller that has a lot of features to simplify the coding process. It will also operate in a "legacy mode" that acts as a normal SPI controller. On top of that, the Zynq 7000 has two other standard SPI controllers that are not setup for QSPI. I would highly encourage you to read the technical documentation here:
http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
If I write a driver from scratch, what is the basic procedure?
That is very hardware dependent. I did a quick overview of your hardware, but detailing the steps here would take far too long. However, the technical manual for your device appears to have great step-by-step instructions for configuring and using both the QSPI and SPI controllers. Here is an example from the SPI section:
17.3.1 Start-up Sequence
Example: Start-up Sequence
Reset controller: Assert and de-assert the Ref and CPU_1x resets, refer to section 17.4.1 Resets.
Program clocks: Program the SPI_Ref_Clk, refer to section 17.4.2 Clocks.
Tx/Rx signal routing: Refer to section 17.5 I/O Interfaces.
Controller configuration: Refer to section 17.3.2 Controller Configuration.
Interrupt configuration: Configure the ISR to handle the interrupt conditions. The simplest ISR
reads data from the RxFIFO and writes content to the TxFIFO. The PS interrupt controller is
described in Chapter 7, Interrupts. The interrupt mechanism for the SPI controller is described in
section 17.3.5 Interrupt Service Routine.
Start data transfers:
Master Mode operation select: Manual/Auto start and SS, refer to section 17.3.3 Master Mode Data Transfer.
Slave Mode operation, refer to section 17.3.4 Slave Mode Data Transfer.
I hope that helps!