How do i implement parallel to serial conversion and vice versa using the PSoC. Looks like i need extra hardware. Is that so?
There is no xtra hardware needed for a parallel - to serial conversion and back.
Consider to use a shift register (8, 16, 24 or 32 bits - wide). You shift out a serial datastream which you may shift into another shift register receiving now a parallel word of the desired size again.
Another solution could be made with a multiplexer and a de-multiplexer connected back-to-back working pretty well when serializing hardware signals.
Last solution is serializing with the help of the CPU but that method will cost you MIPS.
Yes , definitely we can convert parallel to serial using Shift register. But I am not sure whether this is the best solution because i used serial register to stuff data in CRC component.
For the first time when the component was initialised and data was loaded parallely to the shift register, only after giving the first clock the first data bit (say MSB) was held out from shiftout terminal of serial register.
But for the second and subsequent times when the data was loaded into shift register, even before the first clock was given the first bit was out from the shift register. On giving the first clock the second bit was out......
I was totally baffled by this act of shift register.....
Before, I started a topic saying CRC had a problem and calculating wrong CRC but eventually i found out that actually shift register was going crazy ..........
I am not an expert but I had this bad experience in saying Shiftregister is acting crazy......
Please try out and if possible i will try to attach the screenshot of the data output from Shiftregister.....
Even you can attach the screenshot......let me see if i went wrong in doin something or is the componenet that is acting like this......
Please please try this.......Actually BOB has attached a project where in Shiftregister is used ...you can take a look at that and try changing things in the top design (like i toggled value in control register to act as clock, you can feed the clock from PWM or direct clock whatever...)
Verilog allows you to design your own fully custom shift register.
LUTs can be used as SR's. D's in simple shift register.
Even LUTs can be used.....but the concern is there is a dedicated component which is solely built for shifting data..........
When such a verified, tested and approved component is used I doubt anyone will think on investing their time on reinventing the wheel.
Whatever... i dont know whether my implementation was right or wrong.......If any of you get to work the component right (I am talking about shifting data serially out) then please do attach the project as well as screen shot in CRO (containing clock and serial out)
The shift compoent is actually what you need. If you can show the problem you describe in a simple project (not involving anything else), which compiles without any warnings (esp. from STA regarding timing), you should file a support case with Cypress.
When you say the shift component clocks out the first bit when you load the parallel value - what exact moment do you mean? Is it when you write it with the API, or when you use the LOAD input to load it into the register itself? For the latter one, the data sheet says it happens the exact moment when, after LOAD went high, the clock also wents high. Could this be your problem?
I am writing value into the shiftreg using the API Shiftreg_WriteRegValue() and I am left shifting the data later on
So here is my code functionality
Stop Shift register(data sheet says component should be stopped to use the API Shiftreg_WriteRegValue)
Use the API Shiftreg_WriteRegValue()
Start the Shift register
In the for loop provide 8 clocks to shift all the bits out.....
What I noticed was for the first time I had to provide 8 clocks to component to get all the 8 bits out, but for second and consequent times I just had to provide 7 clocks to get all bits out because first bit was already out before even giving the clock.........
What is the problem??????
Since this function writes directly to the shift register, which in turn might be connected directly to the output, this might happen (according to the data sheet, the shiftout output is connected directly to the shift register, so I think the MSB [or LSB] is directly connected to the output).
Can you try to use the ShiftReg_WriteData() function instead, in conjunction with the Load input? That way, the values should only be loaded by a clock pulse.
I tried even that there is some problem which exists .....it is same as the prevoious one.......
It seems like the component works perfectly when using alone and using API ShiftReg_writeData();
I am doing shift left so when the data is fed to register the MSB is not availble until a clock is provided . only when the clock is provided the data is out and is held.
But using some other components (CRC) I got the same error as that of ShiftReg_writeRegValue();
I dont know why....I will attach my project....
So this looks like a bug in the routing / optimization step. Then maybe adding a sync component between Shiftreg and CRC might help. Where there any warnings from the STA?
The project posted by Marlowe implements serial to pparalle conversion> Am i right? and implementing the parallet to serial conversion will require only one shift register right?
We have similar problem using the shift register but I can remember what exactly it was, we used our own shift routine due to the project schdule and was planning to check that again if we have the time. As everybody knows, that time never come. I think you should issue a case for Cypress support.
The project I posted contains both: parallel to serial and back.
Tonight I had the idea not to use a shift-register but an UART which will work as well
could you post the UART example when you have done it. When i'm in debug mode using the example you sent, the execution halts on
What causes this. Is it my interrupt service routine.
I didn't had in mind to do that UART-project myself. Just drop an UART on your schematic. Every byte you send comes serially out of Tx and you may connect it to Tx. Then you'll receive every byte in parallel again.