Shop OBEX P1 Docs P2 Docs Learn Events
flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 120 — Parallax Forums

flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

1114115116117118120»

Comments

  • con
    
        rh_header_s(byte length, ...
                    byte dest, ...
                    byte src, ...
                    byte flags )
    
        control_s(  byte type, ...
                    byte class, ...
                    byte cmd )
    
        msgq_s( rh_header_s header, ...
                control_s   ctrl, ...
                byte        payload[32-4-3], ...
                byte        slot_in_use )
    
    
    obj
    
        ser:    "spin/SmartSerial"
    
    
    dat
    
        name    byte    "Testing testing 1 2 3", 0
    
    
    pub main() | msgq_s test1, b
    
        ser.startx(63, 62, 0, 2_000_000)
    
        test1.header.length :=  6+strsize(@name)
        test1.header.dest :=    $04
        test1.header.src :=     $01
        test1.header.flags :=   0
        test1.ctrl.type :=      8
        test1.ctrl.class :=     $de
        test1.ctrl.cmd :=       $ad
    
        ' fill payload array: method 1
        bytemove(@test1.payload, @name, strsize(@name) <# 25)
    
        ' fill payload array: method 2
    '    repeat b from 0 to strsize(@name)-1
    '        test1.payload[b] := byte[@name][b]
    
        ' hexdump of structure memory
        repeat b from 0 to 7+strsize(@name)-1
            ser.hex(byte[@test1+b], 2)
            ser.tx(" ")
    ' results in 1B 04 01 00 08 DE AD >20< 54 65 73 74 69 6E 67 20 74 65 73 74 69 6E 67 20 31 20 32 20 33
    ' the byte surrounded by > < is extra, and may change
    
    ' here's the code that _would_ appear afterwards:
    ' radio.tx_payload(@test1, 7+strsize(@name) ) ' this would just copy the data in the test1 structure to the packet radio's FIFO, to be transmitted
    

    Hi Eric, Ada,

    In the above snippet (distilled down from a project I'm working on that sends packets over wireless links using nRF24L01+ or other similar chips), I'm filling a structure with data (well, manually populating each member here, anyway) but am having an issue when sending this structure as a packet of data.
    In my original code I was sending the structure with a string copied to the payload array member, which mostly worked, but the last character of the payload was always getting cut off on the other end. Eventually I traced it to the transmitter, before it reached the radio. In memory, it looks like there's an unexpected gap between the ctrl.cmd member and the payload member array (shown in the above with the hexdump). It seems like this might be related to long-alignment, since the gap disappears if I add another member to the control_s structure. Can you confirm this is expected? If it is, do you have any advice on ways to write the closest equivalent of the above (pretending the last line with tx_payload() that's commented out actually does something)?

    Also, is a call to bytemove the recommended way to copy one structure to another right now? In this application, there's a function that queues messages to be sent by copying them into an available slot - it takes a pointer to a structure as the param, then copies it with bytemove to the queue. This seems to work fine.
    BTW this is with both P2 bytecode (Nu) and PASM2.

    Thanks!

  • ersmithersmith Posts: 6,025

    @avsa242 Unfortunately as it stands now structs are always padded out to longword boundaries. That means you'll get a byte inserted at the end of your control_s structure. I don't know if this is a conflict with PNut or not. Chip is still revising structures, so we'll have to see how that settles down.

    In the meantime, for transmissions or other things where the in-memory format has to match exactly you'll have to use arrays, or else manually transmit any shorter structs.

    For copying structures, I think the new COPY method is currently the way to do this, but again, the struct stuff seems still to be churning and this may get replaced by an operator. BYTEMOVE should always work though.

  • Gotcha, thanks!

  • I am having an issue adding libraries. Attempting to add the simpleide libraries because when I open up the examples I see
    that the icon for flexprop is there. Assumption that flexprop will run these. Am I missing something.
    Thanks in advance
    Martin

  • evanhevanh Posts: 15,620

    @pilot0315 said:
    I am having an issue adding libraries. Attempting to add the simpleide libraries because when I open up the examples I see that the icon for flexprop is there. Assumption that flexprop will run these. Am I missing something.

    Spin code is generally compatible. What problem is occurring?

  • evanhevanh Posts: 15,620

    Got a question myself ... I'm trying to use unsupported instructions, namely CALL, by handcrafting them. Anyone know a way to specify a PC relative offset in inline Pasm2, within FlexC?

    I currently have this:

            long    0x3db00000 | 9    // IF_NC CALL #crc_check
    

    but would like to replace the fixed 9 with a compiler calculated offset based on the crc_check label that is ten longwords later.

  • ersmithersmith Posts: 6,025

    @pilot0315 said:
    I am having an issue adding libraries. Attempting to add the simpleide libraries because when I open up the examples I see
    that the icon for flexprop is there. Assumption that flexprop will run these. Am I missing something.
    Thanks in advance
    Martin

    What do you mean by "adding libraries"? Flexprop doesn't really have anything for libraries, at least not like simpleide does, and it certainly won't be able to use the simpleide libraries.

  • ersmithersmith Posts: 6,025

    @evanh said:
    Got a question myself ... I'm trying to use unsupported instructions, namely CALL, by handcrafting them. Anyone know a way to specify a PC relative offset in inline Pasm2, within FlexC?

    I currently have this:

          long    0x3db00000 | 9    // IF_NC CALL #crc_check
    

    but would like to replace the fixed 9 with a compiler calculated offset based on the crc_check label that is ten longwords later.

    You can write CALL in inline assembly, the reason the documentation say it's "unsupported" is that trying to call functions outside of the inline assembly is undefined. But if you only call things within the same block I think it should work.

  • evanhevanh Posts: 15,620
    edited 2024-09-26 01:27

    Huh, typical, I never tried ...

    Yep, works just fine. :) I've hand coded the RET instruction, ie: long 0xfd64002d, because I know that would be replaced with a JMP if I used the RET mnemonic.

  • @ersmith

    Since there is not an actual list that I can find that tells me what is each of the files that are accessable under "include", I assume that they are libraries because they start with
    "lib" and I am having issues with the simpleide, I wanted to port over all of my code. First of all I am interested in the counters.
    Having opened up each of them I may have missed it.
    Is there a list of what is in each one so as to make it easier to navigate.?

    Thanks.
    Also I am getting used to your gui. Pretty good. I like it so far much easier to navigate.
    Thanks
    Martin

  • ersmithersmith Posts: 6,025

    @pilot0315 There's no need to do anything to add any of the "libraries" or include files under the "include" directory, all of those are automatically accessible by FlexProp. There isn't much documentation about the libraries, I'm afraid, other than what's available under the Help menu item. The BASIC language is the best documented; for Spin2 and C we rely more on Parallax's documentation.

  • @ersmith

    Sorry for the late reply.
    Thanks for the information.
    I found that SimpleIde does not give one any libraries that are full access to the counters in the P1. So I am
    attempting to write from scratch that access. Any suggestions would be appreciated.
    Is that possible with FlexProp?
    Thanks.
    Martin

  • evanhevanh Posts: 15,620
    edited 2024-10-02 11:13

    Access is not really a valid term when hitting the metal in a system that doesn't have memory protection. You just use it.
    The main doc for Prop1 counters is here - https://www.parallax.com/package/an001-propeller-p8x32a-counters/

    EDIT: They're pretty open ended in what they can be used for. Do you have a particular use case?
    I've written one program for the Prop1, it used the counters as DACs. Wiring was simple, as was the code. The Duty counter mode naturally produces PDM pulses on the pin it outputs to. PDM is ideal switching mode for an R-C filter.

  • ersmithersmith Posts: 6,025

    @pilot0315 said:
    I found that SimpleIde does not give one any libraries that are full access to the counters in the P1. So I am
    attempting to write from scratch that access. Any suggestions would be appreciated.
    Is that possible with FlexProp?

    As Evan said, the P1 counters are just registers (named _FRQA, _FRQB, _PHSA and _PHSB in FlexC, and aliased to FRQA, FRQB, PHSA, and PHSB in propeller1.h. There are some simpletools functions to manipulate them, e.g. pulse_in(), pulse_out(), rc_time().

    You could also look in the OBEX to see if there are objects that do what you want. Spin objects can be used directly from FlexC, so there's no need to port them (usually).

  • My Spin P1 programs work with the counters. Based on the tutorials in the P E Kit. Getting them to work in the PropIde C environment for some reason is a No Go.
    I will post the example soon.
    Do not understand why the examples y'all sent me are not working. Again I have tried in both gui's .
    I must be a dummy :D
    Got some family issues right now. Get back to y'all next week.
    Thanks
    Martin
    Maybe I will get lucky and stumble on the fix my self. B)

  • evanhevanh Posts: 15,620

    I assume the P E Kit is for Spin. You're probably a lot better off sticking with Spin. C isn't a particularly easy language to grok. And the build environments are arcane, even with the assistance of an IDE.

Sign In or Register to comment.