USB callback

I’ve just discovered _kernel_current_stack_chunk() in kernel.h and thought of a way of implementing callbacks without using assembler.

So I have 2 schemes shown below. cb_construct would be how you set up the callback in your module and cb_call is called from the usb module when transfer is complete.

I was wondering if anyone has a preference I keep flip flopping between the 2.

SchemeA has no assembler so may be better for future maintainability but it’s slightly more complicated to set up.

SchemeB I suppose is a more traditional way of doing things but needs veneers from CMHG

Any thoughts?

SchemeA

typedef struct
{
        int magic0;
        int magic1;
        void* (*callback)(void*);
}cb_t;

void cb_construct(cb_t* cb, void* (*cbfn)(void*))
{
        int* magic = (void*)(_kernel_current_stack_chunk()+1);
        cb->magic0 = magic[0];
        cb->magic1 = magic[1];
        cb->callback = cbfn;
}

void* cb_call(cb_t* cb, void* p)
{
        int* magic = (void*)(_kernel_current_stack_chunk()+1);
        int magic0 = magic[0];
        int magic1 = magic[1];
        magic[0] = cb->magic0;
        magic[1] = cb->magic1;
        
       p = cb->callback(p);
        
        magic[0] = magic0;
        magic[1] = magic1;
        return p;
}

SchemeB

typedef struct
{
        void*  private_word;
        void  (*callback)(void);
}cb_t;

static void* private_word;

/* cbfn is a generic-veneer function created by CMHG */
void cb_construct(cb_t* cb, void (*cbfn)(void))
{
        cb->private_word = private_word;
        cb->callback = cbfn;
}

void* cb_call(cb_t* cb, void* p)
{
        __asm
        {
                mov r12, cb->private_word
                mov r0, p
                blx cb->callback, {r0,r12}, {r0}, {LR,PSR}
                mov p, r0
        }
        
        return p;
}

I’d say scheme B is better – scheme A is too tied down to the SCL stack format and would run into lots of compatibility issues if the stack format was changed in future or if you had to support non-SCL code (e.g. GCC with UnixLib).

Ok seems sensible except a variation of schemeA is required to write USB controller modules already.

Ok seems sensible except a variation of schemeA is required to write USB controller modules already.

Yeah, I’m not quite sure why the controller modules are set up that way. AFAIK there’s nothing stopping them from using generic veneers.

Actually – the USB modules are more akin to scheme B, not scheme A. With scheme A it’s the caller’s responsibility to set up the magic words on the stack ready for the target, while with scheme B (CMHG/USB) it’s the target’s responsibility to set everything up for himself.