Yep, I did a crude test by substituting the iotn2313.h in place of the iotn4313.h file and the t4313@1MHz worked fine with serial activity.

I think this is similar to other definition problems in the iotn4313.h file you had, relating to your other post.

I'll see if the Atmel AVRToolchain is any different.

Edit: Nope, still the same files in Atmel Studio 6.0 AVRToolchain.  I haven't tried checking Atmel Studio 6.1 yet.

The WinAVR-20100110 toolset will add support for the t4313 and others, but not the t1634.

The Atmel AVRtoolchain will add support for the t1634.

Is there any drawback to the Atmel AVRtoolchain?

I can confirm the same problem with my t4313 @ 1MHz.  Higher 8 and 16MHz seem to be okay.

However, I also tried it with a t2313 @ 1MHz, and it works fine.  No delays with serial active.  So it may be something with the t4313 files.  I am thinking it may be something with the include\avr\iotn4313.h file.

Pighixxx's diagram for the T84/44 are not correct for the Attiny-core.  I don't know which core he is referencing, but his number is backwards.  I would not use that.

Check out this one instead.  http://www.akafugu.jp/images/microcontroller-reference-sheet.png
This should work correctly with Attiny-core.

You need to add support for it to the tiny-core files.  I believe INPUT_PULLUP is a newer feature support that was added after tiny-core was developed.

\hardware\tiny\cores\tiny\wiring.h:

Code:

#define INPUT 0x0
#define OUTPUT 0x1
#define INPUT_PULLUP 0x2

\hardware\tiny\cores\tiny\wiring_digital.c, replace the pinMode function with this:

Code:

void pinMode(uint8_t pin, uint8_t mode)
{
uint8_t bit = digitalPinToBitMask(pin);
uint8_t port = digitalPinToPort(pin);
volatile uint8_t *reg, *out;

if (port == NOT_A_PIN) return;

// JWS: can I let the optimizer do this?
reg = portModeRegister(port);
out = portOutputRegister(port);

if (mode == INPUT) {
uint8_t oldSREG = SREG;
                cli();
*reg &= ~bit;
*out &= ~bit;
SREG = oldSREG;
} else if (mode == INPUT_PULLUP) {
uint8_t oldSREG = SREG;
                cli();
*reg &= ~bit;
*out |= bit;
SREG = oldSREG;
} else {
uint8_t oldSREG = SREG;
                cli();
*reg |= bit;
SREG = oldSREG;
}
}

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?

Are you testing with a Leonardo or your own circuit?

If with the Leonardo, did you burn the latest bootloader?  Most shipping Leonardos have the older bootloader with the 8 second delay.  I believe you need IDE v1.0.3 or later that has the correct fixes for skipping the bootloader on power-on.

Why don't you just program the t85 with an external 16MHz crystal, then later change the fuse settings to internal clock settings.

To clarify, the IDE does not need to have Optiboot present in the file system to talk to Arduinos.  It is only needed if you want to burn bootloader.

However, yo do need to have the proper boards.txt entries to select the proper Tools->Board type, so that it will communicate at the proper serial baud rate.

So for a fresh IDE install you should be able to talk to any Arduino as long as you have the proper Board definition to select from.

For the proper low speed mode detection make sure your UCAP is at the proper 3.3V level.

From the Atmel datasheet:

21.8 Speed Control
The speed selection (Full Speed or Low Speed) depends on the D+/D- pull-up. The LSM bit in
UDCON register allows to select an internal pull up on D- (Low Speed mode) or D+ (Full Speed
mode) data lines.

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.

Code:

//#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))

Code:

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.

I got a bunch of these https://www.sparkfun.com/products/8508 to breakout either the 6-pin or 10-pin ICSP headers to a breadboard.  They work great.  Unfortunately it looks like they currently are on backorder.

To disable auto reset on serial connection on arduino, i added 10uf between pin-1 and ground, and 110 ohm between pin-1 and Vin. Also for the target atmega i have added a 10k between pin-1 and Vin.

You should not be connecting to Vin.  Vin is NOT 5V.  You should be using the 5V pin for pull-up resistors.

Didn't you already post this question before?  I think they answered you best they can without know more about what your circuit does.  There are many variables to programming and without know more details we can only guess at it.

So you have a product.  It is using 30 pro minis.  You want to program it "in circuit".  You only want one port to program all 30  pro minis.  What kind of reliability do you need?  Is this a non-critical application so if a chip fails to program correctly it will not cause a catastrophic failure or injure someone?  Why must you program all 30 at once?  Is due to operational issues or just convenience?

Note ISP programming is not just for burning bootloaders.  It can be used for uploading sketches too.  Programming "in circuit" requires the use of special ISP pins, MOSI, MISO, SCK, and RESET.  Are you using these pins for other functions?  If so you will need to alter your circuit for multiplexing pin usage.

Bottom line is we need more details of what you are trying to accomplish.

Are you selecting "Upload Using programmer" instead of just "Upload"?