PSoC™ 5, 3 & 1 Forum Discussions
I am attempting to use a USB to UART cable with a freesoc mini.
The UART when I write a string to the buffer prints garbage data in the terminal. I am using a 5 volt power supply. This is funny because the UART works just fine with Cypress development kits.
Do logic levels have anything to do with this? What is going on?
Thanks
Show LessHi community,
I am new to the PSoC world and recently was working on a project to enable USBFS in DMA mode and measure its throughput compared to non-DMA mode.
I would greatly appreciate if anyone could point me to source of such example project. It looks like this project may resolve many of my issues. One of which is that I set up the buffer size on PSoC endpoints as 64 bytes but PC software (C# or Python alike) does not allow declaring buffers longer than 8 bytes.
Thank you
Show LessHi all,
I am a bit confused. The data sheet of the CY8C58LP Family states that every PSoC of this family has a CAN-Component. The data sheet for CY8C5888LTI-LP097 mentions it, too. http://www.cypress.com/?mpn=CY8C5888LTI-LP097#Datasheet
But in PSoC Creator 3.0 I am not able to build a project with a CAN component for CY8C5888LTI-LP097.
In the device selector of PSoC Creator 3.0 the column for CAN 2.0b displays that CY8C5888LTI-LP097 has no CAN-Component.
Is this maybe a bug of service pack 1?
Best regards,
Heiko
Show LessHi,
I would like to be able to allow a long button touch detection time (>15s) but i also must keep the sensor autoreset as enable.
I tried it by setting the baseline_update_threshold at its max (255) but it's not sufficient enough.
So my idea is to disable the sensor autoreset each time a long touch is detected (by a timer).
I searched on cypress datasheet, applications notes, forums and google but didn't found any information on how to do that.
So my questions are : is it possible ? is there any register, variable or function to access the sensor autoreset setting ?
Thanks,
Show LessHi, I am building a simple digital piano for my little sister. Nothing serious, just some bush buttons connected to intterupts, when a button is pressed the intterupt writes a value to a control register. the control register works as a select signal for a mux. the mux inputs are differnet clocks which serve as the piano tunes.
Now, the hardware is connected perfectly, every intterupt triggers perfectly, so here is the weird part:
When I press the first bush button, which is the tune A, everything works as it should, the intterupt triggers, the control register is written, then the return statement is excuted which brings the program back to main.
when I press the second bush button, the intterupt triggers, the control register is written, but the return statment is IGNORED. the program just keeps going to the next ISR where the its return statment is also ignored, and the next and the next until it creats an infinte loop outside of main.
I have uploded the project on two links if you care to shed some light on this problem.
http://www.mediafire.com/download/sp7z1hvm2ccu3eh/Simple_Piano_Using_Square_Waves.Bundle01.zip
https://drive.google.com/file/d/0BwvX4pp-M0KyNzlqY00yWUZzOGc/view?usp=sharing
Show LessHi,
I am using the DieTemp_Start and DieTemp_Query functions periodically in my main loop. If I write data to the EEPROM it fails. I have to disable the DieTemp functions to get the EEPROM written. Is there a way to get periodic Die Temperature measurement and EEPROM writing both together ? Maybe by blocking the Temp reading when accessing the EEPROM ?
Here is the update function from the main loop:
void UpdateDieTemp()
{
if (DieTemp_Query(&dieTemp) == CYRET_SUCCESS)
DieTemp_Start();
}
void SecondLoop()
Thanks
Show Lesshow can i store data greater than 128 bytes in buffer?
Hello,
I'm using the DST option of the RTC component (PSoC5LP CY8C5868AXI-LP035) in this way:
RTC_WriteDSTStartHour(1); // + 1 at 01:00 last Sunday of March
RTC_WriteDSTStartDayOfWeek(DIMANCHE);
RTC_WriteDSTStartWeek(5); // last week of March
RTC_WriteDSTStartMonth(MARS);
RTC_WriteDSTStopHour(1); // - 1 at 01:00 last Sunday of October
RTC_WriteDSTStopDayOfWeek(DIMANCHE);
RTC_WriteDSTStopWeek(4); // Last week of October RTC_WriteDSTStopMonth(OCTOBRE);
RTC_WriteDSTOffset(60); // 60-minute delay
RTC_WriteDSTMode(1); // Relative
When I set the date & time for the last Sunday of March, at 01:00 the time is correctly incremented by 60 minutes (01:00 => 02:00).
However when I set it for the last Sunday of October, at 01:00 the time also shift to 02:00. However I expect to read 00:00.
Am I missing something in the DST setup above?
Michel
Show LessRegression Testing and Migration Paths.
Regression Testing.
A recent PSoC3 Problem Determination episode elicited a Cypress Forum suggestion to migrate from Creator 2 to Creator 3 in an effort to find the cause. This step was undertaken but with a large amount of trepidation as to what to do if Creator 3 resolved the problem.
A significant amount of development, which included extensive testing, was expended using Creator 2. My project is one of an embedded design for Data Acquisition and Control of some fairly expensive machinery; one where expensive damage to the machinery could occur if an error went undetected as a result of a migration. The damage could well exceed the profit that would accrue as a result of a customer purchasing my embedded system.
Being a small shop, I did not develop extensive regression testing procedures. I employed as much data independency as the Keil C compiler would support so that incremental changes to my C code would be isolated from other code. Granted this is not a fool-proof process.
During the testing of Creator 3, I took a few minutes to compare selected Creator 2 generated source files with Creator 3 versions. I particularly noted that the PS0C3 files of CyLib.c and ADC.c Delta Sig appear to be significantly re-written. I rely heavily on the ADC Delta Sig. Thus I am faced with having to re-do a significant testing effort if I migrate.
So far, Creator 3 testing has not solved the problem. But if it were to do so, would Cypress provide a corrective “patch” for Creator 2?
Creator strongly advises that Component upgrades be made when migrating to a new release. Do older component versions get regression-tested with a new release so that migration can be a slow process by a user without introducing transition problems as a result?
Show Less