Вид для печати
Говорят , Win CE может быть установлена на некоторые типы "Бытовых"
материнских плат (на сайте микрософта есть перечень ).
Есть в наличии даже среда , в которой эта ОС компилится
под материнку . Занимался ли кто нибудб такими вещами ?
Это вообще реально ?
а смысл такого извращения?
Эта ОС заявлена как система реального времени , приэтомЦитата:
Сообщение от RA9QCE
без проблем перенести данные с помощью обычной ЭППЗУ УПШ (флешки) .
Вообще, для программирования под СЕ достаточно найти либо старую версию Embedded Visual Studio 3.0 или 4.0, либо для новых VS2005 просто поставить SDK (доступны SDK для разных платформ, точно есть Windows Mobile 5.0 и 6.0).
Ну а далее, программирование примерно как под обычную винду, большой разницы нет (грубо говоря, есть конечно ряд отличий связанный с более урезанным API).
Перекомпилять WinCE под обычный проц - теоретически наверно возможно, только большого смысла ИМХО мало, т.к. весь имеющийся софт для СЕ под другим типом процессора просто не заработает.
Т.е. под какую-то определенную промышленную задачу возможно это имеет смысл, а просто "для дома" абсолютно никакого. Если хочется поизвращаться, можно просто Linux поставить :)
Есть легальная VS2005 . Просто не вполне представляю , что надо сделать ,Цитата:
Сообщение от DmitryElj
чтоб скомпилить и залить эту OC в "бытовую" материнку . Большая часть
мобильных платформ грузится с ПЗУ.
А что есть SDK ?
Например SDK (Software Developement Kit) для Windows Mobile можно скачать тут - http://www.microsoft.com/downloads/d...displaylang=en
После инсталляции, в VS2005 при выборе нового проекта можно будет писать под Windows Mobile. Есть ли такие же под Windows CE, не знаю.
Насчет перекомпиляции СЕ, исходников её в открытом доступе ни разу не видел. Возможно их поставляют только OEM производителям.
2 KulibinV
А у Вас уже есть исходники?
И еще: что Вы понимаете под словами "ОС реального времени". А что, ХР, к примеру, ОС нереального времени, чтоль?
ОС реального времени (RTOS - real taйм ОС) - операционная система , гарантирующаяЦитата:
Сообщение от RK3FW
время реакции на внешние прерывания .
Добавлено через 6 минут
Мобил это другое ядро .Цитата:
Сообщение от DmitryElj
СЕ всегда перекомпилируется под заданную матчасть .
Она аппаратно зависима .
Перекомпиляция - как я понял , она происходит с промежуточного кода .
Хотя и прямые исходники могут поставляться OEM производителям , только
дорого это , 15k$.
И ради реалтайма надо так извращаться?
непмомню с какой версии ядра 2.6 (больше 2х лет назад точно)
линукс по дефолту стал soft realtime системой. Если надо жесткий реалтайм то просто патчик добавить открытый к ядру.
Сейчас из-за этого даже кьюникс позиции терять стала
С Линуксоидами (разными) контактировали года 4 .Цитата:
Сообщение от RA9QCE
Но реально на гора они ничего не выдали .
Вы лично это делали ? Ну ,например , чтобы реакция на получение
данных с COM порта была 250E-6 секунды (двести пятьдесят микросекунд )?
Какой Линукс ?
Хм, а Вы думаете СЕ будет быстрее? :)
Используйте тогда микроконтроллер, даже для AVR было написано некое подобие RTOS.
А кто Вам сказал , что делаю по другому ?Цитата:
Сообщение от DmitryElj
Только на Microchipe .
Вот только буфер для обмена между "верхним" и "нижним" софтом не удается сделать более
0.5 секунды . Похоже придется ставить промежуточный контроллер , способный работать с внешним
ОЗУ . Вот только внешнего озу ставить не доводилось (на контроллере есть штатная конфигурация с такой
шиной) , отчего стремно .
РеалтаймОС пока осталось только 2 это QNX http://www.qnx.com/ и MorphOS http://www.amirus.org.ru/mid/mid_ru.html остальное либо клоны или просто разработки на базе чего либо.Разработки от Микрософт явно не подходят под это дело.Правда морфОС на РС не работает она под РРС архитектуру.
Цитата:
Сообщение от rus013
Диллеры микрософта долдонят , что Win CE имеет другое ядро , прерывания пользователя
могут иметь приоритет выше приоритета ядра , и при наступлении пользовательского
прерывания во время выполнения прерывания ядра последнее прерывается и выполняется
пользовательское . Впрочем , одновременно они заявляют , что не несут никакой
ответсвенности .
KulibinV
http://www.gotdotnet.ru/Forums/default.aspx
http://forum.wce.by/
вот по этим ссылкам тебе больше информации принесёт.Там как раз по этой ОСи инфа.
rus013:
Уважаемый, такое заявление насчет RTOS, высказанное вами, просто неуместно, так как непонятно за какие уши притянуто. Я работаю в области Embedded Systems уже без малого лет так 17... и как-то не представлял, что всего только 2 системы имеются. :)
На мой взгляд, вы наверное просто не в курсе, или не знаете предмета обсуждения, но существует также VxWorks, которая широко применяется для многих гражданских и военных нужд. А также и другие RTOS, как например: SMX ARM RTOS; Atmel JBOSN High-Performance RTOS; On Time RTOS-32 где ядро всего 16 килобайт занимает и бежит спокойно на 32/64 битных х86 без проблем; тот же охаянный здесь QNX Neutrino, который сейчас одна из самых перспективных систем для автоматиации газовых установок и производства, где повышенные уровни безопасности; Microware OS-9; LinxOS на базе линуксового ядра. Таки не будем...
KulibinV:
Говоря о программировании под СЕ, необходимо сначала определить задачи и цели. То есть что надо/хотелось бы получить, а затем как. Исходники СЕ поставляются ОЕМ, но в реалиях они и не нужны. Все делается на основе конкретного SDK. Я бы посоветовал обратить свой взор сначала к выбору железа, а затем уже к СЕ или другой RTOS. Посмотрите на системы от:
1. www.kontron.com - поддерживается ХРе, СЕ и другие RTOS.
2. www.coreexpress.com - здесь найдете небольшую Embedded РС размером с кредитную карточку.
Также советую почитать что-то на тему SoC - System On Ship, RSoC - Reconfigurable System On Ship, NoC - Network On Ship (например фирма www.hilscher.com/netx.html) - семейство netХ, работает под СЕ.
Если в плане создания чего-то для цифрового трансивера или для управления им, то кое-какие наработки тоже есть.
Будут конкретные вопросаммированию или по конфигурации, готов ответить.
RX1AL
Да я имел ввиду оси которые свободно доступны для домашнего использования и те которые достаточно на слуху.А так я не спорю полно различных систем но они как правило не так распространены как указанные мной ОСи.
Второй сайт проглядел . Сколька такая материнка может стоить .Цитата:
Сообщение от RX1AL
По поводу ОС - заказчит хочет , чтоб лазание по файловой системе и подключение
к сети для внешнего обмена было похоже на винду.
Разработка под промышленный контроллер .
Главный вопрос - является ли вин се действительно RTOC ,
то есть какова вероятность (минус какая степень в час), что эта ОС
не подзависнет и возникнет задержка реакции на прерывание .
Можно ли на материнки со второго сайта поставить вин се (похоже , что да)?
Из первых вопросов :Насколько сложно залить в эту материнку ос до состояния
"картинки на экране и работы клавиатуры " (в моем понимании это первый и
самый сложный этап ,
дальше чуть попроще)?
Для KulibinV:
По заданным вопросам. Давайте мы с вами переведем наше общение на более понайтный, профессиональный язык. Мне так будет проще понять задачу или ее постановку. Потому как обычно пляшут от требований, а-ля спецификация, а уж потом нарисовывается и все остальное... Насчет того, что заказчик хочет, чтобы "лазание по файловой системе" было похоже на винду. Да за ради бога! Какой интерфейс ему сделаете, так и будет. Но об этом еще рано. Отсюда по пунктам:
1) Что за промышленный контроллер? Какие протоколы должны поддерживаться: EtherCAT, CANbus, CANopen, I2C, S7, Fieldbus, Modbus - что конкретно?
2) Какова должна быть минимальная частота опроса сенсоров/датчиков и другого оборудования, так как я понимаю, что вам неоходимо иметь Data Aquisition (систему сбора данных)? Время реакции также важно.
Исходя из требований к системе и ее параметрам и выбирается та или иная система RTOS - не ранее. Потому, что говоря о СЕ, да система реального времени, но для определенных задач и уровня применения.
Не совсем понятно, что значит "файловой системы" - какая там может быть задача в плане "ползать", да еще в реальном времени? Не совсем я уловил. Так как любая файловая система в любой системе, никогда не поддерживает режим реального времени в том понятии, которым он является - так как операция с файлами чтение/запись всегда квази-реальное время, даже если операции производятся синхронно. Исключением является запись на специальные носители информации типа SSD или Dual Port Flash, но там нет никакой файловой системы - совершенно иной принцип.
В сути своей, поставьте задачу, я тогда смогу поточнее вам ответить. А что касается ответа на вопрос о стоимости контроллера с кредитную карточку, то всего 290 евро стоит кит вместе с SDK под СЕ 6.0.
И по СЕ. Сама система очень стабильна. За многолетнюю практику сама ни разу не сыпалась. Если у программистов руки не из одного места растут, то все ОК...
Добавлено через 4 минуты
Залить не сложно, гораздо сложнее создать SDL (системно-независимый лайер), оттестировать все времменые последовательности и переходы и програнть стресс-тест. А прошивка системы - дело двух-пяти минут. То есть понимание задачи и умение писать под систему - сиречь главная сложность.
RS485 (можно RS232, преобразователь есть), рассматриваются также варианты CAN и USB.Цитата:
Сообщение от RX1AL
Цитата:
Сообщение от RX1AL
4 канала быстрых -частота опроса 1 кГц , при этом повторный запрос при ошибке CRC
через 50E-6 [c] , время обратного ответа с вычислительной обработкой - 250E-6 [c].
Разрядность -20 бит +CRC.
Данные опроса полностью не сохраняются , сохранению в файл ошибок подлежат лишь превышения
с меткой времени (примерно раз в час ).
16 каналов медленных (логических 0-1)- частота опроса 20 Гц , время ответа50У-3 [c].
Данные опроса полностью не сохраняются , сохранению в файл ошибок подлежат лишь превышения
с меткой времени (примерно раз в час ).
Цитата:
Сообщение от RX1AL
Задача частично похожа на обращения к двухпортовой памяти .
Сначала (не в реальном масщтабе времени) берется файл исходных данных (точнее, открывается для чтения
и считывается в ОЗУ некоторая его часть ),
производится его интерполяция и запись в програмный кольцевой буфер (аналог двухпортовой памяти) с указателем наполнения . когда буфер наполнен до некоторого значения , начинается работа в прерываниях
в реальном масштабе времени . Кольцевой буфер ограничен , производится его подкачка(включая считывание
в из файла очередного фрагмента для обработки). Это низкоприоритетная задача. При этом обработчик прерываний берет ближайшее в очереди значение и
сдвигает указатель заполнения на 1 , давая возможность подкачивать буфер .
Информация о текущем состоянии выводится на экран оператору .
Собственно из за необходимости удобного для пользователя поиска и открытия файла данных
и отображения промежуточных результатов на экран оператору ориентировался на CE.
Потенциальные входные носители в порядке важности: USB флаш , жесткий диск , сеть , 3.5' дискета,
оптический диск . " Верхиий" формат данных на сменных носителях - совместимый с виндой .
Речь не о глобальном зависании системы (процессора , моста и др.).Цитата:
Сообщение от RX1AL
Обсуждается вероятность " подзависания " , то есть единичной сверхнормативной задержки
реакции на прерывание .
возможно я не совсем в теме и терминологии , но предвижу сложность в перекомпиляцииЦитата:
Сообщение от RX1AL
аппаратно зависимой OC под материальную часть и загрузку её на носитель , с которого она потом
в месте установки будет грузится .
ОК, с этим ясно. По сути своей нормальный Modbus или Profibus. Теперь по параметрам, у меня уже есть кое-какие вопросы... так как не все гладко... Смотрим: "4 канала быстрых -частота опроса 1 КГц , при этом повторный запрос при ошибке CRCЦитата:
Сообщение от KulibinV
через 50 микросекунд , время обратного ответа с вычислительной обработкой - 250 микросекунд".
То есть датчики опрашиваются с частотой 1 КГц = 1 мс, и при этом мы хотим получить ответ датчика через 50 мкс. Хорошо! Примем на веру, что есть такой быстродействующий датчик, и зададимся вопросом: почему частота поллинга датчиков выбрана меньшей, чем время ответа? Какой резон? Никакого. Датчик будет простаивать 90% времени - это раз, а два, как раз тут и начинаются подводные камни с синхронизацией низкой частоты поллинга с быстродействующими датчиками. Почему камни или грабли? Очень просто: простая ситуация - на момент времени Т0 производится чтение данных датчика 20 бит + CRC, при этом время на чтение, согласно спецификации - 50 мкс. А у нас цикл в 1 мс. То есть на момент времени Т0 + 50мкс по логике, мы должны иметь уже готовый ответ от датчика и далее система должна с ним что-то сделать, скажем вычисления или вывод на дисплей. Моменты тут такие:
а) Любой датчик, а у нас RS-485 - имеет handshake. Это время нигде не учитывается. Почему? Даже, если мы будем оперировать с датчиком при скорости 8 kbps (самой низкой), то время для handshake будет значительно выше, чем 50 мкс. И практикой докзано.
б) У нас не один датчик, а много. Соответственно наш 1 КГц или 1 мс надо поделить на их количество для одного канала (все остальные каналы идентичны), то есть имеем 1 мс / N датчиков и получаем реальное Т для поллинга по всем датчикам. Это и есть наш основной цикл. При этом учитываем, что время сбора данных Т2 со всех N датчиков равно N * 50 мкс. Плюс учет самого handshake также принимаем во внимание.
в) Также отсюда мы находим время Т1 для реакции самой системы, ввод/вывод, вычисления и так далее. Это надеюсь понятно. Вот это время и есть наш камень преткновения.
Попробуйте, смоделировав вашу временную диаграмму (sequence diagram) в любом бесплатном редакторе UML-RT, подсчитать реальное время и вы сами все это увидите. Если пришлете мне такую диаграмму, готов разобрать ее по "косточкам" и дать рекомендации. Ссылки на редакторы:
www.magicdraw.com
www.visual-paradigm.com
Что ещё вызывает вопросы, так что такое "с меткой времени"? Откуда она берется, если у вас датчик гарантированно должен отдать свой ответ в 50 мкс или в 250 мкс, если ошибка CRC. И низкий опрос в 20 Гц при времени ответа в 50 мс? Как это согласуется? Есть теорема Котельникова о частоте дискретизации, и на практике обычно берут 4 или 6 раз выше, чтобы учесть всё. В реальных системах сбора информации, по RS-485, обычно используется 4-х кратное увеличение частоты поллинга, для того, чтобы в случае невозможности получить данные от датчика иметь возможность так называемых повторных запросов - retry. И только в случае полной невозможности такой датчик маркируется, как non-responding, оператору выдается соответствующий alarm или просиходит автоматическое переключение на дублирующий датчик, в случае full redundant и fault tolerant системы.
Про файловую систему мне все понятно. Это уже не относится к самому процессу поллинга и сбора информации. С такой задачей справится любая мультизадачная ОС.
Под вашу задачу могу рекомендовать несколько устройств, которые мы сами тоже используем, подумайте, может не стоит слишком заморачиваться и взять готовое решение, а к нему лишь дописать весь графический интерфейсный с выводом данных по мониторингу? Ссылки я привожу ниже:
а) www.infocon-technology.com - EasyIO-30Р контроллер сбора по RS-485. Мы его используем именно под СЕ .NET 6.0. Нужен будет готовый написанный стек под Modbus для СЕ - пришлю на приватный е-майл.
б) http://www.exar.com/Common/Content/P...ils.aspx?ID=18 - Exar XR19L400 или XR16L580 может вас заинтересует, так на сегодняшний день эта фирма лидер по таким решениям. Для СЕ у них есть (да и у меня тоже) весь SDK.
По поводу перекомпиляции. Не сосвем вы меня поняли. Вы создаете свою системно-независимую модель (безо всякой оглядки на RTOS) в терминах UML-RT и SDL. Потом эту модель компилируете (смотрите на Executable Modeling UML-RT) и получаете код на языке, который вы выбрали и также WCET (Worse-Case Execution Time) для своей модели. В случае СЕ - С++ или С. Далее этот исходный код просто компилируете в СЕ вместе с SDK для своего железа. И полученный модуль прожигаете или записываете на нужный носитель. Изменилась что-то - меняете только модель UML-RT и все.
Жду комментариев. Если не возражаете, можем все перенести в личню почту, не знаю насколько темя актуальна для радиолюбителсьтва? А то модераторы "фэ" могут сказать... :)
По поводу поллинга . Насколько мне известно , поллинг - это тупое ожиданиеЦитата:
Сообщение от RX1AL
ответа .
Система управления через 1Е-3 выставляет (трансмит для неё (хоста)) свои данные на датчики
(адресуемые контроллеры датчиков) по очереди , после чего они с очень небольшой
задержкой выставляют (ресив для СУ (хоста)) ответ (заранее подготовленные данные) .
Линии на прием и передачу
раздельные. СУ "на лету" проверяет CRC каждого датчика или либо делает повторный
запрос при несхождении CRC (короткая короткая ветвь обработчика прерываний RS),
либо при схождении CRC всех ответов начинает математическую обработку результатов
(длинная ветвь обработчика прерываний RS).
При этом повторный запрос в случе несхождения CRC датчика должен быть отправлен
не более чем через 50E-6 [с] , а полная математическая обработка должна быть закончена
(и данные выставлены на контроллеры датчиков) через 250E-6 [с] . Если контроллер любого датчика
обнаруживает несхождение CRC , он выставляет запрос на повторную выдачу ему (только) данных.
Повторные данные должны быть выставлены не более чем через 50E-6 [с] . Варианты двухкратного
несхождения CRC не рассматриваются , в этом случае вырабатывается аппаратный сигнал
аварийного завершения (выставляются на другой COM , LPT порт или другую дискретную периферию ).
Поскольку 250E-6 [с] + 50E-6 [с] (одна ошибка приема)+ 50E-6 [с] (одна ошибка передачи) = 350E-6 [с]
более чем в 2 раза меньше чем время цикла СУ , теорема Котельникова удовлетворена и уровень
низкочастотных "биений" незначителен . Так как за 350E-6 [с] нужно передать в худшем
случае 80 байт , то потребная скорость обмена 228.6 [ kB/s] . У стандартных " мамок" бывают 250 [ kB/s],
я на контроллерах на эту скорость программы писал , работало чисто .
По поводу метки времени . Когда начинает работать часть программы в прерываниях , "верхняя " программаЦитата:
Сообщение от RX1AL
создает на диске файл ошибок (название состоит из названия исходного файла данных + закодированоо время
из часов компьютера ) Если происходит превышение значение датчика (точнее ,его производной, вычисленной
как разность соседеих значений) , в файле делается запись , состоящая из № датчика, аномального значения,
времени из часов компьютера и символа разделителя .Если таких значений много подряд, избыток выкидывается.
По завершению обработки файл закрывается , последняя запись = время окнчания .
4 раза по Котельникову жирно будет , 2.5 вполне достаточно .
Дублирующих датчиков нет (вернее их функции выполняют редко опрашиваемые аварийные датчики).
Здесь я кажется "поплыл" . Я полагал , что надо перекомпилировать под матчасть ОС (CE 6) и загрузитьЦитата:
Сообщение от RX1AL
её , чтоб экран "светился" . Потом думал создать приложение "верхнего софта" (на чем нибудь
типа С++ билдер) , скомпилировать и поставить на матчасть . Затем изголится , написать перехватчики прерываний таймера и RS и вкрячить их как резеденты (как под ДОС).
Пока обсуждало более 2х человек . Думаю , можно оставить как общую .
Если остальные отпадут , перенесем в приват .
Для KulibinV:
ОК. Я прочитал все. Сегодня уже отвечать подробно не буду, просто только с остатков теста CQ WW CW вернулся с ОЕ9 (весь никакой) ... напишу завтра.
Только несколько моментов отмечу:
а) Поллинг - не всегда понимается, как пассивный опрос. Сейчас просто этим термином часто называют Publish Subscribe с гарантированной доставкой данных от датчика. Аналогия, чтобы понять смысл работы такой схемы смотрите по OLE for Process Control (ОРС). И более подробно здесь: www.opcfoundation.org
б) Вот уж чего бы я не советовал, так писать на уровнях прерываний. Почему? Да ответ простой. В системах типа СЕ или ХРе вы не всегда сможете взять себе высокий приоритет над ними. И мучений сие доставляет очень много. Поверьте на слово, зубы я уже на этом съел. Потому и придумали способ (см. выше через ОРС). Мы же все-таки работаем с сом, а не чисто с железом, да и не ассемблере, где все гораздо проще. И не в ДОС, где прерывания перехватываются на ура. А в виндовой системе или СЕ, так на ура не получится... Ну нет там наших любимых демонов, которых можно в фоновом режиме запускать...
Дальнейшее завтра. В принципе мне задача более-менее стала понятна. Можно сесть и писать на основе готовой базы.
Mike ,ты мне aprs/ce подправь, чтобы кажный раз установки не вводитьЦитата:
Сообщение от RX1AL
Danke,73
Для DL8RCB:
Толя, да подправлю... без проблем. Дай мне из Radfeld (Tirol) с одного проекта, который мы заканчиваем там, к 12-15 декабря в Линц перебраться и там пожалуйста. А то замучали буржуи окаянные... :) Неймется им под новый год новый проект начать, а носу уже адвент и вайнахтен. Ну не идиоты ли? :)
как говаривал Мао: райзе пасс, райзе пасс,..... але брудэр, одер вас?Цитата:
Сообщение от RX1AL
Для KulibinV:
Перейдем к нашим баранам... Начнём с самого контроллера (или PLC, как его называют). Данный контроллер, как было уже сказано имеет "4 канала быстрых" и "16 каналов медленных" (цифровых), поскольку имеем дело с 0 или 1. Все живёт под интерфейсом RS-485. Первый вопрос для вас, который вы должны для себя решить и понять - это то, что если вы собрались использовать СЕ, то контроллер должен иметь поддержку СЕ также. То есть, как минимум драйвер или лучше всего полноценный SDK. Есть уже у вас конкретный тип от заказчика, или вы свободны в своем выборе? Если последнее, то здесь есть уже готовые типы. Едем далее. Данный контроллер должен иметь либо Flash, SD карту или мини жесткий диск (в зависимости от типа исполнения контроллера), где собственно будет располагаться часть ПО для контроллера. В терминах автоматизации - это хост (Host). Таких хостов будет столько, сколько у вас в системе предусмотрено контроллеров. При этом каждый хост имеет свой уникальный UID (идентификатор хоста), для того, чтобы однозначно знать от какого контроллера "прилетели" данные. Основное приложение (Client), которое вы будете использовать для визуализации, обработки и.т.д. своих данных, "подписывается" на данные от каждого хоста, то есть устанавливается протокол Publish-Subscribe. Он может быть как Queued, если данные имеют какой-то приоритет в обработке , так и нет, когда приоритет не важен. Другими словами, наше клиентское приложение должно создать N "слушателей" (Listener) для каждого канала хоста. И каждый такой listener будет реагировать только на данные, которые адресованы ему. Поскольку у нас нет прерываний в "чистом" виде (мы не в ДОС), я писал уже, то хост выдает нам данные событийно (Events). Соответственно каждый наш listener (по сути объект или класс на С++) реагирует на определенный event и что-то делает, согласно логике обработки аргументов по данному event. Для организации такой модели взаимодействия, как я писал служит ОРС. В случае, если у вас будет наличие стека TCP/IP, то в этом случае задачу можно решить более просто - через мониторинг пакетов по каждому сокету от хоста. Но в любом случае, ваше клиентское приложение лишь реагирует на события (events). Итак мы подошли к тому, что нам необходимо написать две части нашего софта: а) серверную (хост) и б) самого клиента. Я упоминал ранее про SDL. Именно эта часть является наиболее ответсвенной. Ее реализуют на основе стандарта IEC 61499, который полностью отвечает протокол Publish-Subscribe и имеет множество дополнительных возможностей. Подробнее, если не знакомы:
а) http://www.fiord.com/news/new_list/new_32.html - искал что-то на русском и подоступнее.
б) http://www.microns.org/12.0.html - собственно пример реализации именно SDL на основе IEC 61499.
Когда вы создали и оттестировали всю свою модель SDL (UML-RT), то для вас наступает самый интересный момент - программирование контроллера, заливка в него софта. Делается это Boot Loader для JTAG, прямо по коду той скомпиленной модели. Ну а далее берется SDK, VS 2005/2008 и начинается написание собственно клиентской части и визуального контроля и интерфейса. Вот так, более-менее. По конкретике и написанию готов помочь, но не все 100%... :) ибо также на проектах занят. Но в любой части, как хоста, так и клиенсткой. Что нужно? Нужна лишь правильно описанная диаграмма переходов (Sequence diagram) и модель SDL. Все остальное дело техники. Библиотека визуальных контролей уже имеется под СЕ. Да и интерфейсы тоже. С этим никаких проблем нет.
Жду вестей с фронта...
ПЫСЫ: Не надо так много оверквотинга... :) Я свой текст знаю, а в вашем найду все сам. Иначе не совсем удобно читать. Ну фидошник я старый... :)
Добавлено через 28 минут
[Оффтопик]Цитата:
Сообщение от DL8RCB
Толя, согдня навеяло картиной в "Media Markt". Так сказать лирическое отступление на тему тупости или глупости... уж как хочешь, так и назови. Надо конечно в раздел анекдотов, но такой австрийский юмор будет не всем понятен... :) Итак (с) "картина маслом":
"Длинная-длинная очередь на входе... Вы думаете их тут не бывает? Ай, как вы заблуждаетсеь, Абрам..." - иду с женой далее и вижу следующее: примерно человек так 50-60 стоит в зале у столба из картонных нехилого размера, сваленных на палетте, а рядом стоит молодой феркойфер (продавец) и втюхивает что-то как обычно, размахивая проспектом. Ну думаю, надо мимо пройти. Жена, давай типа посмотрим. Ну встали. Короче идет раздача слонов, а именно телевизора LCD от Medion (ну про качество сей фирмы ты в курсе!). Короче раздают за 200 с чем-то евро, а размерчик королевский 42". Не хило так. Ну думаю, а где подвох-то? Нормально так такие телики стоят за штуку. И он нашелся, но не сразу... Короче написано контраст 800:1. Стоит демострационный телик и на нем при нормальном свете, что-то такое на экране движется... Но главное нифига не видно, даже при регулировке яркости и контраста. Я в недоумении. Вопрос на немецком к продавцу: "Почему не видно нифига?" Ответ: "Отбракованная партия,ому и дешево". Ага, думаю, мне нафиг не надо! И тут стоит в толпе один чел, ну с очками где диоптрии я так думаю -12... и выдает в толпу... обращаясь к продавцу... сидеть надо на стуле... иначе геферлих (смертельно): "Хей, я уже оплатил 7 штук, почему мне их не отгружают!" Тот ему "Да-да, херр Гридах, сейчас, сейчас!" И тут я не удержался и спросил этого в очках, а ему так лет под 60-65 наверное: "Зачем так много? Тем более на них ничего не видно и разве только на запчасти... Да и вашему зрению хуже будет." Теперь сам ответ от чела: "Мне будет плохо??? С чего? Я итак уже ничего не вижу! А телики для моей семьи! Пусть семья видит, и не говорит, что дедушка слеп, как крот!" Вот так у нас живут... Тут хочется лишь сказать, но по-немецки: "Virklich? Virklich? Od' wie?" ... :) О tempera, o mores...
А ты про паспорт... Мелко! :)
Добавлено через 38 секунд
[Оффтопик]Цитата:
Сообщение от DL8RCB
Толя, согдня навеяло картиной в "Media Markt". Так сказать лирическое отступление на тему тупости или глупости... уж как хочешь, так и назови. Надо конечно в раздел анекдотов, но такой австрийский юмор будет не всем понятен... :) Итак (с) "картина маслом":
"Длинная-длинная очередь на входе... Вы думаете их тут не бывает? Ай, как вы заблуждаетсеь, Абрам..." - иду с женой далее и вижу следующее: примерно человек так 50-60 стоит в зале у столба из картонных нехилого размера, сваленных на палетте, а рядом стоит молодой феркойфер (продавец) и втюхивает что-то как обычно, размахивая проспектом. Ну думаю, надо мимо пройти. Жена, давай типа посмотрим. Ну встали. Короче идет раздача слонов, а именно телевизора LCD от Medion (ну про качество сей фирмы ты в курсе!). Короче раздают за 200 с чем-то евро, а размерчик королевский 42". Не хило так. Ну думаю, а где подвох-то? Нормально так такие телики стоят за штуку. И он нашелся, но не сразу... Короче написано контраст 800:1. Стоит демострационный телик и на нем при нормальном свете, что-то такое на экране движется... Но главное нифига не видно, даже при регулировке яркости и контраста. Я в недоумении. Вопрос на немецком к продавцу: "Почему не видно нифига?" Ответ: "Отбракованная партия,ому и дешево". Ага, думаю, мне нафиг не надо! И тут стоит в толпе один чел, ну с очками где диоптрии я так думаю -12... и выдает в толпу... обращаясь к продавцу... сидеть надо на стуле... иначе геферлих (смертельно): "Хей, я уже оплатил 7 штук, почему мне их не отгружают!" Тот ему "Да-да, херр Гридах, сейчас, сейчас!" И тут я не удержался и спросил этого в очках, а ему так лет под 60-65 наверное: "Зачем так много? Тем более на них ничего не видно и разве только на запчасти... Да и вашему зрению хуже будет." Теперь сам ответ от чела: "Мне будет плохо??? С чего? Я итак уже ничего не вижу! А телики для моей семьи! Пусть семья видит, и не говорит, что дедушка слеп, как крот!" Вот так у нас живут... Тут хочется лишь сказать, но по-немецки: "Virklich? Virklich? Od' wie?" ... :) О tempera, o mores...
А ты про паспорт... Мелко! :)
Похоже , мы друг друга слабо понимаем . Под контроллером датчика я понимаю устройство , которое
обеспечивает преобразование специфичного и явно не воспринимаемого компьютером интерфейса датчика,
их 4 (+ один для дискретных сигналов, на некоторых видах матчасти хоста (СУ), например платформах
фирмы моторола , дискретная периферия может быть заведена прямо на процессор, только "кит" под неё
стоит 4'500 евров, а сделать свою плату поблематично , так как там бол грид аррай с шагом 0.5 мм).
Под хостом я понимаю СУ (выполненную на компьютере под СЕ ), она одна .
Контроллер датчика специфичный , СЕ на него точно не поставишь .
В протоколе (последовательность байт в посылке , коды запросов) обмена я свободен .
ПО контроллера хранится в нем самом , на внутренней ЭППЗУ (флеш). Оно автоматически
загружается (устанавливается на начальный адрес ) при подаче питания или после сброса внешним
или собственным (по отсутствию активности в течении некоторого времени) аварийным ресетом .
Заливка новых версий софта контроллера осуществляется по джитег , процесс отработан .
Таким образом , как я понял , задача уперлась в написание драйверов верхнего уровня для контроллеров .
ЗЫ по поводу деда , это серьезно ?
Зная мелкософт я бы не стал с этим связываться...Цитата:
Сообщение от KulibinV
P.S. Летел я как то самолетом - там пасажирская развлеклка была сделана на мелокософте, правда не помню это была СЕ или мобайл - висла и блускринила постоянно...
Для KulibinV:
Нет, мы нормально понимаем друг друга. По крайней мере, я читаю и вижу то, что вы пишете... :) "Под контроллером датчика я понимаю устройство , которое
обеспечивает преобразование специфичного и явно не воспринимаемого компьютером интерфейса датчика..." Стоп! Первый вопрос: что значит не вопринимаего компьютером интерфейса, если в самом начале речь шла об RS-485? Кажется мне, что RS-485 стандартный интерфейс, вопринимаемый компютером. Второе, я подразумеваю под контроллером именно PLC, не более, ни менее, который загружается по JTAG. То есть с этим все в порядке. "Контроллер датчика специфичный , СЕ на него точно не поставишь" - да и не надо на него-то СЕ ставить! СЕ будет с ним работать и брать от него лишь данные! Надеюсь, у вас контроллер не "глухой", то есть под него, по крайней мере через драйвер достучаться можно? Если драйвер контроллера есть, то на СЕ лишь пишется сама клиентская часть. И наконец, нету понятия драйверов верхнего или драйверов нижнего уровня... Есть один драйвер - драйвер контроллера, или на худой конец API, по функциям которого контроллер будет чего-то отдавать или делать у себя внутри. Если, как вы пишете, у контроллера есть свое ПО, то простите, как вы с ним сейчас общаетесь? Явно же за какие-то внутренние функции дергаете. Теперь о СЕ еще раз. Ей, то бишь СЕ абсолютно по барабану, что у вас за контроллер... ей нужно знать через драйвер, API, SDK, как добраться до внутренностей контроллера и "спросив" его о чем-то, получить ответ. Не более. А уж как вы будете сей ответ интерпретировать, дело ваше. И на контроллер не влияет. У вас есть описание самого контроллера, можете тип, API выложить? И задача уперлась в написание системы взаимодействия... я вам писал про ОРС - вы прочли, разобрались? Именно так с большинством контроллеров мы работаем. Кроме того, вы писали, что у вас есть возможность конвертировать RS-485 -> RS-232. Господи, да тогда любая обработка данных с такого интерфейса пишется на любом языке за 3-4 дня по уму. :) Надо через USB, так конвертер RS-485 -> USB делается на паре микросхем за два часа на макетке и используется стандартный драйвер. Готовых промышленных навалом.
И задача сводится к двум этапам:
1) Раз вы свободны в плане протокола, так и опишите его так, чтобы СЕ поняла. Сведите все к обычному сериал протоколу. И зажгите в контроллер.
2) А далее садитесь и пишите само клиентское ПО на СЕ.
Нужна библиотека для СЕ под RS-485, написання на С++ под "чистый" СЕ и есть С для .NET версии.
ПЫСЫ: По поводу дедуни, хера Гридаха... да, вполне серьезно... я от хохота плакал... Ну бывают у нас такие вот "кадры".
Для ER1MF:
"Зная мелкософт..." - хочется спросить "зная как"? Как пользователь, или как программист? Посему, считаю, заявление ваше ну совершенно неуместным. Хаить можно все, что по каким-то причинам не работает... и часто причины эти от наших "кривых ручек"... случаются. А если как программист, то давайте приведите мне аргументы, что там с мелкомягкими не так. А заявления типа ОБС я не люблю... не солидно.
Для тех, кто летает в самолете... Ну гнать на мелкомягких мы гоним... Но дома-то не линукс на своем домашнем РС в основном пользуем. А? :) Тем более игр для детей на нем не особо найдешь... Так что... :)
Добавлено через 1 час 23 минуты
Для KulibinV:
Вот нашел в архиве на компе статейку, которая вам поможет понять, что такое поллинг и как должно быть организовано взаимодействие между вашим контроллером(ами) и клиенской частью на СЕ. Код на С++ и все подробно разжевано. Но это лишь, как отравная точка. Будут вопросы, я здесь...
PS Админам: Будьте любезны, поправьте что-нибудь в авших скриптах для аплоада вложений... Уж больно часто скрит зависает даже на маленьких файлах. В топике "Про баги" писалось не только мной, но пока ответа нет...
Само вложение... В первый раз пропало. :(
Ваш предыдущий ответ я понял как предложение сделать не только СУ (хост) подЦитата:
Сообщение от RX1AL
СЕ , но и контроллеры датчиков . С этим разобрались .
Драйвера контроллера датчика под СЕ нет.Его надо писать .
Сейчас я с ним общаюсь:
1: под ДОС .Все работает , но заказчик не доволен интерфейсом .
2: Через СОМ под ХР . В целом - не работает .
Про переходник USB > COM . У меня такой сделан . С ним экспериментировали . Стандартные его
драйвера (фирмы FTDI)не поддерживают нужного режима - изохронного.
Там только потоковый режим . У него большая пропускная способность, но обмен идет очень
длинными посылками - 1 E-3 [с], как для фулл спид так и для хайт спид . Не проходит
по времени реакции
Микрософт поставляет пакет для написание пользовательских драйверов изохронного режима.
Для ХР . Но стоит он по разным данным 3'000$-5'000$ .
Про два этапа в понятно .Я так примерно и предполагал . Идея подпихнуть и использовать "чужие" драйвера обсуждается.
Статья понятна и очевидна (очень ). Она для микроконтроллеров . Чем я собственно и занимаюсь.
Под ДОС аналогично легко обращался к сом операторами С++ inportb(,) и outportb(,).
Под ХР такой обмен идет через связанные потоки , только он рваный .
Вопрос , останится ли он настолько рваным под СЕ или нет ?
А вот описание этой библиотеки представляло бы максимальный интерес
Что конкретно не работает? Я не совсем понял... СОМ никогда не поддерживал isochronous transfer и поэтому как он может работать? Во-вторых, попытка взять на себя под ХР управление СОМ - чревата... так как в "исключительном режиме" невозможна по определению. А для того, чтобы работать, надо либо через P/Invoke, либо через wrapper драйвера. Хотя в С++ и есть функции для работы с СОМ, они не предоставляют "искличительного" режима доступа. Все идет через систему. А вам, такое не нужно, так как потеря лишнего времени на обработке.Цитата:
Сообщение от KulibinV
Начнём, помолясь... И сначала с того, что мне до сих пор непонятно, зачем такой огород городить для работы с датчиками на RS-485? У вас опрос 1 мс, а вы пытаетесь с ними работать, как с датчиками реального времени. Почему? Да ответ на поверхности. Вы пишете, что в связке USB -> COM вам необходим isochronous USB transfer. Открываем документацию по USB 1.1 или 2.0 и читаем:
а) "Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream." - у нас вроде не видео и не аудио данные.
б) "Isochronous transfers provide stream pipe - unidirectional" - вопрос, а зачем нам двунаправленный канал? Мы лишь забираем данные от датчика.
Кроме того, максимальный size data payload ограничен и развен 1023 (full speed device) и 1024 байта (high speed device), что тоже важно. Далее при работе в таком режиме при 1 мс такте, окно для снятия данных всего 250 мкс, согласно спецификации. Тоже критичная величина. Ну да ладно, хозяин - барин, хотя непонятно такое желание.
Теперь поедем по всем вашим трудностям и проблематике:
1. FTDI имеет в своем драйвере поддержку isochronous transfer, как для чипа FTDI-232, FTDI-245В, так и для последующих. Что-то вы упустили, в описании или использовании драйвера. Фрагмент кода и обсуждение здесь (когда-то сам с этим боролся давно):
http://www.motherboardpoint.com/t895...-transfer.html
2. По поводу библиотеки от Микрософт. Во-первых, такая библиотека называется WINDDK (Windows Device Driver Kit) и она совершенно бесплатна, вот весит прилично, один дивидюк полностью. Если вам надо, могу прожечь на болванке и отослать, но думаю в России ее достать также легко.
В этой библиотеке есть все, что вам надо для старта. Куча примеров на С++, и кстати под СЕ также.
Смотрите например ссылку: http://msdn.microsoft.com/en-us/library/ms790482.aspx
После инсталляции найдете в папке WINDDK\6000\src\usb\isousb\ весь исходный код того, как такой isochronous transfer должен быть написан. Тест также приведен. Более, чем достаточно.
3. Собственно по библиотекам. Наша вам точно не подойдет. Мы используем нормальный, квотированный обмен с устройством, и я извиняюсь, но так "не извращаемся", ибо в наших задачах все попроще. Но тем не менее, готовых библиотек много и ссылки на них я привожу ниже. Все бесплатные и хорошо описаны:
а) http://www.opencores.org/projects.cg...slave/overview - что поддерживает, видно из описания. Код на исходный текст в статье.
б) http://docs.sun.com/app/docs/doc/819...xfer-9f?a=view - с самой книге (PDF) все разжевано до нельзя со всеми примерами. Как стартовая точка, то, что надо.
в) http://techon.nikkeibp.co.jp/article...29/152601/?P=3 - описание общего принципа для работы с USB в плане embedded. Также очень полезно ознакомиться.
г) http://www.lvr.com/usb.htm - основной старт пункт для всех вопросов.
д) www.sourceforge.net/projects/easyusb - собственно сам драйвер с исходниками, со всеми режимами работы.
е) http://www.opensource.apple.com - Darwin hardware (IOKit) - не надо пугаться, что под Макинтош... я кучу этого кода уже для наших задач адаптировал. Там чистый С++, не более. А главное он хорошо документирован, что немаловажно.
Для начала думаю хватит. Что я точно не хочу делать, так это писать все... но если у вас будут конкретные затыки или проблемы с кодом, здесь пожалуйста.
И последнее: используйте не USB -> СОМ, а USВ -> RS-485 переходник. Не нужно включать дополнительное звено...
Добавлено через 5 минут
Что конкретно не работает? Я не совсем понял... СОМ никогда не поддерживал isochronous transfer и поэтому как он может работать? Во-вторых, попытка взять на себя под ХР управление СОМ - чревата... так как в "исключительном режиме" невозможна по определению. А для того, чтобы работать, надо либо через P/Invoke, либо через wrapper драйвера. Хотя в С++ и есть функции для работы с СОМ, они не предоставляют "искличительного" режима доступа. Все идет через систему. А вам, такое не нужно, так как потеря лишнего времени на обработке.Цитата:
Сообщение от KulibinV
Начнём, помолясь... И сначала с того, что мне до сих пор непонятно, зачем такой огород городить для работы с датчиками на RS-485? У вас опрос 1 мс, а вы пытаетесь с ними работать, как с датчиками реального времени. Почему? Да ответ на поверхности. Вы пишете, что в связке USB -> COM вам необходим isochronous USB transfer. Открываем документацию по USB 1.1 или 2.0 и читаем:
а) "Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream." - у нас вроде не видео и не аудио данные.
б) "Isochronous transfers provide stream pipe - unidirectional" - вопрос, а зачем нам двунаправленный канал? Мы лишь забираем данные от датчика.
Кроме того, максимальный size data payload ограничен и развен 1023 (full speed device) и 1024 байта (high speed device), что тоже важно. Далее при работе в таком режиме при 1 мс такте, окно для снятия данных всего 250 мкс, согласно спецификации. Тоже критичная величина. Ну да ладно, хозяин - барин, хотя непонятно такое желание.
Теперь поедем по всем вашим трудностям и проблематике:
1. FTDI имеет в своем драйвере поддержку isochronous transfer, как для чипа FTDI-232, FTDI-245В, так и для последующих. Что-то вы упустили, в описании или использовании драйвера. Фрагмент кода и обсуждение здесь (когда-то сам с этим боролся давно):
http://www.motherboardpoint.com/t895...-transfer.html
2. По поводу библиотеки от Микрософт. Во-первых, такая библиотека называется WINDDK (Windows Device Driver Kit) и она совершенно бесплатна, вот весит прилично, один дивидюк полностью. Если вам надо, могу прожечь на болванке и отослать, но думаю в России ее достать также легко.
В этой библиотеке есть все, что вам надо для старта. Куча примеров на С++, и кстати под СЕ также.
Смотрите например ссылку: http://msdn.microsoft.com/en-us/library/ms790482.aspx
После инсталляции найдете в папке WINDDK\6000\src\usb\isousb\ весь исходный код того, как такой isochronous transfer должен быть написан. Тест также приведен. Более, чем достаточно.
3. Собственно по библиотекам. Наша вам точно не подойдет. Мы используем нормальный, квотированный обмен с устройством, и я извиняюсь, но так "не извращаемся", ибо в наших задачах все попроще. Но тем не менее, готовых библиотек много и ссылки на них я привожу ниже. Все бесплатные и хорошо описаны:
а) http://www.opencores.org/projects.cg...slave/overview - что поддерживает, видно из описания. Код на исходный текст в статье.
б) http://docs.sun.com/app/docs/doc/819...xfer-9f?a=view - с самой книге (PDF) все разжевано до нельзя со всеми примерами. Как стартовая точка, то, что надо.
в) http://techon.nikkeibp.co.jp/article...29/152601/?P=3 - описание общего принципа для работы с USB в плане embedded. Также очень полезно ознакомиться.
г) http://www.lvr.com/usb.htm - основной старт пункт для всех вопросов.
д) www.sourceforge.net/projects/easyusb - собственно сам драйвер с исходниками, со всеми режимами работы.
е) http://www.opensource.apple.com - Darwin hardware (IOKit) - не надо пугаться, что под Макинтош... я кучу этого кода уже для наших задач адаптировал. Там чистый С++, не более. А главное он хорошо документирован, что немаловажно.
Для начала думаю хватит. Что я точно не хочу делать, так это писать все... но если у вас будут конкретные затыки или проблемы с кодом, здесь пожалуйста.
И последнее: используйте не USB -> СОМ, а USВ -> RS-485 переходник. Не нужно включать дополнительное звено...
Добавлено через 17 минут
ПЫСЫ: А глюки на форуме продолжаются... :( Первый раз послал ответ... сразу залип по сессии, пришлось перелогиниваться. Отрефрешился на страничке топика - ответа нет. Логин тоже слетел. Залогинился и вижу свой ответ в топике, но почему дважды и с разницей в 5 минут... Что за ерунда?
Изохронные трансакции относятся к USB . Сттандартный сом может генерить прерывания ,Цитата:
Сообщение от RX1AL
и под досом все работает . Под ХР посылки рваные ,т есть интервалы обмена гуляют .
[/QUOTE]
.
Цитата:
Сообщение от RX1AL
Я не только опрашиваю контроллер датчика , но и должен не позже чем через
350Е-6 залить в него результаты обработки , той же разрядности
По спецификации (стр. 205), синхронизирующие посылки (Start Of Frame (SOF) packet each and every 1ms)Цитата:
Сообщение от RX1AL
идут через 1 мс. Упрощенные варианты обработки собирают весь пакет между синхроимпульсами ,
заталкивают его в буфер и лишь потом с ним работают .
По крайней мере так было некоторое время назад. Вариантов когда CRC начинает автоматически
вычислятся отдельной аппаратной веткой при начале пакета и что бы после аппаратного обнаружения
конца пакета (укороченного) мне пока неизвестно . Следующий обмен инициируется только апппаратно
по началу SOF.
По крайней мере , это соответствует исследованию осциллографом обмена через драйвера FTDI
Для RX1AL .
По одной из Ваших ссылок нашел указания на "правильные" драйвера.
Только похоже , что они не родные . По крайней мере там упоминается
аналогичная моей проблема с виртуальным СОМ портом .
Буду читать дальше . К сожалению там не просто на английском
(техническом), а на разговорном , с оборотиками .
Мне стал непонятным один момент - "но и должен не позже чем через 350 мкс залить в него результаты обработки". Не понял, если честно.
Получается, что сначала снимаем данные с контроллера, быстренько "в темпе вальса" делаем вычисления и опять отдаем контроллеру для каких-то дальнейших операций. Что-то уж мудрено. Не проще ли возложить всю эту вычислительную задачу также на контроллер? А клиентская часть будет лишь для визуализации и т.д. Иначе вы сами себе придумываете проблемы на ровном месте. И что за контроллер такой мудреный, вроде интерфейс RS-485 обычно служит для снятия данных... в обычном его применении.
Касательно ссылки по драйверам и проблем с английским. Кидайте отрывок... переведу.
Контроллер сам не справится (да и программировать больно мудреноЦитата:
Сообщение от RX1AL
выходит ). Хотя задумка такая есть .
Сам буду переводить . Надо малость подучиться . А то одни даташиты
читать умею . Впрочем уже понял , что речь идет о микрософтовской программе
написания драйверов . Дорогая она .
Для KulibinV:
Контроллер сам не справится"... - что за контроллер такой, что с простой задачей вычислений не справится? Уж всяко лучше решать это средствами контроллера, чем средствами самой системы. Насчет DDK, WDK и Kernel-Mode Driver Framework (KMDF). Ну кто вам сказал, что они стоят денег? Со сне приснилось? :) Я вот ну никак не понимаю людей, которые не знают, но упорно считают, что они "понаслышке" правы - "денег стоит, дорогой"... Да бесплатно! Скачивайте за ради бога все, только зарегистрируйтесь на сайте у Микрософта:
1. http://connect.microsoft.com/ - основной вход.
2. http://www.microsoft.com/whdc/DevTools/default.mspx - все про WDK и так далее.
3. http://www.microsoft.com/whdc/driver/wdf/KMDF.mspx - Kernel-Mode Driver Framework.
4. http://forums.microsoft.com/MSDN/Sho...85068&SiteID=1 - Онлайн туториал.
Этого думаю будет более, чем достаточно. Надо будет чего еще, скажите.
dsPIC33.......Цитата:
Сообщение от RX1AL
вопрос о быстродействии тонкий . Несмотря на то , что датчики дискретные ,
их разрядность напрямую превышает разрядность контроллера .
С учетом избежания проблем , PC работает (переменные выбраны) во float .
Чтоб обеспечить вычисления на контроллере , обработка данных во флоат (хоть его и
можно заявить , он эмулируется) не проходит по скорости - эксперементально
проверено .
Программу на контроллере можно написать в целочисленной арифметике , но так как
там используются приличные массивы , для экономии памяти данных (по програмной большой запас), придется мешать кучу типов - long, short и char причем последние
2 будут как unsigned так и signed . Заставить нормально работать эту мешанину
можно лишь путем очень длительной отладки .
Расчет на потребность (размер внутренненго ОЗУ) я делал , проходит только в варианте
такой каши .