[SOLVED] ATtiny85, ATTinyCore .need a lead on a tuner program, Optiboot

EDIT: Solved. Bootloader burned, Optiboot loads sketches to ATtiny85 using 8MHz internal, no fine tuning.

So I got a Sparkfun AVR Pocket Programmer (USBTiny ISP) and ATtiny85 to play with. I’m new to using Arduino and I have been successful in using the Arduino Uno R1 with Windows 7 x64 to play around.

Jumping into ATtiny85 (I like the size!), I installed the ATTinyCore by adding the boards manager URL, then adding it.

I found some example C code for the ATtiny85 compiled using avrdude, but I guess the #include is not used when using the Arduino IDE to compile? Namely #include <avr/pgmspace.h>?

Because this works:

//  #include <avr/pgmspace.h>

void setup() {
  // Power saving
  // Disable the ADC by setting the ADEN bit (bit 7)  of the ADCSRA register to zero.
  ADCSRA = ADCSRA & B01111111;
  // Disable the analog comparator by setting the ACD bit (bit 7) of the ACSR register to one.
  ACSR = B10000000;
  // Disable digital input buffers on all analog input pins by setting bits 0-5 of the DIDR0 register to one.
  DIDR0 = DIDR0 | B00111111;
  // initialize digital pin PB3 as an output.
  DDRB = B00001000;

}

void loop() {
    
    // set PB3 high
    PORTB = B00001000;
    Serial.println("PB3 high"); 
    delay(1000);
    // set PB3 low
    PORTB = B00000000;
    Serial.println("PB3 low");
    delay(1000);

  }

Using these settings under the tools menu: Board: “ATtiny25/45/85 (No bootloader)”, Chip: “ATtiny85”, Clock: “1 MHz (internal)”…

For whatever reason, it compiles, but then I need to use “Export compiled Binary” because the Arduino IDE fails to flash it. That’s fine, I’ve been learning to use avrdude, and after adding some path environment variables, I use it to flash the exported hex file.

C:\Users\Owner\Documents\Arduino\ATtinyBlink>avrdude -p t85 -c usbtiny -U flash:
w:ATtinyBlink.ino.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be perform
ed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "ATtinyBlink.ino.hex"
avrdude: input file ATtinyBlink.ino.hex auto detected as Intel Hex
avrdude: writing flash (1160 bytes):

Writing | ################################################## | 100% 2.95s

avrdude: 1160 bytes of flash written
avrdude: verifying flash memory against ATtinyBlink.ino.hex:
avrdude: load data flash data from input file ATtinyBlink.ino.hex:
avrdude: input file ATtinyBlink.ino.hex auto detected as Intel Hex
avrdude: input file ATtinyBlink.ino.hex contains 1160 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.08s

avrdude: verifying ...
avrdude: 1160 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:D7, L:62)

avrdude done.  Thank you.

So that’s great! I have .1 uF caps on pin 5 and 8 to ground, but when I use the flasher, avrdude gets the wrong signature if I tie the AVR Pocket Programmer ground to pin 4, then also to a common ground that the caps are tied to.

Anyway, it flashed. Then I decided to try to get the Optiboot on there.

Shall I just flash the one: optiboot_attiny85_8000000L.hex

And will that set the clock to 8MHz internal? Or do I adjust a fuse bit?

Back in the Arduino IDE I once was able to hit burn bootloader and somehow it worked, but it won’t work now. I guess it tried to put Optiboot on there?

I flash the optiboot_attiny85_8000000L.hex, I think maybe I need to tune the chip, yes?
I found an older tuner example, but it didn’t work for me and wasn’t written for this core.

Is there a tuner program example for this core?

I ask because I’m interesting in how to get optiboot going to upload sketches via serial.

Or, just trying to get a software serial working.

I see on the ATTinyCore page, that for the ATtiny85 (it uses USI), there is a Serial function.

How do I include it, and then do I just add:

Serial.begin(9600);
Serial.println("start");

to setup like usual?

I found this code, but it didn’t work for me: https://www.hackster.io/porrey/easy-serial-on-the-attiny-2676e6

#include <SoftwareSerial.h>
// ***
// *** Define the RX and TX pins. Choose any two
// *** pins that are unused. Try to avoid D0 (pin 5)
// *** and D2 (pin 7) if you plan to use I2C.
// ***
#define RX    3   // *** D3, Pin 2
#define TX    4   // *** D4, Pin 3

// ***
// *** Define the software based serial port. Using the
// *** name Serial so that code can be used on other
// *** platforms that support hardware based serial. On
// *** chips that support the hardware serial, just
// *** comment this line.
// ***
SoftwareSerial Serial(RX, TX);

Also, I found a Blink example online that used avrdude and a make file. I got that to work once I installed WinAVR, but I then I removed it because the version of avrdude shipped with it doesn’t support the USBTiny type programmers. I tried adding a new avrdude and avrdude.conf to WinAVR, but it hosed up Arduino compiling… every time I used the Arduino IDE to compile after that, it would work but avrdude would crash in Windows.

I’m starting to think I need to go back to my days of dual-booting Linux Mint or something so that all the GNU based stuff works better. The GNU utilities and GCC seem to integrate better under the Linux kernel.

I don’t know, I’m trying to find the best formula for playing with ATtiny85!

Oh, and I use the FT231x 3.3v breakout from Sparkfun to do USB to Serial TTL. I can use it to open up a serial monitor on my Arduino Uno, so I know it works, but now I want to test on the ATtiny85.

I do use .1 uF caps from Vcc to ground, and also from AREF to ground while I have attempted to make a serial connection. I think it is correct, and I power the chip with the FTDI for convenience. It can only handle 500mA though. I burned a .hex with some serial stuff, but didn’t see anything on Putty (COM4, 9600, 8,N,1).

Once last thing, the makefile I found set the clock to internal 8MHz. Is this something that can be done with avrdude at the command line, or using the Arduino IDE, or do I need a makefile?

I see that once I have the bootloader, I need to communicate with the chip using pins 5 and 6 , AIN0, AIN1. It is at 19200. OK, I guess I did it wrong because there was nothing in Putty.

Thanks so much!

Use the SLOW programmer option to flash a 1 MHz part with USBTinyISP - I changed the settings for USBTinyISP in the most recent release (have already change the names of those programmer options to clarify that), because the old "fast" option was nearly as slow as the slow one, and I tried to use it as a general use programmer, uploaded a couple of times, and it was just insanely slow.

Fuses are needed to change the clock speed. Use the Burn Bootloader option from the IDE, with the "slow" option selected if it's currently set to 1MHz. This is done by the "burn bootloader" function from the IDE.

I have only ever used a makefile for one thing in Arudino-land, and that is to build optiboot.

What I do for building with makefiles in that case, is to download Arduino 1.0.6 .zip version, extract that, and then copy the latest toolchain over the old one (The most updated one is this AFAIK currently: https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azzy1-i686-w64-mingw32.zip though the one from latest IDE will work unless you want to use the latest Dx-series parts). NEVER actually install WinAVR (or rather, don't let it put anything into the PATH), as that breaks stuff.

If you then copy the bootloaders folder from ATTinyCore into (updated-compiler-1.0.6 root)/hardware/arduino/bootloaders) after deleting the optiboot folder that was there before for the stock bootloaders that you're unlikely to be rebuilding anyway, especially since the codebase is ancient. Arduino uses an ancient version of optiboot, even in latest versions), and then all the tooling will work... though I know this isn't really what you're asking about)

What I'm saying though, is that you don't ever need to mess with makefiles. Everything can be done from within the Arduino IDE except blowing RSTDSBL fuse on non-micronucleus board definitions, because that makes it unreprogramable without an HV programmer which nobody has, and I don't want to leave traps for people, because then people brick their chips and complain to me about it.

Most attiny parts are close enough to work for UART at room temp and 3.3~5v without tuning. Lately people have been reporting that they have ones that don't work, but I don't have any in my stash, which makes it really hard to test any sort of tuning, as I have to make my code "detune" it first to simulate starting from a bad tuning. Obviously I have 841's, 1634's and 828's that don't work at 5v, as their oscillator is very highly voltage dependent, wheras the one on every other classic AVR is only weakly voltage dependent, but strongly temperature dependent. If you can acutally verify that you have one that's that far off, I don't suppose you could hook me up with one?

I have plans, a page of notes, and half a sketch written to tune parts, but to make the whole thing work I need to make some changes optiboot to really make it sing anyway. My plan is that I'm going to dedicate 4 bytes between optiboot and the version number in the last word of flash to storing internal oscillator calibration numbers for a couple of speeds. But then I realized I needed to stop wasting time on that and put out a bunch of much more urgent fires before I do something like that!

One final note: I basically never use optiboot on most ATTiny parts - I just do ISP programming. If only there was a USBAsp (a much better, also dirt cheap, programmer) wih a microusb socket instead of a USB A type male on it... Hell, maybe some time when I have time I'll even make one.... the hardware is nothing hard shrug USBAzzyp anyone? Realistically it will be under the Azduino branding, once I get that set up. I was shocked that there wasn't an "Azduino" yet, and I snagged the domain name. But I don't have the website set up or anything...

DrAzzy,

Thanks for the info! Yes, certainly using ISP for these is perfectly fine. I thought maybe it would be interesting to use a boot loader though. The reason for Optiboot is to be able to upload programs via UART, yes? I mean, there is no other use for a boot loader, right? Otherwise it would be interesting to have some serial output from the tiny to the PC. In the ATTinyCore web page, I see you fixed the broken link about baud rates, thanks. ATTinyCore/TinySoftSerialBaud.md at master · SpenceKonde/ATTinyCore · GitHub
I see we need to just try different rates. So, to use Serial, and not SoftwareSerial, is there an #include I use…

Sorry to be lost on the specifics.

OK, I will try again to ISP the Bootloader at 1MHz using the Arduino IDE. I did try burn bootloader at 1MHz with USBTiny(SLOW) option. But I will try again. I have a couple ATtiny85, and I’m getting some ATtiny45.

But, yes, if I find a chip that seems to be off and I can’t get UART going, you can have it. I just need to make sure I’m wiring up everything correctly and using the .1uF caps where needed.

I will try some stuff and report back…

OK, I got serial communication working! (not uploading through Optiboot yet, just monitoring).

I had a .1uF cap from AREF (pin 5) to ground because I thought I needed it for serial uploads, but for ISP it foobars because pin 5 is also MOSI, I guess.

Another thing that the programmer doesn't like is when I power the circuit through a battery connected to a (cheap?) LD1117V33 3.3V regulator. But if I use the ISP VCC as a source to the regulator it is OK. The regulator has a .1uF from input to ground, and a 10uF electrolytic between output and ground as recommended. It is possible a 50uF cap would help more.

I didn't quite understand until you replied to me, and I read over the ATTinyCore manual pages that the way the Arduino IDE handles the fuse setting, is as you said, by selecting "burn bootloader."

OK, so basically I selected the settings under tools, like 8MHz internal (CKDIV8=1, I guess), then burn bootloader. Now, if I have a no bootloader tiny selected, then it won't actually burn a bootloader? I noticed it erased the chip, so to then program it, I had to then select upload using programmer. That worked!

Next I removed the ISP, then attached the FTDI, and using pin 5 and pin 6 for TX/RX I was able to see serial messages from my code in Putty/Arduino IDE!

Using 9600 baud at 1MHz was garbled a bit, but 9600 at 8MHz internal works.

void setup() {
  // Power saving
  // Disable the ADC by setting the ADEN bit (bit 7)  of the ADCSRA register to zero.
  ADCSRA = ADCSRA & B01111111;
  // Disable the analog comparator by setting the ACD bit (bit 7) of the ACSR register to one.
  ACSR = B10000000;
  // Disable digital input buffers on all analog input pins by setting bits 0-5 of the DIDR0 register to one.
  DIDR0 = DIDR0 | B00111111;
  // initialize digital pin PB3 as an output.
  DDRB = B00001000;
Serial.begin(9600);
Serial.println("start");
}

void loop() {
    
    // set PB3 high
    PORTB = B00001000;
    Serial.println("PB3 high"); 
    delay(1000);
    // set PB3 low
    PORTB = B00000000;
    Serial.println("PB3 low");
    delay(1000);

  }

9600-OK.jpg

9600-OK.jpg

Not surprised 9600 baud doesn’t work at 1MHz. Honestly, I’d really like to rewrite that serial code, but like, too many project too little time.

If Vcc = 3.3v, but programmer Vcc = 5 MHz, that’s bad (not only is it at risk of not working, it could damage the chip)

Is LD1117 rated for 10uF output cap? Even if it’s electrolytic? Is 0.1uF as only input cap okay? I don’t think it is - they may only show that, but it assumes sufficient board-level decoupling on Vin, which if you have wires between the input power source and the board and no other caps, you don’t have. You also should have a 0.1uF cap between Vcc and Gnd on the t85 no matter what. I know the datasheet says you don’t need one, but I’ve had problems without it. Always include a 0.1uF ceramic cap between Vcc and Gnd right next to the chip unless the datasheet explicitly tells you not to.

As an aside, the LD1117 is a crap regulator these days - you want an LDL1117. Those things are amazing. 0.35V typuical dropout (0.6v max) under max load - and less at sane loads! Lower Iq (Quiescent Current - as opposed to IQ, which is lower in any designer who uses inferior 1117-alikes). And you can use ceramics on both sides, too - many regulators are picky about the type of cap, and oscillate if you use the wrong kind, but the LDL1117 isn’t; ceramic caps are generally preferable, since they’re smaller and cheaper, at least for modest capacitance at low voltages. I almost never use any other kind. Rarely tants in non-production boards. LDL1117 is about the same price too.

DrAzzy:
If Vcc = 3.3v, but programmer Vcc = 5 MHz, that's bad (not only is it at risk of not working, it could damage the chip)

Well, there is a slide switch on the programmer, and you can select power target or not. So, of course I don't use that when I use an external battery through the regulator. The datasheet shows that it could be programmed at a voltage under 5V, so I wanted to verify that. So, it does work at 3.3V, but I hope the programmer itself doesn't mind having the chip powered at that voltage. I don't think it matters?

I may not have mentioned it, but yes, I have a .1uF cap from Vcc to ground. The programmer generally has been working without it, but you mentioned it on your wiring page, and others recommend. I don't have a scope to really check out transients. I should get one. I learned to use one barely when I took digital electronics many years ago. I'm a copier tech, and we never carry them in the field, but I wished I had one sometimes when faxing isn't working, but I digress.

Thanks for the info about the voltage regulator, and the caps. I will try the LDL1117 and ceramic caps. I got some .1uF 25V caps for decoupling, multilayer. Are most these days?

Do you have a part number for things like 3x2 male pin header (ISP), or 6x1 male (FTDI). I know they are 2.54mm (.1 inch), but it is challenge somewhat for me to ferret out the best connector to solder on, or even in a solderless breadboard. Like the Arduino Uno has the pin header, I guess they are just gold-plated breakaway.

Hey, for tuning, people might be better off getting one of these cheap frequency counters, assuming they are accurate. This guy references ATTinyCore for his build - Technoblogy - ATtiny85 20MHz Internal Clock

He used a frequency counter to check and adjust the OSCCAL.

I admit, until today I didn't read over the calibration stuff on the datasheet much. I worked with different micros before that did it a bit differently, or maybe were more accurately calibrated at the factory? For example, the old PIC12F508, you set up the fuse bits right in the code, and you write down the OSCCAL, or mark it in binary with dots on the chip package, then just make sure to add the value back into the hex file. There wasn't extra tuning involved.

If I couldn't get serial working with the internal 8MHz, my plan was to try an external crystal. Then it should be very accurate, I assume.

The ATtinyx5 has a PLL it uses. So that's interesting. My exposure to phase locked loops are for keeping a copier motor at an accurate operating speed. Like a 24v motor.

So, thanks for making the core. It is very nice to use to be able to build using the Arduino IDE. I still like avrdude to do a quick sanity check by verifying the part's signature.

Oh, check out this article about noise from voltage regulators that I found - https://electrooptical.net/static/oldsite/www/sed/ErrolDietzRegulatorNoisePeaks.pdf

For pin header, go on ebay (or better yet aliexpress) and you can score them all there (aliexpress even has colored 2 row header). It comes in 40-pin lengths either way, for dirt cheap, then cut them up (male header cuts easy. For female header, you cut it in the middle of the adjacent row and remove the pins, then clean up the edge with a razor. Female header of specific lengths is also dirt shit cheap on aliexpress). Note that half pitch (1.27/0.05") double row through hole male header doesn't cut well (though using the method I described for female header does work, and both straight and angled hreader also cutswell). All 0.1" (2.54mm) cuts easy.

For best results you want a cutter like... google "sears handicut" and get a generic that looks like it (I don't think the originals are made anymore). If I ever have a bandaid on my hand, I'll take the opportunity to say "This is my handicut, see - and this is the hand i cut".

DrAzzy:
If I ever have a bandaid on my hand, I’ll take the opportunity to say “This is my handicut, see - and this is the hand i cut”.

LOL, those are an awesome set of shears. Thanks for the info.

BTW, I saw online a solution if someone foobars their fuses ISP, you can use one t85 to program another, just bring in an external 12V supply for the reset to achieve HV ISP.

Question, have you tried MPLABX with XC8 compiler, and the pic-as assembler? It is fairly new, and MPASM is no longer used. So, there is a big migration guide, and a bunch of manuals. So, the learning curve is steeper than using the Arduino IDE, and you need an official hardware device like to read the fuse bits and have the MPLABX use them interactively. Still, you can compile as long as you are mindful when you flash with avrdude.

Actually for 2 blink programs, that do the same thing, the version out of XC8/pic-as is much smaller. The annoying thing is you write the C code differently than for PIC micros. I flashed both sample hex files to a t85, then I dumped both.

Here is my source using MPLABX with XC8 to build for the ATTiny85:

#define F_CPU 8000000UL
#include <xc.h>
#include <util/delay.h>
 
int main (void)
{
  // Power saving
  // Disable the ADC by setting the ADEN bit (bit 7)  of the ADCSRA register to zero.
  ADCSRA = ADCSRA & 0b01111111;
  // Disable the analog comparator by setting the ACD bit (bit 7) of the ACSR register to one.
  ACSR = 0b10000000;
  // Disable digital input buffers on all analog input pins by setting bits 0-5 of the DIDR0 register to one.
  DIDR0 = DIDR0 | 0b00111111;
  // set PB3 to be output
  DDRB = 0b00001000;
  
  while (1) {
    
    // set PB3 high
    PORTB = 0b00001000; 
    _delay_ms(1000);
    // set PB3 low
    PORTB = 0b00000000;
    _delay_ms(1000);
  }
    return 1;
}

The Arduino IDE:

void setup() {
  // Power saving
  // Disable the ADC by setting the ADEN bit (bit 7)  of the ADCSRA register to zero.
  ADCSRA = ADCSRA & B01111111;
  // Disable the analog comparator by setting the ACD bit (bit 7) of the ACSR register to one.
  ACSR = B10000000;
  // Disable digital input buffers on all analog input pins by setting bits 0-5 of the DIDR0 register to one.
  DIDR0 = DIDR0 | B00111111;
  // initialize digital pin PB3 as an output.
  DDRB = B00001000;

}

void loop() {
    
    // set PB3 high
    PORTB = B00001000;
    delay(1000);
    // set PB3 low
    PORTB = B00000000;
    delay(1000);

  }

The XC8 with pic-as dumps out at a final offset of 11Dh (285 bytes), but the Arduino dump comes out at 443h (1091 bytes). avrdude showed flashing 110 bytes for the first, and 448 for the second hex file.

console output of avrdude on flash and dump of the XC8 version -

C:\Users\Owner\MPLABXProjects\BlinkATtiny85.X\dist\default\production>avrdude -p
 t85 -c usbtiny -U flash:w:BlinkATtiny85.X.production.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be perform
ed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "BlinkATtiny85.X.production.hex"
avrdude: input file BlinkATtiny85.X.production.hex auto detected as Intel Hex
avrdude: writing flash (110 bytes):

Writing | ################################################## | 100% 0.32s

avrdude: 110 bytes of flash written
avrdude: verifying flash memory against BlinkATtiny85.X.production.hex:
avrdude: load data flash data from input file BlinkATtiny85.X.production.hex:
avrdude: input file BlinkATtiny85.X.production.hex auto detected as Intel Hex
avrdude: input file BlinkATtiny85.X.production.hex contains 110 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.42s

avrdude: verifying ...
avrdude: 110 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:D7, L:E2)

avrdude done.  Thank you.


C:\Users\Owner\MPLABXProjects\BlinkATtiny85.X\dist\default\production>avrdude -p
 t85 -c usbtiny -U flash:r:./BlinkATtiny85-no-serial.dump.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: reading flash memory:

Reading | ################################################## | 100% 27.63s

avrdude: writing output file "./BlinkATtiny85-no-serial.dump.hex"

avrdude: safemode: Fuses OK (E:FF, H:D7, L:E2)

avrdude done.  Thank you.

console output of flash and dump using Arduino hex export (same size using IDE)

C:\Users\Owner\Documents\Arduino\ATtinyBlink-no-serial>avrdude -p t85 -c usbtiny
 -U flash:w:ATtinyBlink-no-serial.ino.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.06s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be perform
ed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "ATtinyBlink-no-serial.ino.hex"
avrdude: input file ATtinyBlink-no-serial.ino.hex auto detected as Intel Hex
avrdude: writing flash (448 bytes):

Writing | ################################################## | 100% 1.09s

avrdude: 448 bytes of flash written
avrdude: verifying flash memory against ATtinyBlink-no-serial.ino.hex:
avrdude: load data flash data from input file ATtinyBlink-no-serial.ino.hex:
avrdude: input file ATtinyBlink-no-serial.ino.hex auto detected as Intel Hex
avrdude: input file ATtinyBlink-no-serial.ino.hex contains 448 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.45s

avrdude: verifying ...
avrdude: 448 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:D7, L:E2)

avrdude done.  Thank you.


C:\Users\Owner\Documents\Arduino\ATtinyBlink-no-serial>avrdude -p t85 -c usbtiny
 -U flash:r:./ATtinyBlink-no-serial.dump.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: reading flash memory:

Reading | ################################################## | 100% 27.86s

avrdude: writing output file "./ATtinyBlink-no-serial.dump.hex"

avrdude: safemode: Fuses OK (E:FF, H:D7, L:E2)

avrdude done.  Thank you.

Also, random question, have you tried the TI MSP430 MCU line? I got a dev kit for cheap from TI MSP-EXP430G2ET and it has a MSP430G2553. I was able to start writing for it using Code Composer Studio. I really like the possibilities with this MCU for low power applications.

My one attempt to use mplabx was a waste of two days without making anything do anything, I was like, f this, and went back to Arduino. Couldn’t even detect my brand new programmer that I just bought from them :-/ (and they wonder why people use Arduino instead of their tooling, even in actual products…)

Your Arduino code is doing way the hell more though! It’s running the millis timer and ISR in the background tracking cumulative millis. With ATTinyCore (at least any vaguely recent version), if you do “export compiled binary” you also get an assembler listing, the kind with source mixed in. Also make sure LTO is enabled, though if it’s not enabled by default, you’re also using an ancient version of the core; update.

Fairer comparison would be to #include <util/delay.h> and use _delay_ms(1000); in place of delay and use the tools submenus that appear when attinycore part is selected to disable millis… I’ll bet that would help significantly. You can also override main (it’s weakly defined) to lose the function call overhead shrug

Zero interest in learning a new architecture, have my hands full with AVR, and am deep enough into AVR that I don’t want to throw that away. I mean, I haven’t memorized the numeric values for all the opcodes, but I can recognize a few of them in hex files. RJMP and JMP stand out like sore thumbs, obviously… A while back, I think with micronucleus, I started mapping out the RJMPs it created. I can’t say I was entirely happy with it at first glance, but then I got hold of myself, reminded myself of priorities and went and did something more useful.

Is the compiler for that even open source? No open source compiler = refuse to use, because doing so would support such bullshit behavior. Similarly, I consider using IAR and XC8 to go against my code of ethics anyway. Though having looked intently at code that avr-gcc generates it’s no mystery why companies who need to get the most from the hardware do. I get the feeling that avr-gcc is not getting the level of development work that it deserves :frowning:

Oh, I misread your original post, I thought those sizes were reversed....

I wonder why XC8 generates such bloated code, I thought it was supposed to be better enough that it was worth paying money for.... Though we are giving it very little to work with (like, _delay_us() goes through some macros to inline assembler, and there's just like, hardly anything there to optimize, you know?

I suspect someone with too much time on their hands could modify the Arduino IDE to use that other compiler (I think it's just platforms.txt stuff; I think you could even make a tools submenu choose between them), and one could compare what it generated for the actual Arduino API functions, which as we all know are bloat city. Same for IAR C. Making that rig such that it could be transferred between systems is another animal all together (not to mention, if you provided a way for them to get their hands on it, illegal). But the point isn't as a practical tool, the question it would answer is "how much better or worse is XC8/IAR at compiling realistic Arduino code", or put another way, "Does avr-gcc suck, and if so how much?")

The whole legal complication angle just put a hilarious image into my mind...

"tools": [
          {
          "name": "XC8",
          "version": "2.3.0_pirateduino1",
          "systems": [
            {
              "size": "51118111",
              "checksum": "SHA-256:f2d82bfef9de7190066f0ffc0d86f84939a43a9abda87cb045278d68a8613239",
              "host": "i686-mingw32",
              "archiveFileName": "xb8-2.3.0-atmel3.6.2-pirateduino1-i686-w64-mingw32.zip",
              "url": "https://3s8kv5i47usqwe86q24k.onion"
            },

(to be clear - that's a made up name and all - the joke is the Tor (darknet) link to download the toolchain package from)

Hey DrAzzy,

The Arduino compiled and exported binary was indeed larger than the XC8. However, you're right, it was not a fair comparison! I didn't clue in on the fact some of those menu items under "tools" turn some stuff on. I'm just too new to these, but I will get the hang of it. I was also thinking using a timer would be more fair. Ah, yes, and of course the delay used was different. Thanks for pointing out the tools menu and the millis.

DrAzzy:
My one attempt to use mplabx was a waste of two days without making anything do anything, I was like, f this, and went back to Arduino. Couldn't even detect my brand new programmer that I just bought from them :-/ (and they wonder why people use Arduino instead of their tooling, even in actual products....)

That's a major level of suck. Yeah, it shouldn't take so much digging to do simple stuff. Then there was a whole post on their forum about how almost impossible it was to make it build a pure assembler program using their new MPLABX with pic-as. That's pretty bad. Not that I use it, but it would be nice to have a clue in case I wanted to learn.

Texas Instruments supports the use of the alternative IDE Energia for use with MSP430, which is basically the Arduino IDE. People are more likely to make libraries for Arduino and Energia, but CCS has some power to it. I do feel open source is best, however. But, yes, I understand having to focus on the ATtiny! I am trying out different micros without having gone too deep into any yet, to be honest.

[/quote]

DrAzzy:
Your Arduino code is doing way the hell more though! It's running the millis timer and ISR in the background tracking cumulative millis. With ATTinyCore (at least any vaguely recent version), if you do "export compiled binary" you also get an assembler listing, the kind with source mixed in. Also make sure LTO is enabled, though if it's not enabled by default, you're also using an ancient version of the core; update.

Fairer comparison would be to #include <util/delay.h> and use _delay_ms(1000); in place of delay and use the tools submenus that appear when attinycore part is selected to disable millis.... I'll bet that would help significantly. You can also override main (it's weakly defined) to lose the function call overhead shrug

Yes, LTO is enabled, thanks. Right, I've seen the assembler listing before, but I didn't look this time, I should. Yeah, I started to think that some of the size was probably related to the different delay methods.

I don't know why, but I was trying to do the burn bootloader thing a few minutes ago, and it tries then errors out. Should it burn the bootloader if the chip is at 8MHz internal? Or should I set it to 1 MHz internal for better results? I was attempting to put Optiboot on there again. Coming back around to trying that, lol

This is what happend:

C:\Users\Owner\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/avrdude.conf -v -pattiny85 -cusbtiny -B8 -e -Uefuse:w:0xFE:m -Uhfuse:w:0b11011111:m -Ulfuse:w:0xE2:m -Uflash:w:C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex:i 

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : usbtiny
         Setting bit clk period        : 8.0
avrdude: usbdev_open(): Found USBtinyISP, bus:device: bus-0:\\.\libusb0-0001--0x1781-0x0c9f
         AVR Part                      : ATtiny85
         Chip Erase delay              : 400000 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : possible i/o
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    12     4    0 no        512    4      0  4000  4500 0xff 0xff
           flash         65    12    32    0 yes      8192   64    128 30000 30000 0xff 0xff
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          2    0      0     0     0 0x00 0x00

         Programmer Type : USBtiny
         Description     : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/
avrdude: programmer operation not supported

avrdude: Setting SCK period to 8 usec
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: erasing chip
avrdude: Setting SCK period to 8 usec
avrdude: reading input file "0xFE"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFE:
avrdude: load data efuse data from input file 0xFE:
avrdude: input file 0xFE contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0b11011111"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0b11011111:
avrdude: load data hfuse data from input file 0b11011111:
avrdude: input file 0b11011111 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex"
avrdude: writing flash (8192 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 8192 bytes of flash written
avrdude: verifying flash memory against C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex:
avrdude: load data flash data from input file C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex:
avrdude: input file C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex contains 8192 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 8192 bytes of flash verified

avrdude done.  Thank you.

Error while burning bootloader.

These are the settings:

tinyset85.jpg

tinyset85.jpg

DrAzzy:
Oh, I misread your original post, I thought those sizes were reversed....

I wonder why XC8 generates such bloated code, I thought it was supposed to be better enough that it was worth paying money for.... Though we are giving it very little to work with (like, _delay_us() goes through some macros to inline assembler, and there's just like, hardly anything there to optimize, you know?

I suspect someone with too much time on their hands could modify the Arduino IDE to use that other compiler (I think it's just platforms.txt stuff; I think you could even make a tools submenu choose between them), and one could compare what it generated for the actual Arduino API functions, which as we all know are bloat city. Same for IAR C. Making that rig such that it could be transferred between systems is another animal all together (not to mention, if you provided a way for them to get their hands on it, illegal). But the point isn't as a practical tool, the question it would answer is "how much better or worse is XC8/IAR at compiling realistic Arduino code", or put another way, "Does avr-gcc suck, and if so how much?")

The whole legal complication angle just put a hilarious image into my mind...

"tools": [

{
          "name": "XC8",
          "version": "2.3.0_pirateduino1",
          "systems": [
            {
              "size": "51118111",
              "checksum": "SHA-256:f2d82bfef9de7190066f0ffc0d86f84939a43a9abda87cb045278d68a8613239",
              "host": "i686-mingw32",
              "archiveFileName": "xb8-2.3.0-atmel3.6.2-pirateduino1-i686-w64-mingw32.zip",
              "url": "https://3s8kv5i47usqwe86q24k.onion"
            },




(to be clear - that's a made up name and all - the joke is the Tor (darknet) link to download the toolchain package from)

No, you didn't mis-read. But I mentioned in my last post about that...

That's funny, yes, the whole closed source legal stuff is annoying. Microchip should use the Arduino IDE and develop their own mappings to it or whatever. They would be smart to do so.

Does avr-gcc suck?

OK, I got it down to 410 bytes as shown under Windows for the exported binary from Arduino, and the other was 350 bytes under Windows properties. I didn’t flash and dump yet. Leave it to a n00b to not get the obvious.

Here is the new Arduino code, like you said;

#include <util/delay.h>

void setup() {
  // Power saving
  // Disable the ADC by setting the ADEN bit (bit 7)  of the ADCSRA register to zero.
  ADCSRA = ADCSRA & B01111111;
  // Disable the analog comparator by setting the ACD bit (bit 7) of the ACSR register to one.
  ACSR = B10000000;
  // Disable digital input buffers on all analog input pins by setting bits 0-5 of the DIDR0 register to one.
  DIDR0 = DIDR0 | B00111111;
  // initialize digital pin PB3 as an output.
  DDRB = B00001000;

}

void loop() {
    
    // set PB3 high
    PORTB = B00001000;
     _delay_ms(1000);
    // set PB3 low
    PORTB = B00000000;
     _delay_ms(1000);

  }

Thanks for all the help!

I do hope avr-gcc gets more attention too!

Oh! You're looking at file properties on a .hex file? no wonder things aren't making sense in your post.

.hex format is text, it is less than 50% efficient (each byte of data is represented with 2 letters, plus there's a checksum for each line, and a few bytes (each of which is represented with two hexadecimal digits) at the beginning to specify the address it starts at and the length of the line.

The number arduino IDE prints out for the compiled sketch size is the actual compiled sketch size. The .hex file is markedly larger than that.

When I compile that sketch, Arduino gets 110b.

Examining the hex file

:100000000EC015C014C013C012C011C010C00FC064
:100010000EC00DC00CC00BC00AC009C008C011241E
:100020001FBECFE5D2E0DEBFCDBF02D01EC0E8CFFD
:10003000379880E888B984B38F6384BB88E087BB36
:1000400088BB2FEF39E698E1215030409040E1F72E
:1000500000C0000018BA2FEF39E698E12150304077
:0E0060009040E1F700C00000EBCFF894FFCF16
:00000001FF

we see that the data ends 0x0E bytes after 0x60, ie, at 0x6E. 0x6E in hexadecimal is 110 in base 10.

I don't feel like checking exactly how large the interrupt vectors are - by eye, though, I think it's the first 48 bytes (24 instruction words - parts with 8k of flash or less have 2 byte vectors, since you can jump to anywhere in the flash with RJMP (relative jump - +/- 2k words). I mean, certainly the first 24 instruction words are all RJMP's, which is consistent with that.

Which is why I say it's a pretty bad test case - there are only 31 instruction words there, and the _delay_ms() macro ends up getting turned into a timing loop implemented with inline assembly (indeed, you can see pieces of the timing loop in two places, that 00C0 0000 - that's rjmp .+0 nop - relative jump (2 cycle instruction) to current location, that is, a 2 cycle no-op that fits in a single word of flash, followed by a no-op) The compiler doesn't have much discretion in this example (it certainly didn't make those two three-cycle two-word patterns I pointed out - that was specified explicitly by delay.h). Who the hell CARES whether XC8 can shave a few instructions off something trivial like this,anyway? \

We haven't demontrated any deficiency in the official toolchain, so it's a bit premature to talk ways to address that....

Also, goddamnit man, I have better things to do than look at assembly listings for minimal implementations of blink...

In any event, it's an intensely pointless test case... like, a quick look at the assembly listing shows that the compiler is picking somewhere around a dozen instruction words here, and the stuff the program is doing is so simple it doesn't exercise the complicated parts where a better compiler would shine.

And no idea if avr-gcc sucks, or how much it does if so! I said it was possible to examine it completely within the arduino context, I didn't say I'd done so!

[/quote]

DrAzzy:
Oh! You’re looking at file properties on a .hex file? no wonder things aren’t making sense in your post.

.hex format is text, it is less than 50% efficient (each byte of data is represented with 2 letters, plus there’s a checksum for each line, and a few bytes (each of which is represented with two hexadecimal digits) at the beginning to specify the address it starts at and the length of the line.

The number arduino IDE prints out for the compiled sketch size is the actual compiled sketch size. The .hex file is markedly larger than that.

When I compile that sketch, Arduino gets 110b.

Examining the hex file

we see that the data ends 0x0E bytes after 0x60, ie, at 0x6E. 0x6E in hexadecimal is 110 in base 10.
Intel HEX - Wikipedia

I don’t feel like checking exactly how large the interrupt vectors are - by eye, though, I think it’s the first 48 bytes (24 instruction words - parts with 8k of flash or less have 2 byte vectors, since you can jump to anywhere in the flash with RJMP (relative jump - +/- 2k words). I mean, certainly the first 24 instruction words are all RJMP’s, which is consistent with that.

Which is why I say it’s a pretty bad test case - there are only 31 instruction words there, and the _delay_ms() macro ends up getting turned into a timing loop implemented with inline assembly (indeed, you can see pieces of the timing loop in two places, that 00C0 0000 - that’s rjmp .+0 nop - relative jump (2 cycle instruction) to current location, that is, a 2 cycle no-op that fits in a single word of flash, followed by a no-op) The compiler doesn’t have much discretion in this example (it certainly didn’t make those two three-cycle two-word patterns I pointed out - that was specified explicitly by delay.h). Who the hell CARES whether XC8 can shave a few instructions off something trivial like this,anyway? \

We haven’t demontrated any deficiency in the official toolchain, so it’s a bit premature to talk ways to address that…

Also, goddamnit man, I have better things to do than look at assembly listings for minimal implementations of blink…

In any event, it’s an intensely pointless test case… like, a quick look at the assembly listing shows that the compiler is picking somewhere around a dozen instruction words here, and the stuff the program is doing is so simple it doesn’t exercise the complicated parts where a better compiler would shine.

And no idea if avr-gcc sucks, or how much it does if so! I said it was possible to examine it completely within the arduino context, I didn’t say I’d done so!

Hey, sorry for jumping around, but in my first post (that was an un-fair comparison), I did mention the hex size reported by avrdude, and the size shown in a hex editor after I dumped the file. I did not do that last night, and I looked at the Windows properties for a quick check, but that is not a good thing to do.

My point was, with your advice, the file became much smaller, so you were right, and I’m totally happy with it. I certainly didn’t mean for you to analyze it. I just wanted to show that now things are making more sense to me.

You went on to say the other reasons the comparison of efficiency is not good using this example, and I agree. Let’s not waste any more time on it!

I just am exploring all the ways I can build with the Tiny, and I’m new to them.

You are an expert, and I really appreciate all the work you have done to make it possible to use the Arduino IDE to compile and set fuses on the ATtiny series.

I really also want to try the more powerful ones with the UART.

If anything, this discussion will show other novice users how NOT to compare code build sizes.

Anyway, I saw the page for your megaTinyCore, and it really makes me want to try the 3217!

Moving on to using Arduino to set fuse bits and burn bootloader.... I have the t85 going at 8MHz internal, then I picked the Optiboot choice, then burn bootloader. The avrdude output in the Arduino IDE seemed to indicate everything verified, except there is one line that reported "avrdude: programmer operation not supported"

But, I'm not sure what the operation was that failed. At the end I got "error burning bootloader" but I'm really not sure why.

I copied and pasted the output....

leafybye:
This is what happened:

C:\Users\Owner\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/avrdude.conf -v -pattiny85 -cusbtiny -B8 -e -Uefuse:w:0xFE:m -Uhfuse:w:0b11011111:m -Ulfuse:w:0xE2:m -Uflash:w:C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex:i 

avrdude: Version 6.3-20190619
        Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
        Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/avrdude.conf"

Using Port                    : usb
        Using Programmer              : usbtiny
        Setting bit clk period        : 8.0
avrdude: usbdev_open(): Found USBtinyISP, bus:device: bus-0:\.\libusb0-0001--0x1781-0x0c9f
        AVR Part                      : ATtiny85
        Chip Erase delay              : 400000 us
        PAGEL                        : P00
        BS2                          : P00
        RESET disposition            : possible i/o
        RETRY pulse                  : SCK
        serial program mode          : yes
        parallel program mode        : yes
        Timeout                      : 200
        StabDelay                    : 100
        CmdexeDelay                  : 25
        SyncLoops                    : 32
        ByteDelay                    : 0
        PollIndex                    : 3
        PollValue                    : 0x53
        Memory Detail                :

Block Poll              Page                      Polled
          Memory Type Mode Delay Size  Indx Paged  Size  Size #Pages MinW  MaxW  ReadBack
          ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
          eeprom        65    12    4    0 no        512    4      0  4000  4500 0xff 0xff
          flash        65    12    32    0 yes      8192  64    128 30000 30000 0xff 0xff
          signature      0    0    0    0 no          3    0      0    0    0 0x00 0x00
          lock          0    0    0    0 no          1    0      0  9000  9000 0x00 0x00
          lfuse          0    0    0    0 no          1    0      0  9000  9000 0x00 0x00
          hfuse          0    0    0    0 no          1    0      0  9000  9000 0x00 0x00
          efuse          0    0    0    0 no          1    0      0  9000  9000 0x00 0x00
          calibration    0    0    0    0 no          2    0      0    0    0 0x00 0x00

Programmer Type : USBtiny
        Description    : USBtiny simple USB programmer, USBtinyISP - Inexpensive USB AVR Programmer
avrdude: programmer operation not supported

avrdude: Setting SCK period to 8 usec
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: erasing chip
avrdude: Setting SCK period to 8 usec
avrdude: reading input file "0xFE"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFE:
avrdude: load data efuse data from input file 0xFE:
avrdude: input file 0xFE contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0b11011111"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0b11011111:
avrdude: load data hfuse data from input file 0b11011111:
avrdude: input file 0b11011111 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex"
avrdude: writing flash (8192 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 8192 bytes of flash written
avrdude: verifying flash memory against C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex:
avrdude: load data flash data from input file C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex:
avrdude: input file C:\Users\Owner\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.4.1/bootloaders/optiboot/optiboot_attiny85_8000000L.hex contains 8192 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 8192 bytes of flash verified

avrdude done.  Thank you.

Error while burning bootloader.




These are the settings:



![tinyset85.jpg|495x252](upload://7H5MWrqUDTiavSnnEtOTK1QNN55.jpeg)

wonder why XC8 generates such bloated code, I thought it was supposed to be better enough that it was worth paying money for.

Xc8 is currently just the same as a avr-Gucci for the avr chip, the 8bit pic chips do get better code when you pay full price.

westfw:
Xc8 is currently just the same as a avr-Gucci for the avr chip, the 8bit pic chips do get better code when you pay full price.

Interesting, do you have a reference? The Output from the free XC8 under MPLABX was indeed a bit smaller than avr-gcc, but the example I made only used a delay, and not a timer. As DrAzzy pointed out, we would need to test code that uses more instructions from the set. It is meh, whatever, as long as I can get my crap to fit onto whatever ATtiny, I don't care. Me, I'm pretty new, and my understanding is infantile compared to DrAzzy.

I would like to learn to just use pic-as and learn a little assembly, and I finally got MPLABX to NOT use XC8 and use pic-as, but it is so new there isn't much beginner tutorial information. I will figure it out, but so far I only got a dummy program with a NOP to compile. PITA that I will return to later.

In the XC8 Compiler section of your MPLABX project configuration panel, set “verbose” in the “processing and messages” section, and recompile your project:

CLEAN SUCCESSFUL (total time: 51ms)
make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make[1]: Entering directory '/Volumes/MacOS/HD-Users/BillW/MPLABXProjects/test-da28.X'
make  -f nbproject/Makefile-default.mk dist/default/production/test-da28.X.production.hex
make[2]: Entering directory '/Volumes/MacOS/HD-Users/BillW/MPLABXProjects/test-da28.X'
"/Applications/microchip/xc8/v2.20/bin/xc8-cc"  -mcpu=AVR128DA28 -c  -x c -D__AVR128DA28__    -Wl,--gc-sections -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields -v -Wall -DXPRJ_default=default    -gdwarf-3     -MD -MP -MF "build/default/production/main.o.d" -MT "build/default/production/main.o.d" -MT build/default/production/main.o -o build/default/production/main.o main.c 
/Applications/microchip/xc8/v2.20/avr/bin/avr-gcc @/tmp/xcgooJSuj.cmd [ -mmcu=avr128da28 -c -x c -D__AVR128DA28__ -Wl,--gc-sections -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields -v -Wall -DXPRJ_default=default -gdwarf-3 -MD -MP -MF build/default/production/main.o.d -MT build/default/production/main.o.d -MT build/default/production/main.o -obuild/default/production/main.o main.c -mdevice=avr128da28 -mconst-data-in-progmem -mdfp=/Applications/microchip/xc8/v2.20/dfp/xc8 -D__XC -D__XC8 -D__XC__ -D__XC8__ -D__XC8_VERSION=2200 ]
Using built-in specs.
Reading specs from /Applications/microchip/xc8/v2.20/dfp/xc8/avr/device-specs/specs-avr128da28
rename spec link to old_link
COLLECT_GCC=/Applications/microchip/xc8/v2.20/avr/bin/avr-gcc
Target: avr
Configured with: /Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/src/gcc/configure CFLAGS='-Os -g0 -I /Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64-hostlibs/include/libxml2 -DMCHP_XCLM_SHA256_DIGEST=1792d3dcd04dc14634b99935fa2ac1a7c75ac10a0af82185f3ec1e4cbfbece55 -DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7da32606911a8b08a1a8d  -I /Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64-hostlibs/include/' CXXFLAGS='-I /Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64-hostlibs/include/libxml2 -DMCHP_XCLM_SHA256_DIGEST=1792d3dcd04dc14634b99935fa2ac1a7c75ac10a0af82185f3ec1e4cbfbece55 -DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7da32606911a8b08a1a8d  -I /Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64-hostlibs/include/' LDFLAGS=-L/Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64-hostlibs/lib CPPFLAGS= --target=avr --host=x86_64-apple-darwin17.0.0 --build=x86_64-apple-darwin17.0.0 --prefix=/Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64 --libdir=/Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64/lib --enable-languages=c,c++ --with-dwarf2 --enable-doc --disable-shared --disable-libada --disable-libssp --disable-nls --with-avrlibc=yes --with-mpfr=/Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64-hostlibs --with-gmp=/Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64-hostlibs --with-mpc=/Volumes/build_disk/jenkins_mcu/workspace/xc8-avr-gcc-osx/avr8-gnu-toolchain-darwin_x86_64-hostlibs --with-pkgversion=AVR_8_bit_GNU_Toolchain_3.6.4_177 --with-bugurl=http://www.microchip.com
Thread model: single
[color=red]gcc version 5.4.0 (AVR_8_bit_GNU_Toolchain_3.6.4_177) [/color]
COLLECT_GCC_OPTIONS= '-c' '-D' '__AVR128DA28__' '-O1' '-ffunction-sections' '-fdata-sections' '-fpack-struct' '-fshort-enums' '-funsigned-char' '-funsigned-bitfields' '-v' '-Wall' '-D' 'XPRJ_default=default' '-gdwarf-3' '-MD' '-MP' '-MF' 'build/default/production/main.o.d' '-MT' 'build/default/production/main.o.d' '-MT' 'build/default/production/main.o' '-o' 'build/default/production/main.o' '-mdevice=avr128da28' '-mconst-data-in-progmem'  '-D' '__XC' '-D' '__XC8' '-D' '__XC__' '-D' '__XC8__' '-D' '__XC8_VERSION=2200' '-mpack-dir=/Applications/microchip/xc8/v2.20/dfp/xc8' '-B' '/Applications/microchip/xc8/v2.20/dfp/xc8/avr/' '-I' '/Applications/microchip/xc8/v2.20/dfp/xc8/avr/include' '-B' '/Applications/microchip/xc8/v2.20/dfp/xc8/avr/lib' '-specs=device-specs/specs-avr128da28' '-mmcu=avrxmega4' '-mdevice=avr128da28'
 /Applications/microchip/xc8/v2.20/avr/bin/../libexec/gcc/avr/5.4.0/cc1 -quiet -v -I /Applications/microchip/xc8/v2.20/dfp/xc8/avr/include -imultilib avrxmega4/memx-const -iprefix /Applications/microchip/xc8/v2.20/avr/bin/../lib/gcc/avr/5.4.0/ -isystem /Applications/microchip/xc8/v2.20/dfp/xc8/avr/include -MD build/default/production/main.d -MF build/default/production/main.o.d -MP -MT build/default/production/main.o.d -MT build/default/production/main.o -D__AVR_AVR128DA28__ -D__AVR_DEVICE_NAME__=avr128da28 -D__AVR_DEV_LIB_NAME__=avr128da28 -D __AVR128DA28__ -D XPRJ_default=default -D __XC -D __XC8 -D __XC__ -D __XC8__ -D __XC8_VERSION=2200 main.c -mn-flash=2 -mno-skip-bug -quiet -dumpbase main.c -mdevice=avr128da28 -mconst-data-in-progmem -mpack-dir=/Applications/microchip/xc8/v2.20/dfp/xc8 -mmcu=avrxmega4 -mdevice=avr128da28 -auxbase-strip build/default/production/main.o -gdwarf-3 -O1 -Wall -version -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields -o /var/folders/gv/zn3wcml52jq0vvjnd95j8g6h0000gp/T//ccyGooFc.s
[color=red]GNU C11 (AVR_8_bit_GNU_Toolchain_3.6.4_177) version 5.4.0 (avr)
    compiled by GNU C version 5.5.0, GMP version 5.0.2, MPFR version 3.0.0, MPC version 0.9[/color]
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/Applications/microchip/xc8/v2.20/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/sys-include"
ignoring duplicate directory "/Applications/microchip/xc8/v2.20/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/include"
ignoring duplicate directory "/Applications/microchip/xc8/v2.20/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/include-fixed"
ignoring nonexistent directory "/Applications/microchip/xc8/v2.20/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/../../../../avr/sys-include"
ignoring duplicate directory "/Applications/microchip/xc8/v2.20/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/../../../../avr/include"
ignoring duplicate directory "/Applications/microchip/xc8/v2.20/dfp/xc8/avr/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 /Applications/microchip/xc8/v2.20/dfp/xc8/avr/include
 /Applications/microchip/xc8/v2.20/avr/bin/../lib/gcc/avr/5.4.0/include
 /Applications/microchip/xc8/v2.20/avr/bin/../lib/gcc/avr/5.4.0/include-fixed
 /Applications/microchip/xc8/v2.20/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/include
End of search list.
GNU C11 (AVR_8_bit_GNU_Toolchain_3.6.4_177) version 5.4.0 (avr)
    compiled by GNU C version 5.5.0, GMP version 5.0.2, MPFR version 3.0.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

(An mplabx project doing bliink with direct port manipulation and _delay_ms() from main() is just a MUCH different program than an Arduino sketch using delay() from setup()/loop())

If I paste your main()/_delay_ms() based version into an Arduino window (which you can do because the main() will override the arduino() initializations), you wind up with:

Sketch uses 110 bytes (1%) of program storage space. Maximum is 8192 bytes.

Which was the same thing you got with MPLABX:

avrdude showed flashing 110 bytes for the first