Для правильного понимания этого поста необходимо ознакомиться с
"Продвинутые make'еры: все уже изобретено!"
http://www.caxapa.ru/echo/arm.html?id=61898
http://electronix.ru/forum/index.php?showtopic=18212&hl=

Также имеет смысл посмотреть на COG (респект bialix Сахара)
http://www.nedbatchelder.com/code/cog/index_ru.html
Cog — это инструмент для генерации исходных текстов программ. Он позволяет вам использовать небольшие фрагменты программ на языке Python в качестве генераторов в вашем исходном коде. Такие генераторы могут создавать любой код, который вам нужен.

******************************* Постановка задачи ******************************

Итак, пусть мне необходимо разработать _линейку_ устройств, например, GSM "охранно-телеметрических" девайсов. Пусть все будет делаться в пределах ARM архитектуры (когда все упрется в быстродействие, BlackFin можно использовать)(51, AVR оставим в покое в виду малой стоимости младших ARMов; в принципе, если эту идеологию удастся расширить до кроссядерности ARM | AVR - возражать не буду ).

* простейшее устройство - несколько входов, SMS, да фиксированное голосовое соообщение. AT91SAM7Sххх за глаза
* среднее устройство - то же самое, но скриптовый язык для продвинутого описания реакций на события; голосовые диалоги для звонящего на девайс. STR91ххх + SRAM внешний самое то. Sharp LH97525 тоже хорошо пойдет.
* VIP устройство - фотки (включая MMS), запись звука на носитель и т.д. В идеале, понятно, на BF532 каком-нибудь это сделать (зашита от копирования - FPGA на шину + строго по заветам уважаемого AlexabnderY ).
http://www.caxapa.ru/echo/arm.html?id=51028
http://www.caxapa.ru/echo/arm.html?id=51002

Особый каф - иметь единый репозиторий кода. Т.е. если завтра я найду новый GSM мудем, с "фирменными" удобными командами, то я один раз перепишу (и отлажу!) кусок кода, который у меня занимается этим мудемом, а не три раза.

******************************* Симуляторы ******************************

Штука хорошая, много раз обсуждавшаяся. Но в некотором смысле избыточная (см. ниже)

Хорошо про симуляторы тут "написалось"
Сквозная система разработки embedded устройств
Полноценная GNU среда для embedded разработки
http://www.caxapa.ru/echo/arm.html?id=60891
http://electronix.ru/forum/index.php?showtopic=17562


******************************* Синтетический порт для Win32 ******************************

Синтетический порт - это запуск моего целевого кода (но с эмуляторами драйверов) как обычной Win32 задачи. Это позволит решить массу проблем:

* асбтрагироваться от аппаратуры при разработке архитектуры системы (когда пришется каркас системы - тонкости того, как именно работает UART в данном чипе не должны волновать)

* аутсорсеры

* продвинутое тестирование. Для тестирования "верхней логики" (драйвер UART как-нибудь и на железяке оттестируется и без описанных "наворотов") можно использовать другие процессы Win32: MATLAB, Python и пр. Можно такоей test unit написать - просто заглядение! И все очень легко автоматизировать. Т.е. поправил что-то в "логике" системы, запустил "тестовую систем", пошел чайку попил, посмотрел логи - сколько новых багов внес при попытке исправить один

* отладка для системных интеграторов.
Купил у меня системный интегратор "VIP устройство" для того, чтобы хитрозадый коттедж автоматизировать. Написал скрипт, которые вроде бы делает то, что надо. Как тестировать? На живом железе - устать можно микрики "открывания дверей" нажимать. На кустомере? Нда, не завидую я системному интегратору...

А тут все гораздо проще. Настроил "генератор воздействий" (или вообще тупым перебором | монте-карло), натравил его на модель устройства, с утра посмотрел логи - какие события и как отрабатывались. Все баги все равно не выловить (это вообще невозможно), но вероятность заболеть "асфальтной болезнью" (мордой об асфальт) резко уменьшается.

В принципе все то же самое можно и на симуляторе сделать, но:
* хорошие GNU симуляторы только под Linux есть
* недорогие коммерческие симуляторы едва ли позволят такое сделать
* профессиональные коммерческие симуляторы стоят больше бюджета проекта

******************** IDE, компиляторы ****************************

Таким образом, мой код должен работать на следующих платформах:
* GCC во всех инкарнациях
* KEIL
* IAR
* CrossWorks
* RVDS
* Visual C++ для AD BlackFin
* CCS для TI ARM & DSP

Для Wi32 (будет выбрана одна среда, разумеется):
* M$ VC 6.0+
* Bloodshed Dev-C++ (http://www.bloodshed.net/devcpp.html), пакеты для этой среды (http://devpaks.org/)
* Code::Blocks (http://www.codeblocks.org/)
* Digital Mars (http://digitalmars.com/)
* lcc-win32 (http://www.cs.virginia.edu/~lcc-win32/)
* Open Watcom (http://www.openwatcom.org)

******************************* Что мне надо от ОСи? ******************************

Необходимость использования ОСи в рамках данного поста не обсуждается (было много копьев сломано на эту тему - просто примем как данность, что ОСь нужна).

От ОСи (и "стандартных" программ) мне надо (кроме собственно многозадачности и IPC (Inter Process Comminication)):
* IP
-- Ethernet
-- PPP
-- Web сервачек с динамическим контентом
-- TFTP, FTP клиенты
* Script Engine
-- для описания сложных, но медленных задач (управляющей логики самого верхнего уровня).
-- Tcl, LUA самое то.
* БД - база данных
-- SQL не нужен и даже вреден - я не собираюсь сетевой сервер из своей платки делать!
* GUI - лично мне не сильно нужен, но пусть будет такая возможность
* Файловая система

******************************* Какие бывают ОСи ******************************

** Linux
Замечательная штука, если
* нет жесткого reail time
* все дрова и kernel module готовы, предстоит написание в user space.

Во всех остальных случаях это либо очень муторно, либо очень дорого (Montavista и другие "коммерческие линухи"), либо и то, и другое сразу.

** eCos
Совершенно замечательная вещь, если
* есть готовый порт
* либо есть "взрослый" JTAG для GDB

Если порта нет, то с "вигглером" написать и отладить свой порт _очень_ трудно (в варианте FLASH ARM еще труднее).

Самый дешевый из "взрослых" JTAG для GDB - это 1.5K Euro
http://www.ronetix.com/peedi.html

Поскольку это на каждое рабочее место - то тоскливо.

Портирована eCos много на что, но на самые интересные девайсы открытых портов нет (AT91RM9200, LH7952x, i.MX21 и т.д.)

** uCOS
"Народная" ОСь. Я достаточно долго поглядывал на нее свысока - мол примитивна, софта готового нет (либо денег стоит "недеццких") и т.д. Но постепенно я переосмыслил роль этой ОСи, о чем и повествую ниже.

********************** uCOS **************************************
Портирована под все мыслимые архитектуры и под многие камни. Если есть порт для архитектуры, но нет порта для конкретного контроллера, то написать свой порт - вполне решаемая задача.

Порт uCOS для Blackfin 533 для VisualDSP++ V3.1
http://www.micrium.com/analog/index.html

** Синтетический порт.

Порт uCOS под Win32 для Microsoft Visual C++ V6
http://www.micrium.com/windows/index.html

Порт, похоже, вполне качественный!
As a result of this hierarchy, ?C/OS-II tasks are really Windows threads and their stacks are converted to Windows thread stacks. The system ticker is driven by the high resolution multi-media timer if WIN_MM_TICK is defined in os_cpu.h. Otherwise it is driven by sleep(), the system coarse timer. A more realistic real-time effect can be achieved by using the multi-media timer since it has finer granularity (1ms) than the system coarse timer.
Critical sections are implemented using the Win32 API.

Fortunately, the underlying architecture is transparent to the application programmer and all ?C/OS-II application code can utilize various features using tradiational documented ?C/OS-II function calls.

Since ?C/OS-II is an infinite loop by nature, it should be noted that the processor utilization under windows will remain close to 100% while ?C/OS-II is running. This is normal operating behavior for infinite loop consol based programs under Windows. (ну и бог с ней, загрузкой процессора).

Полагаю, на его основе можно сделать порт для любого компилятора | IDE под Win32.

** Вывод:
Таким образом, проблем с синтетическим портом нет.

************************ LwIP ***********************************
lwIP - A Lightweight TCP/IP stack
http://savannah.nongnu.org/projects/lwip/

Порт LwIP для uCOS
http://geocities.com/michaelanburaj/

** Синтетический порт.

Синтетический порт PPP - выловлено в листе по LwIP:
You may want to try with this code as a starting point; it's my first try with LWIP and PPP under W32, but it worked just fine. I'm using good old VC++ 6.0 to build it:
http://web.comex.com.ar/temporary/pppw32.zip
(по данным на 3.07.06 качается)

Синтетического порт для Ethernet тоже есть
http://lists.gnu.org/archive/html/lwip-use...3/msg00095.html
==
I am running the contrib/msvc6 port compiled with visual studio 2003. It uses winpcap for the interface. I guess it should be possible to compile it in cygwin too.
It doesn't compile out of the box, because the port is a little bit outdated, but the changes required are minimal. If you want I can give you a tarball that works for me.
==
с использованием драйвера WinPcap
http://www.winpcap.org/
WinPcap is the industry-standard tool for link-layer network access in Windows environments: it allows applications to capture and transmit network packets bypassing the protocol stack, and has additional useful features, including kernel-level packet filtering, a network statistics engine and support for remote packet capture.

Более того, сегодня по моей просьбе в лист запостили порт LwIP 1.1.1 для Visual Studio 2003. Пока на сайте этот пост не отображен, но, вероятно, завтра уже будет
http://lists.gnu.org/archive/html/lwip-use...6-07/index.html

** Вывод:
Синтетический порт реализуем.

************************ Script Engine ***********************************
**** Tcl ****

Компактрый интерпретатор Tcl
http://jim.berlios.de/
Jim is an opensource small footprint implementation of the Tcl programming language. It implements a large subset of Tcl and adds new features like references with garbage collection, closures, built-in Object Oriented Programming system, Functional Programming commands, First class arrays. All this with a binary size of about 85kb (that can be reduced further excluding some non-vital commands, and commands not available in Tcl itself).

The Jim core is currently entering the beta stage, must of the core language is already implemented and it is possible to use it to run many unmodified Tcl programs. In the mean time we started to develop extensions, some like sqlite, and ANSI I/O are already ready for prime time, some other like SDL, Win32 and Win32 COM, POSIX, Event loop, and many others are work in progress. All the extensions are included in the source distribution.

* Support for important features that will be availabe in Tcl8.5, like dict and {expand}.
* Arrays in Jim aren't collection of variables like in Tcl, but a first class type. Array access syntax is in Jim syntax sugar to set and get dictionaries elements.
* A compact design. Jim is currently less than 10k lines of code. It does a heavy use of dual ported objects, in Jim even the VM pseudo-bytecode is a specialized Jim_Obj type.
* lambda with garbage collection, and a reference system to build linked data structures.
* Math operations as commands (together with expr support).
* Ability to load extensions at runtime via a STUB system. Even programs using Jim that are linked statically are able to load extensions.
* 85Kbyte binary size!

На нем сделан порт Tcl под eCos
http://www.caxapa.ru/echo/arm.html?id=60595
http://electronix.ru/forum/index.php?showtopic=17298

Раз эта штуковина даже под Event loop работает, под eCOS затащить ее, полагаю, можно

** Синтетический порт.
Вроде как никаких аппаратно зависимых вещей в этом интерпретаторе быть не должно. Посему, полагаю, больших проблем не возникнет.

******* LUA *******
Довольно интересный скриптовый язык
http://www.lua.org/
http://lua-users.org/wiki/LuaDirectory

Цикл статей по LUA
http://itc.ua/article.phtml?ID=20951
http://itc.ua/article.phtml?ID=21025
http://itc.ua/article.phtml?ID=21293
http://itc.ua/article.phtml?ID=21409

Порт LUA для eCos
http://www.xylanta.com/WordPress/?page_id=22

Пример использования LUA в контроллере
http://www.circuitcellar.com/renesas2005m1...inners/1685.htm

** Синтетический порт.
Принципиальных препятствий быть не должно.

************************ БД (база данных) ***********************************

*** GDBM
http://www.gnu.org/software/gdbm/gdbm.html
http://database.sarang.net/database/dbm/gdbm/gdbm.html - некая дока

Простейший вариант, но, на самом деле, лично для моих целей этого хватит.

** Синтетический порт.
Думаю, несложно.

*** Berkeley DB
Это было бы просто идеальным вариантом.

http://www.sleepycat.com/products/bdb.html
* Local, in-process data storage
* Schema-neutral, application native data format
* Indexed and sequential retrieval (Btree, Queue, Recno, Hash)
* Multiple processes per application and multiple threads per process
* Fine grained and configurable locking for highly concurrent systems
* Support for secondary indexes
* In-memory, on disk or both
* Online Btree compaction
* Online Btree disk space reclamation
* Online abandoned lock removal
* On disk data encryption (AES)
* Records up to 4GB and tables up to 256TB

* Programmatic administration and management - zero human administration
* Language support (C, C++, Java, Perl, Python, PHP, Tcl, Ruby, etc.)
* Operating system support (Linux, Windows, BSD UNIX, Solaris, Mac OS/X, VxWorks and any POSIX-compliant operating system)
* Installer for Microsoft Windows
* Apache integration
* RPC enabled API
* Support for memory constrained devices (footprint as small as 350KB)
* Scalable to terabytes of data, billions of records
* Source code, test suite included

** Портирование под uCOS.
Исходники организованы очень грамотно. Все зависимые вещи вынесены в отдельные директории. Процесс будет сложным, но линейным.

** Синтетический порт.
Процесс будет сложным, но линейным.

************************ ГУЙ (GUI) ***********************************

*** Pico Windows
http://sourceforge.net/projects/pwlib/
PW is a small graphics and windowing library. It was designed especially for small embedded systems using 1 bit graphic LCDs. It is very portable, written in ANSI-C and has a small memory footprint.

То, что доктор прописал для большинства моих проектов. Портировать можно под все.

** Nano-X
http://www.microwindows.org/

What is The Nano-X Window System?
The Nano-X Window System is an Open Source project that brings some of the features of modern graphical windowing systems to the programming community not wanting or requiring the large disk and ram requirements of higher-end windowing systems like Microsoft Windows or the X Window System. Nano-X does not require any operating system or other graphics system support, as it writes directly to the display hardware, although it runs well on Linux framebuffer systems. Nano-X is designed to be portable, and can run in a wide variety of hardware and software environments. One the of more interesting targets is the emerging market of portable handheld and pocket PC's running Linux, also known as LinuxCE.

What does Nano-X run on?
Nano-X currently runs on 32-bit Linux systems with kernel framebuffer support, under the X Window system, or through the popular SVGAlib library. In addition, it has been ported to 16-bit Linux ELKS, real-mode and protected mode MSDOS, and the RTEMS real time operating system. Screen drivers for 1, 2, 4, 8, 16, 24 and 32 bits-per-pixel have been written, as well as a VGA 16 color 4 planes driver. The Nano-X system has been ported to a number of Handheld and Pocket PC's, as well. The graphics engine is capable of running on any system that supports readpixel, writepixel, drawhorzline and drawvertline, and setpalette. Blitting support is optional, but if implemented allows enhanced functionality. All bitmap, font, cursor and color support is implemented on top of these routines. Support for 8, 15, 16, 24 and 32 bit truecolor systems as well as 1, 2, 4 and 8bpp palletized systems is implemented.

По отзывам разобравшихся с ней, не такая уж и сложная штуковина
http://electronix.ru/forum/index.php?showtopic=14856
"microwindows замечателеная вещь - там есть чудный документ на несколько страниц с описанием его архитектуры. там в частности сказано:
- наврех он поставляет два набора API на выбор
- снузу ему надо поставить 5 (вроде) функций для рисования - смысла PutPixel GetPixel DrawLine FillRect - уже могу что то напутать. На базе этих функций он сам рисует все остальное." ryhor Электроникс.

** FLTK - хорошая надстройка над Nano-X

http://www.fltk.org/index.php
FLTK (pronounced "fulltick") is a cross-platform C++ GUI toolkit for UNIX®/Linux® (X11), Microsoft® Windows®, and MacOS® X. FLTK provides modern GUI functionality without the bloat and supports 3D graphics via OpenGL® and its built-in GLUT emulation.

FLTK is designed to be small and modular enough to be statically linked, but works fine as a shared library. FLTK also includes an excellent UI builder called FLUID that can be used to create applications in minutes.


готовый пакет для Dev C++
http://sourceforge.net/project/showfiles.php?group_id=94270

*** Simple DirectMedia Layer - вот это очень пригодится для синтетического порта под Win32
http://www.libsdl.org/index.php
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power."

SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.

SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, C#, Eiffel, Erlang, Euphoria, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, and Smalltalk.

************************ Файловые системы ***********************************

"Их есть у нас"

***************** EFSL (Embedded Filesystems Library)
http://sourceforge.net/projects/efsl/

Library for filesystems intended to be used in embedded projects. The library currently supports FAT12/16/32 reading & writing on SD-cards, and is easily expandable for use with other devices on any platform.

Там не только SD, там и CF есть.

Проект хорошо развивается, дока очень грамотная.

** Синтетический порт
Есть изначально. Одна из targer - большой внешний файл (для отладки)

***************** LEAN FS (Lean yet Effective Allocation and Naming)
http://freedos-32.sourceforge.net/showdoc.php?page=leanfs

Раскопал это чудо (без иронии!) КонстантинТ (Сахара), он ее перехачивал для uCOS, работы (по его словам) было много, но результат его сильно впечатлил
http://www.caxapa.ru/echo/arm.html?id=48631
http://www.caxapa.ru/echo/arm.html?id=50594

** Синтетический порт
Реализуемо.

***************** YAFFS (Сейчас, конечно, имеет смысл юзать YAFFS2)
http://www.aleph1.co.uk/node/38

si21 (Электроникс) успешно использует ее для простых ARM устройств.

********************* Выводы *********************************

Интересно, до сюда кто-нибудь дочитал?

1. Если внимательно все собрать в кучку, то uCOS не такая уж и примитивна ОСь. Все минимально-необходимые вещи есть. Собственно, AlexanderY давно мне про это говорил, а я ему с eCos оппонировал.

2. Похоже, что можно сделать синтетический порт uCOS + "стандартные программы". В моем понимании, это будет просто фантатический шаг для структуризации разработки.

3. Возни, конечно, со всеми этими "синтетическими портами" будет очень много, но, IMHO, оно того стоит. Можно силами всего нескольких сотрудников (+ аутсорсеры) организовать целый конвеер по производству ПО, который сейчас доступен только очень "толстым" фирмам.

Кто раскритикует мои идеи?

Доктор, много букав.. ниасилил Вы бы резюме сразу для малограмотных дали... Ну я вот точно знаю, что Nucleus лучше и не надо мне никаких тестов, достаточно глянуть сурцы. У UCOS они примерно уровня курсовой студента. Всё таки резюмируйте пожалйуйста, ну нет сил вникать во все это
Кстати, чем это "Педи" JTAG "взрослый" ? Те же 400 кило в сек что и jlink 5-ой модели. Дровами под GDB и все ?

А вы не рассматривали как вариант скриптовый язык Io? Идеи очень интересные (корни растут из Smalltalk), и ему ядро ОС как раз необходимо (задавал вопрос автору).

ага, а так же почему JAVA упущена ;-) Неужели скриптовый язык Io лучше документирован и имеет лучшую поддержку, чем Java от Sun Microsystem ?

Жабе не повезло. Как-то исторически сложилось так, что я ее не люблю.


1. До сего момента о нем не слышал.
2. Фирма молодая, язык - тоже. Вот подождем пару лет и посмотрим, куда оно вывезет Tcl, LUA существуют уже 10 лет как минимум - так что завтра они точно не исчезнут.



"Каждый выбирает по себе". Я много тем затронул - каждый найжет в посте что-то интересное (или не найдет).

Особый упор я сделал на синтетический порт всего встроенного софта будущего проекта под Win32. Оказалось, что на uCOS это сделать проще всего.

Кроме того, как выяснилось, uCOS не такая уж и "голая - при необходимости ее можно обвестить вполне нормальным набором "прибамбасов".

Кстати, я совсем незаслуженно забыл БД http://www.sqlite.org/. К ней, кстати, интерфейс в http://jim.berlios.de/ встроен изначально.

Кстати, удалось хоть один коммерческий проект под Nucleus сделать?

Сколько лицензия на Nucleus стоит? uCOS, если прижмет, можно и купить (2.5k$) - а ментор, я полагаю, просто разорит...Взрослый он тем, что он под GDB работает "в лоб", через встроенный Ethernet. И много серьезного народа, в отношении которого у меня нет основания для подозрений в предвзятости, очень доволен работой с ним под eCos. Типа берем AT91SAM7Sxx и работаем с FLASH как с RAM в плане отладки кода.

неа проект под Нуклеус не сделал. Нету задачи + дикая природная лень

Жаль. Интересно было бы понять, в чем "теоретическая правильность" на практике выражается.

Системные требования к охранным устройствам Вы закладываете, прямо скажем, непомерные
Несколько входов, SMS, голос - да практически любой дешевый чип справится. SAM7S на объектовом блоке - сразу +200 р к себестоимости.

Требования я так понял поставлены из учета того что будет video capturе. Если видео не требуется - авр справится.

Мне одно интересно во сколько все это вылется - внешняя рам нужна фпга и прибомбасы к ней. Может получиться немного дороговато.

Если интересно: на Nucleus построена многие контроллеры внутри банкоматов Wincor (Siemens).

Здесь речь (по моему) идет больше об исследовательском проекте "на будующее", чем о повседневном "куске хлеба" с жесткими сроками и бюджетом
Не забываем также про системные требования.
А еще смотрим лицензию Io - BSD.



Это, конечно, верно, но выигрывает обычно тот, кто на поезд садится первым.
По поводу LUA, у меня сложилось стойкое мнение, что все эти N лет он в основном развивается как скриптовый язык для игр.
Все small footprint TCL реализации урезанные и малоподдерживаемые (т.е. самоделки), ничем не лучше Io, но без его идей и строгой концепции.
Системные требования "полноценного" TCL требуют полноценных ресурсов, полноценной ОС и полноценного лицензирования. Но это индустриальный стандарт "де-факто", как ни крути.

По поводу "странных" языков - как вам PAWN (C-подобный скриптовый с реализацией алгоритмов автоматического управления в структуре языка) или FICL (Forth-подобный встраиваемый с расширениями на C/C++)?



Я видел несколько проектов с использованием Nucleus, даже очень коммерческих.
Все лицензии покупались + платная поддержка (сколько стоило не знаю, но много).
Результат, прямо скажем, страшненький. Правда, может сам Nucleus в этом и не виноват

Как сказать. При цене самого GSM модуля $50+ +-200р лично меня не волнуют. За счет возможностей всегда можно комипенсировать ценой.

Ресурсы AVR и SAM64 не сравнимы.

Время программиста - самый дорогой ресурс.


GSM охранку я привел как пример. Не более того.

2 dmivs: , похоже на скриптовых языках Вы собаку съели!Ваши аргументы весомы. Но!

* Tcl - как Вы верно заметили, стандарт. И будущих "системных интеграторов" не надо будет переучивать именно под "особый язык проекта".
* Мне всей мощи Tcl не надо. Скрипт будет оперировать достаточно ограниченным набром объектов и методов. Мне важно, чтобы это делалось в рамках какой-либо стандартной идеологии. Будем крутеть - будет и реализация Tcl крутеть. Зато идеологию переделывать не надо будет!
* В приведенной мной реализации сразу есть поддержка БД, что для моих целей - большой +. еще раз. Смотреть надо, за 5 минут не осознать



Forth - это круто и правильно, но непопулярен он. Пока?

PAWN - не отсюда ли растут ноги REFLEX'а Зюбина?

И во сколько будет гипотетическая разница цен ? Я так понял расчет идет на больше чем 64-128 кБ рам.
В консюмерных устройствах цена это один из решаюших факторов плюс потребление по питанию при одинаковой скорости синтетического и натурального процессоров. Если сравнивать АРМ9 атемла или арм7 с внешней рам и фпга ?

Не понял ничего. "Синтетичесий" процессор, он же синтетический порт, для кустомера не предназначен - это средство отладки.

Для простого варианта на ARM 16к за глаза. Может, и меньше - LPC210 (1 | 2 | 3) можно взять. А это уже по цене от AVR будет рублей на 30 отличаться.

Время программиста - самый дорогой ресурс. Вы устанете индивидуально править код для каждой "серхоптимальной" реализации - и обязательно где-то ошибетесь.

При наличии линейки зоопарк процессоров (и средств разработки) вреден. Выиграть можно и на оптовых закупках одного чипа.

Все (ну >>> 95%) из того, о чем здесь написано, есть у AcceleratedTechnology
http://www.mentor.com/products/embedded_software/
Но, это все есс-но денег стоит - вот данные ~ на 2000-2001гг:
- Nucleus PLUS (x86 RM, 68xxx, 68HCxx, NEC V25, Siemens C167) - $8,994
- Nucleus PLUS (ColdFire, MIPS, CR16A/B, CR32, TI DSP) - $11,994
- Nucleus PLUS (PowerPC,MCORE,ARC,ARM Family,H8/300H,H8S,SH1/2/3,SH3/DSP,TriCore,V8xx) - $14,994
- Nucleus NET - TCP/IP Protocol Stack - $14,994
- Extended Protocol Package for Nucleus NET (TFTP, Telnet, Nucleus FTP) - $8,994
- Nucleus WebServ - $11,994
- Nucleus FILE - Re-entrant File System - $5,394
- Nucleus GRAFIX (rendering services & windowing toolkit) - $17,994
- Ethernet Driver Template (or existing ethernet driver) - $3,594
- IDE and Floppy Driver - $4,794
.... ну и т.д.
А еще надо среду EDGE и SimTest ...

Да нет... Разве-что мышку
В свое время просто проводил серьезный анализ применимости скриптовых языков в своих встроенных системах класса AT91SAM7/MCF5213 с/без ОС. Но практически так пока и не использовал ни один из них. Хотя понравился больше других именно Io, по многим причинам. Поэтому и интересно обсудить тему с заинтересованным человеком - может в следующем проекте и применю.



Скорее уже
Списки рассылки читать печально, чувствуешь себя на похоронах совмещенных с торговлей гробами и венками

Не зря я чуял, что нуклеус без штанов оставит Не уж то на ARM меньше, чем за 15k$ его не бывает? Привет DASM'у

А Вы пробовали его хоть на что-нибудь портировать?Да как сказать. С учетом того, что Patriot Scientific продала лицензии Intel и AMD
http://www.ptsc.com/products/index.asp
создатель языка Форт (по слухам) работает сейчас в AMD, может и будет на улице Форта праздник.

Да вот пока нет. Я же говорю дальше монументальных исследований дело не пошло. Да и проекта у меня сейчас нету где бы он был в самый раз.


Да вы что!

Чарльз Мур же давно на пенсии
Цветочки на огороде сажает где нибудь в Калифорнии

Вы его последнее творение, Color Forth видели? Это что-то с чем-то.
Ногу прострелить себе вы

Вообше то идея хорошая. То есть имеется в виду многоплатформенность и возможность симуляции в условиях билзким к реальным . Удаленное проектирование конечно хорошо но как быть с hardware зависимыми модулями ? Допустим тот же модем или специфичная периферия ? И в чем преимущество скрипта по сравнению с native в случае разработчика а не продвинутого пользователя? Только во времени компиляции и загрузки ? На какой спектр продукции эта платформа может расчитывать? В конкретных случаях ненужное может выбрасываться что позволит уменьшить футпринт но определенный оверхед остается. Хорошо бы оценить время нужное на подготовку всего софта и написания документации (без нее вроде никак не получится).

П.С. Просьба проигнорировать предыдушие посты ,голова не сообрaжает - глаз разболелся .

Знаит, это только слухи Написано (дока) круто. В 64к он все собрался уместить ??? "Веревка достаточной длины, чтобы выстрелить себе в ногу?" Это Вы имели в виду?


Может я чего не разумею? В моем понимании UART вместе с мудемом - это
uart_init ();
uart_status ();
put_char ();
put_string ();
get_char ();
get_string ();

FIFO буфер софтовый на выходной и выходной потоки.

Далее все платформонезависимо.

Преимущество крпита в том, что он структуриует мышление. У Вас есть категории
* событие, память событий
* SMS
* некоторые входные данные (списко рассылки SMS и т.д.)

И все. Вас больше ничего не волнует. И Вы можете все усилия потратить на придумывание оптимального для кустомера алгоритма компоновки SMS (что сообщать), кому с каким тектом SMS отправлять, как фильтровать события по степени важности и т.д.

ЗАДАЧА: Прострелить себе ногу.

C: Вы простреливаете себе ногу.
Форт: Hога простреливать себе вы.
Бейсик: Вы простреливаете себе ногу из водяного пистолета. В расширенных реализациях языка продолжайте, пока вся нижняя часть тела не промокнет.
Ассемблер: Вы пытаетесь прострелить себе ногу, но обнаруживаете, что прежде вам придется изобрести пистолет, пулю, курок и вашу ногу.

но это все шуточки

Вот еще

Дело в том что я делал эту систему и сейчас она на стадии прототипа. Симулировал на ucos dos port, а использовал R520 . потом решили использовать встроенный модем на benq. Я думал что пойдет сразу , ну хотя бы команда АТ. А не получилось. Пришлось тайминги менять по несколько раз перезапрашивать и плюс чтото. И модем ведь не все . Сушествуют системы с gpio, spi и другой периферией. Как бы их на синтезаторе симулировать ?
Конечно модульность это очень хорошо, и надо критерии вывести которые определяют ее физибилити .

Стоп! Дрова UART - это одно, дрова модема - это совершенно другое! И при унифицированном интерфейсе дров UART безразлично, где именно драйвер "мудема" отлаживать - в синтетическим порту Win32 или по JTAG на железяке.

Теперь давайте с SPI разбираться. У нас там могут жить
* RTC
* IO расширители
* ADC/DAC
* DATA FLASH

Опять же, есть драйвер для каждой из сущностей. Т.е. условно есть файл rtc.c, который написан по разному для синтетического порта и реального железа. При сборке проекта продвинутым мейкером я подставляю тот вариант, который мне нужен.

В этом файле описаны все примитивы работы с RTC.

DATA FLASH олично файлом эмулируется.

Вот он, синтетический порт LwIP 1.1.1 для M$ Visual Studio 2003 (wincap драйвер)
http://lists.gnu.org/archive/html/lwip-use...7/msg00007.html

Евгений, в отношении uCOS полностью с Вами согласен. Компактная, достаточно легко портируемая, шустрая при межзадачном переключении, с минимальными накладными расходами в прерываниях и т.п.
16-18 параллельных задач с поддержкой LCD-графики (своя полнооконная система со всеми наваротами) и бешеной нагрузкой в режиме прерываний (более 20 разнотипных каналов ввода-вывода: SPI/RS232/LPT/ETHERNET/Порты на ПЛИС, большая часть из них достаточно тупые и слабо буферизированы) с таймером 1 миллисекунда (OS_TICKS_PER_SEC = 1000) на 90 мГц ARM CPU отрабатываются со свистом (кратковременная пиковая загрузка до 90% - средняя 30-40%, средняя частота межзадачного переключения мониторится в диапазоне 1200-700).

>>>>
***************** YAFFS (Сейчас, конечно, имеет смысл юзать YAFFS2)
si21 (Электроникс) успешно использует ее для простых ARM устройств.
>>>>
Простыми я бы назвал условная, т.к. работает полноценная СУБД с индексными файлами (всего ~ 40-60 файлов минимум) + непрерывное (поточное) пополенение журналов и различных логов, позволяет легко как отдельные каталоги подключить отдельные чипы флеш и части одного флеш-чипа
....Много можно писать, но получится что хвалюсь

1. А какая СУБД используется?

2. Насколько я понимаю, YAFFS - это не законченная файловая система, а ее "заготовка" нижнего уровня что ли. Все остальные функции верхнего уровня (чтобы как в ANSI C файлы открывать) сами дописывали?