PSoC™ 5, 3 & 1 Forum Discussions
text.format{('custom.tabs.no.results')}
Hello,
I'd like to implement three bandpass filters with the CY8CKIT-001 PSOC DEVELOPMENT Kit. I read some information about PSoc filters into the forum and I read the AN2099 application note too, but I'm still not sure that they can be implemented and how would can I do it.
The filter's characteristics are:
Filter1: Fs=105Hz Fi=45Hz B=60Hz Fr=68,7Hz Q=1,14
Filter2: Fs=145Hz Fi=65Hz B=80Hz Fr=97Hz Q=1,21
Filter3: Fs=8Hz Fi=0,5Hz B=7,5Hz Fr=2Hz Q=0,26
If it is really possible to implement these kind of filters, what would be the best method, using DBF blocks, SC/CT o FIR filters?.
Best regards,
Antonio M.
Show LessHi,
I have to write software for psoc 3 which is going to sleep (~uA consumption) for dozen of milliseconds, few times per second. Each time it has to be different value of sleep time.
I'm was surprised that i'm expecting some many problems with such case in PSoC3...
my program should looks like this(pseudo code):
while(1){
GoToSleepFor(5ms)
DoSomething()
GoToSleepFor(100ms)
DoSomething()
GoToSleepFor(1ms)
DoSomething()
GoToSleepFor(800ms)
DoSomething()
}
Problem is with CyPmSleep which:
1. It does not accept any other delay then power of 2 (2,4,8,16ms..etc)
2. When I mix different intervals i need to wait more or less one interval to be sure that next, same interval will be fine (as it's written in system documentation). Documentation is right - when i'm mixing intervals then times are way different than it is expected.
RTC can be used only for intervals >1second.
Is there no way of doing this?!
I was thinking about putting an extra timer (internal) into psoc and connect it to 32kHz clock from external oscillator but i dont know how to make it work during sleep:
1.timer would have to work when everything else is sleeping (~uA consumption)
2.somehow signal from this timer has to wakeup psoc3.
Other workaound is to always go to sleep for 2ms.Sometimes for hundreads of times - 400x when i want to sleep 900ms. But this doesnt look like proper way of doing it.
ps. using externals signals or devices to wake up is not accpetable...
ps2. its battery powered and every uA counts.
I would appreciate some advice/hint
Thank You in advance for reply!
Show LessHi,
I am having difficulty implenting low power modes combined with using the FreeRTOS platform and the PSoC 5. Specifically, UART comms are getting corrupted.
I have a task which receives messages to send to the UART. When it receives a message, it prevents the uC from sleeping, wakes the uart up, and then sends the message using the API (Uart_PutSring()). It then waits until the message is sent before allowing the micro to sleep and sleeping the uart itself.
Some messages are getting through un-corrupted, others are a horrible mess...
Here is a code snippet of the UART task...
//! @brief Main debug uart task
//! @param *pvParameters Void pointer (not used)
//! @note Not thread-safe. Do not call from any task, this function is a task that
//! is called by the FreeRTOS kernel
//! @public
void vDebugUart_MainTask(void *pvParameters)
{
// Sleep uart
UART_DEBUG_Sleep();
uint8 *message;
for(;;)
{
// Wait for a message pointer to arrive in the queue
xQueueReceive(xDebugUartTxQueue, &message, portMAX_DELAY);
#if(DEBUG_LEDS == 1)
DebugUart_FlashLed();
#endif
// Message must of been received, so now prevent micro from sleeping and send
PowerMgmt_SleepLock();
// Wakeup UART
UART_DEBUG_Wakeup();
UART_DEBUG_PutString(message);
//vTaskDelay(200/portTICK_RATE_MS);
// Wait until UART has completely finished sending the message
// (both the hardware buffer and the byte sent flag are set)
while(!(UART_DEBUG_ReadTxStatus() & (UART_DEBUG_TX_STS_FIFO_EMPTY | UART_DEBUG_TX_STS_COMPLETE))); //(software wait)
//while(!(UART_DEBUG_ReadTxStatus() & UART_DEBUG_TX_STS_COMPLETE));
// Sleep uart
UART_DEBUG_Sleep();
// Now it is safe to unlock the micro to allow for sleeping
PowerMgmt_SleepUnlock();
// Finished, now loop for next message
}
}
Cheers, Geoff
Show LessI'm required to give a presentation about PSoC1 architecture and programming at my office . I have previously seen some where in this site the link to download all the prebuilt slides for presentation on PSoC. Can anyone help
Show LessWhen running the install I'll get a message box with
"The installed version of the application could not be determinated. Setup will now terminate."
Installed is the 3.12.5 Software.
So, what to do ?
H.
Show LessHello,
I need to sense a plenty of signals with Operational Amplifiers and Comparators as a circuit contitioning. I am thinking in to use PSoc3 because I have read it is possible implement many of them inside. Could any one tell me how many of each other could implement at most? Taking into account the family device that allows the maximum number.
Thank you in advance,
Albert.
Show LessHey guys,
Any plans at Cypress for a DIP package for the PSoC3/5? Recently came across announcements from both Microchip and NXP doing so for their new 32bit chips,and wondered if there are any similar plans in the PSoC 3/5 camp.(fingers crossed)
Show LessOne of the more powerful aspects of PSoC 3 and PSoC 5 is the ability to use components that encapsulate both hardware and software functionality. Cypress provides a large library of the most common components that you might need (I2C, UART, DAC), but there is no end to the possible components that PSoC 3 and PSoC 5 can support. The Creator platform allows you to develop and use your own components using the same methodology as Cypress engineers.
There are 3 levels of components that a user might want to develop:
- Schematic Component
- Verilog Component
- Datapath Component
Each level gets progressively more involved and more powerful. A schematic based component provides a hierarchical schematic capability. Here you can combine any of the components in the current library and also encapsulate the APIs that go with that combination. With a Verilog based component you have the ability to pull in more complex unique digital content and take direct advantage of the PLDs built into PSoC 3 and 5. The capability to do either Schematic or Verilog based components is in Creator today. The third level, datapath based components, adds to a Verilog component the usage of the datapath resources in PSoC 3 and 5. With datapaths you can create denser designs and more flexibily communicate between your hardware component and the CPU.
In order to get you started on the right track, several training classes are developed that include:
- Video
- Slides
- Example Projects
They are all posted on the Cypress website under the Design Support tab, then Technical Training, then On-Demand Training, or you can skip directly there with the following links:
- PSoC Creator 110: Schematic Components
- PSoC Creator 111: Component Parameters
- PSoC Creator 112: Introduction to Component API Generation
- PSoC Creator 113: PLD Based Verilog Components
Many of you may know that both PSoC1 and PSoC3/5 devices have PGAs (Programmable Gain Amplifiers). These are handy devices allowing you to either select the system gain during design time or during run time. The gain for these PGAs is controlled by calling one of the API function calls. Sometimes it would be nice to be able to control the PGA's gain with a digital signal. With PSoC 3 and 5, there is a way to do this by making use of the handy internal opamps. There are a couple of ways to do this using different combinations of pins and analog muxes.
This first option is the simplest, using the internal opamp, a couple of external resistors, and some GPIO pins. If the signal you want to amplify is referenced to Vss, you can use GPIO pins in the open-drain, drive low mode to select one of N resistors. The diagram below shows an example of how to use three GPIO pins and four external resistors to provide eight selectable gain combinations. The LUT (Look Up Table) controls the the gain selection by what ever means that is required by your application.
Another option is to use a hardware mux to select the feedback resistor. This allows you to select a reference other than Vss. In the diagram below, the VDAC8 is used to generate the reference voltage which is then buffered with another opamp. The disadvantage for this design, is that to maintain gain accuracy the resistors should be as large as possible to wash out the affect of the analog mux switch resistance. Each analog switch in the hardware analog mux is about 200 ohms, so the external resistors should be above 10K or more. The gain for this option is the same as the first, it provides 2^N gain combinations where N is the number of pins and resistors used for gain control.
A third topology eliminates the issue with switch resistance. The analog mux is used to select the tap point along a string of external series resistors. Since the current through the mux switches is just that of the opamp input, the 200 ohm switch resistance can be ignored. The disadvantage, is that one pin is required for each gain setting you want to select, therefore using more pins. As with the other two options the gain can be controlled purely with digital signals.
If we add a window comparator to one of theses examples, a simple AGC (Automatic Gain Control) can be implemented. The LUT in this example uses the comparator outputs to determine if the gain should be increased, decreased, or remained the same.
Many of you may know that both PSoC1 and PSoC3/5 devices have PGAs (Programmable Gain Amplifiers). These are handy devices allowing you to either select the system gain during design time or during run time. The gain for these PGAs is controlled by calling one of the API function calls. Sometimes it would be nice to be able to control the PGA's gain with a digital signal. With PSoC 3 and 5, there is a way to do this by making use of the handy internal opamps. There are a couple of ways to do this using different combinations of pins and analog muxes.
This first option is the simplest, using the internal opamp, a couple of external resistors, and some GPIO pins. If the signal you want to amplify is referenced to Vss, you can use GPIO pins in the open-drain, drive low mode to select one of N resistors. The diagram below shows an example of how to use three GPIO pins and four external resistors to provide eight selectable gain combinations. The LUT (Look Up Table) controls the the gain selection by what ever means that is required by your application.
Another option is to use a hardware mux to select the feedback resistor. This allows you to select a reference other than Vss. In the diagram below, the VDAC8 is used to generate the reference voltage which is then buffered with another opamp. The disadvantage for this design, is that to maintain gain accuracy the resistors should be as large as possible to wash out the affect of the analog mux switch resistance. Each analog switch in the hardware analog mux is about 200 ohms, so the external resistors should be above 10K or more. The gain for this option is the same as the first, it provides 2^N gain combinations where N is the number of pins and resistors used for gain control.
A third topology eliminates the issue with switch resistance. The analog mux is used to select the tap point along a string of external series resistors. Since the current through the mux switches is just that of the opamp input, the 200 ohm switch resistance can be ignored. The disadvantage, is that one pin is required for each gain setting you want to select, therefore using more pins. As with the other two options the gain can be controlled purely with digital signals.
If we add a window comparator to one of theses examples, a simple AGC (Automatic Gain Control) can be implemented. The LUT in this example uses the comparator outputs to determine if the gain should be increased, decreased, or remained the same.