LPCXpresso IDEのトピックRe: How do the SPI driver bitfield macros work?

How do the SPI driver bitfield macros work?

lpcware — Wed, 15 Jun 2016 23:51:51 GMT

Content originally posted in LPCWare by justyn on Sat May 21 17:16:11 MST 2011
Hi all,

spi.h (and perhaps others) in the driver files (for the LPC111x at least) contains various macros like this:

#define SSPCR0_SCR (0x1<<8)

I'm perfectly familiar with using notation like the above to set individual bit flags.

But SCR isn't a single bit flag, it is an 8-bit value set in bits 15:8 of the CR0 register.

So since the macro resolves as 0x10 or 0b0000000100000000, how is it useful? Surely the macro needs to be 0xFF00, or perhaps:
#define SSPCR0_SCR(x) (x<<8)
or something like that?

What am I missing?

Re: How do the SPI driver bitfield macros work?

lpcware — Wed, 15 Jun 2016 23:51:52 GMT

Content originally posted in LPCWare by Ex-Zero on Sat May 21 17:34:04 MST 2011
That's a common way to define values in registers and not restricted to set single bits.

In this case Serial Clock Rate. So if I my SCR calculation results in 7, I define:

#define SSPCR0_SCR (0x7<<8)

and can assemble my CR0 with:

LPC_SSP0->CR0 = ... | SSPCR0_SCR;

Re: How do the SPI driver bitfield macros work?

lpcware — Wed, 15 Jun 2016 23:51:53 GMT

Content originally posted in LPCWare by Rob65 on Sat May 21 23:56:18 MST 2011
Hi Justyn,

I think you got that perfectly well.
You even suggest an alternate macro to be able to program the serial clock rate in our own programs:

Quote:
#define SSPCR0_SCR(x) (x<<8)

What I am concerned about is the fact that you name these files [B][I]driver files[/I][/B].
These files are called [I][B]example projects[/B][/I] by NXP and are in no way meant to be driver files that are of general use. The older versions of the example projects were simple: the ssp directory contained ssp.c and ssp.h and the program ssptest.c.
In the new version of the example projects the ssp.c and ssp.h files have just been moved to a common/driver directory which makes this less readable as an example (since now there is no SSP sample code in the SSP project, it's all 'hidden' in the common/driver project).

These files are, again, in no way ever meant to be used as general purpose drivers.
The documentation is a bit sparse:

LPCXpresso examples common files
================================
Welcome to the LPCXpresso examples common files project. This project
does not build. It is used together with the template project to
create other projects.

See template_readme.txt in the template project for a complete
explanation.

:eek:

So I have no clue what the [I]drivers[/I] do or what they don't do - how would this make these files usable in my own projects?
The next thing is that there are errors and funny things in the code telling me it was not properly tested or even reviewed. At one time I got a chearfull email from someone within NXP in San Jose telling me they were going to write a general driver library and he asked me if I'd be willing to review specifications, documentation and code.

I think you are using these [I]driver files[/I] exactly the way they should be: the code in one hand, the user manual in the other and intelligently look at it and change it to your own needs (use the force Luke)

I think it is hard to create general purpose drivers and for some components this may even be out of bounds: a general SPI driver which is able to be both master and slave may not be what you want (I mostly only act as a master). I2C slave/master is even worse: this will make your code grow.

Regards,

Rob

Re: How do the SPI driver bitfield macros work?

lpcware — Wed, 15 Jun 2016 23:51:54 GMT

Content originally posted in LPCWare by justyn on Sun May 22 09:31:10 MST 2011

Quote: Rob65
What I am concerned about is the fact that you name these files [B][I]driver files[/I][/B].
These files are called [I][B]example projects[/B][/I] by NXP and are in no way meant to be driver files that are of general use. The older versions of the example projects were simple: the ssp directory contained ssp.c and ssp.h and the program ssptest.c.
In the new version of the example projects the ssp.c and ssp.h files have just been moved to a common/driver directory which makes this less readable as an example (since now there is no SSP sample code in the SSP project, it's all 'hidden' in the common/driver project).

These files are, again, in no way ever meant to be used as general purpose drivers.

Ah OK, thank you, yes it is clear I was misunderstanding the purpose of these files.

Quote: Rob65
I think it is hard to create general purpose drivers and for some components this may even be out of bounds: a general SPI driver which is able to be both master and slave may not be what you want (I mostly only act as a master). I2C slave/master is even worse: this will make your code grow.

I understand what you're saying but I can't help feeling that with the use of #define and #ifdef statements we could create some more general purpose drivers for the peripherals that are no larger than custom or hand-modified code.
I think this would be fine for the initialization of the peripherals at least - actual data transfer and such is more likely to be dependent on how you're using interrupts etc.