User forums > Embedded development

Code completion and STM32 peripheral registers

<< < (3/4) > >>

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

--- End code ---
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
--- End code ---


--- Quote from: stahta01 on March 22, 2017, 08:50:30 pm ---
--- Quote from: BlueHazzard on March 22, 2017, 08:33:23 pm ---it is quite tricky to build on windows...
Linux is izi..

--- End quote ---

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.

--- End quote ---
@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.

Some progress about the code suggestion on a complex expression.

--- Code: ---((GPIO_TypeDef*)((((uint32_t)0x40000000)+0x08000000)+0x00000000))->CC
--- End code ---
This is the code when the parser actually see:

--- Code: ---((GPIO_TypeDef *) GPIOA_BASE)->CC
--- End code ---
Now, here is the tree for code completion.

--- Code: ---        CC

--- End code ---
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.  :(

I wrote a CC test case:

--- Code: ---//Code completion and STM32 peripheral registers -

#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 */

#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

--- End code ---

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

--- End code ---
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)

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

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
Total 1 tests, 1 PASS, 0 FAIL

--- End code ---

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


[0] Message Index

[#] Next page

[*] Previous page

Go to full version