As I revise the RPI demo, I'm encountering the following behavior: if I put in flight-like assertions that driver initialization is OK, then the app crashes on the Mac. I presume this is because the stub drivers return error status on the Mac, even when nothing is wrong. Presumably it would work better on the RPI, but we want the demo to behave nicely on Mac/Linux. So for now I am putting in a bunch of code to handle error cases and behave nicely if things fail. This code is non-flight-like, and somewhat annoying to write.
I think it would be better if we had stub drivers always do something reasonable and always return OK. That way we could plug a stub driver into flight-like code that says FW_ASSERT(driverInit()) and everything will still work. The driver behavior can still be very limited for the demo, but at least it won't report a failure that the application layer has to handle in a non-flight-like way.
As I revise the RPI demo, I'm encountering the following behavior: if I put in flight-like assertions that driver initialization is OK, then the app crashes on the Mac. I presume this is because the stub drivers return error status on the Mac, even when nothing is wrong. Presumably it would work better on the RPI, but we want the demo to behave nicely on Mac/Linux. So for now I am putting in a bunch of code to handle error cases and behave nicely if things fail. This code is non-flight-like, and somewhat annoying to write.
I think it would be better if we had stub drivers always do something reasonable and always return OK. That way we could plug a stub driver into flight-like code that says FW_ASSERT(driverInit()) and everything will still work. The driver behavior can still be very limited for the demo, but at least it won't report a failure that the application layer has to handle in a non-flight-like way.