Mega Junior,1284

Bob, ya beat me to it by 1-minute. BTW, on another thread someone said the I2C pins are
not "fully open-drain" [or somesuch, whatever that means], so you cannot get I2C on a 5V
chip to talk to I2C on a 3.3V chip properly, or you'll overdrive the 3.3V pins. Do you know
anything thing about this?

For SDA and SCL the pins are 16 and 17

static const uint8_t SDA = 17;
static const uint8_t SCL = 16;

But what 16 and 17? Pins of the chip? Cannot be. The datasheet states for the PDIP Package
that SDA is pin 23 and SCL is pin 22 for TQFP/QFN/MLF the pins are SDA 20 and SCL 19

So I'm very confused with that listing:

Can someone explain what this is all about?

static const uint8_t SS   = 4;
static const uint8_t MOSI = 5;
static const uint8_t MISO = 6;
static const uint8_t SCK  = 7;

static const uint8_t SDA = 17;
static const uint8_t SCL = 16;
static const uint8_t LED = 7;

static const uint8_t A0 = 24;
static const uint8_t A1 = 25;
static const uint8_t A2 = 26;
static const uint8_t A3 = 27;
static const uint8_t A4 = 28;
static const uint8_t A5 = 29;
static const uint8_t A6 = 30;
static const uint8_t A7 = 31;

Thank you very much,
Michael.

@oric_dan,
If the internal pullups to 5V are turned off, see 22.5.1, then external pullups to 3.3V can be used for interfacing to 3.3V devices.

22.2.2 Electrical Interconnection
As depicted in Figure 22-1, both bus lines are connected to the positive supply voltage through pull-up resistors.
The bus drivers of all TWI-compliant devices are open-drain or open-collector. This implements a wired-AND function
which is essential to the operation of the interface. A low level on a TWI bus line is generated when one or
more TWI devices output a zero. A high level is output when all TWI devices tri-state their outputs, allowing the
pull-up resistors to pull the line high. Note that all AVR devices connected to the TWI bus must be powered in order
to allow any bus operation.
The number of devices that can be connected to the bus is only limited by the bus capacitance limit of 400 pF and
the 7-bit slave address space. A detailed specification of the electrical characteristics of the TWI is given in ”Twowire
Serial Interface Characteristics” on page 313. Two different sets of specifications are presented there, one relevant
for bus speeds below 100kHz, and one valid for bus speeds up to 400kHz.

22.5.1 SCL and SDA Pins
These pins interface the AVR TWI with the rest of the MCU system. The output drivers contain a slew-rate limiter in
order to conform to the TWI specification. The input stages contain a spike suppression unit removing spikes
shorter than 50 ns. Note that the internal pull-ups in the AVR pads can be enabled by setting the PORT bits corresponding
to the SCL and SDA pins, as explained in the I/O Port section. The internal pull-ups can in some systems
eliminate the need for external ones.

@Mkroll,
If you look at these 3 arrays:
const uint8_t PROGMEM digital_pin_to_port_PGM[] =

const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[] =

const uint8_t PROGMEM digital_pin_to_timer_PGM[] =

The first assigns Ports to software-named pins, (D0-31)
the second assigns pins within the ports, (also for D0-31)
the third assigns whether the pin has a timer associated with it for PWM (for D0-31 again).

Linking them together, you can see that PC0 is D16 and PC1 is D17.
Reviewing the '1284 datasheet, PC0 is SCL and PC1 is SDA.

Then it is up to the user to connect the physical pin for PC0 and PC1 to the I2C devices.
The code does not know or care which physical package the chip die is in, only that PC0 and PC1 will be manipulated for I2C.

There also a couple other lines that map analog pins to digital pins, and PWM pins to digital pins

#define analogInputToDigitalPin(p) ((p < NUM_ANALOG_INPUTS) ? (p) + 24 : -1)

#define digitalPinHasPWM(p) ((p) == 3 || (p) == 4 || (p) == 6 || (p) == 7 || (p) == 12 || (p) == 13 || (p) == 14 || (p) == 15)

and similar for PCINTs:
(Pin Change Interrupt Control Register, and Pin Change Mask Register, names are something along those lines)

#define digitalPinToPCICR(p) (((p) >= 0 && (p) < NUM_DIGITAL_PINS) ? (&PCICR) : ((uint8_t *)0))
#define digitalPinToPCICRbit(p) (((p) <= 7) ? 1 : (((p) <= 15) ? 3 : (((p) <= 23) ? 2 : 0)))
#define digitalPinToPCMSK(p) (((p) <= 7) ? (&PCMSK2) : (((p) <= 13) ? (&PCMSK0) : (((p) <= 21) ? (&PCMSK1) : ((uint8_t *)0))))
#define digitalPinToPCMSKbit(p) ((p) % 8 )

oric_dan:
jbaum is using the fix that was discovered on a couple of incredibly long threads about 1284
RX0 problems from back in february 2013. With the fuse bit settings used in the maniac 1284
bootloader files [low power oscillator], chip operation is disrupted because of crosstalk between
RX0 and the crystal pins. Maniacbug still hasn't fixed his files.

Hi oric_dan,
yea i have read a lot of this - it makes sens to use the full swing if you dont care about power..
my main question is :
Why is the CKOUT activated?

sunny greetings stefan

Why is the CKOUT activated?

I'm not sure what you're referring to. CKOUT = pin 2 on the chip?

You only need to use the XTAL1,XTAL2 pins.

Hey all,

you are right - CKOUT is PB1 == pin number 2 on the dip == pin number 41 on the TQFP;
he maps PB1 to Arduino D1 (check in the pins_arduino.h file)

if i interpret the fuse settings right -
the fuse for CKOUT is set - so it would output the cpu_clock on this pin.
and that means you cant use this pin as Digital IO -
so i just want to know why jbaum has choose to do this.
it could be that i have misunderstood the datasheet..
pleas check my explanation / table in my earlier post
if i have all thinks understood right - it shows - what the settings i have found in the make file - would mean...
iam in the process of learning about bootloaders - so i want just to understand what is going on...
sunny greetings stefan

Hmmm, I'm no expert on these darn fuses, but I think you had your original post
"backwards". 0xD = 1101, not 1011.

CKDIF8  CKOUT  SUTn  CKSELn   hex    comment
               1 0   3 2 1 0       
1       1      1 1   0 1 1 1   0xF7  Full swing Crystal Oscillator, slowly rising power;  mighty modified;
1       0      1 1   0 1 1 1   0xD7  Full swing Crystal Oscillator, slowly rising power, CKOUT Enabled; <--your version?!
1       1      1 1   1 1 1 1   0xFF  Low Power Crystal Oscillator,  slowly rising power; mighty optiboot;
Table 27-5. Fuse Low byte.
Fuse Low byte Bit no. Description Default value
CKDIV8 (4)    7 Divide clock by 8        0 (programmed)
CKOUT (3)     6 Clock output             1 (unprogrammed)
SUT1          5 Select start-up time     1 (unprogrammed) (1)
SUT0          4 Select start-up time     0 (programmed) (1)
CKSEL3        3 Select Clock source      0 (programmed) (2)
CKSEL2        2 Select Clock source      0 (programmed) (2)
CKSEL1        1 Select Clock source      1 (unprogrammed) (2)
CKSEL0        0 Select Clock source      0 (programmed) (2)

thanks oric_dan!
your right-
i have get it the wrong way-
so i will update my original post!
the fuse settings mean: Brown Out Detection enabled for the Power Condition.

Thanks!!

Hi jbaum81,

i have tried to use your 20Mhz Version on Breadboard.
installed with an Arduino Duemilanove (328) with Arduino ISP sketch.
the ide tolled me it was successfull.
when i try to upload a sketch (the blink example)
i get an out of sync error

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\_Local_DATA\_tools\_Develop\_app_arduino\arduino-1.0.5\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM19
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: 
avrdude: stk500_getsync(): not in sync: resp=0x00

avrdude done.  Thank you.

the led on PB0 is flashing 3times on reset - so i know the reset is triggered -
but somehow the chip is not answering.
if i test it with your 16MHz version all is fine
the only thing i change on the breadboard is the crystal.

i have used the tools from Nick Gammon
(Atmega1284P minimal board and nickgammon / arduino_sketches)
his Fuse Calculator shows:

Atmega fuse calculator.
Written by Nick Gammon.
Entered programming mode OK.
Signature = 0x1E 0x97 0x05 
Processor = ATmega1284P
Flash memory size = 131072
LFuse = 0xD7 
HFuse = 0xD6 
EFuse = 0xFD 
Lock byte = 0xCF 
Clock calibration = 0x83 
OCD Enable.............................. [ ]
JTAG Enable............................. [ ]
Enable Serial (ICSP) Programming........ [X]
Watchdog Timer Always On................ [ ]
Preserve EEPROM through chip erase...... [X]
Boot into bootloader.................... [X]
Divide clock by 8....................... [ ]
Clock output............................ [ ]
Bootloader size: 1024 bytes.
Start-up time: SUT0: [ ]  SUT1: [X] (see datasheet)
Clock source: full-swing crystal.
Brownout detection at: 2.7V.

His Board Detector Shows

Atmega chip detector.
Entered programming mode OK.
Signature = 1E 97 05 
Processor = ATmega1284P
Flash memory size = 131072
LFuse = D7 
HFuse = D6 
EFuse = FD 
Lock byte = CF 
Clock calibration = 83 
Bootloader in use: Yes
EEPROM preserved through erase: Yes
Watchdog timer always on: No
Bootloader is 1024 bytes starting at 1FC00

Bootloader:

1FC00: 11 24 84 B7 14 BE 81 FF E7 D0 85 E0 80 93 81 00 
1FC10: 82 E0 80 93 C0 00 88 E1 80 93 C1 00 86 E0 80 93 
1FC20: C2 00 85 E1 80 93 C4 00 8E E0 C0 D0 20 9A 86 E0 
1FC30: 2C E3 3B EF 91 E0 30 93 85 00 20 93 84 00 96 BB 
1FC40: B0 9B FE CF 18 9A A8 95 81 50 A9 F7 EE 24 FF 24 
1FC50: BB 24 B3 94 A1 E1 CA 2E F3 E0 DF 2E 9B D0 81 34 
1FC60: 59 F4 98 D0 08 2F A8 D0 02 38 39 F1 01 38 09 F4 
1FC70: 7F C0 83 E0 87 D0 83 C0 82 34 11 F4 84 E1 03 C0 
1FC80: 85 34 19 F4 85 E0 A0 D0 7A C0 85 35 91 F4 82 D0 
1FC90: 08 2F 10 E0 7F D0 E8 2E FF 24 FE 2C EE 24 E0 2A 
1FCA0: F1 2A 8F 2D 88 1F 88 27 88 1F 8B BF EE 0C FF 1C 
1FCB0: 65 C0 86 35 21 F4 84 E0 87 D0 80 E0 DB CF 84 36 
1FCC0: 09 F0 41 C0 67 D0 66 D0 08 2F 64 D0 80 E0 E8 16 
1FCD0: 80 EE F8 06 18 F4 F7 01 D7 BE E8 95 C0 E0 D1 E0 
1FCE0: 59 D0 89 93 0C 17 E1 F7 F0 E0 EF 16 F0 EE FF 06 
1FCF0: 18 F0 F7 01 D7 BE E8 95 5F D0 07 B6 00 FC FD CF 
1FD00: A7 01 A0 E0 B1 E0 2C 91 30 E0 11 96 8C 91 11 97 
1FD10: 90 E0 98 2F 88 27 82 2B 93 2B 12 96 FA 01 0C 01 
1FD20: B7 BE E8 95 11 24 4E 5F 5F 4F F2 E0 A0 30 BF 07 
1FD30: 51 F7 85 E0 F7 01 87 BF E8 95 07 B6 00 FC FD CF 
1FD40: C7 BE E8 95 1C C0 84 37 61 F4 24 D0 23 D0 08 2F 
1FD50: 21 D0 32 D0 F7 01 87 91 7F 01 14 D0 01 50 D1 F7 
1FD60: 0E C0 85 37 39 F4 28 D0 8E E1 0C D0 87 E9 0A D0 
1FD70: 85 E0 80 CF 81 35 11 F4 88 E0 18 D0 1D D0 80 E1 
1FD80: 01 D0 6C CF 98 2F 80 91 C0 00 85 FF FC CF 90 93 
1FD90: C6 00 08 95 80 91 C0 00 87 FF FC CF 80 91 C0 00 
1FDA0: 84 FD 01 C0 A8 95 80 91 C6 00 08 95 E0 E6 F0 E0 
1FDB0: 98 E1 90 83 80 83 08 95 ED DF 80 32 19 F0 88 E0 
1FDC0: F5 DF FF CF 84 E1 DE CF 1F 93 18 2F E3 DF 11 50 
1FDD0: E9 F7 F2 DF 1F 91 08 95 28 2E 80 E0 E7 DF EE 27 
1FDE0: FF 27 09 94 FF FF FF FF FF FF FF FF FF FF FF FF 
1FDF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE00: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE10: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE80: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FE90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FEA0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FEB0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FEC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FED0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FEE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FEF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF00: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF10: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF80: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FF90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FFA0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FFB0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FFC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FFD0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FFE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1FFF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 05 

MD5 sum of bootloader = 02 98 C3 84 86 12 DA 29 D3 94 65 05 C4 41 A0 C3 

First 256 bytes of program memory:

0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
10: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
80: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

the fuse settings look fine if i sea it right.
is there a way to check if the bootloader is flashed right and working?!
or there are other checks that i can do ?
can some one else read something out of the test tool outputs??

thanks for your help!

sunny greetings stefan

Which board did you select from the boards list, and which boards.txt file
do you have installed?

jbaum81:
On the subject of the firmware, I've found an issue with my digital numbering (some typo's) in my pins_arduino.h file while fixing it I discovered the core seems to be ignoring my port numbering for A0-A7 and always wants to make PA0 A0, PA1 A1 and so on. This appears to affect the bobuino similarly . I'm not real strong in C so it may take me a few days to get it all ironed out but if someone wants to chip in and help find a fix it would be appreciated. I think I have A0 - A5 (PA7 - PA2) working correctly once I have that I'll post the contents of the pins file.

I've been playing with the MegaJr V2 board. I downloaded the source from your google link, but it did not have the latest pins_arduino.h yet for this v2 board. So I used the SMD version, which I believe is the same?

Anyway, I found some wrong definitions and typos for the analog pin definitions.

//#define analogInputToDigitalPin(p)  ((p) == 14 || (p) == 15 || (p) == 16 || (p) == 17 || (p) == 18 || (p) == 19 
|| (p) == 26 || (p) == 27)
// should be as below
#define analogInputToDigitalPin(p)  ((p < 6) ? (p) + 14 : ((p < 8) ? (p) + 20 : -1))
const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[] =
{
	_BV(0), /*0*/
	_BV(1),
	_BV(2),
	_BV(3),
	_BV(4),
	_BV(5),
	_BV(6),
	_BV(7),
	_BV(2), /*8*/
	_BV(3),
	_BV(4),
	_BV(5),
	_BV(6),
	_BV(7), /*13*/
	_BV(7),              // changed from 0
	_BV(6),              // changed from 1
	_BV(5),              // changed from 2
	_BV(4),              // changed from 3
	_BV(3),              // changed from 4
	_BV(2), /*19*/       // changed from 5
	_BV(7),
	_BV(6),
	_BV(5),
	_BV(4),
	_BV(3),
	_BV(2), /*25*/
	_BV(1),
	_BV(0), /*27*/
	_BV(0),
	_BV(1), /*29*/
	_BV(1),
	_BV(0) /*31*/
};

After making these changes I was able to get the Adafruit 16x32 RGB LED Matrix Panel working. I was then able to get two 16x32 Panels working in cascade as a 16x64 Panel with double buffering. Looks awesome!

I was only able to do single frame buffering with the Uno, because of limited RAM. Lot's of flickering with only single buffering. But with your MegaJr v2 board, I was able to use the same interface shield without mods. So the concept does work as a drop in replacement with more RAM and Flash space.

Adafruit16by64DualMatrixPanel.jpg

i used the zip file from jbaum81 dated 04042013.1.zip
and for upload / burning the bootloader i used the
[MegaJr] Mega Junior,1284 V.1 Rev. A (16MHz) and
[MegaJr] Mega Junior,1284 V.1 Rev. A (20MHz)

boards.txt settings:

#############################################################

mega_jr_16.name=[MegaJr] Mega Junior,1284 V.1 Rev. A (16MHz)
mega_jr_16.upload.protocol=arduino
mega_jr_16.upload.maximum_size=130048
mega_jr_16.upload.speed=115200
mega_jr_16.bootloader.low_fuses=0xd7
mega_jr_16.bootloader.high_fuses=0xd6
mega_jr_16.bootloader.extended_fuses=0xfd
mega_jr_16.bootloader.path=megajr
mega_jr_16.bootloader.file=optiboot_atmega1284p_16.hex
mega_jr_16.bootloader.unlock_bits=0x3F
mega_jr_16.bootloader.lock_bits=0x0F
mega_jr_16.build.mcu=atmega1284p
mega_jr_16.build.f_cpu=16000000L
#mega_jr_16.build.core=arduino:arduino
mega_jr_16.build.core=standard
mega_jr_16.build.variant=MegaJr

##############################################################

mega_jr_20.name=[MegaJr] Mega Junior,1284 V.1 Rev. A (20MHz)
mega_jr_20.upload.protocol=arduino
mega_jr_20.upload.maximum_size=130048
mega_jr_20.upload.speed=115200
mega_jr_20.bootloader.low_fuses=0xd7
mega_jr_20.bootloader.high_fuses=0xd6
mega_jr_20.bootloader.extended_fuses=0xfd
mega_jr_20.bootloader.path=megajr
mega_jr_20.bootloader.file=optiboot_atmega1284p_20.hex
mega_jr_20.bootloader.unlock_bits=0x3F
mega_jr_20.bootloader.lock_bits=0x0F
mega_jr_20.build.mcu=atmega1284p
mega_jr_20.build.f_cpu=20000000L
#mega_jr_20.build.core=arduino:arduino
mega_jr_20.build.core=standard
mega_jr_20.build.variant=MegaJr

hiduino:
Anyway, I found some wrong definitions and typos for the analog pin definitions.

There are several known problems with the maniacbug library files, and he's not
cleaned them up as yet, but we know what to do,

s-light:
i used the zip file from jbaum81 dated 04042013.1.zip
and for upload / burning the bootloader i used the
[MegaJr] Mega Junior,1284 V.1 Rev. A (16MHz) and
[MegaJr] Mega Junior,1284 V.1 Rev. A (20MHz)
............

I assume you have the libraries located in the correct place, and the variants show
up in the IDE "Tools > Board" menu? When I get a not in sync error, it's usually because
I have the wrong board selected.

i have the thing in the hardware folder in my sketchbook folder.
and yea - the showing up in the ide -
i have used the ide to program the bootloader -
therefore i had to choos the the board type.
after the bootloader upload i just switched the Serialport to the USB-Serial Converter one and opend the blink sketch and hit upload-
so i dont changed the board type..

this evening i will redo the process step by step and document with photos - just to be sure i dont have missed something..

oric_dan:
...When I get a not in sync error, it's usually because
I have the wrong board selected.

hm - is there a possibility to check if the bootloader is running fine?
(the 3flashes after reset are visible.)
i have read long ago about a debuging mode??! or something if you have !!! in your sketch the bootloader goes in ?-mode??
i dont remember what this was about..

I have no idea what jbaum changed in his variant files. I would just try burning
the manaicbug optiboot into the chip, and use the 16-mhz version. Go to 20Mhz
later after ringing everything out, if you want to.

All of the maniacbug variants that use optiboot burn exactly the same bootloader
into the 1284P, and the only differences are how the I/O pins are remapped later
on when you burn a sketch. I would change the fuse setting in the boards.txt
file of the variant I'm burning.

I was able to burn bootloader using [MegaJr] Mega Junior,1284 V.1 Rev. A (20MHz), with a 1284P and 20MHz crystal. I was then able to upload Blink sketch without any problems. I am using the MegaJr download as is.

So it may be a problem with s-lights 20MHz crystal or something else?

hiduino:

jbaum81:
On the subject of the firmware, I've found an issue with my digital numbering (some typo's) in my pins_arduino.h file while fixing it I discovered the core seems to be ignoring my port numbering for A0-A7 and always wants to make PA0 A0, PA1 A1 and so on. This appears to affect the bobuino similarly . I'm not real strong in C so it may take me a few days to get it all ironed out but if someone wants to chip in and help find a fix it would be appreciated. I think I have A0 - A5 (PA7 - PA2) working correctly once I have that I'll post the contents of the pins file.

I've been playing with the MegaJr V2 board. I downloaded the source from your google link, but it did not have the latest pins_arduino.h yet for this v2 board. So I used the SMD version, which I believe is the same?

Anyway, I found some wrong definitions and typos for the analog pin definitions.

//#define analogInputToDigitalPin(p)  ((p) == 14 || (p) == 15 || (p) == 16 || (p) == 17 || (p) == 18 || (p) == 19 

|| (p) == 26 || (p) == 27)
// should be as below
#define analogInputToDigitalPin(p)  ((p < 6) ? (p) + 14 : ((p < 8) ? (p) + 20 : -1))






const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[] =
{
_BV(0), /0/
_BV(1),
_BV(2),
_BV(3),
_BV(4),
_BV(5),
_BV(6),
_BV(7),
_BV(2), /8/
_BV(3),
_BV(4),
_BV(5),
_BV(6),
_BV(7), /13/
_BV(7),              // changed from 0
_BV(6),              // changed from 1
_BV(5),              // changed from 2
_BV(4),              // changed from 3
_BV(3),              // changed from 4
_BV(2), /19/       // changed from 5
_BV(7),
_BV(6),
_BV(5),
_BV(4),
_BV(3),
_BV(2), /25/
_BV(1),
_BV(0), /27/
_BV(0),
_BV(1), /29/
_BV(1),
_BV(0) /31/
};




After making these changes I was able to get the Adafruit 16x32 RGB LED Matrix Panel working. I was then able to get two 16x32 Panels working in cascade as a 16x64 Panel with double buffering. Looks awesome!

I was only able to do single frame buffering with the Uno, because of limited RAM. Lot's of flickering with only single buffering. But with your MegaJr v2 board, I was able to use the same interface shield without mods. So the concept does work as a drop in replacement with more RAM and Flash space.

Didn't have a chance to read it in detail, but looks like you found the location of some of my sins, Hopefully tonight ill have time to fix up the pin numbering and publish an up to date set of files. Life has been a little hectic lately. I appreciate everyone who has been answering questions in my absence.

Also Crossroads since your a mod, can you look and see why I'm not getting emails when there are new posts? I believe I am properly configured and subscribed?

I have no control over that jbaum. Send a message to webmaster@arduino.com and ask.

Do you mean webmaster@arduino.cc ?