standard pin mapping about megacore HOT 15 CLOSED

Actually that was a surprise for me too.. For a while I had been quite happy with the inexpensive ProMini328's but with my 1st slightly bigger project I ran into the 32kB FLASH limitation rather quickly - and tried to find a cheap upgrade that would get me just a bit more FLASH. Most people suggested to upgrade to ATMEGA1280/2560 - which seems a bit expensive when all you need is a little bit more FLASH..

I am happy that I came across your page :-)

from megacore.

According to your pinout graph I am inclined to think that PF4 corresponds to Arduino analog A4 but the graph also suggests that the hardware SDA pin is PD1 - my existing Arduino ProMini code expects that A4 and SDA is actually the same pin (similarly there is a mismatch between the SS,SCK,MOSI,MISO pins and the standard Arduino digital pin assignment, e.g. MOSI=D11 not D10).

On the ATmega64/128 A4 is located at PF4, but SDA and SCL are not located at Arduino pin A4 and A5, but Arduino pin 19 and 18 (PD1 and PD0). It's how the microcontroller is designed, so there's nothing I can do to change this. There should not be a problem using pin 18 and 19 instead. When you're calling Wire.begin(), the library automatically selects the correct pins for SDA and SCL. The same goes for the SPI interface to. if you want to refer to the SDA or SCK pin in your code, use the name SDA og SCL directly. as you can see in the pins_arduino.h file, these names (and the SPI pins too) are already predefined here.

Finally, what pins are the Arduino digital pins 2-7 mapped to: PE2-PE7?

As you can see in the pinout diagram on the first page PE2 - PE7 corresponds to D2 - D7

from megacore.

thx! (I must have been blind to miss the "Arduino PIN" IDs.) Is there some ATmega128 specific define that I could base some #ifdefs on - just in case I might need to do some ProMini328/ATmega128 distinction in my code?

from megacore.

You can always use #if defined(__AVR_ATmega64__) || defined(__AVR_ATmega128__) to make some hardware specific code 😉

from megacore.

perfect :-)

from megacore.

another noob question: I just installed Arduino 1.6.4 IDE and MegaCore. Also I installed libusb_0.1.12.1 for the programmer. The "Burn Bootloader" seems to succeed but within the respective console log I see the below warning:
avrdude: auto set sck period (because given equals null) avrdude: warning: cannot set sck period. please check for usbasp firmware update.

Is that something to be worried about?

from megacore.

I'm on vacation right now, but I believe I got the same warning too. You shouldn't worry about it if it still works

from megacore.

Thx! and have a nice vacation :-)

from megacore.

avrdude: auto set sck period (because given equals null) avrdude: warning: cannot set sck period. please check for usbasp firmware update.

That can be safely ignored. For more information, and how to upgrade the firmware, see: https://forum.arduino.cc/index.php?topic=363772.0

This warning is caused by a proprietary firmware found on the clone USBasps. It is actually superior to the official USBasp firmware. Once you change the firmware you can never go back to the proprietary firmware. There is an experimental firmware version in development listed at that link that does have some significant improvements but if you want to try it I'd definitely make sure to have a spare USBasp that you leave the stock firmware on in case you have problems with the upgrade.

from megacore.

What's new in the "new" USBasp firmware? And what makes the proprietary firmware superior to the original one? I'm using a USBtinyISP and AVRISPmkII, so I'm just curious 😉

from megacore.

What's new in the "new" USBasp firmware?

The thing that originally led me to it is that it allows me to Upload Using Programmer to ATmega2560 with the standard fuse settings(see https://petervanhoyweghen.wordpress.com/2015/12/02/the-usbasp-and-atmega2560-mystery). It allows you to flash images >128KB. Automatic sck clock rate selection. Compatible with ATmega48 based USBasps. Fixed some SPI bugs. Drag and drop utility for flashing the USBasp firmware.

what makes the proprietary firmware superior to the original one?

It has some way of being compatible with certain clock speeds that the Fischl firmware doesn't work well with. Details are a bit fuzzy since it's not open source and to be honest some of this stuff is a bit over my head. There's a ton of info on that forum thread if you feel like doing a lot of reading to find it.

With the new firmware the USBasp seems to be the best programmer choice. I haven't found any cases where it doesn't work and the price is certainly reasonable. I started with Arduino as ISP but quickly encountered its limitations and bought the Atmel AVRISP mkII, assuming it was worth the investment because it would fill all my needs. Then I ran into the mkII's incompatibility with recent versions of the Arduino IDE and Windows(arduino/Arduino#2986) and was forced to start using the USBasp I had bought as a cheap backup. The one thing I still like about the mkII is the automatic logic level detection but it's kind of annoying having to separately power the target board.

from megacore.

Am I missing something with regards to Interrupt pins? By looking at the "ATmega64/128 standard pinout" I would think that I cannot use INT0 + INT1 when I already depend on these pins for my I2C stuff (see SCL/SDA).

But when I look at the RF22.h lib that I am also using, at least this lib (and it might not be the only one) seems to be very limited in its ideas regarding how many INT pins there might be:
// Set up interrupt handler if (_interrupt == 0) { _RF22ForInterrupt[0] = this; attachInterrupt(0, RF22::isr0, LOW); } else if (_interrupt == 1) { _RF22ForInterrupt[1] = this; attachInterrupt(1, RF22::isr1, LOW); } else return false;

=> from what I see I would like to use something between INT4 and INT7 to avoid any I2C clashes.. Do I need to patch all the respective libs to achieve that, or is there a better way?

Could your standard pinout be changed such that the INT0-INT3 and the INT4-INT7 mappings are just switched?

Does your "core" support the mappings for all the INT* - such that it would correctly handle attachInterrupt(7);?

from megacore.

I'm not able to remap the interrupt pins. I'm only able to remap the analog and digital pins. My best guess would be to edit your library your self, or create an issue at the library repo and explain your problem there. IMO it's bad practice to make a library like that hardware dependent to the microcontroller. Maybe the author will include some #ifdefs to fix this?

from megacore.

thanks for the feedback. I'll just patch the lib then..

from megacore.

But it's great to see that someone's still interested in using the ATmega128, even if it's quite old. I created this core a few months ago, and I was surprised that no one had ever done this before! The ATmega128 is quite capable with its 128kB and 53 IO pins. And the price at less than a dollar is just unbeatable!

from megacore.