I'm new to microcontroller programming and I have interfaced my microcontroller board to another device that provides a status based on the command send to it but, this status is provided on the same I/O pin that is used to provide data. So basically, I have an 8-bit data line that is used as an output from the microcontroller, but for certain commands I get a status back on one of the data lines if I choose to read it. So I would be required to change the direction of this one line to read the status thus converting this line as an ouput to an input and then back to an output. Is this acceptable programming or will this changing of the I/O pin this frequently cause instability?
Thanks.
There should not be any problem with changing the direction of the I/O line to read the status returned by the peripheral provided that you change the state of the line to an input before the peripheral starts to drive the line and then do not try to drive the line as an output until the peripheral stops driving it. What you must try to avoid is contention between the two driver devices, i.e. having the two ends being driven to opposite states by the processor and peripheral. This would result in, at best a large spike in the power consumption or worse blown pin driver circuitry in the processor, peripheral or both.
You do not say what the processor or peripheral are so I cannot tell whether there are any control bits in the interface that enable the remote device to output the status so that you can know whether the peripheral is driving the line at any time.
I've done this on digital I/O pins without any problems but I'm very far from an expert on this. It probably depends entirely on which microcontroller you are using though.
Yes, it's perfectly fine to change I/O direction on microcontroller repeatedly.
That's the standard method of communicating over open-collector buses such as I2C and the iButton. (see PICList: busses for links to assembly-language code examples).
transmit 0 bit: set output LATx bit to 0, and then set TRISx bit to OUTPUT.
transmit 1 bit: keep output LATx bit at 0, and set TRIS bit to INPUT (let external resistor pull-up line to high)
listen for response from peripheral: keep output LATx bit at 0, and set TRIS bit to INPUT. Let external resistor pull-up line to high when peripheral is transmitting a 1, or let the peripheral pull the line low when peripheral is transmitting a 0. Read the bit from the PORTx pin.
If both ends of the bus correctly follow this protocol (in particular, if neither end actively drives the line to high), then you never have to worry about contention or current spikes.
It`s important to remember that any IO switching in high speed generates EMI.
Depending of switching frequency, board layout and devices sensibilities, this EMI can affect performance and reliability of your application.
If you are having problems in your application use an oscilloscope to check for irradiated EMI in your board lanes.
Related
In my project, I am using Winbond W25Q64 64-MB Serial flash, When i read datasheet of this serial flash there is two type:
SPI(W25Q64 FLASH ID :- 0xEF4017) and QPI(W25Q64FV FLASH ID :- 0xEF6017).
I know SPI very well, but first time i heard about QPI. So i have some Questions-
1.What is the difference's between SPI and QPI?
2.Can i use QPI communication type Flash(using SPI)?
3.What is the main feature's of QPI and what is QPI(a Communication Protocol or something else)?
Description of the QPI protocol is part of the datasheet (I have added the link into your question).
Judging from the description there, it does use four data lines for I/O (in contrast to SPI where one line is designated for input and another for output), thus saving clock cycles (compared to standard SPI) as one byte can be transfered in 2 cycles only. Available commands seems to be different too compared to SPI mode.
This chip supports some "extended" SPI modes (called Dual and Quad SPI) where more data lines are used for sending data to master. These are triggered by standard SPI command, but data transfer differs. See the details in the datasheet.
It is not compatible with "standard" SPI, and I am not sure if there is any common MCU supporting this mode. It looks similar to the SD card / SDIO, but I have no idea how much is it (dis)similar.
Yes, you can. The standard SPI (one input and one output data line) seems to be the default interface. The extended SPI modes are used in response to particular SPI commands only and the QPI mode has to be explicitly enabled by respective SPI command (see figure 3 in page 12).
In addition:
Quad SPI and QPI instructions require the non-volatile Quad
Enable bit(QE) in Status Register-2 to be set. When QE=1,
the /WP pin becomes IO2 and /HOLD pin becomes IO3.
...
QE bit is required to be set to a 1 before issuing an “Enable QPI
(38h)” to switch the device from Standard/Dual/Quad SPI to QPI,
otherwise the command will be ignored. When the device is in QPI mode,
QE bit will remain to be 1. A “Write Status Register” command in QPI
mode cannot change QE bit from a “1” to a “0”.
Advantage is faster data transfer at the same clock frequency. Details of the protocol are well described in the datasheet including timing plots etc.
This is driving me nuts for a couple of days now, so maybe you guys can give me some insights into what is going wrong.
I'm trying to read some data from an EEPROM (24LC16B) with an STM32(F0), but it just doesn't let me. I've tried an Arduino, which worked and does still work, so I do know that the wiring is correct.
This is my function to read the EEPROM data. (It is cut down to the very basis, just for testing): (Pastebin of my I2C_setup function)
uint16_t readEEPROMData(uint16_t deviceAddress, int memAddress){
// Wait while I2C peripheral is not ready
I2C_WaitForFlag(I2C_ISR_BUSY);
// Start I2C write transfer for 2 bytes, do not end transfer (SoftEnd_Mode)
I2C_TransferHandling(I2C1, 0xA2, 2, I2C_SoftEnd_Mode, I2C_Generate_Start_Write);
I2C_WaitForFlag(I2C_ISR_TXIS);
// For testing purpose, be sure to generate a stop command...
I2C_TransferHandling(I2C1, 0xA2, 0, I2C_AutoEnd_Mode, I2C_Generate_Stop);
return I2C_COMM_STATUS;
}
Here's an pastebin of the Arduino library I used.
I've used a logic analyzer to see how the communication is going, and now I really don't understand it. Here's a printscreen of the working Arduino version:
And here's a printscreen of the STM32 communication:
Logic analyzer exports (viewable with Saleae Logic)
As you can see, I'm using the same address (although I had to use 0xA2 with the STM32), and there are no weird things happening, besides the NACK. So what could possible be wrong?
Confirm if all bus timing requirement are satisfied.
Confirm if their is adequate delay after every write cycle (5 mS)
Confirm is bus capacitance falls under permissible limit of I2C (400 pF - Theoretically).
Confirm if the correct VCC is supplied
As mentioned by you are interfacing EEPROM with MCU using cable you need to conform on capacitance.
You can use an oscilloscope to check if their are any distortion in waveform. You can use a LCR meter to check the capacitance.
Try reducing bus speed 25kHz to 50 kHz and check waveform.
Try increasing the strength of pull resister.
The problem with the wrong VCC capacity (4.2v instead of 5v for example) is, that the timing can be different to. (not fully verified, but it fixed the problem)
I have been using the Teensy 3.6 microcontroller board (180 MHz ARM Cortex-M4 processor) to try and implement a driver for a sensor. The sensor is controlled over SPI and when it is commanded to make a measurement, it sends out the data over two lines, DOUT and PCLK. PCLK is a 5 MHz clock signal and the bits are sent over DOUT, measured on the falling edges of the PCLK signal. The data frame itself consists of 1,024 16-bit values.
My first attempt consisted a relatively naïve approach: I attached an interrupt to the PCLK pin looking for falling edges. When it detects a falling edge, it sets a bool that a new bit is available and sets another bool to the value of the DOUT line. The main loop of the program generates a uint_16 value from these bits and collects 1,024 of these values for the full measurement frame.
However, this program locks up the Teensy almost immediately. From my experiments, it seems to lock up as soon as the interrupt is attached. I believe that the microprocessor is being swamped by interrupts.
I think that the correct way of doing this is by using the Teensy's DMA controller. I have been reading Paul Stoffregen's DMAChannel library but I can't understand it. I need to trigger the DMA measurements from the PCLK digital pin and have it read in bits from the DOUT digital pin. Could someone tell me if I am looking at this problem in the correct way? Am I overlooking something, and what resources should I view to better understand DMA on the Teensy?
Thanks!
I put this on the Software Engineering Stack Exchange because I feel that this is primarily a programming problem, but if it is an EE problem, please feel free to move it to the EE SE.
Is DMA the Correct Way to Receive High-Speed Digital Data on a Microprocessor?
There is more than one source of 'high speed digital data'. DMA is not the globally correct solution for all data, but it can be a solution.
it sends out the data over two lines, DOUT and PCLK. PCLK is a 5 MHz clock signal and the bits are sent over DOUT, measured on the falling edges of the PCLK signal.
I attached an interrupt to the PCLK pin looking for falling edges. When it detects a falling edge, it sets a bool that a new bit is available and sets another bool to the value of the DOUT line.
This approach would be call 'bit bashing'. You are using a CPU to physically measure the pins. It is a worst case solution that I see many experienced developers implement. It will work with any hardware connection. Fortunately, the Kinetis K66 has several peripherals that maybe able to assist you.
Specifically, the FTM, CMP, I2C, SPI and UART modules may be useful. These hardware modules are capable of reducing the work load from processing each bit to groups of bits. For instance, the FTM support a capture mode. The idea is to ignore the PCLK signal and just measure the time between edges. These times will be fixed in a bit period/CLK. If the timer captures a two bit period, then you know that two ones or zeros were sent.
Also, your signal seems like SSI which is an 'digital audio' channel. Unfortunately, the K66 doesn't have an SSI module. Typical I2C is open drain and it always has a start bit and fixed word size. It maybe possible to use this if you have some knowledge of the data and/or can attach some circuit to fake some bits (to be removed later).
You could use the UART and time between characters to capture data. The time will be a run of bits that aren't the start bit. However it looks like this UART module requires stop bits (the SIM feature are probably very limited).
Once you do this, the decision between DMA, interrupt and polling can be made. There is nothing faster than polling if the CPU uses the data. DMA and interrupts are needed if you need to multiplex the CPU with the data transfer. DMA is better if the CPU doesn't need to act on most of the data or the work the CPU is doing is not memory intensive (number crunching). Interrupts depend on your context save overhead. This can be minimized depending on the facilities your main line uses.
Some glue circuitry to adapt the signal to one of the K66 modules could go a long way to making a more efficient solution. If you can't change the signal, another (NXP?) SOC with an SSI module would work well. The NXP modules usually support chaining to an eDMA module as well as interrupts.
I have a PIC24 based system equipped with a 24 bit, 8 channels ADC (google MCP3914 Evaluation Board for more details...).
I have got the board to sample all of the 8 channels, store the data in a 512x8 buffer and transmit the data to PC using a USB module when the buffer is full (it's is done by different interrupts).
The only problem is that when the MCU is transmitting data (UART transmission interrupt has higher priority than the ADC reading interrupt) the ADC is not sampling data hence there will be data loss (sample rate is around 500 samples/sec).
Is there any way to prevent this data loss? maybe some multitasking?
Simply transmit the information to the UART register without using interrupts but by polling the bit TXIF
while (PIR1.TXIF == 0);
TXREG = "the data you want to send";
The same applies to the ADC conversion : if you were using interruptions to start / stop a conversion, simply poll the required bits (ADON) and thats it.
The TX bits and AD bits may vary depending on your PIC.
That prevents the MCU to enter an interrupt service routine and loose 3-4 samples.
In PIC24 an interrupt can be assigned one of the 8 priorities. Take a look at the corresponding section in the "Family Reference Manual" -> http://ww1.microchip.com/downloads/en/DeviceDoc/70000600d.pdf
Alternatively you can use DMA channels which are very handy. You can configure your ADC to use the DMA, and thus sampling and feeding the buffer won't use any CPU Time, same goes for UART I beleive.
http://ww1.microchip.com/downloads/en/DeviceDoc/39742A.pdf
http://esca.atomki.hu/PIC24/code_examples/docs/manuallyCreated/Appendix_H_ADC_with_DMA.pdf
I'm currently developing a small application for monitoring the power / current our solar collector is generating.
The array is connected to 3 inverters. Every inverter has a RS232 interface, transmitting one Line of information(its current status) every 10 seconds.
Since I want to do the monitoring using a device only having one serial port, I need to come up with a way to be able to read the data from all of the inverters in parallel.
I don't need to send anything to one of the inverters!
Is it possible to just connect 3 RS232 wires in parallel to one serial port? Collisions will be pretty unlikely since every inverter is transmitting only 64Byte / 10seconds ending with a newline, so I could check for variable line lengths to detect collisions.
I'm sort of chuckling at doomsday and wacky answers that so often pop up on stackoverflow...
But anyway, in years gone buy I have used paralleled RS-232 transmit lines using diodes and it can work fine for situations where collisions are unlikely. In one particular application I used this technique there were two input terminals where a user could key in simple commands to control the system (a specialized security system) and it was very unlikely that two people would be trying to control it at the same time from the two different terminals. Amazingly enough there are no problems with voltage levels with most RS-232A receivers I tested at the time and they tolerated the signal characteristics (no negative voltage) that result from the simple use of the diodes in series with the TXD signals. However, if I had to do this again I would likely add a simple pull-down resister and capacitor to ground with a diode between RXD and the cap in a sort of charge pump configuration or a pull-down to negative going handshake signal to ensure the "OR'd" input signal goes truly negative since the RS-232 spec defines +3 to -3v as invalid.
In any case, I would recommend not using this technique except in very specific, limited, and non-mission critical cases and would not use it in the case where you have multiple devices sending information at a programmed interval as in the case of the OP or where there is a software handshake.
In can be a simple solution to the problem of not enough serial input ports but only in a very limited set of environments.
No, you should NOT connect 3 serial output port in parallel. If you do that you are probably going to broke the RS232 output circuitry of your inverters.
You have 3 RS232 outputs, so you need 3 RS232 input, then you can manage these 3 input the way you like: maybe you can buffer the data from each input, and reoutput the data on a single RS232 output, to be connected to your monitoring device.... but you should add some code in the data flow to differentiate the data coming from the 3 inverters.
Maybe you can use some kind of IC that do the job for you, I'm not sure, but maybe that some IC that multiplex multiple RS232 input on a single RS232 output already exist.
Try this search: rs232 port input multiplexer on Google
Or, if the monitoring device is a Window computer, you can use 3 serial-to-usb converter: that will create 3 virtual COM port on your computer and you can read data from them with any software.
Update
About the hypothesis of securing the output circuitry using diods to block reentering current, I don't think it's going to work...
Many year have passed by since last time I've used an RS232 link at low level (so maybe I'm wrong) but I think that there is some kind of handshake going on between RS232 input and output port (speed to use, parity, stop bit...).
Each RS232 port have inputs and outputs signal, both for data and for transmission control, so your multiple RS232 outputs does have some input signals, and your single RS232 input does have some outputs.
This mean that your input monitoring RS323 port is going to try to make a handshake with 3 RS323 ports at the same time... and the 3 RS232 ports are probably going to respond at the same time... so I think it's not going to work.
Other than that if you place diodes on your output, you are going to loose 0.7v, I don't remember the tolerance on signal level of RS232, but maybe that 0.7v can be relevant.