Microcontroller-involving challenges and the rules.
I'd like to make a challenge that involves the use of a microcontroller, specifically, a challenge to read any 4-bit Gray Code from 4 IO pins, and convert it to binary. Simple introductory type challenge.
Problem, of course, is we have no set precedents for this type of challenge.
A few questions need answered:
-
How should we factor "non-essential parts" into the equation? For example, say someone simplifies their code using a 74xxx IC. Do we even allow this? It's even possible to solve some challenges without any code at all, using only ICs (The example challenge above is one, easy to solve with just 74xxx ICs)
This is just pretty tricky in general, as unlike a computer where you can just.. obtain the language, these are physical parts, so what someone has in their collection affects the quality of their codegolf. For example I currently do not own any 74xxx ICs, but I do have a Parallax Propeller 2, which is rather expensive for an MCU. -
The microcontroller world can be pretty strange, and there definitely will be unfair advantages (For example, a Parallax Propeller has an advantage in the above challenge, as it can efficiently read parallel data, many MCUs must do it one pin at a time). Do we produce some list of "allowed" MCUs, or just allow anything?
-
Byte counts are awkward too. Do we use the final ROM size? What about interpreted programs? These are all baked into a single flat binary at the end, but competition among interpreted languages may be stifled a bit if the interpreter counts against them. Do we just list both final ROM size and bytecode size?
-
How do we even classify an MCU? For example not all MCUs have on-chip code storage (both Parallax Propellers, 1 and 2, require external memory, for example). Basically the only defining feature is the presence of GPIO, and the fact it runs code.
-
What do we do about data hardcoded in ROM? Again, falling to the Parallax Propeller here, which has sine tables in it's on-chip ROM. I personally think they should not count toward total program size as they are immutable, and the programmer has no control over them.
1 answer
For this to work, I think we need to rule out all start-up code (the C runtime) but also the register maps. So I think answers should be a void main (void){ ... } (or equivalent) function solution where the register map is included but not counting as part of the solution. Other than that, ban all 3rd party libs, like pre-made HALs.
Also, there aren't many viable languages for "bare metal" solutions, basically just assembler, C and C++. Not sure if standard libs for the programming language should be allowed. For example some particular compiler might implement printf complete with a UART driver and everything etc and that might be cheating.
How should we factor "non-essential parts" into the equation? For example, say someone simplifies their code using a 74xxx IC. Do we even allow this?
I think all software solutions must use the same external hardware outside the MCU. Unless maybe the challenge is pure hardware: that is "golf" a minimum Bill of Materials in terms of number of components, rather than minimizing some code.
Also, external hardware would depend on how robust a solution needs to be. A proper solution in this case would perhaps have pull-down resistors on all lines. But a "golfed hardware" solution might decide to skip that and purposely allow crappy EMC characteristics, to save the code writing to pull-down enable registers.
Better then if the hardware is given as-is by the challenge, preferably in the form of a schematic.
The microcontroller world can be pretty strange, and there definitely will be unfair advantages
Most MCUs can read all pins in a port register in parallel. But well, if you restrict the challenge to a specific MCU then you certainly won't get many answers. I'm thinking answers will be contributions per MCU type.
Byte counts are awkward too. Do we use the final ROM size?
If it's code golf you'd just count the characters in the source like usual. I think "ROM golf" is probably a different kind of challenge. C for example very likely to beat assembler in code golf, but assembler would maybe have an advantage in "ROM golf".
How do we even classify an MCU?
What do we do about data hardcoded in ROM?
Probably any code that is directly executed within one or several CPU cores. Don't allow FPGA or pre-loaded on-chip ROM code etc. But otherwise allow "smart" hardware peripherals, like on-chip DMA, ADC/DAC, CRC calculators etc etc.
Another thing you definitely need to consider is the output format. How do solutions post output? Writing it to a variable is enough? Or must it drop the output on some serial bus? Or light LEDs etc?
0 comment threads