xiaoxiang781216 commented on issue #353: multiple definition of `up_mdelay' URL: https://github.com/apache/incubator-nuttx/issues/353#issuecomment-590082027 > > Not a whole architecture, different chipset in the same architecture can select the different approach because each chipset has own Make.defs and can include/exclude up_delay.c as needed, but the same chipset must share the same decision. > > Isn't that just an abritrary limitation? Why should implementation on any architecture have this option? Why limit it to just certain, pre-determined architectures? So you want to add an option to let user select? 1.Use up_rtc_*, up_timer_* and up_alarm_* in arch/ or 2.Use up_rtc_*, up_timer_* and up_alarm_* in drivers/timers/ There isn't difference outside the implementatin, the user get the same functionality with either selection. Actually, up_timer_/up_rtc_/up_alarm_ API is duplicated with oneshot_operations_s/rtc_ops_s/timer_ops_s and make the chpset developer write many duplication without any benefit. The best solution is: 1.Remove up_timer_, up_alarm_, up_rtc from nuttx/arch.h 2.Modify the code under sched/ to call oneshot_operations_s/rtc_ops_s/timer_ops_s instead of up_timer_, up_alarm_, up_rtc. 3.Developer just need implement oneshot_operations_s/rtc_ops_s/timer_ops_s for their hardware
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
