Hello Guys
I would like to implement a simple set of application level commands
that would invoke certain functions on the MSP via the UART. The PC
will send the command codes and read back data from the MSP. I would
like some help on the data transfer technique.
I have got the communication going using interrupt mode, so detecting
a single char on the MSP is no issue, I am confused which would be
the best method for transfer of a fixed length string both ways.
For example in the following code, I am able to fill up rx_buff, but
I am lost on how to process it, i.e. if I send in a data from the PC
to the MSP like #d12$ where:-
# - start identifier
d - parameter identifier
12- parameter value
$ - end identifer
What I would like to be able to do is once I have recieved the
string, have a way to switch based on the parameter identifer and
extract the values passed on from the PC.
// UART0 RX ISR
#pragma vector=UART0RX_VECTOR
__interrupt void usart0_rx (void)
{
rx_cnt++; //rx buffer count
if(rx_cnt==5) rx_cnt=0; //overwrite the buffer data
rx_buf[rx_cnt] = RXBUF0; //fill up buffer
if (RXBUF0 == 'V') // responding to single char
command
{
msg_len = 0;
TXBUF0 = msg[msg_len++]; //Transmit version
string
}
}
Thanks
Jay
UART processing string
Started by ●January 6, 2006
Reply by ●January 6, 20062006-01-06
Assuming all fields are bytes try, and assuming you've collected the
data using a pointer to a buffer you might try something like:_
IF(0(R15) != '$' THEN END
ELSE
{
R14 = -2(R15) (R14 MUST BE EVEN)
PC += R14
JMP PARAM0
JMP PARAM2
JMP PARAM4
...
}
PARAM0:
MOV.B &VAR1 = -1(R15)
...
PARAM1:
ETC
This is simple to implement, simple to expand, and simple to understand.
There are as many wasy to do this as there are ways to skin a cat.
Cheers
Al
hc08jb8 wrote:
>Hello Guys
>
>
>I would like to implement a simple set of application level commands
>that would invoke certain functions on the MSP via the UART. The PC
>will send the command codes and read back data from the MSP. I would
>like some help on the data transfer technique.
>
>I have got the communication going using interrupt mode, so detecting
>a single char on the MSP is no issue, I am confused which would be
>the best method for transfer of a fixed length string both ways.
>
>For example in the following code, I am able to fill up rx_buff, but
>I am lost on how to process it, i.e. if I send in a data from the PC
>to the MSP like #d12$ where:-
># - start identifier
>d - parameter identifier
>12- parameter value
>$ - end identifer
>
>What I would like to be able to do is once I have recieved the
>string, have a way to switch based on the parameter identifer and
>extract the values passed on from the PC.
>
>// UART0 RX ISR
>#pragma vector=UART0RX_VECTOR
>__interrupt void usart0_rx (void)
>{
> rx_cnt++; //rx buffer count
> if(rx_cnt==5) rx_cnt=0; //overwrite the buffer data
> rx_buf[rx_cnt] = RXBUF0; //fill up buffer
> if (RXBUF0 == 'V') // responding to single char
>command
> {
> msg_len = 0;
> TXBUF0 = msg[msg_len++]; //Transmit version
>string
> }
>}
>
>Thanks
>Jay
>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
Reply by ●January 6, 20062006-01-06
I love Al's pseudo 'C'.. It's like watching a good horror
movie, scary but you
want to watch again and again..
On Friday 06 January 2006 1:49 pm, Onestone wrote:
> Assuming all fields are bytes try, and assuming you've collected the
> data using a pointer to a buffer you might try something like:_
>
> IF(0(R15) != '$' THEN END
> ELSE
> {
> R14 = -2(R15) (R14 MUST BE EVEN)
> PC += R14
> JMP PARAM0
> JMP PARAM2
> JMP PARAM4
> ...
> }
>
> PARAM0:
> MOV.B &VAR1 = -1(R15)
> ...
>
> PARAM1:
>
> ETC
>
> This is simple to implement, simple to expand, and simple to understand.
> There are as many wasy to do this as there are ways to skin a cat.
>
> Cheers
>
> Al
>
> hc08jb8 wrote:
> >Hello Guys
> >
> >
> >I would like to implement a simple set of application level commands
> >that would invoke certain functions on the MSP via the UART. The PC
> >will send the command codes and read back data from the MSP. I would
> >like some help on the data transfer technique.
> >
> >I have got the communication going using interrupt mode, so detecting
> >a single char on the MSP is no issue, I am confused which would be
> >the best method for transfer of a fixed length string both ways.
> >
> >For example in the following code, I am able to fill up rx_buff, but
> >I am lost on how to process it, i.e. if I send in a data from the PC
> >to the MSP like #d12$ where:-
> ># - start identifier
> >d - parameter identifier
> >12- parameter value
> >$ - end identifer
> >
> >What I would like to be able to do is once I have recieved the
> >string, have a way to switch based on the parameter identifer and
> >extract the values passed on from the PC.
> >
> >// UART0 RX ISR
> >#pragma vector=UART0RX_VECTOR
> >__interrupt void usart0_rx (void)
> >{
> > rx_cnt++; //rx buffer count
> > if(rx_cnt==5) rx_cnt=0; //overwrite the buffer data
> > rx_buf[rx_cnt] = RXBUF0; //fill up buffer
> > if (RXBUF0 == 'V') // responding to single
char
> >command
> > {
> > msg_len = 0;
> > TXBUF0 = msg[msg_len++]; //Transmit version
> >string
> > }
> >}
> >
> >Thanks
> >Jay
> >
> >
> >
> >
> >
> >.
> >
> >
> >Yahoo! Groups Links
>
> .
>
>
> Yahoo! Groups Links
>
>
>
Reply by ●January 7, 20062006-01-07
It's not pseudo C, or not meant to be, it's a warped pseudo code
that
abstracts some of the assembler. I vacilated over the MOV.B, but in the
end stuck it in so that it was clear a byte operation was going on. Same
with the use of JMP, rather than GOTO to make it clear that BR would not
work unless the spacing between identifiers was increased to 4. It looks
a bit C'ish, I admit, because that's what most people here understand,
but then that's probably because C looks like pseudo code. And if I
wrote the thing in nice clean pure assembler I could (almost) guarantee
being asked to provide the same in C (at least privately, if not here),
and since this particular implementation isn't C friendly I didin't
want
to get bogged down with trying to explain why C wasn't suited.
The point is did it convey the correct functionality or not, however
scary it might look? ;@}
Cheers
Micah Stevens wrote:
>I love Al's pseudo 'C'.. It's
like watching a good horror movie, scary but you
>want to watch again and again..
>
>On Friday 06 January 2006 1:49 pm, Onestone wrote:
>
>
>>Assuming all fields are bytes try, and assuming you've collected
the
>>data using a pointer to a buffer you might try something like:_
>>
>> IF(0(R15) != '$' THEN END
>> ELSE
>> {
>> R14 = -2(R15) (R14 MUST BE EVEN)
>> PC += R14
>> JMP PARAM0
>> JMP PARAM2
>> JMP PARAM4
>> ...
>> }
>>
>>PARAM0:
>> MOV.B &VAR1 = -1(R15)
>> ...
>>
>>PARAM1:
>>
>> ETC
>>
>>This is simple to implement, simple to expand, and simple to understand.
>>There are as many wasy to do this as there are ways to skin a cat.
>>
>>Cheers
>>
>>Al
>>
>>hc08jb8 wrote:
>>
>>
>>>Hello Guys
>>>
>>>
>>>I would like to implement a simple set of application level commands
>>>that would invoke certain functions on the MSP via the UART. The PC
>>>will send the command codes and read back data from the MSP. I would
>>>like some help on the data transfer technique.
>>>
>>>I have got the communication going using interrupt mode, so
detecting
>>>a single char on the MSP is no issue, I am confused which would be
>>>the best method for transfer of a fixed length string both ways.
>>>
>>>For example in the following code, I am able to fill up rx_buff, but
>>>I am lost on how to process it, i.e. if I send in a data from the PC
>>>to the MSP like #d12$ where:-
>>># - start identifier
>>>d - parameter identifier
>>>12- parameter value
>>>$ - end identifer
>>>
>>>What I would like to be able to do is once I have recieved the
>>>string, have a way to switch based on the parameter identifer and
>>>extract the values passed on from the PC.
>>>
>>>// UART0 RX ISR
>>>#pragma vector=UART0RX_VECTOR
>>>__interrupt void usart0_rx (void)
>>>{
>>> rx_cnt++; //rx buffer count
>>> if(rx_cnt==5) rx_cnt=0; //overwrite the buffer data
>>> rx_buf[rx_cnt] = RXBUF0; //fill up buffer
>>> if (RXBUF0 == 'V') // responding to
single char
>>>command
>>> {
>>> msg_len = 0;
>>> TXBUF0 = msg[msg_len++]; //Transmit version
>>>string
>>> }
>>>}
>>>
>>>Thanks
>>>Jay
>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>.
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
Reply by ●January 7, 20062006-01-07
> The point is did it convey the correct functionality > or not, however > scary it might look? ;@} It did solve my issue, Thanks Al. Cheers Jay --- Onestone <onestone@ones...> wrote: > It's not pseudo C, or not meant to be, it's a warped > pseudo code that > abstracts some of the assembler. I vacilated over > the MOV.B, but in the > end stuck it in so that it was clear a byte > operation was going on. Same > with the use of JMP, rather than GOTO to make it > clear that BR would not > work unless the spacing between identifiers was > increased to 4. It looks > a bit C'ish, I admit, because that's what most > people here understand, > but then that's probably because C looks like pseudo > code. And if I > wrote the thing in nice clean pure assembler I could > (almost) guarantee > being asked to provide the same in C (at least > privately, if not here), > and since this particular implementation isn't C > friendly I didin't want > to get bogged down with trying to explain why C > wasn't suited. > > The point is did it convey the correct functionality > or not, however > scary it might look? ;@} > > Cheers > > Micah Stevens wrote: > > >I love Al's pseudo 'C'.. It's like watching a good > horror movie, scary but you > >want to watch again and again.. > > > >On Friday 06 January 2006 1:49 pm, Onestone wrote: > > > > > >>Assuming all fields are bytes try, and assuming > you've collected the > >>data using a pointer to a buffer you might try > something like:_ > >> > >> IF(0(R15) != '$' THEN END > >> ELSE > >> { > >> R14 = -2(R15) (R14 > MUST BE EVEN) > >> PC += R14 > >> JMP PARAM0 > >> JMP PARAM2 > >> JMP PARAM4 > >> ... > >> } > >> > >>PARAM0: > >> MOV.B &VAR1 = -1(R15) > >> ... > >> > >>PARAM1: > >> > >> ETC > >> > >>This is simple to implement, simple to expand, and > simple to understand. > >>There are as many wasy to do this as there are > ways to skin a cat. > >> > >>Cheers > >> > >>Al > >> > >>hc08jb8 wrote: > >> > >> > >>>Hello Guys > >>> > >>> > >>>I would like to implement a simple set of > application level commands > >>>that would invoke certain functions on the MSP > via the UART. The PC > >>>will send the command codes and read back data > from the MSP. I would > >>>like some help on the data transfer technique. > >>> > >>>I have got the communication going using > interrupt mode, so detecting > >>>a single char on the MSP is no issue, I am > confused which would be > >>>the best method for transfer of a fixed length > string both ways. > >>> > >>>For example in the following code, I am able to > fill up rx_buff, but > >>>I am lost on how to process it, i.e. if I send in > a data from the PC > >>>to the MSP like #d12$ where:- > >>># - start identifier > >>>d - parameter identifier > >>>12- parameter value > >>>$ - end identifer > >>> > >>>What I would like to be able to do is once I have > recieved the > >>>string, have a way to switch based on the > parameter identifer and > >>>extract the values passed on from the PC. > >>> > >>>// UART0 RX ISR > >>>#pragma vector=UART0RX_VECTOR > >>>__interrupt void usart0_rx (void) > >>>{ > >>> rx_cnt++; //rx buffer > count > >>> if(rx_cnt==5) rx_cnt=0; //overwrite > the buffer data > >>> rx_buf[rx_cnt] = RXBUF0; //fill up > buffer > >>> if (RXBUF0 == 'V') // > responding to single char > >>>command > >>> { > >>> msg_len = 0; > >>> TXBUF0 = msg[msg_len++]; //Transmit > version > >>>string > >>> } > >>>} > >>> > >>>Thanks > >>>Jay > >>> > >>> > >>> > >>> > >>> > >>>. > >>> > >>> > >>>Yahoo! Groups Links > >>> > >>> > >>. > >> > >> > >>Yahoo! Groups Links > >> > >> > >> > >> > >> > > > > > >. > > > > > >Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > >
Reply by ●January 7, 20062006-01-07
Good to know Jay, now, were you scared?
;@}
Al
68HC 08 wrote:
>>The point is did it convey the correct
functionality
>>or not, however
>>scary it might look? ;@}
>>
>>
>
>It did solve my issue, Thanks Al.
>
>Cheers
>Jay
>
>
>--- Onestone <onestone@ones...> wrote:
>
>
>
>>It's not pseudo C, or not meant to be, it's a warped
>>pseudo code that
>>abstracts some of the assembler. I vacilated over
>>the MOV.B, but in the
>>end stuck it in so that it was clear a byte
>>operation was going on. Same
>>with the use of JMP, rather than GOTO to make it
>>clear that BR would not
>>work unless the spacing between identifiers was
>>increased to 4. It looks
>>a bit C'ish, I admit, because that's what most
>>people here understand,
>>but then that's probably because C looks like pseudo
>>code. And if I
>>wrote the thing in nice clean pure assembler I could
>>(almost) guarantee
>>being asked to provide the same in C (at least
>>privately, if not here),
>>and since this particular implementation isn't C
>>friendly I didin't want
>>to get bogged down with trying to explain why C
>>wasn't suited.
>>
>>The point is did it convey the correct functionality
>>or not, however
>>scary it might look? ;@}
>>
>>Cheers
>>
>>Micah Stevens wrote:
>>
>>
>>
>>>I love Al's pseudo 'C'.. It's like watching a
good
>>>
>>>
>>horror movie, scary but you
>>
>>
>>>want to watch again and again..
>>>
>>>On Friday 06 January 2006 1:49 pm, Onestone wrote:
>>>
>>>
>>>
>>>
>>>>Assuming all fields are bytes try, and assuming
>>>>
>>>>
>>you've collected the
>>
>>
>>>>data using a pointer to a buffer you might try
>>>>
>>>>
>>something like:_
>>
>>
>>>> IF(0(R15) != '$' THEN END
>>>> ELSE
>>>> {
>>>> R14 = -2(R15) (R14
>>>>
>>>>
>>MUST BE EVEN)
>>
>>
>>>> PC += R14
>>>> JMP PARAM0
>>>> JMP PARAM2
>>>> JMP PARAM4
>>>> ...
>>>> }
>>>>
>>>>PARAM0:
>>>> MOV.B &VAR1 = -1(R15)
>>>> ...
>>>>
>>>>PARAM1:
>>>>
>>>> ETC
>>>>
>>>>This is simple to implement, simple to expand, and
>>>>
>>>>
>>simple to understand.
>>
>>
>>>>There are as many wasy to do this as there are
>>>>
>>>>
>>ways to skin a cat.
>>
>>
>>>>Cheers
>>>>
>>>>Al
>>>>
>>>>hc08jb8 wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hello Guys
>>>>>
>>>>>
>>>>>I would like to implement a simple set of
>>>>>
>>>>>
>>application level commands
>>
>>
>>>>>that would invoke certain functions on the MSP
>>>>>
>>>>>
>>via the UART. The PC
>>
>>
>>>>>will send the command codes and read back data
>>>>>
>>>>>
>>from the MSP. I would
>>
>>
>>>>>like some help on the data transfer technique.
>>>>>
>>>>>I have got the communication going using
>>>>>
>>>>>
>>interrupt mode, so detecting
>>
>>
>>>>>a single char on the MSP is no issue, I am
>>>>>
>>>>>
>>confused which would be
>>
>>
>>>>>the best method for transfer of a fixed length
>>>>>
>>>>>
>>string both ways.
>>
>>
>>>>>For example in the following code, I am able to
>>>>>
>>>>>
>>fill up rx_buff, but
>>
>>
>>>>>I am lost on how to process it, i.e. if I send in
>>>>>
>>>>>
>>a data from the PC
>>
>>
>>>>>to the MSP like #d12$ where:-
>>>>># - start identifier
>>>>>d - parameter identifier
>>>>>12- parameter value
>>>>>$ - end identifer
>>>>>
>>>>>What I would like to be able to do is once I have
>>>>>
>>>>>
>>recieved the
>>
>>
>>>>>string, have a way to switch based on the
>>>>>
>>>>>
>>parameter identifer and
>>
>>
>>>>>extract the values passed on from the PC.
>>>>>
>>>>>// UART0 RX ISR
>>>>>#pragma vector=UART0RX_VECTOR
>>>>>__interrupt void usart0_rx (void)
>>>>>{
>>>>>rx_cnt++; //rx buffer
>>>>>
>>>>>
>>count
>>
>>
>>>>>if(rx_cnt==5) rx_cnt=0; //overwrite
>>>>>
>>>>>
>>the buffer data
>>
>>
>>>>>rx_buf[rx_cnt] = RXBUF0; //fill up
>>>>>
>>>>>
>>buffer
>>
>>
>>>>>if (RXBUF0 == 'V') //
>>>>>
>>>>>
>>responding to single char
>>
>>
>>>>>command
>>>>>{
>>>>> msg_len = 0;
>>>>> TXBUF0 = msg[msg_len++]; //Transmit
>>>>>
>>>>>
>>version
>>
>>
>>>>>string
>>>>>}
>>>>>}
>>>>>
>>>>>Thanks
>>>>>Jay
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>.
>>>>>
>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>.
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>.
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
Reply by ●January 7, 20062006-01-07
It did give me a shock and clear the "programmer's
block" ;-)
Cheers
Jay
--- Onestone <onestone@ones...> wrote:
> Good to know Jay, now, were you scared?
>
> ;@}
>
> Al
>
> 68HC 08 wrote:
>
> >>The point is did it convey the correct
> functionality
> >>or not, however
> >>scary it might look? ;@}
> >>
> >>
> >
> >It did solve my issue, Thanks Al.
> >
> >Cheers
> >Jay
> >
> >
> >--- Onestone <onestone@ones...> wrote:
> >
> >
> >
> >>It's not pseudo C, or not meant to be, it's a
> warped
> >>pseudo code that
> >>abstracts some of the assembler. I vacilated over
> >>the MOV.B, but in the
> >>end stuck it in so that it was clear a byte
> >>operation was going on. Same
> >>with the use of JMP, rather than GOTO to make it
> >>clear that BR would not
> >>work unless the spacing between identifiers was
> >>increased to 4. It looks
> >>a bit C'ish, I admit, because that's what most
> >>people here understand,
> >>but then that's probably because C looks like
> pseudo
> >>code. And if I
> >>wrote the thing in nice clean pure assembler I
> could
> >>(almost) guarantee
> >>being asked to provide the same in C (at least
> >>privately, if not here),
> >>and since this particular implementation isn't C
> >>friendly I didin't want
> >>to get bogged down with trying to explain why C
> >>wasn't suited.
> >>
> >>The point is did it convey the correct
> functionality
> >>or not, however
> >>scary it might look? ;@}
> >>
> >>Cheers
> >>
> >>Micah Stevens wrote:
> >>
> >>
> >>
> >>>I love Al's pseudo 'C'.. It's like watching
a
> good
> >>>
> >>>
> >>horror movie, scary but you
> >>
> >>
> >>>want to watch again and again..
> >>>
> >>>On Friday 06 January 2006 1:49 pm, Onestone
> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Assuming all fields are bytes try, and assuming
> >>>>
> >>>>
> >>you've collected the
> >>
> >>
> >>>>data using a pointer to a buffer you might try
> >>>>
> >>>>
> >>something like:_
> >>
> >>
> >>>> IF(0(R15) != '$' THEN END
> >>>> ELSE
> >>>> {
> >>>> R14 = -2(R15) (R14
> >>>>
> >>>>
> >>MUST BE EVEN)
> >>
> >>
> >>>> PC += R14
> >>>> JMP PARAM0
> >>>> JMP PARAM2
> >>>> JMP PARAM4
> >>>> ...
> >>>> }
> >>>>
> >>>>PARAM0:
> >>>> MOV.B &VAR1 = -1(R15)
> >>>> ...
> >>>>
> >>>>PARAM1:
> >>>>
> >>>> ETC
> >>>>
> >>>>This is simple to implement, simple to expand,
> and
> >>>>
> >>>>
> >>simple to understand.
> >>
> >>
> >>>>There are as many wasy to do this as there are
> >>>>
> >>>>
> >>ways to skin a cat.
> >>
> >>
> >>>>Cheers
> >>>>
> >>>>Al
> >>>>
> >>>>hc08jb8 wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hello Guys
> >>>>>
> >>>>>
> >>>>>I would like to implement a simple set of
> >>>>>
> >>>>>
> >>application level commands
> >>
> >>
> >>>>>that would invoke certain functions on the MSP
> >>>>>
> >>>>>
> >>via the UART. The PC
> >>
> >>
> >>>>>will send the command codes and read back data
> >>>>>
> >>>>>
> >>from the MSP. I would
> >>
> >>
> >>>>>like some help on the data transfer technique.
> >>>>>
> >>>>>I have got the communication going using
> >>>>>
> >>>>>
> >>interrupt mode, so detecting
> >>
> >>
> >>>>>a single char on the MSP is no issue, I am
> >>>>>
> >>>>>
> >>confused which would be
> >>
> >>
> >>>>>the best method for transfer of a fixed length
> >>>>>
> >>>>>
> >>string both ways.
> >>
> >>
> >>>>>For example in the following code, I am able to
> >>>>>
> >>>>>
> >>fill up rx_buff, but
> >>
> >>
> >>>>>I am lost on how to process it, i.e. if I send
> in
> >>>>>
> >>>>>
> >>a data from the PC
> >>
> >>
> >>>>>to the MSP like #d12$ where:-
> >>>>># - start identifier
> >>>>>d - parameter identifier
> >>>>>12- parameter value
> >>>>>$ - end identifer
> >>>>>
> >>>>>What I would like to be able to do is once I
> have
> >>>>>
> >>>>>
> >>recieved the
> >>
>
=== message truncated ==
Reply by ●January 7, 20062006-01-07
Yes! I didn't mean to sound like it didn't.. It's a good
combination of the
two..
On Friday 06 January 2006 11:36 pm, Onestone wrote:
> It's not pseudo C, or not meant to be, it's a warped pseudo code
that
> abstracts some of the assembler. I vacilated over the MOV.B, but in the
> end stuck it in so that it was clear a byte operation was going on. Same
> with the use of JMP, rather than GOTO to make it clear that BR would not
> work unless the spacing between identifiers was increased to 4. It looks
> a bit C'ish, I admit, because that's what most people here
understand,
> but then that's probably because C looks like pseudo code. And if I
> wrote the thing in nice clean pure assembler I could (almost) guarantee
> being asked to provide the same in C (at least privately, if not here),
> and since this particular implementation isn't C friendly I
didin't want
> to get bogged down with trying to explain why C wasn't suited.
>
> The point is did it convey the correct functionality or not, however
> scary it might look? ;@}
>
> Cheers
>
> Micah Stevens wrote:
> >I love Al's pseudo 'C'.. It's like watching a good
horror movie, scary but
> > you want to watch again and again..
> >
> >On Friday 06 January 2006 1:49 pm, Onestone wrote:
> >>Assuming all fields are bytes try, and assuming you've
collected the
> >>data using a pointer to a buffer you might try something like:_
> >>
> >> IF(0(R15) != '$' THEN END
> >> ELSE
> >> {
> >> R14 = -2(R15) (R14 MUST BE EVEN)
> >> PC += R14
> >> JMP PARAM0
> >> JMP PARAM2
> >> JMP PARAM4
> >> ...
> >> }
> >>
> >>PARAM0:
> >> MOV.B &VAR1 = -1(R15)
> >> ...
> >>
> >>PARAM1:
> >>
> >> ETC
> >>
> >>This is simple to implement, simple to expand, and simple to
understand.
> >>There are as many wasy to do this as there are ways to skin a cat.
> >>
> >>Cheers
> >>
> >>Al
> >>
> >>hc08jb8 wrote:
> >>>Hello Guys
> >>>
> >>>
> >>>I would like to implement a simple set of application level
commands
> >>>that would invoke certain functions on the MSP via the UART.
The PC
> >>>will send the command codes and read back data from the MSP. I
would
> >>>like some help on the data transfer technique.
> >>>
> >>>I have got the communication going using interrupt mode, so
detecting
> >>>a single char on the MSP is no issue, I am confused which would
be
> >>>the best method for transfer of a fixed length string both
ways.
> >>>
> >>>For example in the following code, I am able to fill up
rx_buff, but
> >>>I am lost on how to process it, i.e. if I send in a data from
the PC
> >>>to the MSP like #d12$ where:-
> >>># - start identifier
> >>>d - parameter identifier
> >>>12- parameter value
> >>>$ - end identifer
> >>>
> >>>What I would like to be able to do is once I have recieved the
> >>>string, have a way to switch based on the parameter identifer
and
> >>>extract the values passed on from the PC.
> >>>
> >>>// UART0 RX ISR
> >>>#pragma vector=UART0RX_VECTOR
> >>>__interrupt void usart0_rx (void)
> >>>{
> >>> rx_cnt++; //rx buffer count
> >>> if(rx_cnt==5) rx_cnt=0; //overwrite the buffer
data
> >>> rx_buf[rx_cnt] = RXBUF0; //fill up buffer
> >>> if (RXBUF0 == 'V') // responding to
single char
> >>>command
> >>> {
> >>> msg_len = 0;
> >>> TXBUF0 = msg[msg_len++]; //Transmit version
> >>>string
> >>> }
> >>>}
> >>>
> >>>Thanks
> >>>Jay
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>.
> >>>
> >>>
> >>>Yahoo! Groups Links
> >>
> >>.
> >>
> >>
> >>Yahoo! Groups Links
> >
> >.
> >
> >
> >Yahoo! Groups Links
>
> .
>
>
> Yahoo! Groups Links
>
>
>
Reply by ●January 7, 20062006-01-07
Hehe.. see? Being scared can be good!
On Saturday 07 January 2006 7:07 am, 68HC 08 wrote:
> It did give me a shock and clear the "programmer's
> block" ;-)
>
> Cheers
> Jay
>
> --- Onestone <onestone@ones...> wrote:
> > Good to know Jay, now, were you scared?
> >
> > ;@}
> >
> > Al
> >
> > 68HC 08 wrote:
> > >>The point is did it convey the correct
> >
> > functionality
> >
> > >>or not, however
> > >>scary it might look? ;@}
> > >
> > >It did solve my issue, Thanks Al.
> > >
> > >Cheers
> > >Jay
> > >
> > >--- Onestone <onestone@ones...> wrote:
> > >>It's not pseudo C, or not meant to be, it's a
> >
> > warped
> >
> > >>pseudo code that
> > >>abstracts some of the assembler. I vacilated over
> > >>the MOV.B, but in the
> > >>end stuck it in so that it was clear a byte
> > >>operation was going on. Same
> > >>with the use of JMP, rather than GOTO to make it
> > >>clear that BR would not
> > >>work unless the spacing between identifiers was
> > >>increased to 4. It looks
> > >>a bit C'ish, I admit, because that's what most
> > >>people here understand,
> > >>but then that's probably because C looks like
> >
> > pseudo
> >
> > >>code. And if I
> > >>wrote the thing in nice clean pure assembler I
> >
> > could
> >
> > >>(almost) guarantee
> > >>being asked to provide the same in C (at least
> > >>privately, if not here),
> > >>and since this particular implementation isn't C
> > >>friendly I didin't want
> > >>to get bogged down with trying to explain why C
> > >>wasn't suited.
> > >>
> > >>The point is did it convey the correct
> >
> > functionality
> >
> > >>or not, however
> > >>scary it might look? ;@}
> > >>
> > >>Cheers
> > >>
> > >>Micah Stevens wrote:
> > >>>I love Al's pseudo 'C'.. It's like
watching a
> >
> > good
> >
> > >>horror movie, scary but you
> > >>
> > >>>want to watch again and again..
> > >>>
> > >>>On Friday 06 January 2006 1:49 pm, Onestone
> >
> > wrote:
> > >>>>Assuming all fields are bytes try, and assuming
> > >>
> > >>you've collected the
> > >>
> > >>>>data using a pointer to a buffer you might try
> > >>
> > >>something like:_
> > >>
> > >>>> IF(0(R15) != '$' THEN END
> > >>>> ELSE
> > >>>> {
> > >>>> R14 = -2(R15) (R14
> > >>
> > >>MUST BE EVEN)
> > >>
> > >>>> PC += R14
> > >>>> JMP PARAM0
> > >>>> JMP PARAM2
> > >>>> JMP PARAM4
> > >>>> ...
> > >>>> }
> > >>>>
> > >>>>PARAM0:
> > >>>> MOV.B &VAR1 = -1(R15)
> > >>>> ...
> > >>>>
> > >>>>PARAM1:
> > >>>>
> > >>>> ETC
> > >>>>
> > >>>>This is simple to implement, simple to expand,
> >
> > and
> >
> > >>simple to understand.
> > >>
> > >>>>There are as many wasy to do this as there are
> > >>
> > >>ways to skin a cat.
> > >>
> > >>>>Cheers
> > >>>>
> > >>>>Al
> > >>>>
> > >>>>hc08jb8 wrote:
> > >>>>>Hello Guys
> > >>>>>
> > >>>>>
> > >>>>>I would like to implement a simple set of
> > >>
> > >>application level commands
> > >>
> > >>>>>that would invoke certain functions on the MSP
> > >>
> > >>via the UART. The PC
> > >>
> > >>>>>will send the command codes and read back data
> > >>
> > >>from the MSP. I would
> > >>
> > >>>>>like some help on the data transfer technique.
> > >>>>>
> > >>>>>I have got the communication going using
> > >>
> > >>interrupt mode, so detecting
> > >>
> > >>>>>a single char on the MSP is no issue, I am
> > >>
> > >>confused which would be
> > >>
> > >>>>>the best method for transfer of a fixed length
> > >>
> > >>string both ways.
> > >>
> > >>>>>For example in the following code, I am able to
> > >>
> > >>fill up rx_buff, but
> > >>
> > >>>>>I am lost on how to process it, i.e. if I send
> >
> > in
> >
> > >>a data from the PC
> > >>
> > >>>>>to the MSP like #d12$ where:-
> > >>>>># - start identifier
> > >>>>>d - parameter identifier
> > >>>>>12- parameter value
> > >>>>>$ - end identifer
> > >>>>>
> > >>>>>What I would like to be able to do is once I
> >
> > have
> >
> > >>recieved the
>
> === message truncated ==>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
