Post History

60%

+1 −0

Meta Microcontroller-involving challenges and the rules.

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 ...

posted 5y ago by Lundin‭ · edited 5y ago by Lundin‭

Answer

#3: Post edited by

Lundin‭ · 2021-02-11T10:34:22Z (over 5 years ago)

Copy Link

Raw

Markdown

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 port registers 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?

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?

#2: Post edited by

Lundin‭ · 2021-02-11T10:33:05Z (over 5 years ago)

Copy Link

Raw

Markdown

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 port registers 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.

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 port registers 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?

#1: Initial revision by

Lundin‭ · 2021-02-11T10:29:33Z (over 5 years ago)

Copy Link

Raw

Markdown

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 port registers 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.

Communities

Post History