But avrvars.bat will set PATH, which is already deemed as not wanted.

Moreover, avrvars.bat will fail if you move the installation (as opposed to the GNU Tools which can be freely move without almost any restriction)

Please notice that I had a look at MHV to spot potential problems. I don't seek help here, I am reporting back problems that I encountered so that you can improve your distribution.

Comparing the cc1.exe dependencies for your build comparing with my 4.7.2 yields the following:

Accorning to depends, both builds need: CC1.EXE, GDI32.DLL, KERNEL32.DLL, MSVCRT.DLL, NTDLL.DLL, USER32.DLL.

In addition, the MHV build needs: ADVAPI32.DLL, RPCRT4.DLL, LIBGCC_S_DW2-1.DLL, LIBICONV-2.DLL, LIBINTL-8.DLL.

Perhaps it's a good idea to configure Binutils and GCC with --disable-nls ?

This also helps people that seek the web for help with their application code, because they post error and warning in english and not in german, tratitional chinese or khmer

Thanks Sprinter. I was using the latest published release (1.8.0). I'll build from SVN for the next release of MHV AVR Tools (at least until a new release of AVR LibC is released).

There is a problem in your installer. What I did:

1) Installed MHV_AVR_Tools_20121007.exe with "Add to Path" unchecked, OS = Win2000.

2) Renamed installation directory after install (should not matter, just for completeness)

3) Called avr-gcc by its absolute path name like
$ avr-gcc foo.c

A window will pop up, complain that libintl-8.dll cannot be found, and aborts execution.

Problem is the Windows search policy that does not allow to use LD_LIBRARY_PATH or LIBPATH together with the GCC driver in ./bin that execs, say, ./libexec/gcc/$target/$version/cc1.exe.

Windows will search for the dll in the directory where avr-gcc resides, but not in the place of cc1 et al.

Consequently, one possible fix is to copy libintl-8.dll to the latter directory.

As your installer offers not to change PATH (which is reasonable and appreciated), IMHO it should work properly.

Actually I don't understand why this library is needed in the first place. Maybe you can shed some light on that?

Hi, I have added MHV compiler toolchain support in the Em::Blocks IDE with native Atmel workspace and project loader and with AVR assembler highlighting. If the MHV tools are already installed then Em::Blocks will recognize this. Em::Blocks also supports: - PIC18, 24, 30 and 32 with Mplab8 projects import - Arm with the RealView toolchains and uVision project files - Arm with Yagarto toolchain The current version is 1.80 and at version 2.0 the GDB debugger is a part of the install package. The debugger will support Arm, MIPS, Avr and MSP430. Only the windows version is available right now. You can find the tool here: http://www.emblocks.org/forum/viewtopic.php?f=1&t=37 Maybe this is an interesting tool for your community.

Hi,

The Makefiles in MHVLib use avr-size, so you can use that as a starting point.

Hello, Great hack!

Can I use Arduino Mega 1260 or 2560?

God blesses!!!

Best regards,

Sanyaade

In R2, setTimes is declared inline, so the compiler can optimise away the bulk of it.

Hi Mark,

Sorry, I haven't tried this myself. In principle, it should be possible so I suggest you give it a try, and let us know how you went.

 HELLO SIR,

I just gone through this site and I found it really interesting.

I am currently working on Sure electronics's LED Dot matrix display 0832(DE-DP10XV110) which has HT1632 as a led driver.

I need to interface with PIC16F1937 and display. I am using C code. I try to run but nothing happened.

can you please help me?

Hello, I'm quite new to the Arduino programming but I'm am aware of the core files problems (mostly from other sources). If I install the OSX version of your files can I then use Xcode as the IDE? Can I look at the documentation for your libraries before I install them as I guess the function calls are all different and reusing published code would require a fair bit of retyping? Thanks Michael

 Hi Adam,

First of all, thank you so much for  the great effort....

really appreciated...

am very new for interfacing arduino with ht1632 as i've tried your "simple 16*24" code.. and it works some how.but don't know whether it runs probably or not !

here is a video link for what i 've made,

http://www.youtube.com/watch?v=Blq7kyojjSI&context=C3ccbaa1ADOEgsToPDskLSehAJsSaoAohYtGAHXFFr

i'll be grateful if you could contact me.

any reply will do much help.

and thanks in advance 

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.