@evanh said:
PPS: Regarding those block read/write routines, they partly depend on registers being loaded along with the code. If Fcache is shifted to LUTRAM you'd have to move such data into locals instead.
Yeah I know all about it, that's the tricky part. But we have 32 registers to play with and there are only up to 9 parameters I think. We can get them into C register variables using high level assignments from the source structure.
Also I've been making this multi-instance so your globals are no longer present. Even though I am only exposing the SD mode driver host interface as a single slot initially, I see no reason to fix it to just one interface.
I don't think there is any true globals in that Flex driver. Things like the pin numbers are contained to the instance by FlexC's C++ struct __using() wrapper. Only a DAT section would be global.
Also, in case you missed my previous edit, those register constants could, instead of creating locals, be placed in with the presets that are fast copied into the RES section.
Comments
Yeah I know all about it, that's the tricky part. But we have 32 registers to play with and there are only up to 9 parameters I think. We can get them into C register variables using high level assignments from the source structure.
Also I've been making this multi-instance so your globals are no longer present. Even though I am only exposing the SD mode driver host interface as a single slot initially, I see no reason to fix it to just one interface.
I don't think there is any true globals in that Flex driver. Things like the pin numbers are contained to the instance by FlexC's C++
struct __using()wrapper. Only a DAT section would be global.Also, in case you missed my previous edit, those register constants could, instead of creating locals, be placed in with the presets that are fast copied into the RES section.