[Evgeny_CD 0]

Для правильного понимания этого поста необходимо ознакомиться с

"Продвинутые 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, оно того стоит. Можно силами всего нескольких сотрудников (+ аутсорсеры) организовать целый конвеер по производству ПО, который сейчас доступен только очень "толстым" фирмам.

 

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

[DASM 0]

Доктор, много букав.. ниасилил :tongue: Вы бы резюме сразу для малограмотных дали... Ну я вот точно знаю, что Nucleus лучше и не надо мне никаких тестов, достаточно глянуть сурцы. У UCOS они примерно уровня курсовой студента. Всё таки резюмируйте пожалйуйста, ну нет сил вникать во все это

Кстати, чем это "Педи" JTAG "взрослый" ? Те же 400 кило в сек что и jlink 5-ой модели. Дровами под GDB и все ?

[dmivs 0]

-- Tcl, LUA самое то.

 

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

[DASM 0]

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

[Evgeny_CD 0]

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

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

 

 

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

1. До сего момента о нем не слышал.

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

 

 

 

Доктор, много букав.. ниасилил :tongue: Вы бы резюме сразу для малограмотных дали... Ну я вот точно знаю, что Nucleus лучше и не надо мне никаких тестов, достаточно глянуть сурцы. У UCOS они примерно уровня курсовой студента. Всё таки резюмируйте пожалйуйста, ну нет сил вникать во все это

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

 

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

 

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

 

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

 

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

 

Сколько лицензия на Nucleus стоит? uCOS, если прижмет, можно и купить (2.5k$) - а ментор, я полагаю, просто разорит...

Кстати, чем это "Педи" JTAG "взрослый" ? Те же 400 кило в сек что и jlink 5-ой модели. Дровами под GDB и все ?

Взрослый он тем, что он под GDB работает "в лоб", через встроенный Ethernet. И много серьезного народа, в отношении которого у меня нет основания для подозрений в предвзятости, очень доволен работой с ним под eCos. Типа берем AT91SAM7Sxx и работаем с FLASH как с RAM в плане отладки кода.

[DASM 0]

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

[Evgeny_CD 0]

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

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

[vet 0]

Системные требования к охранным устройствам Вы закладываете, прямо скажем, непомерные :)

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

[_artem_ 0]

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

 

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

[Nixon 3]

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

[dmivs 0]

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

 

Здесь речь (по моему) идет больше об исследовательском проекте "на будующее", чем о повседневном "куске хлеба" с жесткими сроками и бюджетом :)

Не забываем также про системные требования.

А еще смотрим лицензию Io - BSD.

 

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

 

Это, конечно, верно, но выигрывает обычно тот, кто на поезд садится первым.

По поводу LUA, у меня сложилось стойкое мнение, что все эти N лет он в основном развивается как скриптовый язык для игр.

Все small footprint TCL реализации урезанные и малоподдерживаемые (т.е. самоделки), ничем не лучше Io, но без его идей и строгой концепции.

Системные требования "полноценного" TCL требуют полноценных ресурсов, полноценной ОС и полноценного лицензирования. Но это индустриальный стандарт "де-факто", как ни крути.

 

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

 

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

 

Я видел несколько проектов с использованием Nucleus, даже очень коммерческих.

Все лицензии покупались + платная поддержка (сколько стоило не знаю, но много).

Результат, прямо скажем, страшненький. Правда, может сам Nucleus в этом и не виноват ;)

Изменено 4 июля, 2006 пользователем dmivs

[Evgeny_CD 0]

Системные требования к охранным устройствам Вы закладываете, прямо скажем, непомерные :)

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

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

 

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

 

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

 

 

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

 

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

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

[Evgeny_CD 0]

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

Здесь речь (по моему) идет больше об исследовательском проекте "на будующее", чем о повседневном "куске хлеба" с жесткими сроками и бюджетом :)

Не забываем также про системные требования.

А еще смотрим лицензию Io - BSD

....

Все small footprint TCL реализации урезанные и малоподдерживаемые (т.е. самоделки), ничем не лучше Io, но без его идей и строгой концепции.

Системные требования "полноценного" TCL требуют полноценных ресурсов, полноценной ОС и полноценного лицензирования. Но это индустриальный стандарт "де-факто", как ни крути.

Ваши аргументы весомы. Но!

 

* Tcl - как Вы верно заметили, стандарт. И будущих "системных интеграторов" не надо будет переучивать именно под "особый язык проекта".

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

* В приведенной мной реализации сразу есть поддержка БД, что для моих целей - большой +.

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

:a14: еще раз. Смотреть надо, за 5 минут не осознать

 

 

 

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

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

 

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

[_artem_ 0]

И во сколько будет гипотетическая разница цен ? Я так понял расчет идет на больше чем 64-128 кБ рам.

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

[Evgeny_CD 0]

И во сколько будет гипотетическая разница цен ? Я так понял расчет идет на больше чем 64-128 кБ рам.

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

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

 

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

 

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

 

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