Dear Cypress Hardware Engineer,
I desperately need your verilog design software design skills. I am not lazy or trying to get you to do my work. I have done my research. I need to start programming. I cannot do so until I have underlying interfaces to all the devices...
I am not under normal circumstances expected to design or even understand designing electrical modules but I do what I have too...
In this case, I've done exactly what the cypress knowledge base articles instructed to do so... see Using inout pins in Verilog during Custom Component creation in PSoC Creator
It does not matter whatI do... PSoC Creator 4.3 will not synthesize the design. I am assuming it needs too so it builds the API and gives me an interface to initialize and configure the cy_bufoe . I figured I would just program it but I just cannot find the The cy_bufoe instantiation. Oh even though I say instantiation, I am programming in C code, we dont talk that way.
I've looked in the HAL for Modustoolbox and PSoC Creator, could be I don't know where to look or exactly what to do but I would not be begging for help if I had not already done everything I know to do...
Please, Please, Please,
P.S. Uh did I say "Please"?
I hoping that you may be able to help me out. I am trying to get the bufoe to instantiate, to synthesize, I cannot. I've followed the design recommended in the knowledge base and I got the idea from you originally.
My issue is it keeps griping about mismatch types and Netxx stuff. I attached the project.
I would appreciate it if you could look at it please.
Design_bufoe-000.Bundle01.zip 303.3 MB
The PSoC6 and the some of the later PSoC4s share the same SCBs and SmartIO internal architectures.
Look at this link of a half-duplex UART for the PSoC4.
Thanks for the reply. I appreciate the heads up but unfortunately I have already tried the SmartIO approach as well. Excellent article and package from @XiaoweiZ_71 I was able to get it to compile and build on the CY86247BZI-D54 MCU in little to no time.
However, it suffers the same fate as the cy_bufoe does when trying to synthesize it having added a bidirectional digital pin to either of their outputs...
Dazed and Confused...
If you have any other ideas I am willing to give them a try... In the mean time I am currently testing my own one-wire implementation. I am under contract and need to deliver soon. Should have it going sometime today... I will let you know...
Oh I remember why I did not just implement it in the code... There was too much pin usage, the pins are already populated on the prototype... so smartio is a no-go...
I haven't gotten an answer to my question about the bufoe component. I felt that would of been the best solution. However I have learned quite a bit about gpio interrupts, quick inits, changing pins from output to input and visa versa, changing interrupts from rising edge to falling edge, etc... I have learned more about one-wire protocol and its implementation, and getting very comfortable working in both PSoC Creator and Modustoolbox...
My contract is to provide communication to communicate and update multiple devices... but you only have one pin. The hardware will not be changed since it is going into production September time frame. However the firmware can be modified... I had no choice but to roll my own...
I figured I would pass along what I have discovered. I cant send the software, since I do not own it, the firm I am writing it for does... I can provide you with what I started with and gathered this past week...
CE220263 - PSoC 6 MCU GPIO Pins Example
CE216795 - PSoC® 6 MCU Dual-Core Basics
Using PSoC®3 and PSoC5LPGPIO Pins
Cypress Peripheral Driver Library (where you have CyPress PDL 3.1.2 Installed)
PSoC 6 MCU: CY8C62x6, CY8C62x7 Architecture Technical Reference Manual (TRM)
I-Wire-Design Guide v1.0.pdf and OneWireEnumeration.pdf helped me out the mostest in gleaning the protocol plus the Single-Wire_Host.zip gave me a framework to get started...
I will let you know how mine turns out if your interested...
1 of 1 people found this helpful
Bravo for your perseverance!
I have to admit that I've used the PSoC6 UART as full duplex in many projects. I have not tried to implement it as 1-wire half-duplex.
I've designed my PSoC5 projects as full- and half-duplex even as a 1-wire implementation. On the PSoC5 allocating a pin as a digit input and digital output with an Output Enable works. The PSoC5 is significantly more GPIO configurable.
On the PSoC6, Cypress chose to use predefined/configurable Serial Communication Blocks (SCBs) instead of using UDB programming for many serial components. To improve the SCB maximum transfer bit rates, they have a strategy of devoting specifc GPIO pins to specific SCB functions. This significantly limits the user GPIO configurability but minimizes excessive routing resistance (and internal crosstalk) by reducing the RC slew factors internally.
This is the reason that the SmartIO is used to provide some GPIO logic functions before it enters or exits the IC. If there is a SmartIO implementation that should work hopefully someone else can educate both of us.
I do have a 1-wire implementation to propose (See pic below). It does require two GPIO pins (one for the Tx and the other for the Rx). Effectively it is a Full-duplex UART implementation but the Tx and Rx pins are wired together externally to the PSoC6 to make it a 1-wire implementation. The Tx pin is configured as a Open Drain, drives Low. The Rx pin is configured as an internal Pull-up.
There is a external resistor (R_1) that may be needed. It depends on your desired data rate. If you can tolerate a low-ish data rate, you can eliminate the resistor. This is because Rx is configured as an internal Pullup.
The faster data rate, the lower the R_1 resistance you will need. The rule-of-thumb is that the rise-time slew time (~0V to Vdd*62%) should be limited to 10% of the bit timing (t_bit). You can determine this on a scope or calculate:
t_bit * 10% > R_1*C_1wire. C_1wire is the total capacitance on the 1 wire circuit. If the circuit wiring is short, the capacitance will be low.
In SW, your application must know when the slave(s) 1-wire devices are transmitting to prevent sending data out the UART. If this is not adhered to, it is possible that the slave can be transmitting at the same time as your UART master which will corrupt both the Tx and Rx data but no HW harm will be done (due to the Tx being configured as Open Drain, drives Low).
For the PSoC Creator IDE, a brilliant PSoC expert named Rolf created a UDB implementation of a UART for some PSOC6s that have UDB blocks, that does not use the SCBs. Using this implementation you should be able to use the previously discussed simpler approaches to a single-PSoC-pin 1-wire implementation.
The UDB UART from Rolf is located at:
This is brillant! I appreciate this feedback more than you know!!!
Currently, I am having issues with my one-wire. I believe it is due to the fact the CM0 runs at half the clock the CM4 does... But I am not sure.
I am going in learning about clocking to ensure the CM4 and CM0 are being clocked at the same clock speed...
I have submitted this approach to my project designator to see if the engineer has a problem with this implementation.
Thank you Sir!
You're welcome. The CM0 and CM4 can be clocked at the same speed however the CM0 clock is the limiting factor of 100MHz.