- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Labels:
-
PSoC 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Both boud rate is meet each other?
What kind of PSoC1 do you use?
On PSoC1, Interrupt routine have to save CPU context
and have to change memory bank into user program.
Did you do that?
Your interrupt routine is something odd.
You did convert the value of gps, but never write out.
And in the interrupt routine, delay loop is no good.
Meaning of "ignore characters under?"
System part of Interrupt routine is ignored these charactor.
These character is not store into user's buffer.
I recall somthing, I wouldn't like to answer for you,
Because, before, 14th Jun, you had ask something of UART,
I had answer for that, but you never respond to it.
You avoid it, these are rudeness,
Is it as usually in your country? anyway.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some general rules of thumb in dealing with ISR's -
1) Do not make f() calls from within ISR unless you cannot avoid it. That
is because compiler will do a ton of saves, like full stack, etc. to make sure
it can return fully and properly. That in turn slows machine down considerably
wasting a lot of MIPs. Look at your listing file to see what the compiler does with
your ISR code.
2) Best practice is simple, set a flag inside ISR and return to main() to process ISR.
3) Set up ISR to "fire" as infrequently as possible. If you only need ISR at a low rate,
don't "oversample" it, that would be just a waste of MIPS.
4) Look at coding. If you have multiple ISRs, is there any ISR that can essentially
negate the need to process another pending ISR, eg. compute not when not
needed. If you have an ISR that needs a lot of MIPs occasionally, you can always
skip another pending ISR if by doing so nothing terrible happens.
5) If list file shows compiler generating wacky stuff, consider ASM for the ISR
routine.
6) Turn off optimization when first debugging ISRs, then look at it again after
optimization turned back on, to make sure compiler did not "optimize" in some
crazy jump or other unnecessary code.
7) If display issues are affected, jitter, etc.., consider creating a display buffer in
RAM. And when a write is needed first check if RAM already displaying what you
want, if so do nothing, or update RAM and write to display if needed. This some-
times can cure ISR driven display update issues.
http://www.cypress.com/?id=4&rID=36720
http://www.planetpsoc.com/component/content/article/43-writing-a-c-isr.html
http://www.planetpsoc.com/psoc1-articles-digital/13-basics-of-psoc-gpio.html?start=7
With respect to a simple method for handling Rx data, pass a pointer to ISR that points to a
character array, and in ISR simply write the character received via pointer, inc pointer, and return.
No delays in ISR, no tests, do that on return. Many ways of handling buffer, detect EOL or CR,
eg. termination of a line, and use that to flag processing char buffer, then clear buffer. Or use
circular buffer. There are UART project examples on opening screen of Designer that you can
look at to see how they do it.
Some additional help -
www.cypress.com/ USB to UART bridge, but can show you how buffer management done.
www.psocdeveloper.com/forums/viewtopic.php
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi,
Thank you for all ur replies, I am able to read the string now into a pointer. I have implemented ur suggestions regarding ISR, but I hav used a szGetRestOfParam() api instead of buffering. My coding:
if(str4 = UARTgps_szGetRestOfParams())
{
if( *str4 == '$')
{
UART_CPutString(" \r\n saved gps data \r\n"); // the uart that is used for displaying data in computer(baud:9600 bps)
UART_PutString(str4);
for(i=0;i<5000;i++);
UARTgps_CmdReset();// the uart used for receiving GPS data(baud:4800 bps)
}
}
Now am having another issue. I have set the size of Rx buffer as 127. I am getting only a part of the GPS string. what should i do to get the whole string? it consists of 75 characters maximum.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Using command buffer is good choice.
you can check existing data size, before read the data.
like this
... len= UART_bCmdLength();
... if( len>0 )
... { // read rest of data
... // reconstruct GPS data again
... // if find endof text: send it
... }
When using command buffer mode,
setting of terminater and delimiter is important.
So you can get each item of data, one by one.
use: UART_szGetParam();
For example: terminater=0x0d,
delimiter=0x32 or delimiter=','
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"delimiter=0x32" ==> "delimiter=0x20" (one space)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hey, thanks ppl, m getting the GPS string completely now, but there is one thing that is very strange I am observing.
UART_PutString() api can be assigned only to a pointer ryt.. I tried to take the latitude, longitude and time info seperately by having seperate arrays for each. the code is given below:
if(str4 = UARTgps_szGetRestOfParams())
{
if( *str4 == '$')
{
//UART_PutString(str4);
str5 = str4;
str5 =str5 + 3;
if((*str5 == 'G') && (*(str5+1) == 'G') && (*(str5+2) == 'A'))
{
i=0;
str5 = str5+4;
while( *str5 != ',')
{
time = *str5;
i++; str5++;
}
*ptr = str5;
str6 = str5+1;
i=0;
while(*str6!=',')
{lat = *str6; i++; str6++;}
str6=str6+1; h1 = *str6;
str7=str6+2;
i=0;
while(*str7!=',')
{lon = *str7; i++; str7++;}
str7++;
h2 = *str7;
}
UART_CPutString("GPS DATA: Location in - \r\n");
Finally, when I am printing the individual arrays using the UART_PutString() api, the time(which is saved first) array display includes the value of latitude and longitude chars also.. as if in a series.. and the latitude array display shows both latitude and longitude info together, and then the longitude display comes clean. Anyone can tell me why this is happening? My theory is that since the UART_PutString() api uses pointer of the starting location of the string, it is displaying all the information saved next to it in the memory.. Am I right? When I increased the size of all the arrays by 1 element and assigned it to '\0', I am able to get proper results. Also, Is there any way of controlling the location in SRAM in which our variables are saved? (In PSoC1)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Normally you terminate a character array with a '/0', to tell you, and compiler,
where array ends. That also tells all the librabry functions where the string
ends. Keep in mind a string is an array of chars. So if I want a 10 char array
I declare it as myray[ 11 ] so that last char can be null character.
Yes you can force an array in memory to be at an absolute location, in Imagcraft
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello nivi you could share your project in a zip to serve me as an example, I'm doing something similar, thanks for your help
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Welcome in the forum, DEPREDATOR.
The thread you posted to is more than three years old, probaly nivi is not listening any more. I would suggest you to ask for a serial (?) GPS interface for your PSoC. Are you really using a PSoC1? Have you got a development kit?? Which one???
Happy coding
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some possibilities -
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes ,I'm using a PSoC 1 and already achieved listen to gps but now my problem is I can not take the data of interruptions