Winavr easist workaround for unsuported MCU version

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

Hi AvrFreaks!

 

To make a short story long: I have some hardware PCB-mounted in China, with an Atmega48 onboard. On one series they have mounted Atmega48p (I gave them premission, because they are very compatible). My assembler/tech guy in Denmark has to program them. His computer is running OSX 12.12 (Sierra) or Windows 7 on top of it. So here are the problems:

 

- Sierra, won't install avrdude

- Atmel studio won't install on Windows 7 (for some reason, even though it should be within the system requirements)

- Newest version of Winavr does only have the Amega48 header, not the Atmega48p

- My tech guy does not seem have basic skills with computers (his not a computer tech though)

- I'm in California right now, and he is in Denmark, the other side of the globe!

- I'm getting crazy soooon!!

- I'm getting crazy soooon!!

 

So:

 

What is the easiest basic fix/workaround, to make eg. winavr (which seems to be installed by now, but it took me 1 1/2 hour on the phone, so please don't suggest installing a different compiler/environment!).

 

- Modding my own makefile, so it takes the Amega48 instead of Atmega48p, then there is just a device signature problem to fix? How to fix that in the easiest/secure way?

- Somehow dublicate the Atmega48 header and call the new one Atmega48p? How/where should that be done without making to many troubles?

 

Hope someone can help!

 

Best Regards

 

Ole.

 

 

 

 

 

 

 

Last Edited: Wed. Jan 18, 2017 - 09:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your post was not a tutorial teaching others, so I have moved it.

 

Ross McKenzie, Melbourne Australia

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

Totally fine :) I thought I was posting it in a different place sorry!

 

Best Regards

 

Ole. 

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

Why is anyone using WinAVR from late 2009 in 2017? Surely you just get:

 

http://www.atmel.com/tools/atmel...

 

That gives you a shiny new avr-gcc 4.9.2. If you want to operate at the "edge of the curve" then you can get a prebuilt 5.3.0 here:

 

http://gnutoolchains.com/download/

 

but that is built from the GNU/FSF tree not the "private" one that Atmel use so the range of AVRs is a little behind the Atmel offering.

 

You may need to source an update arvdude.exe from somewhere else to actually program the AVRs but for a 48P the avrdude that came with WinAVR (5.3 was it?) should probably be OK.

 

As the host here is OSX you may find this worth exploring too:

 

https://obdev.at/products/crossp...

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

Where in Denmark is he? (I'm in Aalborg)

 

I use the studio 4.18 with win-avr 20100110 and that works fine

 

For a new project I had to use 328PB  (I just needed the extra IO's), so the quick fix was to add :

 

#define PINE _SFR_IO8(0x0C)
#define DDRE _SFR_IO8(0x0D)
#define PORTE _SFR_IO8(0x0E)

 

and then make a 328 project 

Last Edited: Wed. Jan 18, 2017 - 10:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to "AVR512: Migration from ATmega48/88/168 to ATmega48P/88P/168P " the P version is fully backwards compatible other than in the choice of the low frequency crystal.

 

So this should reduce your problem to simply using the existing .hex file to program the P version of the chip.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Are you sure it's not mega48PB's they have installed?

 

They are different, and because the power pins have changed it could easy be a big problem! 

 

 

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

clawson wrote:
As the host here is OSX you may find this worth exploring too: ...
Homebrew is another source for macOS :

Homebrew logo

Homebrew — The missing package manager for macOS

http://brew.sh/

https://github.com/Homebrew/homebrew-core/blob/master/Formula/avrdude.rb 

...

... => :sierra

...

PlatformIO (toolchain, AVRDUDE, etc) made it into Homebrew :

http://docs.platformio.org/en/latest/history.html#id24

...

Created package for Homebrew Mac OS X Package Manager: brew install platformio (issue #395)

...


http://platformio.org/platforms/atmelavr 

 

Edit : PlatformIO

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Jan 18, 2017 - 03:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oleoleo2 wrote:
... so please don't suggest installing a different compiler/environment!).
Here it is anyway ...

oleoleo2 wrote:
- Atmel studio won't install on Windows 7 (for some reason, even though it should be within the system requirements)
https://www.avrfreaks.net/forum/atmel-studio-701188-release#comment-2032006 by charla

 

"Dare to be naïve." - Buckminster Fuller

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

clawson wrote:

Why is anyone using WinAVR from late 2009 in 2017? Surely you just get:

 

http://www.atmel.com/tools/atmel...

 

That gives you a shiny new avr-gcc 4.9.2. If you want to operate at the "edge of the curve" then you can get a prebuilt 5.3.0 here:

 

http://gnutoolchains.com/download/

 

but that is built from the GNU/FSF tree not the "private" one that Atmel use so the range of AVRs is a little behind the Atmel offering.

 

You may need to source an update arvdude.exe from somewhere else to actually program the AVRs but for a 48P the avrdude that came with WinAVR (5.3 was it?) should probably be OK.

 

As the host here is OSX you may find this worth exploring too:

 

https://obdev.at/products/crossp...

 

Thanks Clawson!

 

And anybody else giving advices! There are no particular reason other than "If if works don't fix it reasons" for running an old Winavr. And it obviously didn't in this case :) 

 

I will check it out! (and look through the other answers as well)

 

Best Regards

 

Ole. 

 

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

I'm struggling to follow along here, perhaps you've missed out a part of the story:

 

How did the Production Guy program the original Atmega48 boards ?

I imagine he's getting a Signature Doesn't Match style error. Yes  or No ?

 

Is the Production Guy's MAC (that's a WTF in itself) largely irrelevant and it is in fact, a development problem for you ?

 

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

oleoleo2 wrote:

clawson wrote:

 

Why is anyone using WinAVR from late 2009 in 2017? Surely you just get:

 

http://www.atmel.com/tools/atmel...

 

That gives you a shiny new avr-gcc 4.9.2. If you want to operate at the "edge of the curve" then you can get a prebuilt 5.3.0 here:

 

http://gnutoolchains.com/download/

 

but that is built from the GNU/FSF tree not the "private" one that Atmel use so the range of AVRs is a little behind the Atmel offering.

 

You may need to source an update arvdude.exe from somewhere else to actually program the AVRs but for a 48P the avrdude that came with WinAVR (5.3 was it?) should probably be OK.

 

As the host here is OSX you may find this worth exploring too:

 

https://obdev.at/products/crossp...

 

Thanks Clawson!

 

And anybody else giving advices! There are no particular reason other than "If if works don't fix it reasons" for running an old Winavr. And it obviously didn't in this case :) 

 

I will check it out! (and look through the other answers as well)

 

Best Regards

 

Ole. 

 

 

Ok, I have installed the avr-gcc5.3.0.exe

 

So, how do I select the version / fix the toolchain?

 

Ole.

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

oleoleo2 wrote:
So, how do I select the version / fix the toolchain?
Don't understand those questions.

 

The 5.3 usually installs to c:\sysgcc (I think it was) . The avr-gcc.exe should be in a ...\bin directory beneath there. You just ensure that directory is on PATH then all the tools (avr-gcc, avr-objdump, avr-objcopy etc) should be available to execute in any directory.

 

I have no idea what you mean by "fix the toolchain". What "fixing" needs to be done?

 

(I did have that 5.3 installed on this PC for a while but it got blitz last time I was grubbing around for the odd 16GB to spare!)

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

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

...

G:\SysGCC\bin>avr-gcc.exe -v
Using built-in specs.
Reading specs from g:/sysgcc/bin/../lib/gcc/avr/5.3.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc.exe
COLLECT_LTO_WRAPPER=g:/sysgcc/bin/../libexec/gcc/avr/5.3.0/lto-wrapper.exe
Target: avr
Configured with: ../gcc-5.3.0/configure --target avr --enable-win32-registry=SysGCC-avr-5.3.0 --enable-languages=c,c++ --disable-nls --without-libiconv-prefix --prefix /q/gnu/
auto/bu-2.25+gcc-5.3.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2-avr/ --host i686-pc-mingw32 --disable-shared --with-avrlibc=yes
Thread model: single
gcc version 5.3.0 (GCC)

G:\SysGCC\bin>

"Dare to be naïve." - Buckminster Fuller