Very dumb questions: 1- is 1kb the number I'm looking at for the compiled file? 2- In  case of a bootloader, will it count inside the 1kb?

I would assume that your compiler would have a message saying how much actual storage space is used for the program instead of the programming file created.  That file may have some other debugging stuff in it or in a format for the programmer instead of actual image, so the file size is not accurate.

In my case, it looks something like this for ARM for the compiler messages.  

linking...
Program Size: Code=112 RO-data=32 RW-data=0 ZI-data=256

Code: that's obvious
RO-data: tables, data structure stored in ROM. 

It is my previous question whether that is counted in the 1kB limit.  Straightly speaking that is not machine code.  Need a clarification on the rules as my question was derailed by another comment.

ARM got huge vector table (200+ bytes) in RO-data, so it is a big disadvantage if I want to use interrupts.

RW-data = RAM 
ZI-data = preinitialized to zero RAM data

If it is not in the messages, then there is a .map file with a report usually as a summary.  I don't do Arduinos, so can't answer specific question to that.

Code (inc. data)   RO Data    RW Data    ZI Data      Debug   

       112         24         32          0        256       2828   Grand Totals
       112         24         32          0        256       2828   ELF Image Totals
       112         24         32          0          0          0   ROM Totals

    Total RO  Size (Code + RO Data)                  144 (   0.14kB)

    Total RW  Size (RW Data + ZI Data)               256 (   0.25kB)
    Total ROM Size (Code + RO Data + RW Data)        144 (   0.14kB)

PIC32 might be even worse... you should see the listing from "xc32-size" for my projects, there's something like 60 different  sections. I have no idea how to add them up to determine actual bytes-written to the FLASH. I think some are configuration-registers-stored-in-flash. Others are jump-tables for interrupts, but all those are written to jump to a general exception-handler, even if the interrupts aren't configured. 

-----------

I don't think either of these questions are dumb. There'd have to be a lot of gray-area rules-wise in this contest, not being limited to a specific microcontroller/architecture. If someone comes up with the next amazing/unique USB-gadget but uses the USB-functionality built into their uC's peripherals and libraries supplied by the manufacturer, should that be rated more highly than a USB-blinky which figured out a clever way to "hook" into a previously-untapped commonplace-bootloader whose USB-support was bit-banged? 

If anything, these aren't "dumb" questions, but fundamental questions regarding life, liberty, and all that jazz.

Or, more specifically, as a fellow "hacker", I'd say:

1) Definitely don't rely on the file-size. Use "avr-size" or "xc32-size" or "arm-size"(?) to get a table more like KCLee's, if your compiler doesn't give you that information already. And don't be surprised if it's not at all intuitive (seriously, my AVR project easily fits in my 8KB of flash, but allegedly there's some ".debug" section well over 32KB? How does *that* work?!)

2) Bootloaders... There seems to be a strange, yet understandable, silence on this front. Whelp, there are those who use Arduinos and don't even know there's such thing as a bootloader, despite using them in every project, and there are others who would try something like suggested earlier... There might even be those who would use a bootloader such as grub to gain full 1080p frame-buffer support on an x86-64, then write a 1KB "demo" which wows the crowd.

All I, fellow-hacker, can say about that is... unless the judges explicitly banish them from this contest, which would put a tremendous burden on newbies' creativity--which would kinda ruin the point of contests like these, no?--nevermind a slew of other such pedantry which has yet to come up, the judges are going to have a *lot* of work ahead of them, and after the fact likely quite a bit of judgment. We should be giving these folks unquestionable "props" (that is: "Proper Respect") for their part in these things.

ARM: if you don't use any interrupts, then you can reuse vector table space for your code. And if you are sure that HARDFAULT handler never happened then you need to use only stack pointer and RESET handler, this eat only 8 bytes of code.

Hardfault handler would be a final option as I can waste a lot of time chasing ghosts.  I have 3-4 different uC architectures that I could use and still undecided on the actual projects.

1. program an atmega328 to have one input, and one output

2. output=not(input)

3. make it be 1kb

4. profit?

dude, must be something memorable, not just a NOR gate on steroids :-)

finally a reason to get my attiny10 out of the parts bin! if only i could find it...

>machine code must be less than 1kB.

Does that means that RO data usage (ie ROM tables for data) are not counted?

LOL, loving all the ideas people are coming up with to get around the size-limit... So, then, say you've got an SD-card, and all it takes is 1KB to bootload from that? I mean, that's a major gray-area, but... what if it's an interpretted-language, rather than code that runs *directly* on the machine-architecture? ROM-tables... that's great! Personally, I think it should only be allowable in the case that you've implemented the ROM tables *outside* the processor's dedicated flash/program-memory. Throw an EEPROM at it :)

Apologies! I didn't realize my earlier comment was a derailment of your question... I was applauding what I thought was your creative/out-of-the-box-solution, as I thought you were trying to hack e.g. a typically-large program into a small amount of code-space via e.g. creating huge lookup tables, *and* trying to get away without having to count those lookup tables toward the 1KB.

(E.G. Why make your lowly uC calculate something like (int)( 128 + 128*sin(theta) ) in realtime when a suitable LUT is much faster and might be smaller than loading support for floating-point?)

I can see how it'd be confusing as to whether your project would qualify if you're using a uC with more program-space than the contest's requirement. I recall my first experience filling up my AVR's program-space... didn't make sense, the code (.text) section was well-under the 8KB flash-size, but I didn't know that additional flash/program-memory is necessary for initializing global variables... (is that the .bss or .data section?).

So, you bring up a good side-question... now that you've declared this thread "derailed".... (and since you've discussed the topic in another thread, above).

Should those who *unknowingly* stumble upon this be penalized for it in the context of this contest? Doesn't seem particularly fair, in terms of disqualifying otherwise interesting projects that did their best to work within the rules.

OTOH, those who *know* about it could easily come up with a way to make use of techniques like these to stretch the contest's rules... That might be considered unfair, or it might be considered a clever use of one's understanding, aka "a hack," which otherwise might be respectable in a place like Hackaday.

OTOOH, now that this knowledge *has* been put on the table...?

Gotta give props to the judges of these contests for working through these sorts of dilemmas in a place with such a broad array of experience/perspective.

Hope you got the answer you were looking for.

(This is preliminary and the rules may change)  RO Data must be included in the 1kB calculation.  It puts ARM at a disadvantage - if you use interrupts. 

Thanks.  I know a couple of ways around that.

In general, ARM is at a disadvantage for tiny space as I/O registers are memory mapped in 32-bit space unlike the 8-bit I/O space which carries a bit of overhead.  The peripherals also require a few more things to be initialized.  :(

Once you get to higher level codes, the code density is actually pretty good and get better when you start having to do with larger data size.

Aw man! Early #LiFePO4wered/Pi prototypes used to have < 1K, but production now uses 2K. :)

Also, the 1kB limit is the size of the initial assembled instructions themselves, right?  If I have an initial 1kB of instructions that grows to fill a larger piece of executable space, that's still OK, right?  Oh, I've said too much already...

indeed! this is going to be too fun!

Or have you said enough?

I have found that I generally always say too much :-)

(This is preliminary, and the rules may change) If you want to compress your code, go for it - but remember, the decompression algorithm and the compressed binary must both fit within 1kB.  

Hahaha, I had no idea you were talking about compression until Adam's response... brilliant!

I am going to blame Linus for all the time I'll end up sinking into trying to make a compressed PIC image.  After I saw this contest announcement, I upgraded my linux desktop distro, and noticed it say "uncompressing linux" as it booted.

Are multiple microcontrollers allowed, and if so are duplicates allowed? e.g. 2 microcontrollers running identical 1kB code.

Sounds great but I have too much happening to do this sort of thing at short notice so I hope it's an ongoing thing. 

And ... C2 00 D0 // is machine code

but ... JP D000h // is assembly

No one does machine code anymore - well since assemblers were written.

Does the memory limit include a bootloader (i.e. Arduino)? If so, folks using anything but a bare micro might have some trouble..

there are attiny13 avrs that only fit 1kb and can be programmed with an arduino over the IDE - that way you (or folks) would be safe :)

Maybe the link in the sidebar can be fixed now? :) 

It couldn't fit in 1kB.  :)

that's right