General header file question (bit access)...

Comments

12 comments

  • Avatar
    Wolfgang Hill

    Hi Kam,

    The problem with Bit Fields is that they are not always portable between platforms/compilers

    • integers may be signed or unsigned
    • Many compilers limit the maximum number of bits in the bit field to the size of an integer which may be either 16-bit or 32-bit varieties.
    • Some bit field members are stored left to right others are stored right to left in memory.
    • If bit fields too large, next bit field may be stored consecutively in memory (overlapping the boundary between memory locations) or in the next word of memory.

    For uP registers, the most important issue is clearly getting the left-to-right / right-to-left thing correct.

    I agree some of the names in 'stm32f10x.h' get a bit long, but they at least match well and consistently to the STM32 User Manual, so if you program with that open (like I do) you can have a pretty good stab at guessing them.

    We did make structures for the individual peripherals so we could write (for example):

       TIM1->CCMR1 |= 1 << TIM1_CCMR1_OUTPUT_COMPARE_MODE_OC1M_BIT;

    This is how ST's original STM32 Firmware Library did it too. And this will work nicely with code completion once Rowley get around to implementing it ;-)

    Hope that helps.

    Cheers,

    Wolf

    0
    Comment actions Permalink
  • Avatar
    Kam Bansal

    Hi Wolf,

    Thanks for the reply.

    I understand what you are saying; not sure I agree, but understand. The part that is REALLY frustrating is that the names of the "defines" somewhat match the reference manual, but not really. For example, there is a define called "SysTick_Reload_Value". I need to check the manual to get a better understanding of what are valid values etc., and I just cannot locate it! If in the defines you mentioned the REAL name of the field in a comment etc that would help.

     

    ~Kam (^8*

    0
    Comment actions Permalink
  • Avatar
    Wolfgang Hill

    Hi Kam,

    Of course if portability is not an issue for you, then by all means use bit-fields. We did use them in one instance in my last job. I'm just saying that's why a lot of people don't use them.

    The 'SysTick_Reload_Value' register is a Cortex-M3 core register - not a ST peripheral one. Rowley appear to have followed the naming convention in the ARM Cortex-M3 Technical Reference Manual for ARM-core registers. You may need both that AND the STM32 User Manual open.

    I agree it looks a bit ugly to have 2 different naming conventions in the one file (ARM's CamelCase style and ST's ALL_CAPS style), but at least they've tried to be somewhat consistent.

    Cheers,

    Wolf

     

     

    0
    Comment actions Permalink
  • Avatar
    Kam Bansal

    But I don't want to define the structs for the bit fields! Thats why I purchased Crossworks!

    Now to locate the "other" reference manual to locate the references!

    ~Kam (^8*

     

    0
    Comment actions Permalink
  • Avatar
    Wolfgang Hill

    I see your point. I too was a bit miffed at having to create my own headers after:

    a) purchasing CrossWorks

    b) downloading ST's firmware library (which I ended up just using as example code)

     

    Try here for the ARM doc:

       http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337e/DDI0337E_cortex_m3_r1p1_trm.pdf

    Google is your friend ;)

    Cheers,

    Wolf

     

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    I can assure you that we don't invent names for any of this stuff - we use the names provided in the documentation. The ARM CM3 documentation appears to have avoided naming registers - since this is the definitive document for the NVIC block we had to take a best guess. Hopefully the CMSIS work will mean that we don't have ship our own header files for CM devices however this stuff is changing from release to release and we have what we have.

    Regarding bitfields we don't use these because GCC can (and does) do byte/short access to byte/short aligned,byte/short sized bitfields - which may or may not work depending on the device.

    Regards

    Michael

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    If anybody has a positive view on what should be supplied, share it here.  We're quite able to shoot every single proposal down to show you why it won't work.  Does anybody really think that we haven't thought long and hard over this one ourselves?

    0
    Comment actions Permalink
  • Avatar
    Kam Bansal

    Come on everyone, simmer down...there is no issue here.

    ~Kam (^8*   <--- look, smiley face!

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    No, that's wrong.  There is a problem, but what there is not is a good, universal solution!

    0
    Comment actions Permalink
  • Avatar
    Wolfgang Hill

    I agree there is no good, universal solution. And don't get me wrong, I'm more than happy with Rowley's approach. You chose a convention, and you stuck to it and applied it consistently. That's all we can ask for.


    Our code actually uses 'stm32f10x.h' unmodified - straight from the CPU Support Package. That way we don't have to muck around with anything if it gets updated. We created our own version of the ST Firmware Library's 'stm32f10x_map.h' 'cos it suited our firmware implementation to do so. I.e. - not better, not worse, just right for our particular architecture and coding style.

    I fully understand why you didn't use bitfields. I think your approach is perfectly fine (and if I didn't we would still use your Memory Map xml's with some Python code and Cheetah templates to generate our own anyway).

    Keep up the good work :)

    Wolf

    0
    Comment actions Permalink
  • Avatar
    Tom Cwikla

    I'm just starting out with ARM & CrossWorks and I also find it surprising that there's no bitfield access to the peripherals since I've had this "luxury" on most other platforms in the past. Aside from portability it seems like the biggest hurdle is the fact that when using bitfields, gcc will do byte/short access on registers which can only be accessed as longs. I noticed that in June 2010 there was a new option added to gcc "-fstrict-volatile-bitfields" which supposedly changes this behavior. Is there any way to try this patch with CrossWorks?

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    You can download the sources of GCC which we used to build GCC, apply the patch, and see if you can rebuild.

    0
    Comment actions Permalink

Please sign in to leave a comment.