CPC-CPLINK - a coprocessor interface card for all CPCs

[nicf82]

Hmm strange I was getting errors on all 3, but will check again with a clean start of everything

[nicf82]

OK, seems like that was it! I ran same configuration again, 1st 2 tests worked last one failed, then ran again without restarting the server and all 3 tests failed. So that must have been what happened last time, or something similar.


Am i right in assuming using the fifolib's fifo_out_byte function like this:


https://github.com/revaldinho/cpc-cplink/blob/master/sw/examples/loopback/cpc_cpct/fifo/src/main.c#L57


...then that will handle any checking of the status registers for me? I.e. I can just keep calling that method as fast as I like and it'll block until it has managed to put the byte on the FIFO? Just it does not appear to be checking anything in the code above before making the call.


Cheers!


Nic

[revaldinho]

Right, that all makes sense then. 


fifo_out_byte (data ) doesn't block - it returns 1 if a byte was successfully transmitted or 0 if the FIFO was not ready. In the loopback code example you pointed to , that call is in the middle of a loop and you can see that the data pointer 'i' is incremented only when a byte has been sent successfully otherwise a new attempt to send the byte will be made next time around the loop.


Here's the actual code for the routine from the library file


https://github.com/revaldinho/cpc-cplink/blob/master/sw/examples/loopback/cpc_cpct/fifo/src/fifolib.s

Code: [Select]

        ;; --------------------------------------------------------------
        ;; fifo_out_byte    (__z88dk_fastcall)
        ;; --------------------------------------------------------------
        ;;
        ;; Write a single byte and store it in the location pointed to by
        ;; a parameter.
        ;;
        ;; Entry
        ;; - L holds byte to be written
        ;;
        ;; Exit
        ;; - L =1 if successful, otherwise zero
        ;; - AF, BC corrupt
_fifo_out_byte::
        ld   bc, #0xfd81
        in   a,(c)              ; get dir status flag
        and  #0x2
        jr   z,fob_end          ; go to end if no data available
        dec c                   ; point to data reg
        out (c), l              ; write the byte
        ld   a, #0x1            ; success
fob_end:
        ld   l,a
        ret



Often you can use fifo_out_bytes(pointer, num_bytes) too - in a similar way this one returns the number of bytes written successfully(which may be 0) but again doesn't block. When sending lots of data this one is faster as it loops over the bytes in assembly language and does some loop unrolling to speed things up too.


If you want to check that a FIFO is ready for data to be written out then use fifo_get_dir() first. (And to check that the FIFO has data waiting to be read, you can check fifo_get_dor()). Alternatively just repeatedly call fifo_out_byte until it returns a 1.


If it's useful to have some blocking versions of these then I can easily add them to the library. It's only a code example really, but if it can be more generally useful that would be a good thing.

[nicf82]

I see what you mean, it's just going to keep trying until it sends the lot, and will only increment the counter to get the next byte when successful.


I can write a blocking version which checks fifo_get_dir first so that's no problem!


Im assuming if fifo_out_bytes returns anything less than num_bytes, its safe to continue next time at pointer+(the return value)


Cheers!


Nic

[revaldinho]

Im assuming if fifo_out_bytes returns anything less than num_bytes, its safe to continue next time at pointer+(the return value)

Yes, that's the thing to do.


I just checked in an updated fifolib now which gives you blocking versions anyway

Code: [Select]

byte = fifo_get_byte()
fifo_put_byte( byte )

+ an updated version of the test to check them.

[nicf82]

Wow thanks revaldinho that was a quick turnaround 

[revaldinho]

Make sure to get the very latest checkin - I pushed a typo in my first update. Fixed now. 


While I'm here and having just run the tests again, this is what I see with the Pi 3A+:


Test1 = send/receive the bytes checking status each time using fifo_in_byte/fifo_out_byte (non-blocking)
Test2 = send/receive the bytes checking status each time using fifo_get_byte/fifo_put_byte (blocking)
Test3 = send/receive multiple bytes checking status for each using fifo_in_bytes/fifo_out_bytes (non-blocking)
Test4 = send/receive bytes with no status checking on the CPC side - assumes the Pi can always keep up...


Pi (Python/WiringPi) + CPC (C/fifolib): Test 1 = 1.7s , Test 2 = 1.27s,  Test 3 = 0.51s, Test 4 = 0.15s (many errors)
Pi (C) + CPC ( C/fifolib): Test 1 = 1.7s, Test 2 = 1.07s, Test 3 = 0.32s, Test 4 = 0.15s (no errors)


... so note that the tests are renumbered now so that Tests 1 to 3 should always be error-free, and it's Test 4 which is the one relying on a fast Pi not preoccupied with other tasks to be able to keep up.


The CPC C loop for the blocking tests is simpler than the one for the non-blocking one which explains most of the improvement between Tests 1 and 2.