Shift << not working for me

Rsadeika · 2013-11-03 08:07

Been working on this all morning, and I am not getting any closer to a correct solution. Basically this code segment is receiving a string value of "4\n" which somehow ends up being 32704, I am doing a shift << 4 to get the value back to 4, but the shift process keeps yielding 0. What am I missing here?

Thanks
Ray

if(!strcmp(inBuff,"gofore"))
        {
          print("%s",inBuff); // debug check value = gofore
          writeStr(xbee,"#"); // signal to send next value
          pause(50);
          readStr(xbee,inBuff,40); // incoming value is "4\n"
          int b = atoi(inBuff);  // inBuff is 32704
          int d = b << 4;  // Why isn't this shifting
          print(d);    // debug check value of d = 0, expecting 4
          //drive_goto(d*8,d*8);
          writeStr(xbee,"#"); // send control value
        }

jazzed · 2013-11-03 08:36

Don't be confused with Python print() which doesn't need a format specifier.

Rsadeika · 2013-11-03 08:45

The print "print("%s",inBuff)" that I am using in the code segment is to track, on the SimpleIDE screen, the values that I am getting to the Propeller. So, at one point the PropGCC program gets 32704, which I try to shift <<, and I do not get the expected result.

Ray

mmowen · 2013-11-03 08:55

b<<4 is equivalent to an unsigned multiply by 16.. no?
presuming you are using 32 bit int...
to strip off the low order 16 bits you may want to use b>>16 instead, no?

jazzed · 2013-11-03 08:59

Rsadeika wrote: »

The print "print("%s",inBuff)" that I am using in the code segment is to track, on the SimpleIDE screen, the values that I am getting to the Propeller. So, at one point the PropGCC program gets 32704, which I try to shift <<, and I do not get the expected result.

Ray

Sorry Ray,

All I saw in your listing for printing the result of your shift is this which won't work:

print(d); // debug check value of d = 0, expecting 4

Rsadeika · 2013-11-03 09:03

I tried, for SimpleIDE terminal, print("%d",d), which was also showing 0.

Ray

jazzed · 2013-11-03 09:11

/**
 * This is the main program file.
 */
#include "simpletools.h"


int main(void)
{
  char* inBuff = "32704";
  print("%s\n",inBuff); // debug check value = gofore
  int b = atoi(inBuff);  // inBuff is 32704
  print("%d\n", b); 
  int d = b << 4; 
  print("%d\n", d); 
  return 0;
}

Output:

32704
32704
523264

Rsadeika · 2013-11-03 09:26

Now I am baffled, not sure what is going on. It looks like when you pass "32704" through, the shift to the left is not what I need. The 32704 number is what the PropGCC program is receiving as the conversion of "4\n", a number 4 with a following '\n'.

I just tried the suggestion of b >> 16, and when I have 'print("%d\n", d)', that comes up as 0. Do I have to turn something on in SimpleIDE?

Ray

jazzed · 2013-11-03 09:33

/**
 * This is the main program file.
 */
#include "simpletools.h"

int main(void)
{
  char inBuff[40];
  readStr(simpleterm_pointer(),inBuff,40); // incoming value is "4\n" ... replaced xbee with simpleterm serial pointer
  print("%s\n",inBuff);
  int b = atoi(inBuff); 
  print("%d\n", b);    // debug check value of b = 4
  int d = b << 4;  // shifts fine
  print("%d\n", d);    // debug check value of d = 64
  return 0;
}

Output:

Rsadeika · 2013-11-03 09:47

Maybe I should rephrase the question to: when I have, incoming value is "4\n", how do I get it to be 4 decimal form so when it is applied to //drive_goto(d*8,d*8); it should work as expected? Maybe the shifting thing was the wrong way to approach the problem??

Ray

jazzed · 2013-11-03 10:03

Rsadeika wrote: »

Maybe I should rephrase the question to: when I have, incoming value is "4\n", how do I get it to be 4 decimal form so when it is applied to //drive_goto(d*8,d*8); it should work as expected? Maybe the shifting thing was the wrong way to approach the problem??

Ray

Ok,

I think we have established clearly that readStr(), atoi(), and shif in the examples I posted are doing the right thing.

The d prior to drive_goto(d*8, d*8) will be 64 according to the example. If you remove the shift, then d will be 4.

SRLM · 2013-11-03 10:58

Rsadeika wrote: »

Maybe I should rephrase the question to: when I have, incoming value is "4\n", how do I get it to be 4 decimal form so when it is applied to //drive_goto(d*8,d*8); it should work as expected? Maybe the shifting thing was the wrong way to approach the problem??

Ray

It sounds like the question that you're really asking is how to convert the string representation of a number to the binary (int) representation?

http://www.cplusplus.com/reference/cstdlib/atoi/

Rsadeika · 2013-11-03 11:57

I think my programming logic is all screwed up! When my interpreter was dealing with strictly string values like "gofore" everything was working as expected, now that I put in a number, like 4, everything falls apart. Because I have to use readStr(), this forces me to use '\n', in order to make readStr() work correctly, and now I am not sure what value is in the buffer, if there even is a value there. I guess I have to come up with a new strategy of some sort. My brain is going to explode.

Ray

jazzed · 2013-11-03 12:28

Rsadeika wrote: »

I think my programming logic is all screwed up! When my interpreter was dealing with strictly string values like "gofore" everything was working as expected, now that I put in a number, like 4, everything falls apart. Because I have to use readStr(), this forces me to use '\n', in order to make readStr() work correctly, and now I am not sure what value is in the buffer, if there even is a value there. I guess I have to come up with a new strategy of some sort. My brain is going to explode.

Ray

I think you have some other issue. The readStr() \n will not show up in the buffer. My examples show that.

Rsadeika · 2013-11-03 12:55

Down to the basics, on the Python side, where it is reading a text file that contains strings like "gofore" , I have to use "ser.write(bytearray(line,'ascii'))" to get it excepted by PySerial for sending. For a string like "gofore" it comes out on the propeller end as "gofore", so I am wondering what some number like 4 looks like after it has gone through the "ser.write(bytearray(line,'ascii'))" conversion? Is there something on the PropGCC side that can read it or convert it to the original 4?

Ray

Rsadeika · 2013-11-03 13:35

Just when I was about to give up...
Looking at the Python code again I noticed this:

		ser.write(bytearray(line,'ascii'))
		ser.write(b"\n")

I was thinking that it was not getting the necessary '\n', but I guess I was wrong. Once I removed that line, now the interpreter seems to be working.

if(!strcmp(inBuff,"gofore"))
        {
          print("%s\n",inBuff); // debug check value = gofore
          writeStr(xbee,"#"); // signal to send next value
          pause(100);          
          readStr(xbee,inDuff,10); // incoming ascii value is "4"
          pause(100);
          print("%s\n",inDuff);  // 4
          int d = atoi(inDuff);  // convert to an integer        
          drive_goto(d*8,d*8);  // approximate conversion to one inch, have to figure out how to match it to one inch
          writeStr(xbee,"#"); // send control value
        }

I guess this brainstorming session really works for me, a lot of Thanks to everybody. Now I should have a very crude PropGCC interpreter to work with the PyGUI program ready, in a relatively short time.

Ray

jazzed · 2013-11-04 13:31

Hi Ray,

I think it really helps to break a problem down into small functional units when looking for bugs. Such "unit testing" is valuable for scripted like Python as well as compiled languages like C (i.e., syntax checking). Functional problems are harder to find than syntax issues of course.

One thing you can do if you're not sure about what a serial port is doing is to make a "loopback" .... That is have the target processor echo back whatever is being received in quotes back to your program so you can tell what's happening. Using quotes will make it obvious whether or not a newline is being received. This is just for testing of course.

Shift << not working for me

Comments