Jump to content
Sign in to follow this  
trossin

Plugin Api Question About Internal Control Registers

Recommended Posts

Is it possible to get a call back or monitor internal control register writes and is it possible to deposit values into status registers?

 

For example, it seems that the SPI machine is not emulated in the simulator so it would be nice to be able to have a plugin monitor writes to the SPI register and be able to drive values back into the SPI read register and status to be able to emulate an SD card attached to a PIC.

 

Since plugins get to look at what is going on every clock cycle it seems that if the plugin had access, it could emulate any hardware that might be missing from the simulator or at least emulate the hardware at a high level. I'm just not sure if the internal state of the simulator is exposed to the plugin API.

Share this post


Link to post
Share on other sites

Yes it is possible. Plugin API lets plugin code access registers and check and modify their values (all these are described in the Plugin System document):

 

Get register handle:

void GetRegHandle( char* name, HANDLE* hReg )

 

Read/write register:

void GetRegVal( HANDLE hReg, int* val )

void SetRegVal( HANDLE hReg, int val )

 

Register/unregister register change callback:

void AddRegChangeCallBack( HANDLE hReg, REGCHGCALLBACK pfunc, void* pParam, int iParam )

void RemoveRegChangeCallBack ( HANDLE hReg, REGCHGCALLBACK pfunc, void* pParam, int iParam )

 

where the callback signature is:

typedef void (*REGCHGCALLBACK)( HANDLE hReg, void* pParam, int iParam );

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

I finally got busy and started working on an SD card plugin using the above technique with call backs but ran into a couple problems. The SPI port writes and reads throught the same register spdbuf. So in my plug in if I read a command from spdbuf when it changes then write the result back to spdbuf, I get another call back for what I wrote. No big deal, I just ignore every other call back. There is an exception here which is my 2nd problem:

 

The big problem is that if my PIC code writes the same value twice, the call back is not called on the second write. So say I'm trying to write a sector worth of 0xff to the card and the card will return 0xff until the write is complete. Each write to the spdbuf will get a return value of 0xff but the call back will only be called once for the 512 writes so my plug in will not know that the PIC code did 512 writes and hang up. Polling the register every clock tick does not help either as the register did not change.

 

Is there a way to register a call back which is called every time a register is written? If not, I don't see a way to make this plug in work.

 

Thanks for any help.

Share this post


Link to post
Share on other sites

trossin,

Is there a way to register a call back which is called every time a register is written? If not, I don't see a way to make this plug in work. Thanks for any help.

I understand your problem. The interface only exposes register changes (this was done for efficiency) which is a real shame as you always seem to be doing such interesting things.

 

Internally the simulator does have this functionality, such that hooks into register writes and register reads are available, and it is used by the simulated peripherals to enable them to respond to just the sort of events you describe. Also there are functions to allow reading and writing of registers without triggering read and write events. To get exposure of this functionality would require changes to IDE, debugger and simulator. So its not a couple of key presses away.

 

So at the moment your project can't be completed.

We need to take a more detailed look at things to decide if we want expand the interface and will let you know when we have made that decision.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Hi

 

Trossin, maybe you can use the SFRs to get to where you want.

This is a bit generic, but I don't have time to dig it by myself.

Most peripherals have status flags associated with them that expose all the operations.

If you have a callback handle for changes on the interesting SFRs, maybe you could pinpoint the reads and writes to the comunications buffer.

 

Just an idea....

 

Best regards

Jorge

Share this post


Link to post
Share on other sites

Thanks for the responses. The status flags do not exist Jorge since the SPI is not modeled in the simulator. This is the reason that I'm looking at the register writes directly so that I can model the SPI.

 

I understand that it would be a large change Dave so I will just modify my PIC code to toggle a free port bit or some other unused register when doing spdbuf writes so that the plug in can trigger on the write. I can just ifdef this code in and out based on the build type (debug or release) or just a #define at the top of the file.

 

Again thanks for looking into this. Having the plugin API is really a great feature of your tools.

Share this post


Link to post
Share on other sites

So I just modified my SpiWrite and SpiRead functions to wiggle a bit after changing sspbuf and then made my plug in get a callback when sspcon1 changed. This allows me to create the SDCard plugin with just a little change to my SourceBoost PIC code. I have a ways to go but I'm interpreting commands and returning responses while getting the emulated SDcard out of the init state.

 

unsigned char SpiWrite(unsigned char DataOut)

{

sspbuf = DataOut;

#ifdef SDCARD_PLUGIN_MODE

sspcon1 += 0x80; // Trigger callback to look at sspbuf

#endif

while(!sspstat.BF);

return(sspbuf);

}

unsigned char SpiRead(void)

{

sspbuf = 0xff;

#ifdef SDCARD_PLUGIN_MODE

sspcon1 += 0x80; // Trigger callback to look at sspbuf

#endif

while(!sspstat.BF);

return(sspbuf);

}

Edited by trossin

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...