array to string in usart peripheral

[gusonela]

Posted on June 06, 2014 at 16:02

i know about usart, for transmited by transmittter and received data by receiver i can do it.. i communication usart use looping and use array too... how can i make this array to become string  so i can use function like this

if (x=''septian''){led on}this my concept transmit and receive data void cetak(char huruf[20]){ unsigned char jumlah; unsigned char i; jumlah = strlen(huruf); for(i=0;i<jumlah;i++)USART1_PutChar(huruf[i]);}void USART1_PutChar(char c){ uint8_t ch; ch=c; USART_SendData(USART1,ch); while(USART_GetFlagStatus(USART1,USART_FLAG_TC)==RESET);} and for received data and feedback it use thisvoid USART1_IRQHandler(){ if(USART_GetITStatus(USART1,USART_IT_RXNE)==SET) { receiver_to_feedback(); USART_ClearITPendingBit(USART1,USART_IT_RXNE); }}void receiver_to_feedback(){ uint8_t i=0; char resp[20]=''''; int a; do     {     while (USART_GetFlagStatus(USART1, USART_FLAG_RXNE) == RESET);     resp[i] = USART_ReceiveData(USART1);     i++;     }while(resp[i-1]!=32); for( a=0; a<i-1; a++)     {     USART1_PutChar(resp[a]);     }     USART1_PutChar(' ');     i=0;}maybe someone can help me,, please :D #stm32f4 #usart #stm32 #c-learning #discovery

[Tesla DeLorean]

Posted on June 06, 2014 at 16:55

The USART IRQ allows you to receive and/or transmit a single character. You need to manage the data as it comes in. You really should not be spinning around waiting for additional characters, and outputting strings in the handler. You could use a line buffer, accumulating one character at a time, when you have sufficient, you can then call a processing routine. You could also use a ring/fifo buffering scheme.

As far as the other loops/routines, you really shouldn't have a fixed length string parameter. Perhaps a review of K&R chapters on pointer and strings might help?

//**************************************************************************************
char USART_GetChar(void)
{
while(USART_GetFlagStatus(USART1, USART_FLAG_RXNE) == RESET); // Wait For input character
return((char)USART_ReceiveData(USART1));
}
//**************************************************************************************
void USART_PutChar(char ch)
{
while(USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); // Wait for holding buffer empty
USART_SendData(USART1, ch);
}
//**************************************************************************************
void USART_PutString(char *s)
{
while(*s)
USART_PutChar(*s++);
}
//**************************************************************************************
void USART_PutDecimal(unsigned int i)
{
char String[16];
char *s = String + sizeof(String);
*--s = 0; // NUL
do
{
*--s = '0' + (char)(i % 10);
i /= 10;
}
while(i);
USART_PutString(s);
}
//**************************************************************************************

[Tesla DeLorean]

Posted on June 06, 2014 at 17:02

So for the following pseudo code

if (x=''septian'') { led on } The C would look something along the lines of #include <stdio.h> #include <stdlib.h> #include <string.h> .. char *x; .. if (strcmp(x,''septian'') == 0) {   LEDOn(); } I'd generally recommend learning C thoroughly on a PC platform before migrating to embedded. Line buffering example about 50% down [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/UART%20example%20code%20for%20STM32F0&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=12652]this thread.

[Andrew Neil]

Posted on June 06, 2014 at 20:32

''I'd generally recommend learning C thoroughly on a PC platform before migrating to embedded.''

Seconded.And here are some 'C' learning resources: 

http://blog.antronics.co.uk/2011/08/08/so-youre-thinking-of-starting-with-c/

[jpeacock2399]

Posted on June 07, 2014 at 00:50

''I'd generally recommend learning C thoroughly on a PC platform before migrating to embedded.''

The problem with learning C on a PC platform is the environment is far removed from embedded.  A PC encourages the bad habit of using printf(), malloc(), and all those OS services that don't exist anywhere else.  It creates a mindset that's limited to the usual trivial examples in classroom books. The forum here is full of those examples.  Sending data in ASCII instead of binary and quadrupling bandwidth requirements, declaring huge arrays and assuming memory will be there, wondering why printf() caused the code section to overflow, calling malloc() without any clue as to where the heap is at, and oh by the way, there's no reliable garbage collection to get that heap memory back after out of order allocate and free.   Jack Peacock

[Tesla DeLorean]

Posted on June 07, 2014 at 01:09

I grew up with DOS PC's which were rather slow and memory/storage constrained, and before that 8-bit micros. The temptation to load a 1MB array of numbers just wasn't going to happen.

I honestly think a clear grasp of C, and basic character and file manipulation is pretty lacking in some candidates these days. That, and an appreciation how the machines work. PC's today do provide effectively infinite resources, but if you can't program properly/effectively in that environment, you're pretty much doomed in embedded where the resources are tighter and the visibility more limited.

[Andrew Neil]

Posted on June 07, 2014 at 13:02

''... printf(), malloc(), and all those OS services that don't exist anywhere else''

Of course they do exist!Nothing, of course, is perfect - and I agree that this can be a downside of learning on a ''Big System''.(another could be that most PC environments these days assume C++).But I still reckon that the PC is a more conducive environment to learn the langugage - and one can then learn to apply that in resource-constrained embedded systems.

[Andrew Neil]

Posted on June 07, 2014 at 13:05

''It creates a mindset that's limited to the usual trivial examples in classroom books''

But the OP's code showed that he hasn't even mastered the basics of the language - which should have been learned in those ''trivial'' (sic) examples...