MCUs 0

[PhilGoody]

When I ran setup.py it said MCUs 0 and there is only one MCU to choose from when starting an new project.

[jawher]

Can you provide what OS you're running on and what version of avr-gcc you're using ?

Thanks.

[PhilGoody]

Jawher,

OS X 10.9.5

Just installed CrossPack about a week ago

~ $ avr-gcc -v Using built-in specs. Target: avr Configured with: ./configure --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --prefix=/usr/local/staging.avr-gcc Thread model: single gcc version 4.1.1

~ $ avr-gcc -Wa,-mlist-devices --target-help

Target specific options: -mcall-prologues Use subroutines for function prologues and epilogues -minit-stack=STACK Use STACK as the initial value of the stack pointer -mint8 Use an 8-bit 'int' type -mmcu=MCU Select the target MCU -mno-interrupts Change the stack pointer without disabling interrupts -mno-tablejump Do not generate tablejump insns -mshort-calls Use rjmp/rcall (limited range) on >8K devices -msize Output instruction sizes to the asm file -mtiny-stack Change only the low 8 bits of the stack pointer

Known MCU names: avr1 avr2 avr3 avr4 avr5 avr6 at90s1200 attiny10 attiny11 attiny12 attiny15 attiny28 at90s2313 at90s2323 at90s2333 at90s2343 attiny22 attiny26 at90s4433 at90s4414 at90s4434 at90s8515 at90s8535 at90c8534 at86rf401 attiny13 attiny2313 attiny261 attiny461 attiny861 attiny24 attiny44 attiny84 attiny25 attiny45 attiny85 atmega603 atmega103 at43usb320 at43usb355 at76c711 atmega48 atmega8 atmega83 atmega85 atmega88 atmega8515 atmega8535 at90pwm2 at90pwm3 atmega16 atmega161 atmega162 atmega163 atmega164p atmega165 atmega165p atmega168 atmega169 atmega169p atmega32 atmega323 atmega324p atmega325 atmega329 atmega3250 atmega3290 atmega406 atmega64 atmega640 atmega644 atmega644p atmega128 atmega1280 atmega1281 atmega645 atmega649 atmega6450 atmega6490 at90can32 at90can64 at90can128 at90usb646 at90usb647 at90usb1286 at90usb1287 at94k atmega2560 atmega2561 Assembler messages: Fatal error: unknown MCU: list-devices

Phil

On Feb 7, 2015, at 5:59 AM, Jawher Moussa notifications@github.com wrote:

Can you provide what OS you're running on and what version of avr-gcc you're using ?

Thanks.

— Reply to this email directly or view it on GitHub.

[PhilGoody]

Jawher, I changed the line that searches for the mcus to proc = subprocess.Popen('avr-gcc -Wa, --target-help', stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True) and that fixed the problem. Now after getting through the wizard it gets stuck loading… What is it loading?

Regards, Phil

On Feb 7, 2015, at 5:59 AM, Jawher Moussa notifications@github.com wrote:

Can you provide what OS you're running on and what version of avr-gcc you're using ?

Thanks.

— Reply to this email directly or view it on GitHub.

[jawher]

Phil,

It's weird that you should have an avr-gcc that old (4.1): I tested the setup scripts with gcc 4.6, 4.7 and 4.8.

The lastest version of Crosspack comes with avg-gcc 4.8.1, so if you installed that, I'm suspecting you had an older version which is still polluting your path.

[PhilGoody]

Jawher, Hmm. That�s because Crosspack put all the files in /usr/local/CrossPack-AVR-20131216/bin. And the old ones (4.1.1 etc) are in use/local/bin. So how do I get the Mac to look in the correct location for the new files? Do I have to move the new ones and replace the old? Regards, Phil

On Feb 9, 2015, at 1:37 AM, Jawher Moussa notifications@github.com wrote:

Phil,

It's weird that you should have an avr-gcc that old (4.1): I tested the setup scripts with gcc 4.6, 4.7 and 4.8.

The lastest version of Crosspack comes with avg-gcc 4.8.1, so if you installed that, I'm suspecting you had an older version which is still polluting your path.

� Reply to this email directly or view it on GitHub.

[jawher]

I honestly don't know. You could always try to delete the old files by hand and/or ensure that the crosspack location appears before in your $PATH with something like the following in your .bash_profile:

export PATH=/usr/local/CrossPack-AVR-20131216/bin:$PATH

Or maybe check if you installed the old version with homebrew, in which case you can use it to update or unlink avr-gcc.

[PhilGoody]

Jawher, OK, I re-ordered the $PATH so that the CrossPack path comes before the use/local/bin instead of last. Now I get AVR-gcc version 4.8.1. So now I will try to test a small program created in Xcode. Regards, Phil

On Feb 9, 2015, at 2:10 PM, Jawher Moussa notifications@github.com wrote:

I honestly don't know. You could always try to delete the old files by hand and/or ensure that the crosspack location appears before in your $PATH with something like the following in your .bash_profile:

export PATH=/usr/local/CrossPack-AVR-20131216/bin:$PATH Or maybe check if you installed the old version with homebrew, in which case you can use it to update or unlink avr-gcc.

— Reply to this email directly or view it on GitHub.

[PhilGoody]

Jawher, Well now when building in Xcode I get the following error:

Cleaning project: rm -f Builds/main.hex sh: rm: command not found make: *\ [clean_list] Error 127 Command /Applications/Xcode.app/Contents/Developer/usr/bin/make failed with exit code 2

I�t odd since I can run rm at the command line.

Also I had to change the path in the make file to point to the new gcc tool chain. How do I make that change permanent in the template make file? Regards, Phil

On Feb 9, 2015, at 1:37 AM, Jawher Moussa notifications@github.com wrote:

Phil,

It's weird that you should have an avr-gcc that old (4.1): I tested the setup scripts with gcc 4.6, 4.7 and 4.8.

The lastest version of Crosspack comes with avg-gcc 4.8.1, so if you installed that, I'm suspecting you had an older version which is still polluting your path.

� Reply to this email directly or view it on GitHub.

[PhilGoody]

Jawher, Why is it using a WinAVR makefile? It does not work on in Max OS X. I tried removing the SHELL definition and that got me to the next error (can’t find make). This is getting tedious. If I enter ave-project in terminal it creates a project with a completely (simpler) make file. Regards, Phil

On Feb 9, 2015, at 1:37 AM, Jawher Moussa notifications@github.com wrote:

Phil,

It's weird that you should have an avr-gcc that old (4.1): I tested the setup scripts with gcc 4.6, 4.7 and 4.8.

The lastest version of Crosspack comes with avg-gcc 4.8.1, so if you installed that, I'm suspecting you had an older version which is still polluting your path.

— Reply to this email directly or view it on GitHub.

[jawher]

Why is it using a WinAVR makefile? It does not work on in Max OS X.

I does work on Mac OS X (as XCode only works on Mac OS X).

Try to recreate a new project using the wizard (the compiler and library locations are hard-coded in the Makefile once the project is generated).

Also, regarding the "rm not found" error you're getting, I think you might have messed up your PATH. Are you sure '/bin' is still in there ?

[PhilGoody]

Jawher Well I dont know where it's getting the Win make file from. I was hoping you would know. Yes, when I create a new Xcode AVR project that's what I get. That also is why the rm command doesn't work. I am pretty close to giving up on this. Regards Phil

Phil Gaudet DBA Sirius Tech 81 Pascal Ave. Rockport, ME 04856-5916 C (207) 975-0074

On Feb 9, 2015, at 17:58, Jawher Moussa notifications@github.com wrote:

Why is it using a WinAVR makefile? It does not work on in Max OS X.

I does work on Mac OS X (as XCode only works on Mac OS X).

Try to recreate a new project using the wizard (the compiler and library locations are hard-coded in the Makefile once the project is generated).

Also, regarding the "rm not found" error you're getting, I think you might have messed up your PATH. Are you sure '/bin' is still in there ?

— Reply to this email directly or view it on GitHub.

[CallumA]

I also just encountered this issue except on a much newer version of GCC ("gcc version 5.3.0 (GCC)")

The same fix mentioned earlier does work for me (swapping 'avr-gcc -Wa,-mlist-devices --target-help' for 'avr-gcc -Wa, --target-help') despite that being for a much older GCC version.

Another workaround is to add "out = out + err" after the "proc.communicate()".

Running the original command with '-mlist-devices' on GCC 5.3 returns all the devices (by --target-help) but also returns an error: "Assembler messages: Fatal error: unknown MCU: list-devices"

I believe this is causing all the assembler output to go to stderr rather than stdout, causing the problem.

In the end I guess it's a matter of choice whether you read both out and err or fix the command. I don't know if the "-mlist-devices" is required on some versions of GCC so personally feel "out = out + err" is a better solution, unless it can be confirmed that "-mlist-devices" isn't actually of use on any version of GCC.

[jawher]

Hi @CallumA, thanks for raising the issue.

I'll have a look at this as soon as I can.