Is there a Spin equivalent of C structs?

Jeff Haas

I'm considering a wireless, Prop-to-Prop project and would like to pass a bunch of info, by sending one packet. I've got this going in 'duino C but the Prop has obvious advantages.

A search of previous forum discussions didn't seem to turn anything up. Ideas?

Heater.

Nope.

You can perhaps create your packets in arrays and define some constants that are the offsets of items within the array.

Dave Hein

Cspin handles structs in Spin by using offsets, and accessing elements with either BYTE[], WORD[] or LONG[] depending on the size of the element. Cspin translates the following C code

typedef struct TestS {
    struct TestS *next;
    char *name;
    int size;
    short value;
    char flags;
} TestT;

TestT x;

void sub1(void)
{
    int i;

    i = x.next;
    i = x.name;
    i = x.size;
    i = x.value;
    i = x.flags;
}

to this Spin code

CON
' typedef struct TestS
next_0 = 0
name = 4
size = 8
value = 12
flags = 14


VAR
  long x[4]

PUB sub1 | i
  i := long[@x + next_0]
  i := long[@x + name]
  i := long[@x + size]
  i := ~~word[@x + value]
  i := byte[@x + flags]

macca

Jeff Haas wrote: »

I'm considering a wireless, Prop-to-Prop project and would like to pass a bunch of info, by sending one packet. I've got this going in 'duino C but the Prop has obvious advantages.

A search of previous forum discussions didn't seem to turn anything up. Ideas?

If you have the code in C already, why don't you try to port it to PropellerGCC ?

Duane Degn

I think the way large sections of data are used in Spin is to pass the address of the data.
Dave Hein's post shows a good example.

Parallax put out an appnote on this topic. Here's a link to the document and sample code.

idbruce

Duane

Thanks for the appnote link.

JonnyMac

I recently finished a commercial project that uses XBee in API1 mode with fixed-length packets. I created a template packet in a DAT table and a couple support methods to handle placing the data in it, updating the checksum, and pushing out the serial port. Easy-peasy.

Tracy Allen

I'm with Jon on this one. Here is an example structure. In this case it needed to transmit payloads of 100 bytes in API mode for 802.15.4 xbees. The structure includes the $7e for the start of the packet and is initialized with various configuration options. Some advantages to having it in DAT are that you can initialize the data at compile time, and you have good control over the arrangement of bytes, words and longs. The application fills in the payload over time, and the xbee transmissions boil down to sending the 105 byte string starting at "hey". In this case, the structure was written into the main program, but in other use cases I've had it written into a separate object with methods to set and get the contents.

' The following structure should be word aligned.
  hey         byte $7e                                  ' start for packet
  length1     byte 0                                    ' MSB of the length
  length0     byte 105                                  ' packet length is 100 plus 5 starting with the byte after this one
  apiTXid     byte $01                                  ' API transmission identifier
  frameID     byte 1
  dest1       byte $ff                                    ' destination short address msb
  dest0       byte $ff                                    ' destination short address lsb
  options     byte $4                                   '

  fwv         byte VERSION
  startTime   byte 0,0,0,0,0                            ' mhdmy
  stopTime    byte 0,0,0,0                              ' mhdmy
  giraDayCode byte 36                                   ' code for length of giraDay in minutes (code 36=1440 minutes)
  giraWeek    byte 7                                   '  Gira interval (week) setting in number of giradays
  weekCount   byte 0                                   ' number of giraWeeks logged so far during this deployment
  C_thresh    byte 50                                  ' temperature threshold in units of 0.1 degreec C
  P_thresh    byte 15                                   ' percent of samples above temperature threshold that qualify as used for day
  volts       byte 0                                    '  battery condition, units of 0.1V
  deltaC      byte 0                                    ' temperature differential
  maxC        byte 0                                    ' maximum delta T during this deployment, resolution of 0.5.
  percent     byte 0                                    ' percent of samples above threshold total during this deployment
  days        byte 0                                    ' total days above percent threshold during this deployment

  pcnt1       byte 0                                    ' percent of samples above temperature threshold in the interval
  days1       byte 0                                    ' days used, counts as used if percent of samples is above pcnth
  degday1     word 0                                    ' degree days for the interval.
  '   ... and so on, 100 payload bytes  

Jeff Haas

Wow, thanks for all the information! This forum is a great resource.