AVR-GCC will compile with MingW32 4.6.1 if the libraries GMP, MFFR and MPC are compiled as static libraries rather than shared  DLL's.

I have found patches for MPFR and MPC-0.9 which fix the configuration error for shared library compiling, but not for gmp. Sort of ironic that the new release of GCC breaks the configuration of its own required libraries.

The other comment on your biuld is that it leaves the three ( gmp, mpfr, mpc ) library include and object files in the avr-gcc install tree but these are libraries for the windows GCC compiler and so do not belong in the avr-gcc distribution. I have change the build to put them in a separate library directory. This required changing all the shell build scripts, but works fine.

Have been trying to compile from source over the weekend. ./configure fails in gmp, mpfr and mpc. I tracked this down to gcc spitting the dummy over "-no-undefined" which is a linker option. GCC prior to 6.6 series accepted this and passed on to linker but 4.6 series GCC requires "-Wl,-no-undefine" So all configure files will need to be patched. Seems odd when GCC 4.6.1 mingw  compiler refuses to compile GCC 4.6.2 avr.

OK, so AVRdude is not working correctly in this new version of MHV_AVR_Tools. My set up was Windows 7,  Eclipse 3.6 Helios, with the AVR Eclipse plugin with the .jar file you provide, and the previous version of the MHV_AVR_Tools. That set up was working, including being able to use AVRdude. I downloaded the latest MHV_AVR_Tools_20111106 to test GCC 4.6. So first I uninstalled the previous version of the toolchain. Then I installed the new version. Started up a sample project that compiled, and went to use AVRdude. I could not get AVRdude to run. What I mean by that is within Eclipse you cannot set up a programmer or even edit any AVRdude settings. So I tried to run AVRdude from the command line. It errors out telling me that "libusb0.dll cannot be found". The tool chain is in my system path. I looked in the bin directory and found libusb0.sys and libusb0_x86.dll, but no libusb0.dll. I tried copying and renaming the copies of libusb0_x86.dll and libusb0.sys to just libusb0.dll, but that did not work.

I am downloading the previous version to see if there was a file called libusb0.dll in there. Other than that I am out of ideas. Do you have any suggestions on how to get AVRdude working again? Would just downloading the latest version of libusb0.dll work? If that is possible, where would I put it.

Thanks for any help you can give me,

Tony

I am so glad someone is working on an uptodate avr-gcc for windows environment.

I am keen to remove the default search directories which appear in all the windows avr-gcc's that I have seen, in  a similar way to what tdm-gcc has done for mingw32.

see the output of

avr-gcc -print-search-dirs

which starts " c:/Program Files/atmel/avr tools/avr toolchain\bin/../libexec/gcc/avr/4.6.2/" etc.

These search directories clash with the atmel ide install.

The tdm patches to gcc make these search directories relative to the install directory and make the install truely relocatable.

To this end I have read your build scripts. I did not note any reference to ocaml and yet this is listed as a prerequisite for installing from source. At what point is ocaml used

Useful bits for the pile are:

The head mechanism (linear motion), laser module, driver motor, eject motor, & any switches you can see.

If you're still looking for these I have at least the first couple of Maximite issues. If you're looking for the kits I've heard that Altronics keeps selling out, but they also keep getting more in ! Otherwise if you need it now there was a bunch of enthusiasts who couldn't wait had some of their own boards fabbed. Google might be able to find them

For now, that is right.

At some point, I'll write a USB Serial driver, but everything so far indicates that performance is going to be horrible.

The next thing I plan on writing is a USB HID console driver for MHVLib (which should be easy enough to port to Arduino), which will allow bidirectional comms via a command line app.

The best solution at this point is to use a USB to TTL adapter (~$3 on Ebay), until I complete one of the above drivers. A much more awesome solution is to wedge a bluetooth ttl board (~$7 on Ebay) onto the prototyping area, for wireless serial shenanigans.

In reply to your Pozible project questions:

1. Yes, I would love your money

2. Yes, but probably not through Pozible. Australian Robotics will likely carry some, and I'll also make them available through NMN.

3. The first boards (for those who have confirmed payments) will ship out as soon as I have all the parts, completed the bootloader and written some assembly instructions.

Hi Greg,

The MHVBoard only enters the bootloader upon reset. You need to hit the reset button every time you want to upload to the board.

The fade sample in the Arduino environment works on a different pin to the one the LED is hardwired to. You will need to connect an LED between ground and the pin it is trying to alter. The pin it is trying to alter is Aruduino pin 9 (port B1).

Cheers

I see the problem, the zip contains "arduino-0021", which is now within your "arduino-0022" directory

Just move the contents of it up one level and you should be good.

I've also uploaded a patch for Arduino 22 (which includes some new boards, but is otherwise identical).

Help, I'm new to MHV and having trouble making the Arduino IDE see the MHV board. I'm running the IDE under Windows XP. Here's what I've done

[1] unzipped "arduino-0022" (latest version of Arduino IDE)

(Directory path is c:/program files/arduino-0022)

[2] unzipped "arduino-0021-mhv" and "extracted all files", extracted files and pointed to "arduino-0022" folder.

(Directory path to MHV specifications is c:/program files/arduino-0022/hardware/arduino/boards.txt)

[3] installed USBasp driver, device is detected, driver is pointed at USBasp folder, MHV board appears to run under Windows

(Directory path to USBasp driver is c:/program files/arduino-0022/usbasp-windriver.2011-05-28)

[4] not running on 64-bit machine, skipped 6 Driver Signature steps

[5] connected Upload jumper (J6) to power MHV board from USB port

[6] pressed Reset button, LED winks rapidly

[7] launched Arduino 0022, and select: File, Examples, 1.Basics, Blink

[8] I'm unable to choose "MHVBoard" from the Boards menu I think the problem is my understooding of "extract it over the top of your Arduino installation" in the 2nd bullet-point instruction of "Getting Started with the MHVBoard in the Arduino Environment".

Here is a directory of folders within "arduino-0022"

arduino-0021

drivers

examples

hardware

java

lib

libraries

reference

tools

usbasp-windriver.2011-05-28

I'm sure it is possible to edit hardware/arduino/boards.txt and paste the following lines ############################################################## mhvboard.name=MHV Board

mhvboard.upload.protocol=usbasp

mhvboard.upload.maximum_size=30720

mhvboard.upload.speed=19200

mhvboard.upload.disable_flushing=true

mhvboard.build.mcu=atmega328p

mhvboard.build.f_cpu=20000000L

mhvboard.build.core=arduino

mhvboard.bootloader.low_fuses=0xf7

mhvboard.bootloader.high_fuses=0xda

mhvboard.bootloader.extended_fuses=0x03

mhvboard.bootloader.path=mhvboard

mhvboard.bootloader.file=mhvboard_1.0.hex

mhvboard.bootloader.unlock_bits=0x3F

mhvboard.bootloader.lock_bits=0x2F ##############################################################

but it would be better to know why the instruction I tried to follow didn't cause that to happen automatically.

What do I need to do to make that happen ? Any suggestions welcome. Thanks. Greg S

 I dug thru the horrors that make up my old wardrobe the otherday and found a working an intact robo sapian, My first thought was to make him Bigger!

I think the circuitry could be kept in tact( might need to lengthen the wires), just replacing motors with stronger ones and building a bigger body with maybe pvc?

Now a bluetooth controlled the size of a small child would be an interesting build, a good script combined with the feed back sensors in its fingers would mean it could act as a butler, fetching beer without crushing the cans., Or a (semi) intelligent vice

Not as yet.

I have some vague plans to emulate the debug monitor from the Teensy when I add V-USB support to MHVlib, but I haven't started on it yet (and won't be doing so for a while).

 Adam will be demoing our new Roland JWX-10 CNC mill/engraver tonight. I'll be demoing the almost-complete MHV Space Probe.

Probably lots of other surprises on the night, as well.

 I'm just getting back into AVR hacking after a long hiatus and have been pretty disappointed with the state of the tools. I'm working on a Mac and everything available is either old or poor quality. It's great to see you taking on this task. I'd like to host a version of the tools you've assembled for Mac development if you don't mind. I've started a site (http://avr.marrin.org) and hope to get things together soon.

Thanks again!

I've seen similar problems before in Eclipse, where the project internally refers to old (and potentially uninstalled) compiler headers. Try closing the project and re-importing it, this may be sufficient to force Eclipse to pick up the new paths.

I haven't updated the jar since the installer was created, which installs to the Program Files\MHV AVR Tools directory. For now, you can manually change the paths to the executables by going to Preferences, AVR, Paths. The executables are in the bin directory, while the headers are in avr\include.

The installer will only add the suite to the path if you tick the box asking it to do so. However, this does not affect Eclipse as it uses fully qualified paths to the binaries, rather than calling them naked.

Does not look like it.

Are the patches included in the release?

I couldn't find publically available patches for 4.5, only 4.4 which is what they use in the new toolchain. If you know where I can grab 4.5 patches, I'll be happy to integrate it.

Correct, there is no XMega support in MHV AVR Tools, as I don't develop for these chips and porting the patches from GCC 4.4 to 4.5 is non-trivial.

I am now working with Eric Weddington (WinAVR), Bingo (Linux AVR Toolchain on AVRFreaks) and others to unify our efforts, and Eric is pushing to get XMega support and other pending patches committed to GCC.

In the meantime, if you feel like porting the XMega patches to GCC 4.5, I'm happy to review and integrate it.

You still have to program the MHVBoard through the USB port, as you did before. The bootloader does not support serial programming.

The TTL port is only used for programs you upload to the board that make use of the serial port.

 Those traces are already on the top layer of the PCB.

Nope, the header is the TTL port itself. The pinout should be marked on the board (+5V, Tx, Rx, Gnd).

You will need a USB to TTL serial adapter (not RS-232). They start around $5 on Ebay.

Alternatively, the long way around is to use a MAX232 to drop & invert RS232 back to TTL.

Version 201110306 includes AVR LibC 1.7.1, which fixes the delay.h bug. I have also includes the GNU Win32 tools for rm & friends (I avoided Cygwin as compatibility issues arise when you get multiple cygwin binaries floating around on the system, which each want a different cygwin DLL).