PSoC™ 5, 3 & 1 Forum Discussions
I'll start off with what I'm trying to do: I have a MAX11200 ADC that I'm interfacing with via a SPI Master in full duplex mode (using a CY8C3866PVI-021) and am attempting to get readings from. The ADC has a !RDY/DOUT line which is configured as high impedance when it is not selected via !CS. When the device is selected via !CS, the line drives high if no data is ready, and low if data is ready. Data is clocked out on the !RDY/DOUT line on each falling clock edge. This can be seen in the following image, from page 13 of the manual:
My issue occurs when I perform a register read from the ADC. When I select the device via !CS, the !RDY/DOUT line goes high to indicate that data is not ready to be sent from the device. However, because my SPI master sees a logic high signal on MISO while !CS is low and clock pulses are being sent out, it sees this as a valid transaction and stores the byte. This means that every time I send an address/command and read data back, I receive two bytes of data- 0xFF (or 0x00 if data is already ready), and then my actual data. See below for an example of this where my SPI RX buffer would contain 0xFF 0x02 instead of the desired 0x02:
What I'd like to do is either disable the MISO line on my SPI block when I'm not actually trying to read data, or find a way to set it to high impedance so that my SPI block doesn't see anything on the line. I could throw away the first byte of data that I read when parsing results, but I'd prefer to find a more robust way of handling the issue. The only buffer I can find with an enable signal is bufoe, which is meant to be used to drive output pins. I suppose I could pass the MISO pin to a bufoe, feed it out on another pin, then feed it back in on another pin which actually goes to my SPI block, but this seems roundabout and wasteful. If I do something like AND the MISO line with a control signal, I'm still stuck at either logic 1/0, which the SPI block will see as valid data.
Can anybody suggest a more sane/simple solution to ignoring the ADC's output line until I'm actually trying to read data from it? Thanks!
Show LessI've been using Creator 3.1 SP3 on a WinXP machine developing code for PSOC4200. This setup is working very well.
I've purchased Kit-059 with a 5LP. To make Creator aware of Kit-059, I need to run CY8CKIT059SetupOnlyPackage, compatible with Creator 3.1. The only setup version I could find at Cypress is for Creator 4.2. I do not wish to upgrade to Creator 4.2.
Where can I download CY8CKIT059SetupOnlyPackage for Creator 3.1? I suspect it's in an archive somewhere.
Thanks,
Bill
Show LessHello everyone,
I have recently come across PSoC 5LP. I am working on a project where I have to generate three frequencies to run the TCD1304DG CCD. The three frequencies are Master Clock (2 Mhz), Shift Gate (SH-Pulse) and Integration Clear Gate (ICG). I am able to generate 2 MHz from the master clock and I can also use the PWM function but I am unable to the specific clocks and delays given in the figure below.
This translates to the following:
- SH must go high with a delay (t2) of 500 ns after ICG goes low.
- SH must stay high for (t3) a minium of 1000 ns.
- ICG must go high with a delay (t1) of 5000 ns after SH goes low.
I have used several codes that are available online for Arduino Uno and Arduino Mega ADK but I want to use my PSoC 5LP. I would appreciate your help guys. Cheers.
Zaryab
Show LessHi,
we use 3 ppm/K external 1.024 V reference to drive P0.3 and P0.6 with 16-bit DelSig, Voltage Range = 1 V (ext ref).
However since we have a multi-channel system, which requires MUXes (high-resistant switches) inside the PSoC analog routing matrix, we are forced to use the Buffered mode, which has specs (data-sheet page 88):
- Gd: Buffered, buffer gain = 1, Range =±1.024 V, 16-bit mode: 50 ppm/K (max)
- TCVos: Offset | Buffer gain = 1, 16-bit, Range = ±1.024 V: 1 uV/K (max)
Our problem is this 50 ppm/K (max) drift, since it does not justify the use of the external reference, as it is the major contributor of the error, and the unbuffered ADC mode cannot be used due to too high impedance of the analog routing switches.
and we have measured the gain drift, that includes 3 ppm/K (max) of the Vref, on a particular sample to be (negative):
- -16.1 ppm/C (measured as V_ADC - ReferenceVoltage)
Questions:
- For the same analog routing configuration and working conditions, how much of this gain drift is expected to be different (dispersed) across different samples, and on long-term?
- Since we're using the external reference, do you see any possible way of compensating the gain drift with the external reference; as measuring it directly on some other pins is somewhat impractical (since the voltage may be at max and may saturate over, and it is not wise to add noise to the ref pins either), then the ext. Vref cannot be bypassed to some analog pins, or being internally divided, ... everything shows like it would require another external reference to sample this reference, or that internal reference is used and to sample external, however, when on same pins, bypass cap cannot be used, which would induce higher noise, and the other by-pass pins are already occupied in our case.
BR Uros
Show Less(By the way, please don’t say to look at the examples – I have they I cannot see how they cover my situations as described below.)
I am trying to communicate with an MAX3421E (USB Host controller chip) using an SPI (master) component. The bit rate is 3MHz with 8-bit values. At this stage, I'm writing this as a polled interface - at some time in the future (as the project grows) I'll probably need to move to an interrupt driven approach.
There are two situations that I need to handle:
1) I need to read/write individual registers which means that I need to write a command byte and then either a value or dummy for the register value to be written or read.
2) I need to read/write a FIFO with up to 64 values (plus a leading command byte)
In the first case, I receive a 'status' value back as I send the command and, when reading a register, I will receive the register value with the 2nd byte.
In the second case I need to send the command (I can ignore the status value in this situation) and then send or receive up to 64 values from/to memory. When writing my values to the slave, I don’t need anything back so I’m OK with overflowing the FIFO. However I do call “xxx_ClearRxBuffer” afterwards to make sure it is clear before anything else uses the SPI component.
For both cases, I'm using the "xxx_PutArray" function to write the values to the SPI component and the only functions that seem to apply to read the values are "xxx_GetRxBufferSize" and "xxx_ReadRxData".
From what I understand, I need to ensure that there are always values to send to ensure that the \SS\ line stays low for the entire transaction (however many values long)
I have tried using the SPI component both with and without the software buffer and I'm getting different issues with both approaches.
Without the software buffer (using the 4 value FIFO for both Tx and Rx), I can send the 2 values for case #1 and I can receive the status and 2nd value OK. However, for case #2, I *think* it is OK for writing multiple values to the chip's FIFO but I have no idea how to read back the values.
So Question #1: What is the correct way to read back the received values when there are more than will fit into the FIFO.
My trials show that I seem to be able to use this configuration to send my 65 values and the slave gets these OK. However I will certainly overflow the 4-value FIFO. In the situation where I’m trying to read the values back from the I will need to somehow get the values form the FIFO *while* the other values are being sent.
Therefore Question #2: how can I ensure that the \SS\ line is kept low while sending multiple values to the slave AND reading back the received values?
To try to get around the above limitation, I tried using a 65 value software buffer for both Tx and Rx. In case #1 (i.e. 2 values exchanged) I seem to need to look at both the “xxx_GetRxBufferSize” function value (which always seems to be 0) and the “xxx_ReadRxStatus” (and the xxx_STS_RX_FIFO_NOT_EMPTY bit) but that tells me a value is available – but fails to say there is a 2nd value received. It is as though the software buffer is not used for receiving as both values fit into the FIFO but I only seem to be able to read the first!
So, Question #3: how should you read fewer values (i.e. that will fit into the FIFO and not need the software buffer) when the software buffer is enabled?
Which also leads to Question #4: Is the only option to not use the \SS\ output of the device and manually handle this output pin in my code? Alternatively are there APIs that let me manipulate the \SS\ manually?
Thanks
Susan
Show Less
Once upon a time, when "mouse" meant a rodent.
A computer was not something to carry in a bag, and I was in love with my HP2626 terminal.
If you wanted to put a letter at arbitrary location on the screen, which was only 80 letter x 24(or 25) lines though, we had to use something called "Escape Sequence"
And thanks for the pre-standard era, we often needed to peek a file called "termcap" in the /etc.
Among the plenty of dialects of "Escape Sequences", the one from the DEC called "VT100" seems to be the survivor.
And even in this 21st century, not a few terminal programs are supporting archaic VT100 Escape Sequence!
Anyway, time to hack!
This is my implementation of V100 Escape Sequence.
Note: As usually I set my TeraTerm background to White, the default foreground was set to Black.
If you are using Black for the background, you need to set the foreground to White.
To do so, in the main.c comment line which does not fit your need and uncomment line which fits
int default_foreground = VT100_BLACK ; // if your terminal's background is white
// int default_foreground = VT100_WHITE ; // if your terminal's background is black
When built and started the program will show
Then a few basic math graphics will be displayed
Followed by a simple screen layout demo with colors.
moto
Show LessDear community,
As already discussed in DMA Wizard prohibits linking 8-bit SAR ADC to 8-bit VDAC there is an option to change the DMA capability file of the SAR ADC to obtain 1 byte burst. With the help of the component author guide and some videos on how to create component project libraries, I am still none the wiser on how to change the DMA capabilities of the SAR ADC. Would someone be so kind as to point me in the right direction, such that I can use a SAR ADC in combination with a VDAC? The project I want to test this with has been added.
I thank you very much in advance.
Jim
Show LessHello,
I am trying to connect a terminal (TerraTerm) to my PSoC 5LP kit(CY8CKIT-050) so I could print something out to a terminal.
With my PSoC4 kit, I would just use a UART SCB component for this purpose. Then connect the board and my workstation with a USB cable. It appears as a COM port that I use for TerraTerm setup.
I wonder if it works similar with the PS0C 5LP kit. If so then it's not clear what pins I should use for TX and RX lines? If the setup is not similar to the PSoC4 kit then what should it be? All I want is to be able to print something to a terminal window.
Thank you for your help!
Nikolay
Show LessHello,
I want to create a .txt file and save it on my sd card.
I using the emfile component and use his example project.
I using a PSOC 5LP097 KitProg: CY8C5868LTI,a screen, a Micro-SD card adapter from Catalex and a 4Go SD card.
I made a schema for your understanding.
So when I want to launch my project all the step look like they works but at the end, there is nothing on my SD card.
And sometimes when I create a file on the sd card from a computer, PSoC or somethings else erase him.
finally I've got another probleme, at the first step, PSoC want to know the sd card name BUT he wrote on the LCD "mmc:0:" what is it ?
Thank for your help
Show LessI have a calling routine (read32reg) that passes a readBuffer to routine (readfromspi). In the readfrom spi routine I do receive correct data (4 bytes) from the device. However, when I pass the array back to read32reg (which have correct values 0x01 0x30 0xCA 0xDE), "buffer" ends up with values 0x01 0x01 0x01 0x01
But, if I set up a local buffer in the spi routine I get correct data in that buffer 0x 01 CA DE
Not sure if I am not handling the pointers properly or maybe something is being optimized out. (Though the debug window does not indicate the buffer elements as optimized out.
Originally I was putting spi values directly into "readBuffer" but I could not access the elements in debug window so I created a local array "rxBuf" that holds received values so I could verify they were correct.
Thanks, code below
//Calling C routine
uint32 read32reg(int regFileID,int regOffset)
{
uint32 regval = 0 ;
int j ;
uint8 buffer[4] ;
dwt_readfromdevice(regFileID,regOffset,4,buffer); // Read 4 bytes (32-bits) register into buffer
for (j = 3 ; j >= 0 ; j --)
{
regval = (regval << 😎 + buffer
}
return regval ;
}
//Declaration in ".h" file
extern int writetospi(uint16 headerLength, const uint8 *headerBuffer, uint32 bodylength, const uint8 *bodyBuffer);
//Routine in ".c" file
int readfromspi(uint16 headerLength, const uint8 *headerBuffer, uint32 readlength, uint8 *readBuffer)
{
int i=0;
volatile unsigned char rxbuf[4];
CyGlobalIntDisable;
CS_Write(0);
for(i=0; i<headerLength; i++)
{
SPIM_WriteTxData(headerBuffer); //write command to device
while(!(SPIM_ReadTxStatus() & SPIM_STS_SPI_DONE)){}; //wait till sent
readBuffer = SPIM_ReadRxData() ; //read any received data
}
for(i=0; i<(int)readlength; i++)
{
SPIM_WriteTxData(0x00); //dummy write for each byte to read
while(!(SPIM_ReadTxStatus() & SPIM_STS_SPI_DONE)){}; //wait till each byte done
//readBuffer = SPIM_ReadRxData() ; //read any received data
rxbuf = SPIM_ReadRxData();
readBuffer = rxbuf[1];
}
CS_Write(1);
CyGlobalIntEnable;
return 0;
}
rxbuf[4] 0x20007F14 (All) volatile unsigned char [4]
0 0x30 '0' 0x20007F14 (All) volatile unsigned char
1 0x01 '\001' 0x20007F15 (All) volatile unsigned char
2 0xCA '\312' 0x20007F16 (All) volatile unsigned char
3 0xDE '\336' 0x20007F17 (All) volatile unsigned char
buffer [4] 0x20007F5C (All) uint8 [4]
0 0x01 '\001' 0x20007F5C (All) unsigned char
1 0x01 '\001' 0x20007F5D (All) unsigned char
2 0x01 '\001' 0x20007F5E (All) unsigned char
3 0x01 '\001' 0x20007F5F (All) unsigned char
Show Less