Shop OBEX P1 Docs P2 Docs Learn Events
Fastest way to disect byte into 2 parts? — Parallax Forums

Fastest way to disect byte into 2 parts?

T ChapT Chap Posts: 4,223
edited 2010-08-25 10:22 in Propeller 1
I have a PCF8574 that reads some inputs from two other devices, 4 bits per device. The main program loop needs to examine each of the two devices separately and ignore the output of the other device. What is the fastest way to evaluate the two halves using Spin?

Will using longs as temp holders be faster than bytes?

Here is my idea so far.
PUB main
   Repeat
     Readinputs

PUB Readinputs
      ReadVariable :=  ReadTheI2CBus     'ReadTheI2CBus returns byte with 8 inputs
      DeviceA :=   ReadVariable << 4  'work with the higher 4 bits for DevA
      DeviceB :=   ReadVariable >> 4  'work with  the lower 4 bits for DevB

or
PUB Readinputs
      ReadVariable :=  ReadTheI2CBus     'ReadTheI2CBus returns byte with 8 inputs
      DeviceA :=   ReadVariable & %00001111 
      DeviceB :=   ReadVariable & %11110000   


There are other things in the main loop, so the faster this works the better.

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2010-08-25 10:16
    First of all, ReadTheI2CBus probably takes far longer to process than any extraction statements for the 4-bit values. If time is of the essence, you may want to rewrite ReadTheI2CBus so it stores the two 4-bit values separately rather than returning them as a single 8-bit value. There may be other speedups possible in that routine as well. If speed is really that critical, you may want to use a separate cog for the I2C communications so you're reading the next set of values while you're processing the current set.

    I'd stick to something like:

    DeviceA := DeviceB := ReadTheI2CBus
    DeviceA &= %00001111
    DeviceB >>= 4

    DeviceA and DeviceB could be bytes or longs. It doesn't really matter from a speed perspective.

    When optimizing a program for speed, you never start with an optimized version because you don't know ahead of time where the bottlenecks are. You have to get the program working correctly first, then instrument it to find out where the delays are. They're often not where you think they are. The general rule is that programs spend > 90% of their time in < 10% of the code.
  • T ChapT Chap Posts: 4,223
    edited 2010-08-25 10:22
    OK, thanks Mike, good idea.
Sign In or Register to comment.