Code completion and STM32 peripheral registers

[1essor1]

Hello!

The problem is I want to registers name being autocompleted like normal fields of a struct.
For example, I write GPIOA, then -> and bang - there should be list of GPIOA regs like MODER, OTYPER and other displayed, but nothing happens.



Registers i want access are just memory regions and GPIOA is structure describing them :

Code

typedef struct
{
  __IO uint32_t MODER;        /*!< GPIO port mode register,                                  Address offset: 0x00 */
  __IO uint16_t OTYPER;       /*!< GPIO port output type register,                           Address offset: 0x04 */
  uint16_t RESERVED0;         /*!< Reserved,                                                                 0x06 */
  __IO uint32_t OSPEEDR;      /*!< GPIO port output speed register,                          Address offset: 0x08 */
  __IO uint32_t PUPDR;        /*!< GPIO port pull-up/pull-down register,                     Address offset: 0x0C */
  __IO uint16_t IDR;          /*!< GPIO port input data register,                            Address offset: 0x10 */
  uint16_t RESERVED1;         /*!< Reserved,                                                                 0x12 */
  __IO uint16_t ODR;          /*!< GPIO port output data register,                           Address offset: 0x14 */
  uint16_t RESERVED2;         /*!< Reserved,                                                                 0x16 */
  __IO uint32_t BSRR;         /*!< GPIO port bit set/reset registerBSRR,                     Address offset: 0x18 */
  __IO uint32_t LCKR;         /*!< GPIO port configuration lock register,                    Address offset: 0x1C */
  __IO uint32_t AFR[2];       /*!< GPIO alternate function low register,                Address offset: 0x20-0x24 */
  __IO uint16_t BRR;          /*!< GPIO bit reset register,                                  Address offset: 0x28 */
  uint16_t RESERVED3;         /*!< Reserved,                                                                 0x2A */
}GPIO_TypeDef;

#define PERIPH_BASE           ((uint32_t)0x40000000) /*!< Peripheral base address in the alias region */
#define AHB2PERIPH_BASE       (PERIPH_BASE + 0x08000000)
#define GPIOA_BASE            (AHB2PERIPH_BASE + 0x00000000)
#define GPIOA               ((GPIO_TypeDef *) GPIOA_BASE)

Maybe I'm doing something wrong? Or there is some settings i don't know...

[yvesdm3000]

Where is this struct declared and is that #include 'd ?

Yves

[1essor1]

GPIO_TypeDef and all defines with addresses are in stm32f0xx.h. This file included to main.c where I write code for screenshots.

[Quiss]

http://forums.codeblocks.org/index.php/topic,15482.0.html

[1essor1]

http://forums.codeblocks.org/index.php/topic,15482.0.html

Thanks for link! Yes, this situation is similar to mine.

So, there is no way to deal with this problem? Maybe some CC tweaks that help it to do macro expansion deeper? If it will take more time, it still be ok.

[yvesdm3000]

You might try the ClangCC plugin since it's based on a real compiler, but you'll have to build clang, build the plugin and know a little bit about clang compile options since it needs compile options on its own and I don't know how compatible they are with compilation options for a cross-compiler like for STM32

Yves

[1essor1]

Looks interesting! I'd like to get some more information about this. Where can I find this plugin and appropriate build instructions?

[stahta01]

Looks interesting! I'd like to get some more information about this. Where can I find this plugin and appropriate build instructions?

https://github.com/yvesdm3000/ClangLib
http://forums.codeblocks.org/index.php/topic,20623.msg148278.html#msg148278

[BlueHazzard]

it is quite tricky to build on windows...
Linux is izi..

[stahta01]

it is quite tricky to build on windows...
Linux is izi..

If anybody wants a Window build; I might try building  ClangLib based CC Plugin.
Please reply in this thread; because I will NOT do it unless I have someone willing to test the custom CB build I will have to make.
It will likely be a 7Zipped file that just needs to be extracted.
It will likely based on MSys2 based files/DLLs.

Anyone want a custom build by me?

Edit: It will be an Windows 32 bit build, also.
Edit2: It will also be using wxWidgets 3.0.2 multilib DLLs.

Tim S.

[ollydbg]

Some news about the expression handling:
I just test a simple expression parser, which is derived from the one I found here:
Expression parsing algorithm, it's kind of operator precedence parser(precedence climbing), it looks like parsing the "type cast" is tricky  .

Here is the result:

Code

Enter expression: ((a*)b).c
        c
    .
            b
        CAST
            *
                a

You see, the binary tree shows some nice results, which may help the build-in CC to resolve the correct suggesting list. The current CC does not have the ability to parse the expression which have many parentheses, so even it knows the type of GPIO_TypeDef, it still don't understand the

Code

((GPIO_TypeDef *) GPIOA_BASE)->CodeCompletion

statements.

[icequan233]

it is quite tricky to build on windows...
Linux is izi..

If anybody wants a Window build; I might try building  ClangLib based CC Plugin.
Please reply in this thread; because I will NOT do it unless I have someone willing to test the custom CB build I will have to make.
It will likely be a 7Zipped file that just needs to be extracted.
It will likely based on MSys2 based files/DLLs.

Anyone want a custom build by me?

Edit: It will be an Windows 32 bit build, also.
Edit2: It will also be using wxWidgets 3.0.2 multilib DLLs.

Tim S.

@Tim, I want to try this plugin, but my C::B is built by wx3.1, can you give me your C::B built with wx3.0.2, I don't want to build cb again. Thanks.

[ollydbg]

Some progress about the code suggestion on a complex expression.

Code

((GPIO_TypeDef*)((((uint32_t)0x40000000)+0x08000000)+0x00000000))->CC

This is the code when the parser actually see:

Code

((GPIO_TypeDef *) GPIOA_BASE)->CC

Now, here is the tree for code completion.

Code

        CC
    ->
            (((uint32_t)0x40000000)+0x08000000)+0x00000000
        CAST
            *
                GPIO_TypeDef

For a type cast node(which shows "CAST" above), only the left tree is interesting, so tree traversal could have some steps
1, get the GPIO_TypeDef
2, get the pointer to GPIO_TypeDef
3, get the member of GPIO_TypeDef
With the step 3, you will list all the members of the GPIO_TypeDef.

The problem is that my test code is just some standalone program, it should be integrated(maybe replace) into the CC's source code, so there may be a lot of code changes. 

[ollydbg]

I wrote a CC test case:

Code

//Code completion and STM32 peripheral registers - 
//http://forums.codeblocks.org/index.php/topic,21823.msg148685.html#msg148685

#define __IO

typedef struct
{
  __IO uint32_t MODER;        /*!< GPIO port mode register,                                  Address offset: 0x00 */
  __IO uint16_t OTYPER;       /*!< GPIO port output type register,                           Address offset: 0x04 */
  uint16_t RESERVED0;         /*!< Reserved,                                                                 0x06 */
  __IO uint32_t OSPEEDR;      /*!< GPIO port output speed register,                          Address offset: 0x08 */
  __IO uint32_t PUPDR;        /*!< GPIO port pull-up/pull-down register,                     Address offset: 0x0C */
  __IO uint16_t IDR;          /*!< GPIO port input data register,                            Address offset: 0x10 */
  uint16_t RESERVED1;         /*!< Reserved,                                                                 0x12 */
  __IO uint16_t ODR;          /*!< GPIO port output data register,                           Address offset: 0x14 */
  uint16_t RESERVED2;         /*!< Reserved,                                                                 0x16 */
  __IO uint32_t BSRR;         /*!< GPIO port bit set/reset registerBSRR,                     Address offset: 0x18 */
  __IO uint32_t LCKR;         /*!< GPIO port configuration lock register,                    Address offset: 0x1C */
  __IO uint32_t AFR[2];       /*!< GPIO alternate function low register,                Address offset: 0x20-0x24 */
  __IO uint16_t BRR;          /*!< GPIO bit reset register,                                  Address offset: 0x28 */
  uint16_t RESERVED3;         /*!< Reserved,                                                                 0x2A */
}GPIO_TypeDef;

#define PERIPH_BASE           ((uint32_t)0x40000000) /*!< Peripheral base address in the alias region */
#define AHB2PERIPH_BASE       (PERIPH_BASE + 0x08000000)
#define GPIOA_BASE            (AHB2PERIPH_BASE + 0x00000000)
#define GPIOA               ((GPIO_TypeDef *) GPIOA_BASE)


//GPIOA->MO      //MODER

And running this test case, I get the tree printed in the log window:

Code

...
...
000079.         MO
000080.     ->
000081.             ((((uint32_t)0x40000000)+0x08000000)+0x00000000)
000082.         CAST
000083.             *
000084.                 GPIO_TypeDef

So, I use the Tokenizer to preprocess the tokens of the statement "GPIOA->MO".

Now, the next step is: try to traverse the tree, and make the type resolving. Some code should be changed, such as the below function:

Code

// Here's the meat of code-completion :)
// This function decides most of what gets included in the auto-completion
// list presented to the user.
// It's called recursively for each component of the std::queue argument.
// for example: objA.objB.function()
// The queue is like: 'objA' 'objB' 'function'. We deal with objA first.
//
// No critical section needed in this recursive function!
// All functions that call this recursive function, should already entered a critical section.
size_t NativeParserBase::FindAIMatches(TokenTree*                  tree,
                                       std::queue<ParserComponent> components,
                                       TokenIdxSet&                result,
                                       int                         parentTokenIdx,
                                       bool                        isPrefix,
                                       bool                        caseSensitive,
                                       bool                        use_inheritance,
                                       short int                   kindMask,
                                       TokenIdxSet*                search_scope)
{

Note that the second parameter "std::queue<ParserComponent> components" should be replaced by the tree.

[ollydbg]

OK, two years later, I have some progress about this code completion case. For the above cc test case, now, I can show the expression tree, see the image shot as in attachment, and I can rebuild the std::queue<ParserComponent> components by the tree, then I get the correct result.

Code

********************************************************
  Testing in file: ccc_test_parsing_expression.cpp
********************************************************
+ PASS: GPIOA->MO  MODER
--------------------------------------------------------
Total 1 tests, 1 PASS, 0 FAIL
--------------------------------------------------------

I have a lot of code changes especially the code of operator precedence climbing.

[Alatar]

OK, two years later, I have some progress about this code completion case. For the above cc test case, now, I can show the expression tree, see the image shot as in attachment, and I can rebuild the std::queue<ParserComponent> components by the tree, then I get the correct result.
<...>
I have a lot of code changes especially the code of operator precedence climbing.

Wow, that is cool! I was not here for a while, but I still use C::B for development =). Is this code already in main codebase?