2008-11-18 17:27:27     DTYPE_NORM

2008-11-18 17:27:27     DTYPE_NORM

Michael McTernan (UNITED KINGDOM)

Message: 65456   

I'm building for a BF537-0.3 and setting up the SPORT using some macros:

#define DTYPE_NORM    0x0004    /* Data Format Normal */

#define DTYPE_ULAW    0x0008    /* Compand Using u-Law */

#define DTYPE_ALAW    0x000C    /* Compand Using A-Law */

Checking in the ADSP-BF537 Blackfin Processor HRM, Rev 3.1, September 2008, page 770, there is a TDTYPE field of 2 bits which takes the bit values:

00 - Normal operation

01 - Reserved

10 - Compand using μ-law

11 - Compand using A-law

These occupy bits 2 and 3 of the register so I'd have expected to see defines of 0x0, 0x4, 0x8 and 0xc i.e. 'normal' 0 rather than 4.

Similarly a couple of pages later the RDTYPE bits are given, and normal operation is again 0x0, while DTYPE_NORM is 0x4.

Grepping the code base the defines also change on different plaforms:

mach-bf533\defBF532.h(615): #define DTYPE_NORM    0x0000        /* Data Format Normal                            */

mach-bf533\defBF532.h(641): #define DTYPE_NORM    0x0000        /* no companding                            */

mach-bf537\defBF534.h(1333): #define DTYPE_NORM    0x0004    /* Data Format Normal                                                   */

mach-bf537\defBF534.h(1353): #define DTYPE_NORM    0x0004    /* Data Format Normal                                                   */

mach-bf527\defBF52x_base.h(1075): #define DTYPE_NORM    0x0004        /* Data Format Normal                            */

mach-bf527\defBF52x_base.h(1095): #define DTYPE_NORM    0x0004        /* Data Format Normal                            */

mach\defBF534.h(1333): #define DTYPE_NORM    0x0004    /* Data Format Normal                                                   */

mach\defBF534.h(1353): #define DTYPE_NORM    0x0004    /* Data Format Normal                                                   */

Is this a bug, should I be using some other define, or am I doing something silly?

QuoteReplyEditDelete

2008-11-18 17:37:30     Re: DTYPE_NORM

Mike Frysinger (UNITED STATES)

Message: 65457   

bit defines are a bit inconsistent.  some can be applied directly to the MMR while others expect to be bit shifted first.  usually the bit shifted ones also have a xxx_P type define indicating the number of bits to shift.

since the SPORT requires direct mucking about with the peripheral, feel free to declare your own set of register masks in your driver.

QuoteReplyEditDelete

2008-11-18 17:37:59     Re: DTYPE_NORM

Mike Frysinger (UNITED STATES)

Message: 65458   

ugh, no pun intended in that first sentence

QuoteReplyEditDelete

2008-11-18 17:42:31     Re: DTYPE_NORM

Michael McTernan (UNITED KINGDOM)

Message: 65459   

'bit inconsistend' :-D

Cool - I'll roll my own defines.  Would be good to either remove or fix these though - we got tripped by recompiling a module from BF533 to BF537 where the def changed...

Thanks again, Mike

QuoteReplyEditDelete

2008-11-18 18:06:03     Re: DTYPE_NORM

Mike Frysinger (UNITED STATES)

Message: 65460   

the header files are imported from VDSP at the moment with minimal changes.  their headers arent known for being "clean" by any means, but it was a lot faster than defining our own API methodology.  cleaning up the API is on the TODO, but it's minor at the moment.

probably will pick up steam when GDB gets the capability to parse XML files ...