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.
(http://i.imgur.com/SV8qEMW.png)
(http://i.imgur.com/2Dn8LHN.png)
Registers i want access are just memory regions and GPIOA is structure describing them :
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...
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 (http://rhyscitlema.com/algorithms/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:
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 ((GPIO_TypeDef *) GPIOA_BASE)->CodeCompletion
statements.
Some progress about the code suggestion on a complex expression.
((GPIO_TypeDef*)((((uint32_t)0x40000000)+0x08000000)+0x00000000))->CC
This is the code when the parser actually see:
((GPIO_TypeDef *) GPIOA_BASE)->CC
Now, here is the tree for code completion.
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. :(
I wrote a CC test case:
//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:
...
...
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:
// 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.
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.
********************************************************
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.