We are constantly struggling with making the course better. We got a lot of feedback from the past runs and we would like to address the strongest issues since most of the problems likely started as misunderstandings.
The labs and the lectures are quite different and independent. Aside from the initial C++ tutorial, the labs are not directly connected to the topics covered in lectures. It is not an accident, it is by design. Some of the lectures could indeed be enhanced by additional labs; however, it would also require increasing the lab hours (to have labs every week), which is currently not possible due to many reasons such as manpower shortage and curriculum size limitations.
It is our opinion that getting in touch with real hardware whilst learning fundamentals of C/C++ is much more valuable than having additional seminars to deepen the topics from lectures (especially considering the lectures are mostly an overview and there are subsequent courses that will be more thorough). If a student feels that some of the topics are not clear enough from the lectures, one can always arrange a consultation with the lecturers.
The exam is a test that is taken in digital form (on PCs in the labs). It has been suggested that an oral exam would be preferable. We also received complaints regarding the fact that the grading only counts the correct answers and does not consider the intermediate calculations or procedures. We do understand these concerns and there are arguments to support their point of view. On the other hand, there are arguments (which we consider stronger) that support our way and we plan to keep the format for the foreseeable future. The main reasons are:
Grading the test questions strictly (each question is either completely correct or wrong) may seem harsh, but we have also considered this thoroughly and we think this is the desired level due to some mitigating factors:
In addition, we have added a special dispensation that the students may leave the test once it has started to avoid getting a bad grade (should they decide that they have underestimated the preparation). This dispensation can be invoked only once by each student.
We have registered complaints that some lab teachers had their requirements set at a different level than others. We have designed more detailed guidelines for the lab teachers based on an internal discussion. Furthermore, we have written down the coding guidelines so it is clear which issues we emphasize (since code quality is the most subjective topic in this class).
However, if anyone gets indications that a lab teacher gets overly excessive with the lab requirements, do not hesitate to bring it up to the course guarantors, so we can level things out. On the other hand, please understand, that each lab teacher has an individual style and these differences cannot be leveled.
The remarks related to Moccarduino emulator used in ReCodEx can be summarized into two larger issues:
1) The emulator does not support some features. That is correct, but the list of differences is not that long and it should be bearable to write solutions that avoid these few pitfalls. In addition, some things are disabled explicitly (e.g., blocking the loop()) since we do not wish them to be used in the assignments (using delay(), bypassing standard API, or using interrupts/timers). The undesired practices are explicitly mentioned by the teachers in the labs and the step-by-step guides for the assignments are designed so that the students can avoid them without extra effort.
2) It is difficult to debug. A code could often seemingly work on a real device, but it is not passing the tests in ReCodEx. In most cases we reviewed manually, the reason that the student did not follow the specification of the assignment properly (e.g., the timing was off) or made a mistake that cannot be easily spotted but the ReCodEx tests were explicitly designed to reveal it. Unfortunately, there is little we can do with the output from ReCodEx (though we are planning some minor improvements). On the other hand, the students shouldn't try to debug their code in an error-trial approach using ReCodEx as a black-box evaluator. Should this happen, the recommended course of action is to re-check the assignment specification (and the Moccarduino differences -- mentioned in the first point), and subsequently consult the lab teacher (via Mattermost) if the bug is persistent and elusive. Lab teachers should have enough experience and also have better means for debugging (since they understand the tests), so they can help to find the problem.
There is particular emphasis on code quality in the labs and some students were complaining that the code quality has nothing to do with understanding the Arduino platform or being able to write functionally correct solutions. Technically, that is true, but writing good code is an essential skill that usually takes many years to develop. Hence, we need to incorporate it in all programming courses so the students can get enough practice. On the other hand, we have reduced the scope to five important topics this year to make this manageable even for the rookies.
In addition, code quality can be seen as a balancing element that attempts to make the labs similarly difficult for all levels of students. If you feel that the Arduino assignments are not challenging enough, focus more on the code quality and find some challenges there so you can still learn new things instead of dwelling at the bottom of your comfort zone, simply utilizing what you already know.
Finally, we are working on synchronizing the code quality requirements with Programming I and II, so the students get more accustomed to them and handle them more easily. However, such changes take time since Programming I and II courses have some momentum and cannot be changed overnight.