Cancatenate Strings & Numbers OBJ

Chicago Mike · 2007-12-01 19:03

I'm opening a can of worms I think. I found a few weird thread on this, but it went no-where. What I'm trying to do in the following method is take 2 decimal numbers from another part of the program. Convert them to a padded ascii form using the numbers object. This works.... From there I am trying to concatenate them into one string to send to a device via a serial routine. Below is the very simple code. Running the below, this is what happens. Say I pass channel_dec with 354, and level_dec with 201. The result in trstring when I print it will be ONLY 201. However if I comment out the ascii:=numbers.toStr(level_dec,%000_000_000_0_0_000100_01010), I will get the 354. It seems its acting as last takes precedence. The numbers routine works great. The channel_dec conversion is to be no longer than 5 characters after conversion, and the level_dec is to be no longer than 3. (Extra space to the left is to be padded... Numbers does this well). Doing these separately yields the correct ASCII representations. All I'm trying to do is add to strings together after the conversion which seems to leave me with the last value ONLY.

Incidentally, the numbers OBJ seems a bit strange with padding.... to get a width of say 5 characters the F field needs to be %000110... Shouldn't it really be %000101??? I couldn't find any documentation pertaining to an offset of +1. Anyway. Though I wouldn't mention it, though as I said, the conversion seems to work just fine.

Below is the code.

OBJ
  numbers          : "Numbers"   

VAR
  long trstring[noparse][[/noparse]9]

Pri send_rf_level(channel_dec,level_dec) : response | ascii, index 
    ascii:=numbers.toStr(channel_dec,%000_000_000_0_0_000110_01010)
    repeat index from 0 to 4      
      trstring[noparse][[/noparse]index]:=ascii[noparse][[/noparse]index]
    ascii:=numbers.toStr(level_dec,%000_000_000_0_0_000100_01010)
    repeat index from 0 to 2      
      trstring[noparse][[/noparse]index+5]:=ascii[noparse][[/noparse]index]
    lcd.str(trstring)

Post Edited (Chicago Mike) : 12/1/2007 7:24:01 PM GMT

Phil Pilgrim (PhiPi) · 2007-12-01 19:07

Mike,

If you enclose your code in [noparse][[/noparse]code] [noparse][[/noparse]/code] tags, it will be much more readable, and indenting will be preserved.

-Phil

Mike Green · 2007-12-01 19:09

If you have two zero terminated strings, you can concatenate them easily (assuming the result array is of adequate size):

bytemove(@dest+strsize(@dest),@source,strsize(@source)+1)

The +1 makes sure the zero termination byte is copied.

Post Edited (Mike Green) : 12/1/2007 7:25:47 PM GMT

Chicago Mike · 2007-12-01 20:09

I gave the byte move a try, and that deos effectively do the same thing. I really thought that it had nothing to do with the numbers object, however I did the following. Effectively remoted the second addition to the trstring array, and I still got ONLY the second variable on the display. If I comment out the second use of the numbers routine, I get the ascii version of channel_dec. The numbers OBJ seems to be related to this.. hummm..

OBJ
  numbers          : "Numbers"   

VAR
  long trstring[noparse][[/noparse]9]

Pri send_rf_level(channel_dec,level_dec) : response | ascii, index 
    ascii:=numbers.toStr(channel_dec,%000_000_000_0_0_000110_01010)
    repeat index from 0 to 4      
      trstring[noparse][[/noparse]index]:=ascii[noparse][[/noparse]index]
    ascii:=numbers.toStr(level_dec,%000_000_000_0_0_000100_01010)
'    repeat index from 0 to 2      
'      trstring[noparse][[/noparse]index+5]:=ascii[noparse][[/noparse]index]
    lcd.str(trstring)

Post Edited (Chicago Mike) : 12/1/2007 8:17:04 PM GMT

Mike Green · 2007-12-01 20:14

Try this:

   ascii := numbers.toStr(...)
   bytemove(@trstring,ascii,strsize(ascii)+1)
   ascii := numbers.toStr( ..... )
   bytemove(@trstring+strsize(@trstring),ascii,strsize(ascii)+1)
   lcd.str(@trstring)

Chicago Mike · 2007-12-01 20:41

Thank you so much Mike!

It seems pointers got me again! I was passing my value not reference to the lcd. I have gone over and used the bytemove method. It took me a minute to get at what your doing, but its a very easy method.

One question though. The numbers Object returns the array address of the first LONG of the string as variable ascii. I am using the byte move, and changed my VAR to BYTE trstring[noparse][[/noparse]9] instead of long. How is this working (and it obviously is), with 4 bytes in a long? My understanding. Does byte move only look at the first byte of each long, and love that corresponding byte to the new location?

To explain a different way if I had a longs of

ascii[noparse][[/noparse]0]=11111111 010101010 00000000 10101010
ascii=11111111 010101010 10001001 11101010

and I performed a byte move such as
bytemove(@trstring,ascii,1)

would I get 10101010 in @trsstring?

now if I did a
bytemove(@trstring,ascii,2)

would I get 10101010 followed by 11101010
or would I get 10101010 followed by 00000000

From my understanding of the logic of the code you wrote above it would be the first? Just trying to be clear on my understanding of this.

Thanks again!

Mike Green · 2007-12-01 21:05

The toStr method of the numbers object returns the ADDRESS of the first byte of the result string, not the string itself. There's actually a buffer declared in the numbers object where the string is placed and toStr returns the address of that buffer. Note that the buffer will get changed the next time you call toStr or any other routine in the object that uses the buffer.

Addresses in Spin are byte addresses. Hub/main memory is organized in bytes. Words are just pairs of bytes starting at an even address and longs are just groups of 4 bytes starting at addresses that are multiples of 4. The Propeller processor can access individual bytes, words, and longs depending on the instruction used.

Chicago Mike · 2007-12-01 22:26

Thank you so much! I get it!

Cancatenate Strings & Numbers OBJ

Comments