Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

standard pin mapping #9

Closed
wothke opened this issue Jun 25, 2016 · 15 comments
Closed

standard pin mapping #9

wothke opened this issue Jun 25, 2016 · 15 comments
Labels

Comments

@wothke
Copy link

wothke commented Jun 25, 2016

I want to use an ATmega128 as an upgrade for my existing ProMini328 based circuit and am trying to get the respective pin mapping right (so as to reuse my existing code with minimal changes): 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. (similarilly there is a mismatch between the SS,SCK,MOSI,MISO pins and the standard Arduino digital pin assignment, e.g. MOSI=D11 not D10). Finally, what pins are the Arduino digital pins 2-7 mapped to: PE2-PE7?

Thanks for your help

@MCUdude
Copy link
Owner

MCUdude commented Jun 25, 2016

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

@wothke
Copy link
Author

wothke commented Jun 25, 2016

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?

@MCUdude
Copy link
Owner

MCUdude commented Jun 25, 2016

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

@wothke
Copy link
Author

wothke commented Jun 26, 2016

perfect :-)

@wothke
Copy link
Author

wothke commented Jun 27, 2016

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?

@MCUdude
Copy link
Owner

MCUdude commented Jun 27, 2016

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

@wothke
Copy link
Author

wothke commented Jun 27, 2016

Thx! and have a nice vacation :-)

@per1234
Copy link
Contributor

per1234 commented Jun 27, 2016

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.

@MCUdude
Copy link
Owner

MCUdude commented Jun 27, 2016

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 😉

@per1234
Copy link
Contributor

per1234 commented Jun 27, 2016

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.

@wothke
Copy link
Author

wothke commented Jun 28, 2016

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);?

@MCUdude
Copy link
Owner

MCUdude commented Jun 28, 2016

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?

@wothke
Copy link
Author

wothke commented Jun 28, 2016

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

@MCUdude
Copy link
Owner

MCUdude commented Jun 28, 2016

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!

@wothke
Copy link
Author

wothke commented Jun 28, 2016

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 :-)

@MCUdude MCUdude closed this as completed Jun 30, 2016
MCUdude added a commit that referenced this issue Feb 28, 2020
 Update MightyCore core folder name in .travis.yml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants