build environment

[William Basser]

Dean,

 

Just FYI. 

 

Have LUFA building in a Code::Blocks programming environment.  Approximately 10 minutes of creating the project files.

 

In addition, AVR32 devices can be built using the standard make files that you are currently using, just by calling avr32 binaries.  I have not yet attempted to move this to Code::Blocks, but it looks very doable.

 

If you are interested, I will forward you the project file which is in an XML format.

 

BIll

 

[Dean Camera]

Bill,

> Have LUFA building in a Code::Blocks programming environment. Approximately
> 10 minutes of creating the project files.

Great! I haven't use Code::Blocks myself (preferring Programmers
Notepad) but I've heard of it. Since it can't do integrated debugging
like Studio can (due to the lack of plugins and open protocols) is
there any advantage over a tabbed code editor like PN?

> In addition, AVR32 devices can be built using the standard make files that
> you are currently using, just by calling avr32 binaries. I have not yet
> attempted to move this to Code::Blocks, but it looks very doable.

I started a LUFA port of the core last week, and I found the same to
be true, although I also needed to change the "-mmcu" parameter to GCC
to "-mpart" for the AVR32s. I have to have a bit of a think how I want
to split up the core and keep things sane before I continue with that,
however.

> If you are interested, I will forward you the project file which is in an
> XML format.

Is this one XML used by Code::Blocks for all the project files like
Programmers Notepad project files? If there are enough people
interested, I can commit it to the repository along side my existing
project file for C::B users.

Cheers!
- Dean

[Cameron Tacklind]

Dean,

Getting into the IDE debate... I'm using netbeans to great effect for AVR C development. (I'm actually using mostly C++ but that's a different debate.) I've heard similar praises about eclipse but I'm in love with netbeans and have no interest in switching. I had not seen Code::Blocks before this thread. Maybe it's features are worth exploring.

But to the issue at hand, a reason to switch.

I couldn't stand using PN as it was just a text editor with basic syntax colouring and make integration (with a button). (Maybe it's changed since I used it last...)

The most useful feature I missed from my Java days with netbeans was code completion. Assuming you get your C include paths setup properly, the code completion is simply amazing (especially with C++). The code almost writes it's self.

With all the other goodies a full featured IDE has (excellent versioning integration, refactoring (smart renaming for functions,variables,types,...), better syntax highlighting, code navigation, ...), the only reason reason of substance (besides setup) to not use one is because of the lack of integration with avr-dude that PN has. It wouldn't be too hard to make a plugin to take care of all this. I've had this ambition forever, but no time to dive into netbeans plugins, and my current method of using Makefile targets (still in the IDE, but manually picking a (make) target in right click menu) to do all the work makes the programming process rather painless.

I'd love to share how I setup netbeans with avr-gcc if anyone is interested.
I'm running it on my home linux computer and my work windows computer.

The only thing I haven't taken care of well yet (I haven't needed to) is making the nbproject folder portable between enviroments. Currently, I create a new project on every machine I use and import the source files (manually). Any other netbeans users out there want to share their methods?

 - Cameron

--
You received this message because you are subscribed to the Google Groups "LUFA (Formerly MyUSB) Support" group.
To post to this group, send email to myusb-sup...@googlegroups.com.
To unsubscribe from this group, send email to myusb-support-l...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/myusb-support-list?hl=en.

[Mitch Davis]

Hi Cameron,

On Tue, Nov 16, 2010 at 8:48 PM, Cameron Tacklind <cam...@tacklind.com> wrote:
>
> The most useful feature I missed from my Java days with netbeans was code
> completion. Assuming you get your C include paths setup properly, the code
> completion is simply amazing (especially with C++). The code almost writes
> it's self.

I have used NetBeans for J2ME work. It was a very pleasurable experience :-)

> I'd love to share how I setup netbeans with avr-gcc if anyone is interested.

I'd be interested. May I suggest writing it in a blog post or web
page? That way, we can bookmark it and come back to it and point our
friends at it.

Mitch.

[Donald Delmar Davis]

yeah

Code Completion
Source Control Integration
Jump to definition (find it in the libraries even)

All of the things i like about x-code.

Now if only apple didnt hate embedded developers so much.

[Cameron Tacklind]

Since the linux setup is nearly identical, but needs to support all distros, I'm just going to explain the Windows setup and the savy linux users among us will easily be able to translate.

Assumptions:
 - Netbeans with C/C++ plugin
 - For svn:
  - subversion plugin
 - svn+ssh:
  - putty installed and added to path. (plink is only needed binary, but others are incredibly useful so you can use Public/Private keys and don't have to
Steps:
 - Install Win-AVR. I don't like installing each new version to C:\winavr-xxxx\ so I always change that path to C:\Program Files\WinAVR\ and overwrite old ones if installed. I imagine this will all work fine with the default Win-AVR paths, upgrading might be a slight issue.
 - Add avr-gcc tool collection to Netbeans
  - Options > C/C++ > Build Tools > Add... (bottom left)
  - Browse to base directory C:\Program Files\WinAVR\bin
  - Collection Family & Name should be automatically filled in (newest versions). As far at I know, these are only cosmetic names.
  - It should automatically find all of avr-{gcc,g++,as,gdb}.exe and make.exe
  - The code assistance tab should also be automatically filled in

And you're basically done. You should now be able to create a new project with the WinAVR toolchain selected and all the code assistance will work. What's missing now is Makefile integration.

I always create a new C/C++ application, not from existing sources, only because it then has the useful {Header,Resource,Source,Test,Important} Files lists in the project tree. Otherwise it clumps all the files together in one "folder". Of course these folders have no relation to real system folders and are only for organization in the IDE.

Then I replace the generated Makefile in the project folder (adjacent to nbproject folder) with my Makefile of choice and copy my sources. The other option (suited for an existing file tree with existing .svn folders) is to close the project in Netbeans and quit. Then move the nbproject folder adjacent to the Makefile of the source folder you'd like to use in the IDE. Re-open Netbeans and open the project from the new location. Quitting netbeans is a necessary step. With the second method, netbeans will detect the existing .svn directory and versioning will be working immediately. There are a ton of different ways to do this step. These are the two I use the most. You can also start a new project from an svn checkout started in netbeans.

You're Makefile now shows up under "Important Files" and you can right click on it to run custom targets, like program.
The build buttons at the top work for building and clean building, but the "run" buttons (normal, debugger) don't work.
You just need to "add existing files" to the project to have them show up in the project list.

The last thing is defines (F_CPU, ...) set in your Makefile and by avr-gcc are not automatically recognized by Netbeans. In the Project's options, under build, for the language of choice, add pre-processor definitions like F_CPU and defining which AVR you're using so netbeans follows the correct include in <avr/io.h>. For instance, my current project is based on the 9DOF board from sparkfun and my defines are as follows:
__AVR_ATmega328P__
F_CPU=8000000UL

You can look in <avr/io.h> for the appropriate __AVR_xxxxxxx__ define needed for your current part. I guess most people on this list will need a variant of __AVR_AT90USB1287__

And I'm pretty sure that's it!
Unfortunately I have not tried any of this with LUFA because I haven't had a project I needed/had time to dive into USB. I'm on the mailing list just hoping to pickup the basics.

 - Cameron

--

[Christoph Redecker]

I am also using Code::Blocks and until now just modified the makefiles
to fit my project. However, I had some time to fiddle with compiler
settings today and found that it *is* a good idea to copy the compiler
flags from the makefile without *any* changes.

Especially -ffunction-sections is crucial, otherwise the linker will
complain.

I had to move away from the makefiles because C::B is the "Build
environment of choice" at our institute, and I said "it should be
possible without the makefile". Now I'm working on a CAN box with USB
and libusb(-win32) on the PC side.

Is anyone interested in stories about USBKEY and libusb?

Best regards,

Christoph

> --
> You received this message because you are subscribed to the Google
> Groups "LUFA (Formerly MyUSB) Support" group.
> To post to this group, send email to myusb-sup...@googlegroups.com.
> To unsubscribe from this group, send email to
> myusb-support-l...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/myusb-support-list?hl=en.
>
>
>
>

> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.869 / Virus Database: 271.1.1/3260 - Release Date: 11/16/10 08:34:00
>

[Michael Hennebry]

On Tue, 23 Nov 2010, Christoph Redecker wrote:

> I am also using Code::Blocks and until now just modified the makefiles to fit
> my project. However, I had some time to fiddle with compiler settings today
> and found that it *is* a good idea to copy the compiler flags from the
> makefile without *any* changes.

That is an annoyance with Dean's build mechanism.

> Especially -ffunction-sections is crucial, otherwise the linker will
> complain.

I understand the reason for -ffunction-sections,
but I don't understand why its lack might cause the linker to complain.

--
Michael henn...@web.cs.ndsu.NoDak.edu
"Pessimist: The glass is half empty.
Optimist: The glass is half full.
Engineer: The glass is twice as big as it needs to be."

[Christoph Redecker]

I converted the mouse demo from using a makefile to C::B's build
environment.

Additional define: BOARD=USBKEY
the rest as in the makefile.

Without -ffunction-sections, the following linker error occurs:

obj\Release\LUFA\Drivers\USB\LowLevel\Endpoint.o: In function
`Endpoint_Read_Control_EStream_BE':
Endpoint.c:(.text+0x8d0): undefined reference to `__eeupd_byte_usb1287'

plus similar messages for
Endpoint_Read_Control_EStream_LE
Endpoint_Read_EStream_BE
Endpoint_Read_EStream_LE
Endpoint_Write_Control_EStream_BE (missing __eerd_byte_usb1287)
Endpoint_Write_Control_EStream_LE (missing __eerd_byte_usb1287)
Endpoint_Write_EStream_BE (missing __eerd_byte_usb1287)
Endpoint_Write_EStream_LE (missing __eerd_byte_usb1287)

Somehow these should be present somewhere, but they aren't. The avr-libc
EEPROM header file <avr/eeprom.h> also uses these functions in a macro
(using string concatenation). However, the functions that call
__eerd_byte_usb1287 and eeupd_byte_1287 are not needed by the mouse
demo, and with -ffunction-sections these will be thrown out before the
error occurs. In that case, the whole thing compiles without any
warnings and errors. That's at least what I'm observing here...

Using WinAVR-20100110

On 24.11.2010 20:13, Michael Hennebry wrote:
> On Tue, 23 Nov 2010, Christoph Redecker wrote:
>
>> I am also using Code::Blocks and until now just modified the makefiles
>> to fit my project. However, I had some time to fiddle with compiler
>> settings today and found that it *is* a good idea to copy the compiler
>> flags from the makefile without *any* changes.
>
> That is an annoyance with Dean's build mechanism.
>
>> Especially -ffunction-sections is crucial, otherwise the linker will
>> complain.
>
> I understand the reason for -ffunction-sections,
> but I don't understand why its lack might cause the linker to complain.
>
>
>
>

> No virus found in this incoming message.
> Checked by AVG - www.avg.com

> Version: 9.0.872 / Virus Database: 271.1.1/3276 - Release Date: 11/24/10 08:34:00
>

[Christoph Redecker]

Hi again,

my Linux machine doesn't have a decent avr-gcc, so I switched to Win and
WinAVR. This is an old thread, but I am again encountering a problem
with the endpoint template mechanism Dean is using. I get the following
warning/error combination:

warning: implicit declaration of function `eeprom_update_byte`
error: undefined reference to `eeprom_update_byte`

eeprom_update_byte should be available in avr-libc.
Template_Endpoint_RW.c is included by EndpointStream.c, which in turn
includes EndpointStream.h, which includes Common.h, which includes
avr/eeprom.h. So all functions declared in avr/eeprom.h should be
visible in the template.

I'm again using Code::Blocks and WinAVR 20100110 (it seems there is no
newer WinAVR?), and LUFA 110528.

What could be the reason for this error? I really don't understand it.
While just copying the makefile settings worked before, it refuses to
work now.

Christoph

[Dean Camera]

Christoph,

Are you sure your environment is using the avr-libc library included
in that version of WinAVR? That version should carry the updates
needed to add in the new eeprom_update_byte() routine, which is
similar to eeprom_write_byte() but which checks before writing to see
if the current value matches the new value (to avoid writing the same
value and wasting the EEPROM's lifespan). You should have no problems
compiling if your environment is using the library version included in
WinAVR 20100110. If all else fails, you can patch the code to use
eeprom_write_byte() instead, but beware EEPROM write exhaustion if you
continuously try to write the same values to the EEPROM.

- Dean

On Sep 1, 3:59 am, Christoph Redecker <redec...@avrbeginners.net>
wrote:

[rede...@avrbeginners.net]

I had a wrong include path (not lib path) from WinAVR 2009xxxx and fixed
it. I now get the "old" error messages like

undefined reference to `__eerd_byte_usb1287)`

and -ffunction-section does not have any effect (as it did when I first
had errors of this type). There is a thread at avrfreaks indicating that
this might be caused by the linker not getting the -mmcu option, but in
my case it does (I can post a complete build log later today).

I'm using a per-project copy of LUFA, so I can patch it as required.
What exactly are the update functions used for? Maybe I can get away
without touching the EEPROM at all.

Regards

Christoph

[Dean Camera]

LUFA doesn't use the EEPROM normally, but there are variants of the
Endpoint and Pipe stream functions will will source or sink from/to
the EEPROM rather than RAM. You can safely just remove all the EEPROM
code if you don't intend on using it in your user application.

That said, that error indicates there is still something wrong with
your build environment, which should be sorted out. I'd remove all
traces of old WinAVR installations, and start with the latest WinAVR
(only) installed to make sure the latest toolchain and avr-libc are
used in all circumstances.

Cheers!
- Dean

On Sep 1, 6:16 pm, "redec...@avrbeginners.net"

[rede...@avrbeginners.net]

See the "shift count >= width of type" thread, where my compilation
problems converged to the same - now solved - error, but on a different
machine.

Regards

Christoph