-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework main and loop logic #2
Comments
Nice ideas. It's interesting to see how advanced macros can really help in the embedded world!
I'm not sure this is a good idea. For the simple reason of hiding of the expected and distinguishing (among different MCUs) behavior. In other words I find it much clearer to write But maybe I'm missing something important which would defend such "extreme" level of abstraction 😉. What do you think? |
The reason I didn't want to do this is to increase the potential for sharing code between controllers. The Arduino Uno for example doesn't require a watchdog reset, so a programmer running code on that controller would simply never think to include a |
Thanks for explanation @PMunch . I've given it some thought and think you're right - at least this lib could/should explore how such level of abstraction would pay off in practice. So, yeah, let's do that! Btw. I've finally found some time to take a look at your presentation on FOSDEM - nicely explained, thanks! |
Thanks for listening to my talk :) Hopefully I'll be able to get my suggestions implemented this weekend! |
As mentioned in the FOSDEM presentation something should probably be done around the
proc main() {.exportc.}
andnoMain
which are currently required to get the really small code sizes that Ratel enjoys. After a nice conversation with @yglukhov about this and some preliminary testing it seems that what is actually causing the extra size even without global memory and such is the use ofvolatile
inNimMain
and friends. The reason why it usesvolatile
is to make sure that parts of the code isn't inlined as it tries to set the stack frame to scan for the mark and sweep pass of the GC. This is however not required for ARC which we're using at the moment. It might be required by ORC however. I will probably make a PR to the main Nim repository in the coming days which adds in a check for the C code generation that avoids creating thevolatile
part. I manually wrote a smallNimMain
which did the same things for my module, but avoided those and the code size was the same as it is currently. I'm basically just writing this issue to track progress on this issue. This would allow the example code to simply be written as:The second part of this issue is that
while true
loop. Some platform (the ESP8266 for example) has a hardware watchdog in order to make sure that they don't accidentally enter an infinite loop. This means that code like the above would run until the watchdog fired and then the board would reboot (assuming thatdelayMs
didn't feed the watchdog and sleep the system in a more logical way, which it probably would). I plan on adding aloop
construct which would essentially do the same thing as thewhile true
loop, but have small template calls which would bind to templates in the board definition and allow it to insert logic before the loop, and before and after each loop iteration. This should provide the necessary flexibility to implement such boards, but comments are appreciated if you see other issues with this. The final resulting code would then look like this:With
NimMain
working properly it should also allow modules to have their own initialisation logic in the global scope, if e.g. a board requires some particular things to be done on boot. These should then of course be put behind a compile-time switch if the user wished to do these things manually instead.The text was updated successfully, but these errors were encountered: