Здравствуйте! Давно присматриваюсь к идее запуска на AVR какой-либо РТОС... В моем обзоре есть JacOS, scmRTOS и FreeRTOS. Решил остановится на последней, т.к. она портирована на большинство платформ и о ней достаточно много говорят на этом форуме) Вот хочу спросить, запускал ли кто эту ось на АВРке и какие траблы были? Стоит ли вообще этим заниматься? Может лучше чихнуть на порты для остальных платформ и остановится на менее ресурсоекой JacOS?
Цель моей задумки просто изучение... Хочется в живую пощупать, ощутить работу ОС на AVR...
Прошу прощения, что не очень четко и грамотно изложил вопрос, но я думаю основное направление понятно...
Технически подробности:
1. Предпочитаемый мною компилятор: GCC.
2. МК: ATmega16 либо (если не хватит ОЗУ, т.к. примеры с сайта для 32 меги) ATmega32.
Полная версия этой страницы: FreeRTOS на AVR
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > FreeRTOS
Цитата(haker_fox @ Aug 29 2006, 10:30) 
В моем обзоре есть JacOS, scmRTOS и FreeRTOS. Решил остановится на последней
Я плотно работаю с FreeRTOS, но не работаю с AVR, посему на объективность претендовать не могу :-(
Но FreeRTOS в полной сборке как-то мне кажется тяжеловатой для AVR. Впрочем, наверное следует просто собрать ядро и пару простейших задач, после чего Вы сможете сами решить утраивает Вас размер и тайминги шедулера.
Цитата(zltigo @ Aug 29 2006, 17:06)
Цитата(haker_fox @ Aug 29 2006, 10:30)
В моем обзоре есть JacOS, scmRTOS и FreeRTOS. Решил остановится на последней
Я плотно работаю с FreeRTOS, но не работаю с AVR, посему на объективность претендовать не могу :-(
Но FreeRTOS в полной сборке как-то мне кажется тяжеловатой для AVR. Впрочем, наверное следует просто собрать ядро и пару простейших задач, после чего Вы сможете сами решить утраивает Вас размер и тайминги шедулера.
Спасибо!
Видимо так и нужно будет сделать... В любом случая на FreeRTOS смотрю из за наличия портов для других платформ, так сказать закладываю фундамент для будущего, кто знает, с чем придется работать дальше...
Цитата(haker_fox @ Aug 29 2006, 13:30)
Здравствуйте! Давно присматриваюсь к идее запуска на AVR какой-либо РТОС... В моем обзоре есть JacOS, scmRTOS и FreeRTOS. Решил остановится на последней, т.к. она портирована на большинство платформ и о ней достаточно много говорят на этом форуме) Вот хочу спросить, запускал ли кто эту ось на АВРке и какие траблы были? Стоит ли вообще этим заниматься? Может лучше чихнуть на порты для остальных платформ и остановится на менее ресурсоекой JacOS?
+1 за scmRTOS:
- минимальная ресурсоемкость
- свободная и открытая (в отличии от JacOS)
- отличная документация
- существуе порт для ARM, не за горами для FR (MB91)
Цитата(spf @ Aug 29 2006, 12:38)
+1 за scmRTOS:
- минимальная ресурсоемкость
- свободная и открытая (в отличии от JacOS)
- отличная документация
- существуе порт для ARM, не за горами для FR (MB91)
И -1 за то, что она требует С++ компилера -> WinAVR пролетает, что неправильно.
- минимальная ресурсоемкость
- свободная и открытая (в отличии от JacOS)
- отличная документация
- существуе порт для ARM, не за горами для FR (MB91)
Introduction
Any embedded system usually has three purposes: gathering input, processing, and providing output. The most efficient way to respond to input and present output is to make input and output event driven, such that the normal task execution is interrupted when new events occur: the system has event based multitasking. If this technique is used, the system has event based multitasking. It also can be said to have two priority levels: the event driven interrupt handler and the processing task or tasks. One design could be to have a main loop analyze all events that occur and respond. Another would be to separate events into independent concurrent processes and have a dedicated main task (known as a kernel) transferring control among them. The kernel, allocates and efficiently distributes the resource of the processor between competing tasks.
There are two major methods of sharing processor time. A system timer interval can determine when context switches occur and one process is preempted by another or the tasks themselves can decide when it is a good time to transfer control by using a system call. If timing is used, the system is preemptively scheduled. The other approach describes a cooperatively scheduled system. Of course there are tradeoffs between both designs.
As previously noted any event driven system already has two priority levels: interrupt handling code, and the tasks. Easily enough, different priorities can be given to different tasks, such that when two tasks have the opportunity to run, the higher priority task is chosen by the scheduler. Alternatively, all tasks can be given the same priority. This is known a round-robin kernel. Again, there are tradeoffs as always between these options.
It is obvious that having different priorities allow achieving more flexible control but the price to pay is a problem with priority scheduling - threads with low priority may rarely gain processor control. This is known as starvation. One of the solutions to this is to issue escalating priorities, such that the priority of a task will increase the longer a task waits to be run .
The requirements of your project should help you determine if you need an operating system, and if so, which one.
Requirements for Real Time Kernel
Brick is designed to
• Fit into 2048 bytes of internal SRAM including all application tasks and their separate stacks
• Support up to 15 user defined tasks
• Switch automatically between regular and power save mode
• Switch context in less than 1024 MCU clocks
• Use a very limited amount of inline assembly
What is BRICK?
BRICK stands for Basic Reduced Integrated Cooperative Kernel. It supports a real time, cooperatively scheduled operating system designed to meet very strict memory and the highest achievable speed requirements. It uses round-robin scheduling. It is written in Object Oriented C (C--) with very limited elements of inline assembly. It also supports an internal messaging system for inter-task communications, as well as semaphores, and timer operations. It features functions to handle automatic power saving. This feature requires additional 32 kHz external crystal oscillator. With it system timer frequency is 64 Hz. Otherwise system timer should be running with frequency close to 60 Hz.
This kernel offers only very basic functions. It is reduced to only one system call: sleep () used by the application tasks to transfer control to the kernel and therefore to each other. The internal messaging system has a queue only one message deep which means that any task can receive only one message at a time.
Any project based on BRICK may be interpreted as a proprietary, dedicated operating system which uses BRICK as its kernel. This OS can have memory management, command interpreter, file system, or many other traditional features, but they need to be added when required as application tasks. Most embedded systems do not need a big list of features, but instead require some unique combination. Excluding almost all features makes BRICK very light weight, flexible, and responsive. You can build your own RTOS to fit your needs from BRICK in the same way that many different buildings can be constructed from the same bricks...
BRICK uses only hardware integrated into the MCU circuitry and does not require any external hardware except crystal oscillator(s).
BRICK is a suitable kernel for a real time operating system, which is useful when stringent time deadlines for certain behaviors are necessary. BRICK meets the necessities for time critical computing through strong optimization for speed and a round robin priority cooperative task design.
Why Round Robin?
BRICK uses round robin scheduling instead of a priority based. There is more than one way to implement a prioritized tasks scheme, but there is no clear reason to choose any one for a general unknown model. Interpreting the round robin priority scheme as one level and interrupt handlers as another higher level, seems to be the most efficient design to meet the declared requirements.
Why Cooperative?
BRICK uses cooperative scheduling. This means tasks must cede processor control to each other in order to achieve multitasking. This contrasts the preemptive model, in which the timer may force context switches between tasks.
BRICK was designed to be cooperative due to memory and speed requirements. First, BRICK allows fitting up to 15 application task and itself into 2 kb of SRAM. Each task has its own stack which must be large enough to hold all of the registers needed for context switching as well as those needed for any interrupt: the interrupts use stack of the currently running task and may occur at any time! Because BRICK is cooperative, and therefore context switching is done only using a system call, the optimizing compiler can recognize what registers need to be saved. Only those registers are pushed, thus minimizing the amount of stacks size and time latency needed to allow for context switching. This contrasts a preemptive operating system which must push and pop all registers for each context switch, because the context switch may occur unexpectedly and can not be optimized. Also, in a preemptive system the scheduler has to be executed each system timer tick, but this behavior slows the performance of the tasks which actually need to run, and thus the overall system.
The cost of using cooperative scheduling is that writing a task is writing a part of the OS itself. Therefore it requires more effort from the software engineer. One failing task can cause the whole system to crash. Care must be taken when designing tasks to ensure that they cooperate well with the system.
Using Brick
Drivers
Device drivers are an interface between application software and hardware, allowing access sharing and control. Using BRICK it is often appropriate to divide device drivers into two halves, an interrupt handler and a task.
By default the interrupt is disabled when entering the interrupt service routine and BRICK does not support nested interrupts, so it is necessary that the amount of processing done in the interrupt service routine is minimal, otherwise we may lose other interrupts. Therefore usually all that is done in the interrupt handler is reading/writing input/output/status from/to the device or shared memory location, preparing for the next cycle if necessary and to communicate with another half of the device driver implemented as an application task. This can be done by writing the data to a shared memory location or by sending data or a signal in a message to the destination task. Interrupt handlers are allowed to send a message using the BRICK messaging system, but they can not receive any messages, other than via shared memory. ISRs run in the memory of the task that was running when the interrupt occurred, not only the task with which they are associated. Receiving a message uses the descriptor of the currently running task. This is why interrupt handlers can not receive messages.
Shared Memory Usage
If shared memory is used to communicate between the interrupt handler and the task, some mechanism must be developed to allow the task and ISR to follow all stages of the inter-communication process. Care must be taken to insure that the shared memory is not modified by the interrupt handler while it is being processed by the involved task. Otherwise unpredictable results may occur. This can be prevented by masking (disabling) the interrupt handler or by using a semaphore to obtain mutual exclusion between reading and writing halves to this memory.
Semaphore Operations
Access to resources can be protected through the BRICK supported semaphore operation. There are many ways to achieve a semaphore operation, but BRICK has only one simple built in semaphore used to limit access to a resource on a first come first served basis. It is usually used for communication between the interrupt handler and its corresponding task. The indicator has to be initialized to FREE before communication has begun and changed to BUSY while updating. Once at the end of the critical section, the indicator has to be set back to FREE.
Communication using BRICK Messaging System
As was mentioned above any task or interrupt handler can send a message or number of messages to other tasks. Interrupt handler can only send a message or messages using dedicated BRICK function. At the same time each task can receive one and only one message at a time using another devoted BRICK function. There is an exception. BRICK supports special a WAKEUP_TYPE message. This type does NOT have any data to transfer. When the task descriptor already has a WAKEUP_TYPE message and another type of message is sent it is allowed to replace the WAKEUP_TYPE with that one. The purpose of the WAKEUP_TYPE is to provide a signal of some event occurrence and replacement will not cause data loss but any type will transfer the signal.
When received data is processed a special BRICK function for clearing receive buffer has to be called.
Task Design
A system designed for a RTOS has to be structured so that functionality is divided into independent tasks. BRICK supports up to 15 user defined tasks. Because BRICK uses cooperative scheduling, tasks must be designed to work together. All tasks must use the only one system call sleep () to cede control, giving other tasks a chance to run.
Ceding Control: Sleep ()
This function allows for cooperative scheduling between tasks. It is important that all tasks sleep frequently, so that they may politely give other tasks a chance to run. Usually each task can be described as an initialization section followed by an infinite loop. In this loop some functionality occurs. Before the loop is closed the function should sleep, allowing other tasks to run. There should be no long loops without a call to sleep.
There are 3 modes supported. When calling sleep, a task declares a condition to become ready to run again. Tasks will become ready to run:
• after requested number of ticks (system timer counts);
• after any message has been received
• combined previous two events
Note that system call sleep must NEVER be called from an interrupt handler. It also re-enables global interrupts. Therefore it should not be used inside atomic blocks.
Power Control
To switch to the power save mode several conditions have to be met:
• power save option is turned on;
• kernel has run over all tasks descriptors and hasn’t found any one ready to run;
• minimal time left to wakeup at least one task is greater than some predefined constant;
• no power locks has been set.
Power locks are necessary when task expects some event i.e. wakeup message from the interrupt handler. At the same time it is not ready to run yet. While it is waiting the task should set a power lock.
Timing Operations
BRICK supports several functions to handle timing operations in system ticks. The system timer frequency is close to 60 Hz. Ticks are valued from 0 to 65535. Timing begins when BRICK is started. Overflow of ticks resets the value back to 0. That covers a time interval of approximately 15 minutes. If a greater time period is necessary it becomes responsibility of the application task.
Any embedded system usually has three purposes: gathering input, processing, and providing output. The most efficient way to respond to input and present output is to make input and output event driven, such that the normal task execution is interrupted when new events occur: the system has event based multitasking. If this technique is used, the system has event based multitasking. It also can be said to have two priority levels: the event driven interrupt handler and the processing task or tasks. One design could be to have a main loop analyze all events that occur and respond. Another would be to separate events into independent concurrent processes and have a dedicated main task (known as a kernel) transferring control among them. The kernel, allocates and efficiently distributes the resource of the processor between competing tasks.
There are two major methods of sharing processor time. A system timer interval can determine when context switches occur and one process is preempted by another or the tasks themselves can decide when it is a good time to transfer control by using a system call. If timing is used, the system is preemptively scheduled. The other approach describes a cooperatively scheduled system. Of course there are tradeoffs between both designs.
As previously noted any event driven system already has two priority levels: interrupt handling code, and the tasks. Easily enough, different priorities can be given to different tasks, such that when two tasks have the opportunity to run, the higher priority task is chosen by the scheduler. Alternatively, all tasks can be given the same priority. This is known a round-robin kernel. Again, there are tradeoffs as always between these options.
It is obvious that having different priorities allow achieving more flexible control but the price to pay is a problem with priority scheduling - threads with low priority may rarely gain processor control. This is known as starvation. One of the solutions to this is to issue escalating priorities, such that the priority of a task will increase the longer a task waits to be run .
The requirements of your project should help you determine if you need an operating system, and if so, which one.
Requirements for Real Time Kernel
Brick is designed to
• Fit into 2048 bytes of internal SRAM including all application tasks and their separate stacks
• Support up to 15 user defined tasks
• Switch automatically between regular and power save mode
• Switch context in less than 1024 MCU clocks
• Use a very limited amount of inline assembly
What is BRICK?
BRICK stands for Basic Reduced Integrated Cooperative Kernel. It supports a real time, cooperatively scheduled operating system designed to meet very strict memory and the highest achievable speed requirements. It uses round-robin scheduling. It is written in Object Oriented C (C--) with very limited elements of inline assembly. It also supports an internal messaging system for inter-task communications, as well as semaphores, and timer operations. It features functions to handle automatic power saving. This feature requires additional 32 kHz external crystal oscillator. With it system timer frequency is 64 Hz. Otherwise system timer should be running with frequency close to 60 Hz.
This kernel offers only very basic functions. It is reduced to only one system call: sleep () used by the application tasks to transfer control to the kernel and therefore to each other. The internal messaging system has a queue only one message deep which means that any task can receive only one message at a time.
Any project based on BRICK may be interpreted as a proprietary, dedicated operating system which uses BRICK as its kernel. This OS can have memory management, command interpreter, file system, or many other traditional features, but they need to be added when required as application tasks. Most embedded systems do not need a big list of features, but instead require some unique combination. Excluding almost all features makes BRICK very light weight, flexible, and responsive. You can build your own RTOS to fit your needs from BRICK in the same way that many different buildings can be constructed from the same bricks...
BRICK uses only hardware integrated into the MCU circuitry and does not require any external hardware except crystal oscillator(s).
BRICK is a suitable kernel for a real time operating system, which is useful when stringent time deadlines for certain behaviors are necessary. BRICK meets the necessities for time critical computing through strong optimization for speed and a round robin priority cooperative task design.
Why Round Robin?
BRICK uses round robin scheduling instead of a priority based. There is more than one way to implement a prioritized tasks scheme, but there is no clear reason to choose any one for a general unknown model. Interpreting the round robin priority scheme as one level and interrupt handlers as another higher level, seems to be the most efficient design to meet the declared requirements.
Why Cooperative?
BRICK uses cooperative scheduling. This means tasks must cede processor control to each other in order to achieve multitasking. This contrasts the preemptive model, in which the timer may force context switches between tasks.
BRICK was designed to be cooperative due to memory and speed requirements. First, BRICK allows fitting up to 15 application task and itself into 2 kb of SRAM. Each task has its own stack which must be large enough to hold all of the registers needed for context switching as well as those needed for any interrupt: the interrupts use stack of the currently running task and may occur at any time! Because BRICK is cooperative, and therefore context switching is done only using a system call, the optimizing compiler can recognize what registers need to be saved. Only those registers are pushed, thus minimizing the amount of stacks size and time latency needed to allow for context switching. This contrasts a preemptive operating system which must push and pop all registers for each context switch, because the context switch may occur unexpectedly and can not be optimized. Also, in a preemptive system the scheduler has to be executed each system timer tick, but this behavior slows the performance of the tasks which actually need to run, and thus the overall system.
The cost of using cooperative scheduling is that writing a task is writing a part of the OS itself. Therefore it requires more effort from the software engineer. One failing task can cause the whole system to crash. Care must be taken when designing tasks to ensure that they cooperate well with the system.
Using Brick
Drivers
Device drivers are an interface between application software and hardware, allowing access sharing and control. Using BRICK it is often appropriate to divide device drivers into two halves, an interrupt handler and a task.
By default the interrupt is disabled when entering the interrupt service routine and BRICK does not support nested interrupts, so it is necessary that the amount of processing done in the interrupt service routine is minimal, otherwise we may lose other interrupts. Therefore usually all that is done in the interrupt handler is reading/writing input/output/status from/to the device or shared memory location, preparing for the next cycle if necessary and to communicate with another half of the device driver implemented as an application task. This can be done by writing the data to a shared memory location or by sending data or a signal in a message to the destination task. Interrupt handlers are allowed to send a message using the BRICK messaging system, but they can not receive any messages, other than via shared memory. ISRs run in the memory of the task that was running when the interrupt occurred, not only the task with which they are associated. Receiving a message uses the descriptor of the currently running task. This is why interrupt handlers can not receive messages.
Shared Memory Usage
If shared memory is used to communicate between the interrupt handler and the task, some mechanism must be developed to allow the task and ISR to follow all stages of the inter-communication process. Care must be taken to insure that the shared memory is not modified by the interrupt handler while it is being processed by the involved task. Otherwise unpredictable results may occur. This can be prevented by masking (disabling) the interrupt handler or by using a semaphore to obtain mutual exclusion between reading and writing halves to this memory.
Semaphore Operations
Access to resources can be protected through the BRICK supported semaphore operation. There are many ways to achieve a semaphore operation, but BRICK has only one simple built in semaphore used to limit access to a resource on a first come first served basis. It is usually used for communication between the interrupt handler and its corresponding task. The indicator has to be initialized to FREE before communication has begun and changed to BUSY while updating. Once at the end of the critical section, the indicator has to be set back to FREE.
Communication using BRICK Messaging System
As was mentioned above any task or interrupt handler can send a message or number of messages to other tasks. Interrupt handler can only send a message or messages using dedicated BRICK function. At the same time each task can receive one and only one message at a time using another devoted BRICK function. There is an exception. BRICK supports special a WAKEUP_TYPE message. This type does NOT have any data to transfer. When the task descriptor already has a WAKEUP_TYPE message and another type of message is sent it is allowed to replace the WAKEUP_TYPE with that one. The purpose of the WAKEUP_TYPE is to provide a signal of some event occurrence and replacement will not cause data loss but any type will transfer the signal.
When received data is processed a special BRICK function for clearing receive buffer has to be called.
Task Design
A system designed for a RTOS has to be structured so that functionality is divided into independent tasks. BRICK supports up to 15 user defined tasks. Because BRICK uses cooperative scheduling, tasks must be designed to work together. All tasks must use the only one system call sleep () to cede control, giving other tasks a chance to run.
Ceding Control: Sleep ()
This function allows for cooperative scheduling between tasks. It is important that all tasks sleep frequently, so that they may politely give other tasks a chance to run. Usually each task can be described as an initialization section followed by an infinite loop. In this loop some functionality occurs. Before the loop is closed the function should sleep, allowing other tasks to run. There should be no long loops without a call to sleep.
There are 3 modes supported. When calling sleep, a task declares a condition to become ready to run again. Tasks will become ready to run:
• after requested number of ticks (system timer counts);
• after any message has been received
• combined previous two events
Note that system call sleep must NEVER be called from an interrupt handler. It also re-enables global interrupts. Therefore it should not be used inside atomic blocks.
Power Control
To switch to the power save mode several conditions have to be met:
• power save option is turned on;
• kernel has run over all tasks descriptors and hasn’t found any one ready to run;
• minimal time left to wakeup at least one task is greater than some predefined constant;
• no power locks has been set.
Power locks are necessary when task expects some event i.e. wakeup message from the interrupt handler. At the same time it is not ready to run yet. While it is waiting the task should set a power lock.
Timing Operations
BRICK supports several functions to handle timing operations in system ticks. The system timer frequency is close to 60 Hz. Ticks are valued from 0 to 65535. Timing begins when BRICK is started. Overflow of ticks resets the value back to 0. That covers a time interval of approximately 15 minutes. If a greater time period is necessary it becomes responsibility of the application task.
Цитата(Evgeny_CD @ Aug 29 2006, 15:44)
Цитата(spf @ Aug 29 2006, 12:38)
+1 за scmRTOS:
- минимальная ресурсоемкость
- свободная и открытая (в отличии от JacOS)
- отличная документация
- существуе порт для ARM, не за горами для FR (MB91)
И -1 за то, что она требует С++ компилера -> WinAVR пролетает, что неправильно.- минимальная ресурсоемкость
- свободная и открытая (в отличии от JacOS)
- отличная документация
- существуе порт для ARM, не за горами для FR (MB91)
Никуда WinAVR не пролетает - в нем С++ появился как бы не раньше, чем в IAR (по крайней мере поддержка шаблонов и прочего, чего нет в так называемом Embedded C++ в нем появилась сразу с появлением поддержки ++, в отличие от IAR'а). На scmRTOS есть порт для WinAVR, правда, он довольно старый, еще для версии 1.х.
Цитата(Evgeny_CD @ Aug 29 2006, 14:44)
И -1 за то, что она требует С++ компилера -> WinAVR пролетает, что неправильно.
Давайте не будем опускаться до того что "все что не на Си-89 - неправильно"
Прошу прощения за ламерство!
http://winavr.sourceforge.net/
WinAVR (pronounced "whenever") is a suite of executable, open source software development tools for the Atmel AVR series of RISC microprocessors hosted on the Windows platform. It includes the GNU GCC compiler for C and C++.
Я предыдущий вывод сделал на основе данных сайта
http://klen.org/Projects/Embeded-gnu-tools...last_build.html
http://klen.org/Projects/Embeded-gnu-tools...gcc-cpp-how.txt
http://winavr.sourceforge.net/
WinAVR (pronounced "whenever") is a suite of executable, open source software development tools for the Atmel AVR series of RISC microprocessors hosted on the Windows platform. It includes the GNU GCC compiler for C and C++.
Я предыдущий вывод сделал на основе данных сайта
http://klen.org/Projects/Embeded-gnu-tools...last_build.html
http://klen.org/Projects/Embeded-gnu-tools...gcc-cpp-how.txt
Ещё один +1 в пользу scmRTOS и в поддержку тезиса "минимальная ресурсоёмкость" это отдельный стек прерываний, что для небогатых на ОЗУ AVR (особенно mega16) довольно существенно.
Использую эту RTOS давно и продуктивно (7 проектов).
Использую эту RTOS давно и продуктивно (7 проектов).
Цитата
На scmRTOS есть порт для WinAVR, правда, он довольно старый, еще для версии 1.х.
Т.е. можно рискнуть пересобрать новую версию под gcc?
Большое спасибо, всем ответившим! На основе всего сказанного, решил что действительно FreeRTOS тяжеловата для МК AVR, поэтому останавлюсь пока на выборе между scmRTOS и JacOS...
Немного подумал
... выбор падает на scmRTOS, потому что:
1. Есть несколько портов на другие архитектуры.
2. Вытесняющая многозадачность мне больше нравится, чем кооперативная.
Скачал версию 1.10 для GCC, будем пробывать... уж не знаю, что получится.
Немного подумал
... выбор падает на scmRTOS, потому что:1. Есть несколько портов на другие архитектуры.
2. Вытесняющая многозадачность мне больше нравится, чем кооперативная.
Скачал версию 1.10 для GCC, будем пробывать... уж не знаю, что получится.
Цитата(haker_fox @ Aug 30 2006, 07:13)
Скачал версию 1.10 для GCC, будем пробывать... уж не знаю, что получится.
При желании должно получиться
Скачай и остальные версии для AVR (объем то крохотный) , изучи (раз уж занялся
и объем то крохотный ) да и сделай порт последней версии OS для любимого тобой gcc. Там нет ничего сложного, а хорошее описание поможет разобраться во всех тонкостях.
Цитата(spf @ Aug 30 2006, 12:06)
Цитата(haker_fox @ Aug 30 2006, 07:13)
Скачал версию 1.10 для GCC, будем пробывать... уж не знаю, что получится.
При желании должно получиться
Скачай и остальные версии для AVR (объем то крохотный) , изучи (раз уж занялся
и объем то крохотный ) да и сделай порт последней версии OS для любимого тобой gcc. Там нет ничего сложного, а хорошее описание поможет разобраться во всех тонкостях.К сожалению опыта в портировании у меня совсем нет
Да и со знанием Си++ есть проблемы.... программирую в основном только на Си. В общем проблем будет много, но я думаю смогу их решить.
Сдравствуйте! Объясните пожалуйста дураку целесообразность применения RTOS на AVR.
Заранее спасибо.
Заранее спасибо.
Цитата(Punk @ Aug 30 2006, 12:41)
Сдравствуйте! Объясните пожалуйста дураку целесообразность применения RTOS на AVR.
Заранее спасибо.
Заранее спасибо.
Если бы спросили меня лично, я бы ответил так:
1. Мне нужно "одновременно" опрашивать клавиатуру, управлять дисплеем, крутить два шаговых двигателя и общаться с ПК по RS-232.
2. Заморачиваться разделением времени между процессами самостоятельно не хочется. Тем более что я уже пробывал это делать. Использовались таймеры, оператор switch(...) и др. Получается достаточно хлопотно, хотя ресурсы МК экономятся изрядно.
3. ОС же позволяет сосредоточится только на создании и программировании соответствующих задач для работы с указанной выше периферией (это лично мое мнение).
Цитата(Punk @ Aug 30 2006, 09:41)
Объясните пожалуйста дураку целесообразность применения RTOS на AVR.
Для начала стоит почитать темы в которых встречается слово RTOS, чтоб не возобнавлять религиозные войны...
Цитата(spf @ Aug 30 2006, 08:21)
чтоб не возобнавлять религиозные войны...
Полностью поддерживаю...
Цитата(Punk @ Aug 30 2006, 07:41)
Объясните пожалуйста дураку целесообразность применения RTOS на AVR.
Писать попроще (а иногда и намного проще). Если процессор выполняет несколько асинхронных по отношению друг к другу задач, то без RTOS для каждой задачи нужно создавать свою машину состояния, и при этом следить, чтобы не зациклиться ни в какой фазе слишком надолго. При более-менее сложных задачах это может оказаться весьма проблематичным. А с RTOS все просто - каждая задача пишется отдельно, по линейному алгоритму. И если, например, какому-то из процессов надо ждать события, допустим, ответа от другого устройства, и так, чтобы остальные процессы работали - ничего страшного, ждем и все. А без RTOS пришлось бы выходить, и организовывать обслуживание других процессов, каждый из которых тоже мог ждать события, но другого, в общем, сплошной геморрой.
Сам я scmRTOS использую, в общем, доволен, хотя и подрихтовать ее пришлось. Я как пришел к необходимости RTOS - был проект, рабочий, но потребовалось расширить функциональность, добавить еще задачу, асинхронную ко всем остальным, коих и так штук пять было. И пришло осознание, что впихивать во все циклы обслуживание еще одного внешего устройства немыслимо, запутаюсь. Поставил scmRTOS, объем кода, правда, не уменьшился, но он стал гораздо проще и понятнее, и еще один процесс добавился без проблем.
Люди дайте scmRTOS то немогу найти и описание к ней........
Цитата(zorromen @ Jul 28 2007, 16:47)
Люди дайте scmRTOS то немогу найти и описание к ней........
http://scmrtos.sourceforge.net/
http://sourceforge.net/projects/scmrtos/
Господа!
Возможно я слишком резко высказываюсь, но это мое мнение; итак, все авр-ки - это не стековые машины, это микроконтроллеры с последовательным выполнением команд (переходы, условия и т.д. не в счет), которые не имеют аппаратной реализации многозадачности. Потому, полагаясь на чужой опыт создания многозадачной ос, псевдо, кстати, мы вынуждены свои "кусочки" алгоритмов функций привязывать к не всегда удобной обработке той самой многозадачности, - но это только мое мнение. Думаю, что авр-ки создавались изначально не для многозадачности, а для разделенным по времени или условию программам и подпрограммам. Конечно, более геморойно написать обслуживание нескольких устройств "одновременно", но согласитесь, что размер и мощности камня не безграничны, потому, если кто-то ориентируется на авр, то есть некоторые границы тех же многозадачных ос, либо есть вариант перехода на свою собственную ос, либо на другие контроллеры.
Это все полемика, но для "быстрого" написания программ обслуживания нескольких устройств и т.д. подойдет и RTOS, а для конечного продукта, тем более массового производства, нужно что-нибудь свое, это, повторяюсь, только мое мнение.
Прошу прощение за возможный оффтоп, но всё это результат общения с заказчиками и с субподрядчиками...
Возможно я слишком резко высказываюсь, но это мое мнение; итак, все авр-ки - это не стековые машины, это микроконтроллеры с последовательным выполнением команд (переходы, условия и т.д. не в счет), которые не имеют аппаратной реализации многозадачности. Потому, полагаясь на чужой опыт создания многозадачной ос, псевдо, кстати, мы вынуждены свои "кусочки" алгоритмов функций привязывать к не всегда удобной обработке той самой многозадачности, - но это только мое мнение. Думаю, что авр-ки создавались изначально не для многозадачности, а для разделенным по времени или условию программам и подпрограммам. Конечно, более геморойно написать обслуживание нескольких устройств "одновременно", но согласитесь, что размер и мощности камня не безграничны, потому, если кто-то ориентируется на авр, то есть некоторые границы тех же многозадачных ос, либо есть вариант перехода на свою собственную ос, либо на другие контроллеры.
Это все полемика, но для "быстрого" написания программ обслуживания нескольких устройств и т.д. подойдет и RTOS, а для конечного продукта, тем более массового производства, нужно что-нибудь свое, это, повторяюсь, только мое мнение.
Прошу прощение за возможный оффтоп, но всё это результат общения с заказчиками и с субподрядчиками...
Цитата(Dmitry_Od @ Jul 28 2007, 20:41)
Прошу прощение за возможный оффтоп, но всё это результат общения с заказчиками и с субподрядчиками...
Потому и результат вполне предсказуемый.
Я в таких случаях предпочитаю общаться с профильными специалистами.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.