New Extension - Naggy

Go To Last Post
132 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Naggy is an AVR Studio 5 extension I wrote that uses Clang (LLVM frontend for C) to show compiler diagnostics as you type. It works the same way as the error squiggles you see in Visual Studio and other IDEs.

You can download it from [url=https://github.com/downloads/saa... v0.2.vsix]here[/url], and the source code up on github ( https://github.com/saaadhu/naggy ).

Pictures and more details available here (my blog) and here[/url]

Regards

Senthil

 

blog | website

Last Edited: Thu. Sep 1, 2011 - 08:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Senthil.

It looks like a very useful plugin giving back some functionality I already loved using Studio32.

I tried to install the plugin to the final Studio5 (as user with limited access, WinXP) and cannot actually see that the plugin does anything?

Has it to be activated after installation (visible in Extension manager)? Or do I need external programs?

I will test again this evening at home with admin privileges on Win7-32Bit.
I did the test and it's the same behavior.

Thanks,

Daniel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Daniel.

There is no activation needed - if it shows up as Enabled in Extension Manager, then it should be running.

If you can wait a couple of days, I'll send you a newer build that is much smaller and has (partial) support for graying out of excluded conditional preprocessor code (what you were requesting in the other thread).

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Senthil,

thanks for your reply.
I would be very pleased to do some testing on your new release.
If you have some tips where to find logs or information, I can also invest some time to find out why the current release is not working on my 2 systems. (Of course successfully installed and displayed in the extension manager.)

Daniel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is glorious. I just tried it, and while it didn't appear to work on my existing project, it works fantastically on a new project I tested it with. It may have been a combination of restarting my computer and/or the much smaller source file in the new project, however.

Well done, love it! When it's stable, email it to Atmel and see if you can get it included in the online gallery.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean - good Idea. Projects created after Naggy installation are working.

Senthil - Naggy complains about Atmel C Coding style. (blame Atmel for that) Perhaps you can implement a switch for sloppy style. (UC3 example projects are very red)

Examples what Atmel uses in framework and Naggy marks:
- bool in C programs (ok, allowed since C99)
(bool in c++ is correctly not marked)
- uint8_t without including
- other C99 stuff

The C99 statements make it sometimes also very complicated to use the Atmel framework in C++. Such a lib should be clean portable C.

Daniel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A new version of Naggy is available at https://github.com/downloads/saa... . Naggy can now show conditionally excluded preprocessor code in a "lowlighted" way, like what Visual Studio does.

Didn't have time to put in the C99 support you'd asked for though. I've added it to the issue tracker, the next release will have that fix as well.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update to this: the new "faded inactive preprocessor conditions" feature seems to work fantastically well. One small nitpick: it also fades out the closing "#endif" at the end of the block, which looks a little odd. If possible, could you make it only fade the code inside the inactive condition?

Really, really great job. I'd forward this to the Atmel AS5 team ASAP, since it's the missing bits from AS5 that make it even easier to use.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glad that you found the new feature useful and thanks for the nice words. I actually am a member of the AS5 team, but I'm working on this in my spare time. Just thought I'd release a few versions to quickly get some user feedback before adding it to the online gallery.

The initial version with preprocessor lowlighting support did not handle nested conditionals correctly. I've uploaded a 0.2.1 version ( https://github.com/downloads/saa... ) which fixes that and a couple of other issues.

Can you paste the block of code with the #endif also faded out? It isn't supposed to do that. Does the problem go away if you close and reopen the file?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Glad that you found the new feature useful and thanks for the nice words. I actually am a member of the AS5 team, but I'm working on this in my spare time. Just thought I'd release a few versions to quickly get some user feedback before adding it to the online gallery.

Whoops! Are you based in Norway? If so, I probably met you at some point during my stay.

This really is great when used with Visual Assist, so please do see if you can get it incorporated by default into the next release. If you are in Norway, go show Glen in apps - I'm sure you'll be entertained by the reaction ;).

Quote:

Can you paste the block of code with the #endif also faded out? It isn't supposed to do that. Does the problem go away if you close and reopen the file?

Funny thing, it's gone now and it behaves itself. Must have been a code-gremlin.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Senthil,

the link to 0.2.1 results in a error 404 at the moment?

With 0.2 i have again issues getting naggy to run properly in all projects. Existing projects seem to never use naggy.

Daniel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Daniel,

Sorry, my bad - I tried to upload another build with a minor bug fix, but ended up breaking the link.

The link ( https://github.com/downloads/saa... ) should work now.

Can you attach a small project on which naggy doesn't work? I've been testing this on the RTM build, and I keep running newer versions of naggy with previously created projects. I haven't seen the problem you described.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When trying to download, it gives the following message:

This XML file does not appear to have any style information associated with it. The document tree is shown below.

    AccessDenied
    Access Denied
    59CF9D6326A3CA74
    
        calZnhprvr0qQmkeFtsCbD/Azn7svu2IkGgqc08D1/qGIsqVznNaNscYcbIWDKev
    

Felipe Maimon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Should be fixed now.

Don't know why it got broken - Github's downloads page appears to be pretty flaky the last 2 days.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Senthil,

sorry, but I had to work on another project the last days. But as you requested I attach 2 projects ( C and C++) I have created after installing version 0.2.
None of them is working.

Then I uninstalled naggy and created a project and installed naggy again. And also missing ";" is not detected.

If necessary I can repeat the test with completely uninstalling Studio 5 or setup a clean virtual machine.
Please let me know how I can support you.

Daniel

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, that helped a lot. Looks like I messed up big time - the diagnostics part of Naggy isn't working properly with 32 bit projects (projects with a 32 bit device). When the same code is pasted in a project with an 8 bit device, Naggy works fine.

Integration with the C++ options is not yet done, so even if I fix the 32 bit bug, it'll take some more time for proper C++ support (getting include dirs, predefined symbols etc from AVR Studio).

Will let you know once I fix this (shouldn't take long). Again, thanks for taking the time to attach the projects.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I fixed the problem and upload a new build at https://github.com/downloads/saa... . Can you give it a try?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi saaadhu,
This is fantastic and has helped to restore my faith in the new AS5.
One thing I have noted, when I run up the RTC_Example project, with Naggy enabled I get squiggly's on statements like:
static const gpio_map_t USART_GPIO_MAP =
{
{EXAMPLE_USART_RX_PIN, EXAMPLE_USART_RX_FUNCTION},
{EXAMPLE_USART_TX_PIN, EXAMPLE_USART_TX_FUNCTION}
};
and
Disable_global_interrupt();
The project compiles file with no errors or warnings.
What am I missing (a #include perhaps?)

Also did you say you are a member of the AS5 team? If so are they planning on introducing support for programming of USB DFU Boot Loaders via JTAG ICE MKII like one could in AVR32 Studio?

Your work is appreciated.

Cheers

PS I am using this on a 32 bit AVR at present in case this is a factor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tried this extension, it is OK, especially #if #endif, ..
but my code is:
...
#include
#include
...
ISR(INT0_vect)
- is assigned like error with label "unknown attribute 'externally_visible' ignored, unknown attribute 'signal' ignored"
...
const uint8_t PROGMEM connectedStatus3[3][103] = {...
- is assigned like error with label "unknown attribute '__progmem__' ignored"

Code was compiled without errors and warnings, and working.

Where is problem ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LX_User wrote:

ISR(INT0_vect)
- is assigned like error with label "unknown attribute 'externally_visible' ignored, unknown attribute 'signal' ignored"
...
const uint8_t PROGMEM connectedStatus3[3][103] = {...
- is assigned like error with label "unknown attribute '__progmem__' ignored"
Where is problem ?

Naggy is internally using Clang (a frontend for LLVM, different from GCC), and it's flagging those as errors probably because it doesn't know about those attributes.

In the next build, I'll flag warnings with a different color. That won't fix the problem, but you can atleast ignore these by color. I'll also see if I can make clang ignore warnings about unknown attributes.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aussieavr wrote:
Hi saaadhu,
This is fantastic and has helped to restore my faith in the new AS5.

Thanks. Glad you found it useful.

Quote:

static const gpio_map_t USART_GPIO_MAP =
{
{EXAMPLE_USART_RX_PIN, EXAMPLE_USART_RX_FUNCTION},
{EXAMPLE_USART_TX_PIN, EXAMPLE_USART_TX_FUNCTION}
};
and
Disable_global_interrupt();
The project compiles file with no errors or warnings.
What am I missing (a #include perhaps?)

No, you found a bug. One of the header files included before gpio.h (which has the struct's definition) had GCC and/or C99 specific extensions, and Clang stopped processing the file when it hit those errors. I tried turning on C99 and GNU specific extensions/keywords, and I don't get errors now. I'll update this thread once I upload a new build later in the day.

Quote:

Also did you say you are a member of the AS5 team? If so are they planning on introducing support for programming of USB DFU Boot Loaders via JTAG ICE MKII like one could in AVR32 Studio?

It's in our todo list is all I can say :)

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any hint of when a new version is due saaadhu :wink:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, couldn't find time to work on this. I uploaded a new build though at https://github.com/downloads/saa... .

Naggy can now show warnings (green squiggly) and errors (red squiggly) separately, and it also handles a lot more GCC specific stuff without barfing up. Unfortunately, builtin directives unknown to Clang (Enable_global_interrupt uses __builtin_csrf)x still show up as errors, but that'll have to wait for the next build.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks saaadhu, trying out now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil i think the latest ver of naggy (0.2.4) does not work in AS 5.1 Beta 148.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could someone check it to make it sure that its a Bug?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DieCore wrote:
Could someone check it to make it sure that its a Bug?

Yes, it appears to be a bug. I don't have a proper 5.1 beta build with me at the moment, but based on the description and after some debugging with a dev build, I have a build of Naggy that I think works around the problem. Can you try installing Naggy from https://github.com/downloads/saaadhu/naggy/Naggy%20v0.2.4%20for%205.1.vsix (after uninstalling the previous version)?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:
DieCore wrote:
Could someone check it to make it sure that its a Bug?

Yes, it appears to be a bug. I don't have a proper 5.1 beta build with me at the moment, but based on the description and after some debugging with a dev build, I have a build of Naggy that I think works around the problem. Can you try installing Naggy from https://github.com/downloads/saaadhu/naggy/Naggy%20v0.2.4%20for%205.1.vsix (after uninstalling the previous version)?

Ok
I installed the .vsix that you provided for the AS5.1.
I tried and only the lowlighting of excluded code works.
Its saying again that error, it cant find the first header file...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I have another build of Naggy out. I tested this on the beta build, and it appears to work fine - it works around the problem by hardcoding the default include paths for toolchains. Looks like AS 5.1 broke an API contract.

Anyway, you can try it again from the same link https://github.com/downloads/saaadhu/naggy/Naggy%20v0.2.4%20for%205.1.vsix. Do let me know if it works.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Ok, I have another build of Naggy out. I tested this on the beta build, and it appears to work fine - it works around the problem by hardcoding the default include paths for toolchains. Looks like AS 5.1 broke an API contract.

AS5.l have moved the toolchain out of the root install and into a VS extension itself - could that be the issue? Making the toolchain and ASF modules extensions would/will allow for upgrades to be made to the IDE or the modules without affecting the other components.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:
Ok, I have another build of Naggy out. I tested this on the beta build, and it appears to work fine - it works around the problem by hardcoding the default include paths for toolchains. Looks like AS 5.1 broke an API contract.

Anyway, you can try it again from the same link https://github.com/downloads/saaadhu/naggy/Naggy%20v0.2.4%20for%205.1.vsix. Do let me know if it works.

This WORKS for the 8bit toochain ONLY in a CUSTOM simple project with #include but it can't find a path for instance (C:\Users\Administrator\Documents\AVRStudio 5.1\TC_SIMULATOR_EXAMPLE_xmega\TC_SIMULATOR_EXAMPLE_xmega\src\config\conf_example.h) (Win7 SP1 x64)
for the tc_example for xmega simulator (write simulator in the example projects menu and you find it fast)

SECONDLY it doesn't work for the avr32 toolchain at all i think,
tested with the first simulator gpio example project
it cant find the #include "gpio.h" (C:\Users\Administrator\Documents\AVRStudio 5.1\GPIO_SIMULATOR_EXAMPLE\GPIO_SIMULATOR_EXAMPLE\src\asf\avr32\drivers\gpio\gpio.h)

I also tried other example avr32 & projects with the #include as a first line in the main.c file fo the project with the same issue it cant find the path.

I think you need to hardcode the avr32 toolchain like what you did for the avr8 but also the main project path.I also noticed a strange thing, at the xmega project if i change the to "asf.h" it fixed the path unknown issue (i comment with // the previous headers to let naggy check the asf.h file first).A conversion of <> to "" doesn't help in avr32 projects.

Thanks for the Help! Its really a useful program extension specially for C dummies like me.I think its useful even for the OLD experts... :P

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the nice words, and sorry for the poor testing I did :(

I've uploaded one more build (sigh) that hopefully works - I tested it with both 8 and 32 bit example projects, and it worked fine. You can get it from the same url https://github.com/downloads/saaadhu/naggy/Naggy%20v0.2.4%20for%205.1.vsix

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:
Thanks for the nice words, and sorry for the poor testing I did :(

I've uploaded one more build (sigh) that hopefully works - I tested it with both 8 and 32 bit example projects, and it worked fine. You can get it from the same url https://github.com/downloads/saaadhu/naggy/Naggy%20v0.2.4%20for%205.1.vsix

Hi Senthil!
Yes! Now it works fine with new projects and example projects with both toolchains AVR8 & AVR32 !!!

I have also noticed some bugs in naggy with uTasker Project with both AS5 & AS5.1 versions of AVR STUDIO and naggy [url] http://www.utasker.com/forum/ind...
[url] http://www.utasker.com/software/... [/url] like doesn't know CHAR definition and in some files (for example LCD.c,GLCD.c) has similar issue, cant find the "config.h"
You have PM :-D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is Naggy compatible with AVR Studio 6?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, there is now a build of Naggy available for 6.0. You can download it from https://github.com/downloads/saa...

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

What's the likelyhood of this becoming a standard AS6 extension available through the online gallery, or included in the installer?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's a very good idea Dean! I prefer to be available through the online gallery to be easier for the future updates!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Senthil

Please rebuild Naggy for the AS 6.0 Final which just released.The latest naggy for AS6 doesnt work for the AS 6.0 Final i think because the paths are changed again

Is it possible to extend naggy and make it compatible on Visual Studio 2010? I don't know if there is any gcc x86 toolchain for VS2010 as first step

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a new build of Naggy available targeting the AS 6.0 RTM version. You can download it from https://github.com/downloads/saa...

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think there is a bug in Naggy for AS6 RTM

It works fine when i make a new C project for Atmega32 but it doesnt work for instance with this bigger project and its showing errors because it cant find/recognise the io.h header.

I also use Productinity Power Tools and Ultra Find as third party extensions and i am not sure if there are any compatibility issues.

Does anyone else has similar issues?

I tried to build myself naggy on VS2010 SP1 it opens the main solution file (Naggy.sln)but it showing an error that it can't open the naggy c# project (Naggy.csproj)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No one? :(

Here is the example source code that i have the problem

#include 
#include 
//#include "pic_temp.h"

#define NOP() asm("nop")

#define DATA_LO_DDR  DDRA
#define DATA_LO_PORT PORTA
#define DATA_LO_PIN  PINA

#define DATA_HI_DDR  DDRD
#define DATA_HI_PORT PORTD
#define DATA_HI_PIN  PIND

#define LCD_CS_DDR  DDRB
#define LCD_CS_PORT PORTB
#define LCD_CS_PIN  PINB
#define LCD_CS_BIT  0


#define LCD_RS_DDR  DDRB
#define LCD_RS_PORT PORTB
#define LCD_RS_PIN  PINB
#define LCD_RS_BIT  1


#define LCD_WR_DDR  DDRB
#define LCD_WR_PORT PORTB
#define LCD_WR_PIN  PINB
#define LCD_WR_BIT  2


#define LCD_RD_DDR  DDRB
#define LCD_RD_PORT PORTB
#define LCD_RD_PIN  PINB
#define LCD_RD_BIT  3

#define LCD_RST_DDR  DDRB
#define LCD_RST_PORT PORTB
#define LCD_RST_PIN  PINB
#define LCD_RST_BIT  4

#define DATA_INPUT() {\
						DATA_LO_DDR = 0x00;\
						DATA_HI_DDR = 0x00;\
						}
#define DATA_OUTPUT() {\
						DATA_LO_DDR = 0xff;\
						DATA_HI_DDR = 0xff;\
						}
#define LCD_CS_H() LCD_CS_PORT |= 1<<LCD_CS_BIT
#define LCD_CS_L() LCD_CS_PORT &= ~(1<<LCD_CS_BIT)

#define LCD_RS_H() LCD_RS_PORT |= 1<<LCD_RS_BIT
#define LCD_RS_L() LCD_RS_PORT &= ~(1<<LCD_RS_BIT)

#define LCD_WR_H() LCD_WR_PORT |= 1<<LCD_WR_BIT
#define LCD_WR_L() LCD_WR_PORT &= ~(1<<LCD_WR_BIT)

#define LCD_RD_H() LCD_RD_PORT |= 1<<LCD_RD_BIT
#define LCD_RD_L() LCD_RD_PORT &= ~(1<<LCD_RD_BIT)

#define LCD_RST_H() LCD_RST_PORT |= 1<<LCD_RST_BIT
#define LCD_RST_L() LCD_RD_PORT &= ~(1<<LCD_RST_BIT)


#define PORT_INI() {\
						DATA_INPUT();\
						LCD_CS_H();\
						LCD_RS_H();\
						LCD_WR_H();\
						LCD_RD_H();\
						LCD_RST_L();\
						LCD_CS_DDR |= 1<<LCD_CS_BIT;\
						LCD_RS_DDR |= 1<<LCD_RS_BIT;\
						LCD_WR_DDR |= 1<<LCD_WR_BIT;\
						LCD_RD_DDR |= 1<<LCD_RD_BIT;\
						LCD_RST_DDR |= 1<<LCD_RST_BIT;\
						}

void LCD_WR_REG(unsigned char index,unsigned int val)
{
	LCD_CS_L();
	LCD_RS_L();
	DATA_OUTPUT();
	DATA_LO_PORT = (unsigned char)index;
	DATA_HI_PORT = 0;
	//DATA_HI_PORT = (unsigned char)(index>>8);
	LCD_WR_L();
	NOP();
	NOP();
	LCD_WR_H();
	LCD_RS_H();
	DATA_LO_PORT = (unsigned char)val;
	DATA_HI_PORT = (unsigned char)(val>>8);
	LCD_WR_L();
	NOP();
	NOP();
	LCD_WR_H();
	LCD_CS_H();
}

unsigned int LCD_RD_REG(unsigned char index)
{
	unsigned int ret;
	LCD_CS_L();
	LCD_RS_L();
	DATA_OUTPUT();
	DATA_LO_PORT = (unsigned char)index;
	DATA_HI_PORT = 0;
	//DATA_HI_PORT = (unsigned char)(index>>8);
	LCD_WR_L();
	NOP();
	NOP();
	LCD_WR_H();
	LCD_RS_H();
	DATA_INPUT();
	ret = DATA_HI_PIN;
	ret <<= 8;
	ret += DATA_LO_PIN;
	LCD_RD_L();
	NOP();
	NOP();
	LCD_RD_H();
	LCD_CS_H();
	return ret;
}

void LCD_Write_Start()
{
	LCD_CS_L();
	LCD_RS_L();
	DATA_OUTPUT();
	DATA_LO_PORT = 0x22;
	DATA_HI_PORT = 0x00;
	LCD_WR_L();
	NOP();
	NOP();
	LCD_WR_H();
	LCD_RS_H();
}

void LCD_Write_Data(unsigned int val)
{
	DATA_LO_PORT = (unsigned char)val;
	DATA_HI_PORT = (unsigned char)(val>>8);
	LCD_WR_L();
	NOP();
	NOP();
	LCD_WR_H();
}

void LCD_Write_End()
{
	LCD_CS_H();
}

void LCD_Read_Start()
{
	LCD_CS_L();
	LCD_RS_L();
	DATA_OUTPUT();
	DATA_LO_PORT = 0x22;
	DATA_HI_PORT = 0x00;
	LCD_WR_L();
	NOP();
	NOP();
	LCD_WR_H();
	LCD_RS_H();
	DATA_INPUT();
	LCD_RD_L();//dummy read
	NOP();
	LCD_RD_H();
	NOP();
	NOP();
}

unsigned int LCD_RD_DATA()
{
	unsigned int ret;
	LCD_RD_L();
	NOP();
	ret = DATA_HI_PIN;
	ret <<= 8;
	ret += DATA_LO_PIN;
	LCD_RD_H();
	NOP();
	NOP();
	return ret;	
}

void LCD_Read_End()
{
	LCD_CS_H();
}


void delay_Nms(unsigned int n)
{
	while(n--)_delay_ms(1);
}

#define Display_ON() LCD_WR_REG(0x07,0x0173)
#define Display_OFF() LCD_WR_REG(0x07,0x0000)

void LCD_Init()
{
	PORT_INI();

	LCD_RST_L();
	delay_Nms(10);
	LCD_RST_H();

	//delay 10ms
	delay_Nms(10);

	//initializing funciton 1
	LCD_WR_REG(0xe5,0x8000);
	LCD_WR_REG(0x00,0x0001);
	LCD_WR_REG(0x2b,0x0010);
	LCD_WR_REG(0x01,0x0100);
	LCD_WR_REG(0x02,0x0700);
	LCD_WR_REG(0x03,0x1230);
	LCD_WR_REG(0x04,0x0000);
	LCD_WR_REG(0x08,0x0202);
	LCD_WR_REG(0x09,0x0000);
	LCD_WR_REG(0x0a,0x0000);
	LCD_WR_REG(0x0c,0x0000);
	LCD_WR_REG(0x0d,0x0000);
	LCD_WR_REG(0x0f,0x0000);
	LCD_WR_REG(0x50,0x0000);
	LCD_WR_REG(0x51,0x00ef);
	LCD_WR_REG(0x52,0x0000);
	LCD_WR_REG(0x53,0x013f);
	LCD_WR_REG(0x60,0x2700);
	LCD_WR_REG(0x61,0x0001);
	LCD_WR_REG(0x6a,0x0000);
	LCD_WR_REG(0x80,0x0000);
	LCD_WR_REG(0x81,0x0000);
	LCD_WR_REG(0x82,0x0000);
	LCD_WR_REG(0x83,0x0000);
	LCD_WR_REG(0x84,0x0000);
	LCD_WR_REG(0x85,0x0000);
	LCD_WR_REG(0x90,0x0010);
	LCD_WR_REG(0x92,0x0000);
	LCD_WR_REG(0x93,0x0003);
	LCD_WR_REG(0x95,0x0110);
	LCD_WR_REG(0x97,0x0000);
	LCD_WR_REG(0x98,0x0000);

	//power setting function
	LCD_WR_REG(0x10,0x0000);
	LCD_WR_REG(0x11,0x0000);
	LCD_WR_REG(0x12,0x0000);
	LCD_WR_REG(0x13,0x0000);
	delay_Nms(200);
	LCD_WR_REG(0x10,0x17b0);
	LCD_WR_REG(0x11,0x0004);
	delay_Nms(50);
	LCD_WR_REG(0x12,0x013e);
	delay_Nms(50);
	LCD_WR_REG(0x13,0x1f00);
	LCD_WR_REG(0x29,0x000f);
	delay_Nms(50);
	LCD_WR_REG(0x20,0x0000);
	LCD_WR_REG(0x21,0x0000);

	//initializing function 2

	LCD_WR_REG(0x30,0x0204);
	LCD_WR_REG(0x31,0x0001);
	LCD_WR_REG(0x32,0x0000);
	LCD_WR_REG(0x35,0x0206);
	LCD_WR_REG(0x36,0x0600);
	LCD_WR_REG(0x37,0x0500);
	LCD_WR_REG(0x38,0x0505);
	LCD_WR_REG(0x39,0x0407);
	LCD_WR_REG(0x3c,0x0500);
	LCD_WR_REG(0x3d,0x0503);

	//display on
	LCD_WR_REG(0x07,0x0173);
	//Display_ON();
}


void LCD_Set_XY(unsigned int x, unsigned int y)
{
	LCD_WR_REG(0x20,x);
	LCD_WR_REG(0x21,y);
}

void LCD_Set_Window(unsigned int startX,unsigned int startY,unsigned int endX,unsigned int endY)
{
	LCD_Set_XY(startX,startY);
	LCD_WR_REG(0x50,startX);
	LCD_WR_REG(0x52,startY);
	LCD_WR_REG(0x51,endX);
	LCD_WR_REG(0x53,endY);	
}


void LCD_test()
{
	unsigned int i,j;
	LCD_Write_Start();
	for(i=0;i<320;i++)
		for(j=0;j<240;j++)
		{
			if(i>279)LCD_Write_Data(0x0000);
			else if(i>239)LCD_Write_Data(0x001f);
			else if(i>199)LCD_Write_Data(0x07e0);
			else if(i>159)LCD_Write_Data(0x07ff);
			else if(i>119)LCD_Write_Data(0xf800);
			else if(i>79)LCD_Write_Data(0xf81f);
			else if(i>39)LCD_Write_Data(0xffe0);
			else LCD_Write_Data(0xffff);
		}
	LCD_Write_End();
}

unsigned char LCD_DrawPicture(unsigned char startX, unsigned char startY, unsigned int *pic, unsigned char sizeX, unsigned char sizeY)
{
	unsigned int endX,endY;
	unsigned long totalPixels = (unsigned long)sizeX * (unsigned long)sizeY;
	endX = startX+sizeX-1;
	endY = startY+sizeY-1;
	if(endX>239 || endY>319)return 1;
	LCD_Set_Window(startX,startY,endX,endY);
	LCD_Write_Start();
	while(totalPixels--)LCD_Write_Data(pgm_read_word(pic++));
	LCD_Write_End();
	return 0;
}

unsigned char LCD_DrawPicture2(unsigned char startX, unsigned char startY, unsigned int *pic, unsigned char sizeX, unsigned char sizeY)
{
	unsigned int i,j;

	if((startX+sizeX)>240 || (startY+sizeY)>320)return 1;

	for (j = 0; j

And here is a photo of naggy errors

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oops. That looks bad. Let me take a look tonight.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Senthil,

What's the likelyhood of this becoming a standard AS6 extension available through the online gallery, or included in the installer?

- Dean :twisted:

Dean,

I still consider it incomplete, so I'm hesitant to put it on the gallery or ship it with the installer.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just whack a beta logo on it and put it in the gallery - that way people can at least test it easily. Is there a way to mark it as compatible with all builds of Studio by default, so you don't have to keep updating the manifest with each Studio release?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Just whack a beta logo on it and put it in the gallery - that way people can at least test it easily. Is there a way to mark it as compatible with all builds of Studio by default, so you don't have to keep updating the manifest with each Studio release?

- Dean :twisted:

No, all extensions need to explicit set compatible versions. This is to make sure that extensions are compatible when APIs change etc.

I would like to see this on the extension gallery. A beta warning may generate enough user input to get it out of beta :P ?

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ATmega32A wasn't in the list of devices Naggy knows about, so it wasn't able to use the right device header file.

I've modified Naggy to bring it up to date with Atmel Studio 6.0 RTM in terms of supported devices. You can download the build (0.2.5) from https://github.com/saaadhu/naggy..., as usual.

To open the Naggy solution, you need to install the freely available Visual Studio SDK - that's probably why you weren't able to open it.

Sorry for the terribly late response :(

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:
ATmega32A wasn't in the list of devices Naggy knows about, so it wasn't able to use the right device header file.

I've modified Naggy to bring it up to date with Atmel Studio 6.0 RTM in terms of supported devices. You can download the build (0.2.5) from https://github.com/saaadhu/naggy..., as usual.

To open the Naggy solution, you need to install the freely available Visual Studio SDK - that's probably why you weren't able to open it.

Sorry for the terribly late response :(

Hello!

Thanks for the information!
Its better late than never!

I installed naggy 0.2.5 but its seems its not working at all. Just before i uninstall 0.2.4 and install the 0.2.5, i downloaded from the extension manager and updated the ASF library to the latest 3.2 version so i thought that the ASF update changed something and make naggy not working at all. Well i uninstalled 0.2.5 and reinstalled the previous 0.2.4 and it works like before so something went wrong with the 0.2.5 i thing.

Well it doesnt work i mean that it never showed me the red marking line when typing errors etc exist.

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Found the problem and fixed it today. I have uploaded a new build at the same place (https://github.com/saaadhu/naggy...).

The problem was that I'd used the list of supported devices returned by the toolchain (avr-gcc) directly, without noticing that there were duplicates. This threw an error at startup and that's why nothing worked.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil:
Thanks for your quick correction. I had the same problem, now it works again just fine.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Posted a new update (0.3.1) through the Atmel Gallery - you should be able to install/update via Tools->Extension Manager. This should work for both 6.0 and 6.1 beta users.

The new version shows diagnostics for the current file (and previously viewed files) in the Error List window, in addition to the squiggles in the editor. Dean, you owe me one :)

Also, specific diagnostics that Naggy emits because it doesn't know AVR/GCC specific stuff can now be turned off. I added diagnostics related to inline asm constraints, attributes and builtins to the exclusion list, but you can exclude other diags yourselves. Copy/note down the diag ID you see in the Error List, and just add it to %localappdata%\Atmel\AtmelStudio\\Extensions\Senthil Kumar Selvaraj\Naggy\\BlacklistedDiagnostics.txt. The blacklisting takes effect after you restart Atmel Studio.

As always, feel free to post bugs/suggestions, either here or at https://github.com/saaadhu/naggy...

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

Thanks for Naggy - its a great add-on.

Quote:
The new version shows diagnostics for the current file (and previously viewed files) in the Error List window,

Oh now that's a great feature.

BTW one nice feature in AS6.1 is that as soon as you'd posted the update then the next time I started Studio it popped up to say "a new version of Naggy is available".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Senthil,

Thanks for Naggy - its a great add-on.


Thanks. Glad you like it.

clawson wrote:

BTW one nice feature in AS6.1 is that as soon as you'd posted the update then the next time I started Studio it popped up to say "a new version of Naggy is available".

I'd turned on the "Don't show this again" box on that update popup a long while back and totally forgot about its existence.

One shameless self-plug post once in a while is ok I guess? :)

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, but it doesn´t work in AS6.1. it produces obscure errors in sources which where compiled without errors previously.

One example I described here:
http://son.ffdf-clan.de/include....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

peter9999 wrote:
Sorry, but it doesn´t work in AS6.1
Could you post a complete test case/project that doesn't work? The link you posted was in a non English language and didn't seem to have a complete test case that I could reproduce and debug.

And does that bug occur in AS 6.0 as well?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

You can use Google to translate. The error he's talking about is not at the end of the page where he linked to but in the first post. He uses the C99 feature :

 for (int i=0; i

at two places in the code and is getting warned about "redefinition of i" so it sounds like Naggy's parsing code may not be aware of the limit on the name scope of i. My guess is that once it's seen the definition it may be thinking the name remains in scope until the end of the function.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Cliff. I just pushed in a commit that turns on C99 mode in Naggy if it sees -std=gnu99 or -std=c99 on the Atmel Studio compiler command line. That fixes this and other C99 syntax related issues.

Peter, the fix should be available in the next update of Naggy.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi saaadhu, thank you for the quick response!

peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

I think you might call this a bug now the Naggy errors are added to the error list. If you open a file such as iom32.h for editing (just to look up a bit name or something) then it floods the Error List with warnings. For example the #error near the top about not including it directly and in the iom32.h a whole load of warning about the "poison" macros.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah - I have a partial fix for that in the latest version (should be available in a day), but now I'm wondering if I should even attempt to run Naggy on header files that are not part of the solution.

Thanks for letting me know.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Saaadhu,

thank you very much for Naggy - I had been looking for some way to use LLVM instead of GCC, but in fact what Naggy provides might be enough.

But Naggy (in Atmel Studio 6.0) is giving me tens of nonsense warnings and errors in projects that otherwise compile without warnings and run correctly; looks like Naggy is not really honoring the includes. I have a feeling that this might have something to do with my filesystem organization / include directories configuration / files added as links to the solution, but no idea.

So, I would like to ask for some option to see the output of clang's run (console? some log file?). Maybe that way some hint about what's happening could be gathered...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:

But Naggy (in Atmel Studio 6.0) is giving me tens of nonsense warnings and errors in projects that otherwise compile without warnings and run correctly; looks like Naggy is not really honoring the includes. I have a feeling that this might have something to do with my filesystem organization / include directories configuration / files added as links to the solution, but no idea.

The include file path settings are picked from the project file. Are you using an external make file or Studio's build system? Can you attach a sample project (either here or at https://github.com/saaadhu/naggy...) that shows the issue?

hmijail wrote:

So, I would like to ask for some option to see the output of clang's run (console? some log file?). Maybe that way some hint about what's happening could be gathered...

There's no console/log right now. I don't actually have Clang compile the file - I only ask it to do a syntax/semantic check and give me the diagnostics, and all of them happen in-memory. I should probably do some kind of logging though.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:
The include file path settings are picked from the project file. Are you using an external make file or Studio's build system?

Studio's build system.

saaadhu wrote:
Can you attach a sample project (either here or at https://github.com/saaadhu/naggy...) that shows the issue?

I'll try later.

saaadhu wrote:
There's no console/log right now. I don't actually have Clang compile the file - I only ask it to do a syntax/semantic check and give me the diagnostics, and all of them happen in-memory. I should probably do some kind of logging though.

If that provides even more information, why not :).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tried creating an issue in GitHub to attach the example project, but I don't see an option to attach random files there, only images. So I'm posting it here.

The solution file is PRB-ADC1/PRB-ADC1.atsln . I didn't want to alter much the directory structure in case it has anything to do - since the problems I'm seeing seem somewhat random. The zip file is 47 KB, but the source in fact is a few tens of lines, mostly comments and #defines.

Interesting things:

  • The program compiles without even a warning
  • Naggy complains about TIMER8_0 not being defined, though it is, via the #include "lib_mcu/timer/timer8_drv.h"
  • That complaint disappears if the #include commented out or moved before the other #include
  • When opening timer8_drv, Naggy finds errors even in the comment lines
  • Those comment lines cause no complaint if copied to a new file
  • the line numbers reported by Naggy are always nonsense

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:
I have tried creating an issue in GitHub to attach the example project, but I don't see an option to attach random files there, only images. So I'm posting it here.

The solution file is PRB-ADC1/PRB-ADC1.atsln . I didn't want to alter much the directory structure in case it has anything to do - since the problems I'm seeing seem somewhat random. The zip file is 47 KB, but the source in fact is a few tens of lines, mostly comments and #defines.

Interesting things:

  • The program compiles without even a warning
  • Naggy complains about TIMER8_0 not being defined, though it is, via the #include "lib_mcu/timer/timer8_drv.h"
  • That complaint disappears if the #include commented out or moved before the other #include
  • When opening timer8_drv, Naggy finds errors even in the comment lines
  • Those comment lines cause no complaint if copied to a new file
  • the line numbers reported by Naggy are always nonsense

All the problems go away if I put a space between the / and the * in the first line of timer_drv.h i.e. change
//********
to
// ***

Does that fix it for you as well? Make that change, save the header file, and then type something in the .c file to trigger a reparse, and see if the error goes away.

Looks like a bug in the Clang lexer :). I'll check if the latest code in Clang's trunk fixes this problem.

The number before the colon in Naggy's diagnostics is the diagnostic code - not the line number, in case you misread it. The line/column number show up in separate columns in the error list. The code can be used to blacklist certain diags that are bogus or gcc/avr specific.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:

All the problems go away if I put a space between the / and the * in the first line of timer_drv.h i.e. change
//********
to
// ***

Does that fix it for you as well?

Yes, that fixes it.
Interestingly, even though Doxygen plays a lot with the different comment formats, it seems to avoid using the sequence //* . Maybe there is something about it?

saaadhu wrote:
Make that change, save the header file, and then type something in the .c file to trigger a reparse, and see if the error goes away.

Needing to type something to trigger a reparse feels wrong to me. Can't/shouldn't that be automatic? (of course I have no idea how difficult that would be...)

saaadhu wrote:
Looks like a bug in the Clang lexer :). I'll check if the latest code in Clang's trunk fixes this problem.

Great, thanks.

saaadhu wrote:
The number before the colon in Naggy's diagnostics is the diagnostic code - not the line number, in case you misread it. The line/column number show up in separate columns in the error list. The code can be used to blacklist certain diags that are bogus or gcc/avr specific.

Sorry, I totally misread it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After changing some of those //** comments, other strange errors are coming to the front. Now Naggy errors on "unknown type name uint16_t" (and lots of others) in various header files (as spi_drv.h from the Atmel CAN libs), which I'd say don't do anything different from other header files which don't cause errors...

I guess I will have to wait for some way to track better the reason for these errors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,
uint32_t and bool still not recognized in 0.3.2.
Example:
bool isHere = false; // is producing "968: expected expression"

uint32_t myNbr = 0; // is producing "1127 : unknown type name 'uint32_t"

a #define MY_NUMBER 3 in an included file of an include file makes that is is not beeing recognized in the outer file (include file nesting) => "2694 : use of undeclared identifier 'MY_NUMBER'"

The command line (AVR32/GNU C Compiler => Miscellaneous) contains "-std=gnu99" as stated by you, but it does not help.

Any ideas?

Thanks & regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Any ideas?

Sounds like you aren't doing:

#include 
#include 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Any ideas?

Sounds like you aren't doing:

#include 
#include 

They were already included through main.h => asf.h => compiler.h

But I included now both again, explicitly in main.h, compiled => no more errors :D
Then commented both files out again from main.h, compiled (after doing a "Clean") => no more errors :?:

Sounds as if Naggy needed a refresh to the (nested) included files...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See this example:
- foo.c includes(i.e.) stdint.h, defs.h and foo.h in the right order and uses

uint32_t myFoo[MY_DEF_CONST];

(see below)
- foo.h contains the line

extern uint32_t myFoo[MY_DEF_CONST];

- defs.h defines

#define MY_FOO_CONST 10

then
- compiler shows no error
- foo.c shows no Naggy problems
- foo.h (Naggy) shows

    1127:unknown type name 'uint32_t
    2694:use of undeclared identifier 'MY_DEF_CONST'

Any ideas? All this red lines in the .h - files are not really beautiful...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Any ideas? All this red lines in the .h - files are not really beautiful...

Ok, I really should get off my butt and push out another update :(

Yes, header files are a problem - Naggy parses each editor buffer in isolation. It therefore doesn't know that you included stdint.h in foo.c file when parsing foo.h file.

I'd assumed that most header files would be complete i.e., they'd include all the headers needed to compile. Doesn't look like that's the case, at least with the Atmel Studio crowd :)

I'll push out a new version in the next couple of days to make Naggy ignore parsing of header files. Unfortunately, that's the only solution I can think of right now. I'm all ears if someone can think of a better one.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:
Quote:

Any ideas? All this red lines in the .h - files are not really beautiful...

Ok, I really should get off my butt and push out another update :(

Yes, header files are a problem - Naggy parses each editor buffer in isolation. It therefore doesn't know that you included stdint.h in foo.c file when parsing foo.h file.

I'd assumed that most header files would be complete i.e., they'd include all the headers needed to compile. Doesn't look like that's the case, at least with the Atmel Studio crowd :)

I'll push out a new version in the next couple of days to make Naggy ignore parsing of header files. Unfortunately, that's the only solution I can think of right now. I'm all ears if someone can think of a better one.


Ideas:
    Maybe a "Configuration" - Window, like AStyle does, also with checkboxes to switch parsing of h-files on/off?
    Maybe a configurable list of "common includes" to be parsed with the opened file? Also because you can include special files at compile time, with "-include" - flag and those would lead always to an error.
    I think, if not possible in a configuration window, also a project specific text file (like the blacklist, but at project level) may do the job.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess any solution you try to implement at the editor buffer level will just be a stopgap with lots of uncovered corner cases. To avoid that, shouldn't LLVM be run on the same level than GCC?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:
... To avoid that, shouldn't LLVM be run on the same level than GCC?

I think that is a good idea; at least it should run more often.

Please consider this situation: a .c-file and the header file; with the c-file including the header file, of course.

When I type a new statement in the c-file using a currently undefined e.g. CONSTANT, Naggy will highlight this fact. Very nice, this is how it should be.

OK, I go to the header and type there the definition for the CONSTANT. Should be ok.

Well, it compiles ok, but Naggy still highlights the undefined CONSTANT in the c-File. Only when I touch the c-File, Naggy finds that the issue has be resolved.

I found myself looking for the cause of the issue twice today, only finding that Naggy had not been triggered.

Regards,
Paul

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didn't really understand about running at the same level as GCC. Naggy sees exactly the same thing as GCC does - except that it has to deal with in-memory (unsaved) files. Would you elaborate a bit on what you meant?

The example that Paul gave is fixable though - running Naggy whenever the focused editor changes will make the squiggle go away. Making it work if the header file wasn't saved is more trickier though. I'm working on an update that fixes this and a couple of other problems - I'll push out the update sometime next week.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Saaadhu, I disagree - Naggy is not seeing "the exactly same thing" as GCC, since Naggy misses includes that GCC does see. I guess Naggy is not doing a full preprocessor pass?

And so that's what I meant about Naggy running at the same level than GCC: so it sees full translation units, instead of usaved buffers + some includes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

Silly question but is there any way just to temporarily turn Naggy off. Some times (if I switch target processors a few times) it seems to get confused about what the active header files are and will red line things I know to be valid.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:
Saaadhu, I disagree - Naggy is not seeing "the exactly same thing" as GCC, since Naggy misses includes that GCC does see. I guess Naggy is not doing a full preprocessor pass?

No, Naggy uses Clang under the hood, and therefore does everything a compiler would do except for emitting code.

That said, there are a bunch of things that can cause Naggy to emit incorrect diagnostics.

Macros automatically defined by avr-gcc
Headers automatically included by avr-gcc
GCC specific language extensions.
Inline assembly
Naggy misreads project settings

While full fidelity is not gonna happen, I do try and make sure Naggy gets close to what GCC does. If you see that it doesn't, post about it here, or file an issue at https://github.com/saaadhu/naggy and I'll see what I can do.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Senthil,

Silly question but is there any way just to temporarily turn Naggy off.

Without restarting Atmel Studio, unfortunately no. Otherwise, you can do Tools -> Extension Manager -> Installed Extensions, scroll to Naggy and click Disable.

I'll add a menu option to disable/enable it on the go in the next update (https://github.com/saaadhu/naggy...)

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'll add a menu option to disable/enable it on the go in the next update

Cool :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:

I'll add a menu option to disable/enable it on the go in the next update (https://github.com/saaadhu/naggy...)

:wink: anything new?

Regards
Gerardo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gerardo64 wrote:
saaadhu wrote:

I'll add a menu option to disable/enable it on the go in the next update (https://github.com/saaadhu/naggy...)

:wink: anything new?

Regards
Gerardo

Closed out that issue today. I've also turned off diagnostics for header files. I still have to build LLVM/Clang and check if the /** comment issue is fixed, so a couple of more days atleast before I push out 0.3.3.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great! :D
Can you please post the availability of the new release, so we all become automatically a message?
Thanks, Gerardo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just uploaded a new release (0.3.3) to the atmel gallery. It should up in the Extension Manager in a couple of days.

Important note: If you've customized the blacklisted diagnostics file, please it back up before you upgrade, and restore it after you're done.(%localappdata%/Atmel\AtmelStudio\6.\Extensions\Senthil Kumar Selvaraj\Naggy\0.3./BlacklistedDiagnostics.txt). The VSIX upgrade process deletes the folder containing the old version, taking that file along with it :( I'll move the file to a more permanent location for the next release.

Changes
Diagnostics parsing is disabled for header files.
A new menu option (Tools -> Disable Naggy) can be used to turn Naggy on/off with immediate effect.
Upgraded LLVM/Clang version used to 3.3

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recently installed Naggy and find that it doesn't understand my c++.

Is this something I need to configure or is the scope C only.

If the latter can someone explain how I uninstall Naggy. I tried what I thought were the obvious ways in extension manager and add-ons and windows control panel....... but to no success.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I figured out an answer to the uninstall question....

remove the folder in ...\Atmel\AtmelStudio\6.1\Extensions\

I am still interested in whether Naggy should support c++

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tools -> Extension Manager -> Naggy -> Uninstall doesn't work?

Oh and yes, C++ support will likely be in the next release.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason I asked for an on/off switch above was for the very reason that if I switch from editing C to C++ then pretty much everything turns to red squiggles and it's very difficult to follow.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, there's a wee bit of work involved in extracting the C++ toolchain settings from Atmel Studio, and that's what's holding me back. The underlying LLVM/Clang libraries are perfectly capable of emitting diagnostics for C++ code.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Version 0.3.3 still not showing up in my Atmel Studio 6.1.2562... is that normal?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope, it's still not "approved". My guess - whoever is responsible for approving new releases of extensions is on vacation :)

Will ping a couple of guys next week to see if there is some other problem.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, thanks - waiting with abated breath :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any news on Naggy? I still appear to have 0.3.2 with no sign of an update being available.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...and still waiting...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup sadly I uninstalled it as it makes editing C++ code almost impossible as virtually everything is underlined.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can probably fix that if Senthil doesn't mind - I'll clone it and see what's what.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That would be great. I would like to use Naggy for c++

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I tried to build the code as-is last night and ran into problems - I guess there are some dependencies that aren't listed in the code. I'll contact Senthil and see how to build it.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry about the long delay and the no show. Not easy finding free time with an 8 months old kid to take care of :)

I did upload a 0.3.3 release, but it never made it to your machines because I did not confirm the release in the Atmel gallery after it was approved. Doh!

Anyway, found some spare time yesterday to work on this, and I have working code that does lowlighting and squiggling for C++ projects as well. Will make 0.3.4 release sometime next week.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pushed the confirm button on the Atmel gallery today for a new release with C++ diagnostics support :) Please do give it a shot and let me know how it works.

Here's the changelog.

0.3.4

Add C++ and C++11 diagnostics support for C++ projects in Atmel Studio.
Fix broken support for ARM projects (include path resolution and symbol definition).

0.3.3

Diagnostics parsing is disabled for header files.
A new menu option (Tools -> Disable Naggy) can be used to turn Naggy on/off with immediate effect.
Upgraded LLVM/Clang version used to 3.3

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And oh, if someone wants to build the code fromh ttps://github.com/saaadhu/naggy (I know Dean tried to), switch to Release mode first. The Debug mode settings cause linking against debug mode built libraries of clang, which happen to be bigger than what github allows in a repo :(

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Senthil,

I have just briefly checked the new version with my (C-only) sources. I'm under the impression that the error numbers have changed and the content in the "BlacklistedDiagnostics.txt" needs to be adjusted for the new version.

Anyways, thank you very much for this most useful tool!

Regards,
Paul

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks very much for updating the naggy tool.

I am using the latest 6.1 and get many errors with a c++ project

Error	57	1640 : invalid output constraint '=z' in asm
Error	7	1761 : cast from pointer to smaller type

The errors occur on lines containing "pgm_read_word" and "pgm_read_byte"

Is anyone else having a similar experience?

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, Naggy is using a newer version of Clang under the hood, and yes, the error numbers have changed. My bad, didn't notice the change. I'll add testcases to the test suite to catch this in future versions.

This page (https://github.com/saaadhu/naggy...) has instructions on how to blacklist diagnostics. "invalid output asm constraint"'s error id is now 1640 instead of 1636. Editing the file to update the error code(s) and restarting Atmel Studio should fix the problem.

Meanwhile, I'll push an update to the Atmel gallery to fix this.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the quick feedback.

I also get warning 3780/unknown attribute for progmem and 3545/cast to pointer. It seems that naggy has a view that a pointer is longer than an int.

I can clobber them by editing the blacklist but wonder if I am blacklisting comments that would otherwise be useful.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I pushed an updated BlacklistedDiagnostics.txt file here (https://github.com/saaadhu/naggy...).

The pointer size thing is a real problem - there is port of the AVR target to Clang/LLVM in the main LLVM source base. I arbitrarily chose i386, and therefore the size of a pointer and other builtin datatypes will be incorrect for AVR (int is 4 bytes etc..). You can safely blacklist those warnings/errors, until I manage to find time to hack on a minimal implementation of the AVR target for Clang/LLVM - just whatever is necessary for the Clang frontend to know about.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Darn! Deleted the product instead of the release in the gallery! Now no one can download it unless it gets approved. Previous releases, comments and ratings are gone as well. Double darn :(

I uploaded the binary to github as a workaround (with updated BlacklistedDiagnostics.txt) - you can download it from https://github.com/saaadhu/naggy...

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the updates.

Quote:
I also get warning 3780/unknown attribute for progmem and 3545/cast to pointer. It seems that naggy has a view that a pointer is longer than an int.
Any thoughts on the attribute warning?

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does clang/llvm recognise gcc attributes?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, it doesn't. Unknown attribute warnings would have to go into the blacklist as well. Thought I already had them there - one more update then.

[EDIT] : The updated blacklist file has the correct error id for unknown attributes as well.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,
I am happily using naggy with c++. Thanks very much.
A bug/improvement that you might like to look at when you has a minute is that naggy seems to put the focus on the "error list" window even when there are no errors.

This means that when I build with no errors the focus is moved to the error window. when I do a find rather than seeing the find results I see that there are no errors.

thanks again for naggy and interested in your thoughts on the above.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, whether there are errors or not. E.g., when using the search all functionality it lists all the found matches briefly and then switches to the errors tab again. It might be useful to only switch if there was actually a change in the sources.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glad that you like Naggy.

Yup, that's super annoying. I've fixed it and pushed a new 0.3.5 release. Naggy will no longer explicitly "show" the error window itself - it will silently add diagnostics to it.

The release is available in github already (https://github.com/saaadhu/naggy...), and I've uploaded it to the Atmel gallery as well. Should be available inside Atmel Studio once it gets approved.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hot diggity - the auto-switching was making using my Data Size Viewer a bit harder when navigating symbols, thanks!

Feedback from APPS TRD: "Would be nice to have a 'Naggy' prefix on the error messages, so we don't confuse them with the GCC output errors..."

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my case, Naggy says that the very first #included file can't be found and seemingly does nothing more.

The project builds just fine, so GCC has no problem finding the file.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

so GCC has no problem finding the file.


That's to be expected, Naggy has nothing to do with GCC. In fact it uses a completely different C compiler to check the syntax of the code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

That's to be expected,

How on Earth can a C compiler "be expected" to fail to find includes?

clawson wrote:
Naggy has nothing to do with GCC. In fact it uses a completely different C compiler to check the syntax of the code.

I know, I mentioned long ago how I had been looking for a way to use LLVM directly instead of GCC, and how I hoped Naggy would be "enough".

For that though I will need it getting includes :P. And you can see how there has been some discussion about Naggy getting the needed directories from project properties and such. Only, something seems broken, at least in my case.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

How on Earth can a C compiler "be expected" to fail to find includes?

That is not what I wrote. You said

so GCC has no problem finding the file. 

I was pointing out that just because Naggy (which actually uses the Clang/LLVM compiler) fails to find a .h file does not mean that GCC will have the same problem, because it is a DIFFERENT compiler. In other words just because Naggy says something is wrong doesn't mean it really is wrong (as far as GCC is concerned).

I therefore expected GCC to find the file and that's what you reported so I said "that's to be expected". I wasn't expecting that Naggy/Clang/LLVM wouldn't find it - that's just an unfortunate bug in the way it works.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And my point is that back in May there was already discussion on this, how it might even be a problem in Clang's parser, and I was just reasserting the bug I reported back then.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's an interestingly tortured bug.

NOTE: this problem appears with Naggy installed and enabled in the Extension Manager, but disabled from the Tools menu. If I disable Naggy in the Extension Manager, the problem doesn't appear, so this has to be caused by Naggy.

I have a .c file which calls a function-like macro in an .h file. The macro declares/inits some structure:

#define CIRCBUF_VAR_DECLARE(TYPE, TYPELABEL, QUALIF, QUALIFLABEL, NAME, BUF_NUM_ELEMS)\
	uint8_t buffer_##NAME[BUF_NUM_ELEMS];  			\
	circbuf##TYPELABEL##QUALIFLABEL NAME ={			\
		.buffer_num_elems=BUF_NUM_ELEMS, 				\
		.buffer=buffer_##NAME,                       \
	}

If the .c file is opened (so presumably parsed by the supposedly disabled Naggy) and the .h file is edited, trying to save the .h file causes a dialog box saying "The requested operation cannot be performed on a file with an user-mapped section open".

Naggy is evidently not totally disabled, because the .c file shows some #ifdef lowlighting which is another effect of Naggy. So I guess that Naggy is trying to parse the function-like macro, choking on it and dying while leaving the file kind-of-locked.

If the .h file is edited but the .c file was not opened in the editor, the problem does not appear.

Once the problem appears, closing the .h file in the editor (losing its changes!) and opening it again doesn't fix the problem; the whole Atmel Studio must be restarted to free the .h file.

Incidentally, another bug is that trying to disable Naggy from the Tools menu when no source file has been yet opened fails with a dialog saying "Object reference not set to an instance of an object".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:
Here's an interestingly tortured bug.
If the .c file is opened (so presumably parsed by the supposedly disabled Naggy) and the .h file is edited, trying to save the .h file causes a dialog box saying "The requested operation cannot be performed on a file with an user-mapped section open".

Pretty strange. Naggy actually reads the in-memory contents of the file you're editing, but included files are read from the disk by clang. Did you disable Naggy after you started editing the file? I'll take a look at this anyway

Quote:

Incidentally, another bug is that trying to disable Naggy from the Tools menu when no source file has been yet opened fails with a dialog saying "Object reference not set to an instance of an object".

Nasty - will fix this in the next release.

Do you have a sample project that shows Naggy failing to handle the first #include?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:

Feedback from APPS TRD: "Would be nice to have a 'Naggy' prefix on the error messages, so we don't confuse them with the GCC output errors..."

- Dean :twisted:

'Naggy' is probably too long, unless you're working on a high-res monitor. Maybe N::diag or something like that would work better, I guess. Will add this to the next release.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:
Pretty strange. Naggy actually reads the in-memory contents of the file you're editing, but included files are read from the disk by clang. Did you disable Naggy after you started editing the file? I'll take a look at this anyway

No, I disabled it before even opening the file.

saaadhu wrote:
Do you have a sample project that shows Naggy failing to handle the first #include?

The projects I was editing yesterday now seem to work OK with Naggy... or at least don't show any clear problem. Strange because pretty little has changed.
If I find another problem of that kind I'll let you know. I will try to leave Naggy enabled for now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Naggy seems to have problems with function-like macros. Sometimes it emits warnings as if it thought that they are implicitly-declared functions (particularly when a function-like macro is "calling" another function-like macro passed as a parameter, as in FMACRO(FMACRO2)). But when the project is built, those errors disappear.

Also, I am getting duplicate warnings coming from "#pragma message" lines.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:
Naggy seems to have problems with function-like macros. Sometimes it emits warnings as if it thought that they are implicitly-declared functions (particularly when a function-like macro is "calling" another function-like macro passed as a parameter, as in FMACRO(FMACRO2)). But when the project is built, those errors disappear.

Do you have an example that demonstrates the problem?

Quote:

Also, I am getting duplicate warnings coming from "#pragma message" lines.

I'm not seeing those, perhaps you're seeing both build output from the actual compiler along with Naggy's diagnostics?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just released a new version of Naggy (0.3.6), with a fix for the "unable to save" bug. In case you uninstalled Naggy, do give this release a try.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Senthil,

just installed Naggy 0.3.6 and I'm seeing many complaints regarding variable widths that were not present before, like:

Warning	12	[N] 3517 : 
implicit conversion from 'long' to 'uint32_t' (aka 'unsigned int') changes value from 268435455 to 65535

For me Naggy seems to consider 32bit wide values to be 16bit only.

Regards,
Paul

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this an AVR project?

Dang, looks like I can never win :(. While I just made Naggy aware of the size of avr data types (int = 16 bits, pointers are 16 bits etc..), stdint.h defines uint32_t as

typedef unsigned int uint32_t __attribute__ ((__mode__ (__SI__)));

and Clang/Naggy doesn't (yet) understand the __mode__ attribute, so it just treats it as an int. Which, of course, is not 32 bits, and that's why you're seeing the warning.

Until this release, the size of datatypes was wrong (int was 32 bits), so that's why you weren't seeing it before.

I'll see if I can teach Clang about the __mode__ attribute.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just pushed a new release (0.3.7) which should hopefully fix that problem.

Like I said, I had to hack into the LLVM code to make it map the modes to the right datatypes.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you keep going like this, how long until avr-clang is done ? :P

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Senthil,

thank you very much for the fast update to Naggy version 0.3.7. The wrong messages are gone now.

Unfortunately I'm no longer seeing complaints like 2345 (ambiguous), 2188 (out-of-line definition) or 2431 (redefinition) as it was the case with Naggy 0.3.5. The project is AVR/Arduino with cpp-files handled via the VisualMicroExtension.

Other complaints work as expected.

Regards,
Paul

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I've just published a new version of Naggy that works with Atmel Studio 7.0. You can download it from https://github.com/saaadhu/naggy/releases/tag/0.4.0 , until it eventually shows up in the extensions gallery.

 

I'm now piggy backing off the avr-llvm project (https://github.com/avr-llvm/llvm), rather than my own patch. In case you missed it - the guys working on that have started merging it to upstream LLVM, so there'll soon be a avr-clang out there to compete with avr-gcc :)

Regards

Senthil

 

blog | website