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 ...