I am trying to install the USBUART driver of my PSOC project under a Win7 x64 system.
Unfortunatly the generated .inf file isn't recognized by Windows..
Anyone has a clue?
Ha, thats a common mistake many people do in the beginning. And it is not quite apparent. Even if the Global Interrupt is enabled after USBFS_Start() the code will still work. But the enumeration process will begin once you enable the global interrupt. But if you are waiting for enmureation to be complete(or for a valid configuration to be assigned), you might get stuck there forever.
I encounter the same problem now, where do I have to put the Enable Gloabal Interrupts?
#define CLEAR_SCREEN 0x0C
#define CONVERT_TO_ASCII 0x30u
#define BUFFER_LEN 64u
#define ADC_Config_2V 2
#define ADC_Config_3V 1
#define Restart_ADC 1
#define STX 2
#define ETX 3
#define ACK 6
#define SPACE 0x20
#define PRINT_TORQUE 0
#define PRINT_ADC 1
int pow10(int x);
void Print_Torque_ADC(uint8 ADC);
int length(int64 x);
int64 Nullpunkt=0, Endwert=0;
#if defined (__GNUC__)
/* Add an explicit reference to the floating point printf library */
/* to allow the usage of floating point conversion specifiers. */
/* This is not linked in by default with the newlib-nano library. */
asm (".global _printf_float");
CY_ISR(Counter_Comp_ISR)//timer gesteuerter interrupt zum ausgeben der messdaten
int clear=0; //nutzloser variablenwert
clear=Counter_1_STATUS;//clear sticky Comp-Interrupt flag
uint16 count, i, j, wert, get_stx, get_etx ,count_buffer, Index;
uint8 buffer[BUFFER_LEN],buffer_temp[BUFFER_LEN], Nullpunkt_EE[CYDEV_EEPROM_ROW_SIZE], Endwert_EE[CYDEV_EEPROM_ROW_SIZE];
reg8 * RegPointer;
/* Enable Global Interrupts */
/* Start USBFS Operation with 3V operation */
/* Wait for Device to enumerate */
/* Enumeration is done, enable OUT endpoint for receive data from Host */
this is the beginning of my main. can you tell me if there is something wrong with the place?
No, this place is quite OK. But I don't see in your code the place where you start the actual ISR components (SW2 / SW3). And when they are not started, they won't get triggered...
Seems to be a complete german help...
Look at the warnings you've got: you do not call the function Counter_1_STATUS, you just save its addreess in the variable clear thus not clearing the sticky interrupt-bit. just forgot to write Counter_1_STATUS().
hi together and thanks for your replies,
you are right the SW2 and SW3 ISRs were used for debugging purpose. I deleted them, my problem is this:
im supposed to write a code that gets Data via UART for instance if i receive a 02P03 the box is supposed to transfer the ADC Value to the Software.
The Software works without problems in WIndows XP but as soon as the Software runs on Win7 it doesnt even receive the Data from the Software. For Debugging I used your example for USBUART:
sprintf(lineStr,"SB:%s,Parity:%s", stop[(uint16)USBUART_1_GetCharFormat()], \
with this active I can see that the PSoC changes from parity none to odd(Software requirements) but still doesnt receive anything in the buffer.
Is it the Driver the problem? The Driver installation on Win7 was very slow compared to XP as well.
no, my answer is right for this question and if you have a look into the isr for the timer at variable "clear" you'll see that the interrupt bit is NOT resetted.
I have modified my code according to your tip,
now i use Counter_1_ReadStatusRegister(); instead of int clear=0; clear=Counter_1_STATUS; it works fine this way 🙂
Such a setting is not available. It also makes no sense, since USBUART doesn't involve a physical UART where such a setting could be applied.
The USBUART usermodule is an USB-connection from your PSoC to your PC. On the PC-side a windows driver emulates a COM:-port so that a terminal-software can take over. As you see, the PSoC does not "see" something like an RS232 interface where parity, start and stopbits may be defined. With the appropiate software it could be possible to define a parity within the PC-emulation, but that would not make sense since parity is used to detect errors in a transmission which at this stage already has happened.
PS: Located near Bremen
Thanks for the clearification 🙂
this is good to know. My problem still occurs, is it possible that the Drivers have any known problems? that would be my only guess right now.
And greetings to Bremen 😉
This may help -
|AN58726 - PSoC® 3 / PSoC 5LP USB HID Intermediate (with Keyboard and Composite Device)||06/27/2013|
|AN49943 - PSoC® 1 USB-to-UART Bridge||09/30/2013|
|AN56377 - PSoC® 3 and PSoC 5LP USB Transfer Types||05/28/2013|
|AN52970 - Windows Hardware Quality Labs (WHQL) Signing Procedure for Customer Modified Cypress USB D...||07/10/2012|
|AN57294 - USB 101: An Introduction to Universal Serial Bus 2.0||04/18/2012|