Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Проекты с использованием uСLinux и того-же AT91SAM7S256?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
PrSt
собвственно предлагаю развернуть такую тему, так как весьма актуальна для простых ембидед систем?
на данное семейство контроллеров обычно вешают индикаторы(LED, LCD...), клавиатуру(не менее 2кнопок...), и разлычные сетевые интерфейсы(RS232/485, Ethernet, CAN...), накопители памяти(SD,MMC...)
и если смотреть правде в глаза? то от проекта к проекту эта конфигурация не сильно меняется, но зато меняются задачи и алгоритмы работы...

откровенно говоря, жутко надоело в каждом проекте писать, по сути, индивидуальную операционку, хочется использовать уже готовую (но не чтото типа RTOS потому что не потятная вообще)

Теперь вопрос такой - кто нибудь уже делал такую склейку? - uСLinux and AT91SAM7S256

понятно что это не полноценный линукс, однако ведь порт такой же сужествует, если верить ресурсу http://www.uclinux.org/

Вот и вопрос, что нужно для того что бы заработал на этом камне(AT91SAM7S256) uСLinux , может нужно внешнюю память или что еще? компиляторы, ньюансы сборки...

цель не стоит выжать максимум производительности, если это позволит хотя-бы поиметь полных 10 MIPS - просто блестяще...

Озвучте плз отзывы, идеи, ссылки, может уже есть подобные открытые проекты?
мне кажется весьма правельный ход использовать готовую ось.
aaarrr
Если рассматривать именно AT91SAM7S256, то памяти на борту для uCLinux'а однозначно не хватит, а прицепить внешнюю по-честному возможности нет. Лучше посмотреть в сторону более "легких" операционок.

P.S. Что-то www.uclinux.org уже несколько дней лежит.
PrSt
Цитата(aaarrr @ Oct 26 2006, 11:40) *
Если рассматривать именно AT91SAM7S256, то памяти на борту для uCLinux'а однозначно не хватит, а прицепить внешнюю по-честному возможности нет. Лучше посмотреть в сторону более "легких" операционок.

P.S. Что-то www.uclinux.org уже несколько дней лежит.

сегодня не работает почемуто этот сайт с утра эт точно...
я вчера от туда тянул линукс под этот камень, но не нашел документации о том, как вообще там линукс работает, и что он из себя в таким мелком камне представляет, про внешнюю память это я догадуюсь только....
COMA
Имхо uCOS, eCos.

eCos в минмальной конфигурации и на LPC2106 прекрасно работает smile.gif
SpiritDance
COMA
А сколько ресурсов нужно eCos в минимальной конфигурации и что в нее входит?
IgorKossak
Цитата(COMA @ Oct 26 2006, 16:09) *
eCos в минмальной конфигурации и на LPC2106 прекрасно работает smile.gif

И в конфигурации default тоже.

Цитата(SpiritDance @ Oct 26 2006, 16:51) *
COMA
А сколько ресурсов нужно eCos в минимальной конфигурации и что в нее входит?

Позволю себе ответить.
Состав любой из конфигураций можно посмотреть запустив configtool (из под cygwin только).
COMA
Цитата(IgorKossak @ Oct 26 2006, 17:59) *
Позволю себе ответить.

Спасибо за помощь smile.gif

Цитата
Состав любой из конфигураций можно посмотреть запустив configtool (из под cygwin только).

Можно еще под Linux запустить.
А так eCos достаточно граммотная система.
Я ее пока запускал на двух архитектруах - ARM и x86. Но дальше тестов дело не пошло - пока не нашел практического применения smile.gif
Harbour
минимальный обьем для 2.4 ядер 2Mb озу, для 2.6 - 4Mb, т.е. S серия не катит. linux можно поднять на недавно обьявленном SE семействе, но учитывая частоту камня - это будет бешенный черепах. смотрите в сторону embedded os - благо их описания и флеймы на данном форуме присутствуют wink.gif
SpiritDance
Эта.... ну может все-таки ответите, а то мне до запуска конфигуратора еще далеко? smile.gif Мне, кстати, про ресурсы минимальные более интересно. Вот думаю может начать с серьезного изучения именно eCos на арме а не с ucosа, раз она в мелкие контроллеры тоже влезает. Или сами не знаете про ресурсы? smile.gif))

Да и еще... Где бы ее достать-то, а? А то через CVS ее исходники тянуть как-то... того... не тянет. smile.gif
PrSt
Цитата(Harbour @ Oct 27 2006, 07:55) *
минимальный обьем для 2.4 ядер 2Mb озу, для 2.6 - 4Mb, т.е. S серия не катит. linux можно поднять на недавно обьявленном SE семействе, но учитывая частоту камня - это будет бешенный черепах. смотрите в сторону embedded os - благо их описания и флеймы на данном форуме присутствуют wink.gif

бр-бр, погодитека!
там же ведь ядро для начала 2.0.38 насколько я помню, кстати, правельно помню
вот доказательство

uClinux on the ARM7TDMI and MC68EN302
Information on the ARM7TDMI port is found here: http://www.aplio.com/B/B2111.htm
Information on the MC68EN302 port is found here: http://aplionet.aplio.fr/page2.htm

Be sure to download the binaries and source code for the ARM7TDMI [here].
Be sure to download the binaries and source code for the MC68EN302 [here].


Embedded Linux/Microcontroller Project

Index of /uclinux.org/pub/uClinux/ports/arm7tdmi
Name Last modified Size Description
Parent Directory 23-Jun-2000 11:42 -
arm-elf2flt.tar.gz 23-Jun-2000 10:40 277k GZIP compressed archive>
arm-uc-libc.tar.gz 23-Jun-2000 10:40 403k GZIP compressed archive>
arm-uclinux-binutils..> 23-Jun-2000 10:40 6.2M GZIP compressed archive>
egcs.tar.gz 23-Jun-2000 10:42 17.0M GZIP compressed archive>
newlib.tar.gz 23-Jun-2000 10:42 1.7M GZIP compressed archive>
uclinux-arm.tar.gz 23-Jun-2000 10:43 6.9M GZIP compressed archive>
2.0.38.1pre7-AT91M40..> 29-Oct-2000 20:23 646k GZIP compressed patch>
uclinux-patch-export..> 23-Jun-2000 10:43 107k


правда, надо заметить, что, здесь линукс не на AT91SAM7S256, а на AT91M40800...
aaarrr
Цитата(PrSt @ Oct 27 2006, 14:38) *
бр-бр, погодитека!
там же ведь ядро для начала 2.0.38

Требования к памяти у 2.0 примерно такие же, как и у 2.4 - меньше 2-х мегабайт не получится.
uCLinux предназначен для машин без MMU, но никак не для маленьких машин без MMU.
Harbour
Влом сделать size vmlinux ? Для 2.6.x имеем :

text data bss dec hex filename
9786 1962522 50276 2022584 1edcb8 vmlinux
Harbour
Вообще-то у меня где-то валяется 1.0.9 ядро/rootfs, которые работают на i386 640k ОЗУ wink.gif
AlexandrY
Странно, описали в начале атрибуты realtime системы, а хотите посадить туда тормознутый uLinux.
Как вы себе представляете интересно процесс отладки такого монстра, и сколько думаете времени на это уйдет?
И драйвера то под uClinux уже писать придется настоящие. И память внешнюю и дорогую и без защиты придется ставить.
И ради чего все. Ради файловой системы и TCP стека? Так их навалом и без OS-ей имеется.
А с реальным временем чего делать то будете, патчить uClinux или Blackfin сразу ставить вместо ARM-а?
PrSt
Цитата(AlexandrY @ Oct 30 2006, 08:59) *
Странно, описали в начале атрибуты realtime системы, а хотите посадить туда тормознутый uLinux.
Как вы себе представляете интересно процесс отладки такого монстра, и сколько думаете времени на это уйдет?
И драйвера то под uClinux уже писать придется настоящие. И память внешнюю и дорогую и без защиты придется ставить.
И ради чего все. Ради файловой системы и TCP стека? Так их навалом и без OS-ей имеется.
А с реальным временем чего делать то будете, патчить uClinux или Blackfin сразу ставить вместо ARM-а?

ну скажем так, бывает ряд приложений где совершенно не надо "бешанную" производительность от склейки МК+ОС, а важно не тратить много времени на написание взаимодействия между "просессами или же их бледное подобие".
На счет памяти без спору, согласен - возможно прийдется ставить внешнюю...
драйвера писать - ну скажем напишем, не умрем... на то она и ОСь чтоб все через "дрова" работало...
Разумеется - нет, не ради "файловой системы и TCP стека", есть еще такая замечательная вешь как IPC и более того многозадачность(что более важно)...
+ ко всему переносимость с проекта на проект.

а свякую бяку рассматривать типа RTOS (притянутую за уши к плоскости ОС) или еще чего то, что просто махает флагом - мол RealTime...
В контексте данного вопроса не рассматривается же REALTIME требования, а расматривается возможность как такавая применять uCLinux в данном семействе МК...
AlexandrY
uCOS переносится за день на новый процессор, если он вами хорошо изучен. В uCOS есть все механизмы межзадачного взаимодействия: семафоры, флаги, очереди, майлбоксы и т.д.
Для uCOS я с точностью до 1 мкс могу предсказать время переключения между задачами.
Для uCOS есть детерминированный менеджер памяти. Легко сделать менеджер с очередями запросов.
В uCOS нет уровня HAL, а значит драйверы не обременены лишним прокладочным кодом и их легче и быстрее писать. А ведь на новую платформу 90% времени уходит на написание новых драйверов, перенос OS-и в этом и заключается.
Процессы же могут поддерживаться только на процеесорах с MMU, в процессорах без MMU будут только потоки с общим пространством памяти и не будет никакой абсолютно разницы что програмировать под uCLinux что под uCOS. Под uCLinux только больше пропаритесь и ничего нового не получите кроме тормозов.

Цитата(PrSt @ Oct 31 2006, 11:29) *
ну скажем так, бывает ряд приложений где совершенно не надо "бешанную" производительность от склейки МК+ОС, а важно не тратить много времени на написание взаимодействия между "просессами или же их бледное подобие".
На счет памяти без спору, согласен - возможно прийдется ставить внешнюю...
драйвера писать - ну скажем напишем, не умрем... на то она и ОСь чтоб все через "дрова" работало...
Разумеется - нет, не ради "файловой системы и TCP стека", есть еще такая замечательная вешь как IPC и более того многозадачность(что более важно)...
+ ко всему переносимость с проекта на проект.

а свякую бяку рассматривать типа RTOS (притянутую за уши к плоскости ОС) или еще чего то, что просто махает флагом - мол RealTime...
В контексте данного вопроса не рассматривается же REALTIME требования, а расматривается возможность как такавая применять uCLinux в данном семействе МК...
Krom
Цитата(AlexandrY @ Oct 31 2006, 10:49) *
uCOS переносится за день на новый процессор, если он вами хорошо изучен. В uCOS есть все механизмы межзадачного взаимодействия: семафоры, флаги, очереди, майлбоксы и т.д.
Для uCOS я с точностью до 1 мкс могу предсказать время переключения между задачами.
Для uCOS есть детерминированный менеджер памяти. Легко сделать менеджер с очередями запросов.
В uCOS нет уровня HAL, а значит драйверы не обременены лишним прокладочным кодом и их легче и быстрее писать. А ведь на новую платформу 90% времени уходит на написание новых драйверов, перенос OS-и в этом и заключается.
Процессы же могут поддерживаться только на процеесорах с MMU, в процессорах без MMU будут только потоки с общим пространством памяти и не будет никакой абсолютно разницы что програмировать под uCLinux что под uCOS. Под uCLinux только больше пропаритесь и ничего нового не получите кроме тормозов.


Все это хорошо, но денег за uCOS просят немало однако... А вариант с ворованным софтом не подходит.
PrSt
Цитата(Krom @ Nov 7 2006, 08:58) *
Все это хорошо, но денег за uCOS просят немало однако... А вариант с ворованным софтом не подходит.

и все же инетерсно - может ктото всетаки встречал связку uСLinux+AT91SAM7S256
хочется попробовать...
gladov
Цитата(PrSt @ Feb 16 2007, 11:14) *
Цитата(Krom @ Nov 7 2006, 08:58) *

Все это хорошо, но денег за uCOS просят немало однако... А вариант с ворованным софтом не подходит.

и все же инетерсно - может ктото всетаки встречал связку uСLinux+AT91SAM7S256
хочется попробовать...


По-моему уже не раз сказали, что этого быть не может! Ну нету у AT91SAM7S256 даже 2Мб ОЗУ и внешнюю не прикрутишь нормально! Вопрос еще не снят?
Если uCos не нравится, т.к. денег за нее хотят, есть FreeRTOS. Она чем не катит? Если еще меньше, можно вообще scmRTOS - тож бесплатная. Имхо нет таких задач, куда просто необходимо поставить AT91SAM7S256 и обязательно Linux. Linux подразумевает решение больших и серьезных зачач, а для этого камень явно слабоват....
AVR
Цитата(PrSt @ Oct 27 2006, 10:38) *
правда, надо заметить, что, здесь линукс не на AT91SAM7S256, а на AT91M40800...
AT91M42800A:
Цитата
The AT91M42800A features 8K bytes of on-chip SRAM, an External Bus Interface, a 6-channel Timer/Counter,...
rolleyes.gif
Мухамёд
А какой АРМ тогда порекомендуете для беспроблемной работы под линуксом?
bzx
Цитата(Мухамёд @ Feb 21 2007, 20:34) *
А какой АРМ тогда порекомендуете для беспроблемной работы под линуксом?

Например, AT91RM9200
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.