Big Unsolved Issues

[kammce]

1. Should all methods of all hardware interfaces use Returns, basically assume that any and all hardware interfaces have the capability to return an error?

Answer: Yes. Proof:

1. Lets assume that the I2C interface that requires Error handling.
2. I2C IS an address/register based communication protocol. 5) A typical computer architecture uses a parallel bus architectures 2) A parallel bus architecture is also an address/register based protocol. 3) Thus a computer can be built using I2C as its bus architecture as with a parallel bus architecture. 6) Lets assume that there does not exist peripherals that cannot be put on a parallel bus. 4) Thus any peripheral that would use a parallel architecture as its protocol could also use I2C as its protocol as well. 7) Thus any peripheral that can exist on a parallel bus can also exist on an I2C bus. 8) Thus, any all peripherals can be backed by I2C protocol. 3) Thus all peripherals must be capable of returning an error because any peripheral has the potential to be backed by a system that can also throw errors.

Evidence:

1) I2C to GPIO (io expander), I2C to PWM, and I2C to SPI converters are examples of how the I2C com-protocol can be used to generate other peripherals. 2) Some SOCs use I2C internally to communicate to embedded peripherals

2. Can memory map register polling be reliably unit tested?

1) Option 1: Create a PollRegister() class/function that is different between testing and runtime.

• PROS: Deep insight into access of members of structure which can be controlled at a 'setup' step of a TEST_CASE or SECTION.
• CONS: Requires that ALL libraries MUST use this specific Polling mechanism in order to make testing work, which will cause issues for old and new drivers that do not currently use this method.
• CONS: Bespoke way to poll that is unlike any code other firmware engineers will be used to. 2) Option 2: Set all flags before running tests.
• PROS: Fastest, simplest, and easiest to convey to others
• CONS: Cannot know if the polling logic is correct 3) Option 3: Use std::threads
• PROS: Can work if enough effort is put in
• CONS: Has shown to be quite flakey
• CONS: Can only infer by the increase in testing time that the polling logic is correct
• CONS: Can be quite complex 4) Option 4: Overload -> operator on structures
• PROS: Deeper insight into access of members of structure
• CONS: Requires instrumenting all registers in .h files from vendors,
  and this is too large of a change to be acceptable.

Chosen Option

Option 2 + Option 3 where option 3 is realized using a generic DetectPolling() that can be used during testing to detect if a method/function is stalled Then the rest of the code should set the flags at the start. This way, the test is only polling for those test, proving that they halt when the flag is not set, but when the flag IS set, they proceed as normal.

3. Leveraging C++11 threads

The idea would be to bring in C++11 threads and make them optional for the developers. But, std::thread, and the creation of threads is strictly forbidden within SJSU-Dev2, except in cases where we are creating libraries to assist in the creation of threads.

All libraries that would need some sort of real time control must present an Update() (maybe come up with a better name) function that must be called by a thread to get a process to continue, similiar to how graphics libraries do not control their own thread but let the developer call their refresh() functions when they want to.

There is potential to support and use through out the code base, things such as std::mutex, and C++20's std::binary_semaphore and other primitives that use FreeRTOS in the back.

[kammce]

4. Transition to exceptions

After attempting to move everything to Returns I noticed an increase in binary size. When I configured some of the Error2.0 code to get automatically optimized out, effectively removing Returns for the platform, I observed a small project's code drop nearly 6kB in binary size. Each usage and abstraction of Returns results in a cost. The cost goes as follows:

Size Costs:

1. Cost of creating the result to be returned (typically runs a non trivial constructor)
2. Cost of a memcpy if the result is too large (copy elision is prevented on all compilers)
3. Cost of checking every single function that can return result, which is nearly all of them.

Performance Costs

1. Cost of memcpy
2. Cost of a check at every level of abstraction for an API call

Where as exceptions takes up a fixed amount of 8kB of memory when enabled. This seems like the logical path for most system that have sufficient memory, such as 64kB devices and above.

[kammce]

5. How to handle package management

How do we create an environment that allows for packages to be "installed" and included in a project? How can we make it fit the current folder hierachy of L1, L2, L3, L4? We want to use git for this. Do we have library developers create the same folder hiearchy in there projects and simply -I include a folder of a clone of that repo?

[kammce]

Can memory map register polling be reliably unit tested?

The answer is yes and the PollingVerification() makes it easy to do this and do it right.

[kammce]

The last item in the big unsolved issus to not be solved is C++11 threads but this is mentioned in #427