Incorrect byte order for multibyte DIN packets

[ozzyrob]

As a continuation of yesterdays issue with loading the rio component I was having issues with the byte order being incorrect. As I thought, although I haven't tested yet as this issue has taken up alot of time, should the bracket fix for the DINs be applied to the DOUTs as well, both when creating the pins and in the read\write update. The following mod I've only applied to the rio.c file in my output folder on my local machine. My source is a too little messy ATM for a pull request.

                // Inputs
                int di = DIGITAL_INPUT_BYTES;                   
                                                                // di points to dest
                                                                // bi points to source
                                                                // bi start > di end
                                                                // bi end > di start
                                                                // Without if there is 2 or more bytes for our inputs
                                                                // the DIN bytes are not in the correct order
                                                                // The bit order for each byte is ok
                                                                // Maybe changing bi to src_index and di to dest_index might make to code     
                                                               // easier to read.

                for (bi = 0; bi < DIGITAL_INPUT_BYTES; bi++)  

                    {
                    di--;
//                   printf("Byte %d Data %d\n", bi, rxData.inputs[bi]);
                    for (i = 0; i < 8; i++) {
                        if ((rxData.inputs[bi] & (1 << i)) != 0) {
                            *(data->inputs[(di * 8 + i) * 2]) = 1;      // input is high
                            *(data->inputs[(di * 8 + i) * 2 + 1]) = 0;  // not
                        }
                        else {
                            *(data->inputs[(di * 8 + i) * 2]) = 0;          // input is low
                            *(data->inputs[(di * 8 + i) * 2 + 1]) = 1;  // not
                        }
                    }

                }

I hope you can understand this, it drove me nuts. I wonder to if this should apply to the Digital out section as well.

[multigcs]

I think the bracket issue is not in the dout part because there are no '-not' pin name's

i'm in the office now, i will check the digital io's later at home

[ozzyrob]

Just checked you are correct about the dout.

Just cleaned up my local and pushed to my repo.

[multigcs]

ok, i see the problem, grrrrr, brainf*** :p

assign tx_data = {
    header_tx[7:0], header_tx[15:8], header_tx[23:16], header_tx[31:24],
    jointFeedback0[7:0], jointFeedback0[15:8], jointFeedback0[23:16], jointFeedback0[31:24],
    jointFeedback1[7:0], jointFeedback1[15:8], jointFeedback1[23:16], jointFeedback1[31:24],
    jointFeedback2[7:0], jointFeedback2[15:8], jointFeedback2[23:16], jointFeedback2[31:24],
    jointFeedback3[7:0], jointFeedback3[15:8], jointFeedback3[23:16], jointFeedback3[31:24],
    jointFeedback4[7:0], jointFeedback4[15:8], jointFeedback4[23:16], jointFeedback4[31:24],
    processVariable0[7:0], processVariable0[15:8], processVariable0[23:16], processVariable0[31:24],
    DIN15, DIN14, DIN13, DIN12, DIN11, DIN10, DIN9, DIN8, DIN7, DIN6, DIN5, DIN4, DIN3, DIN2, DIN1, DIN0
};

first i have to reorder the DIN's in verilog

[multigcs]

ok, hope i have fix it now , please can you test it ?

[ozzyrob]

Fantastic, works like a charm. Tested with 17 inputs, ie: 3 packets.

Python is a bit exotic to me. Tho I should learn. Just got my Olimex ICE40HK8X-EVB, as I want to keep the Lattice board for future experiments, so that will be the weekends' project. Still waiting on the Eth to Spi board.

[kzali]

Not related to this topic but, I was wondering if LiteEth can be used instead of an an Eth to Spi board.

[ozzyrob]

Doesn't LiteEth require a soft core ?

[kzali]

I am too new to FPGA's and the litex tools. I looked at the liteeth repository but could not determine, whether Its uses a soft core.
Hey Rob I am also in the Sydney area!

[multigcs]

my verilog knowledge is rather limited, so I wanted to keep this part as simple as possible.

lite eth probably uses a softcore for the ethernet.

but i think it's ok to use a MCU in this place and the spi interface keeps the delay quite low.

if someone can do the ethernet without softcore i would be happy about pullrequests :)