Post History
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 cha...
#2: Post edited
by
moony
·
2021-02-10T14:38:04Z (almost 4 years ago)
- 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)<br/>
- 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, most 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.
- 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)<br/>
- 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: Initial revision
by
moony
·
2021-02-10T14:22:34Z (almost 4 years ago)
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)<br/> 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, most 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.