Moved startTracking() call to setup() #49
Conversation
| print_out("Starting uart task"); | ||
| } | ||
|
|
||
| // Start tracking axis now that pins and UART is initialized |
There was a problem hiding this comment.
Personally i would move this init code to a new freertos task and execute the tracking before the loop.
This way its ensured that that the setup sets everything up prior executing any work. The trackingrate and direction should then also be retrievable.
There was a problem hiding this comment.
Are you suggesting to move all of the pin initialization to a task, or just startTracking(). None of that code is long running as far as I understand, so is a task needed?
There was a problem hiding this comment.
It is not long running yes, but it opens doors for future feature implementation as it groups certain functions with their dedicated time slot of execution. Everyhing that should be initialized prior the scheduler takes control of the numerous work should be done in the setup(). startTracking is something that i expect the system to do when everything init related is done and can now "do the real work".
| // Initialize Wifi and web server | ||
| setupWireless(); | ||
| // Start tracking axis now that pins and UART is initialized | ||
| setupTracking(); |
There was a problem hiding this comment.
Call the setupTracking() in the trackerTask prior the loop.
Also the setupWireless() should happen befor the tasks are created. The previous position in the code for it was better.
| // Initialize Wifi and web server | ||
| setupWireless(); | ||
|
|
||
| if (xTaskCreate(intervalometerTask, "intervalometerTask", 4096, NULL, 1, NULL)) |
There was a problem hiding this comment.
This won't work as it creates the same task that already exists. rename it to trackingTask with the corresponding entry function. Have a look at the other tasks on how they are added, should be fairly simple to add it.
| print_out("Starting uart task"); | ||
| } | ||
|
|
||
| // Start tracking axis now that pins and UART is initialized |
There was a problem hiding this comment.
It is not long running yes, but it opens doors for future feature implementation as it groups certain functions with their dedicated time slot of execution. Everyhing that should be initialized prior the scheduler takes control of the numerous work should be done in the setup(). startTracking is something that i expect the system to do when everything init related is done and can now "do the real work".
|
Any update on this PR @DjofPlusPlus? Please rebase your PR on the |
|
I'm currently abroad away from the hardware. |
2 participants
I'm working with a OG v1. In my setup I was getting tracking rotation in the wrong direction. I found this to be due to pin initialization in
setup()occurring after the code in the staticAxis ra_axisconstructor had executed, withsetDirectionfailing. For the same reason, outputting to UART was also failing since it's initialized insetup()as well.Moving the
startTracking()call to setup resolved these issues.