RTU188MX - переход на RDC8830

Есть ли тут кто нибудь из разработчиков Fastwel? С нами сыграли плохую шуточку - в очередной партии контроллеров RTU188MX прислали 4шт на RDC8830, без предварительного согласования и тестирования с нашей стороны. Естественно, по закону подлости, наше ПО отказывается с ними работать, вернее, новый контроллер не работает в том режиме, в каком мы используем старый - выделение двух секторов flash в качестве user memory. Стоит только прописать на контроллер образ FFD5 вместо FFD7 то загрузка DOS падает по Unused opcode, не доходя до autoexec.bat и собственно нашего ПО. BIOS ставим свежайший. Что делать и кто виноват?

Скорее разработчики Fastwel, не полностью оттестировавшие свой BIOS на поддержку RDC8830 и FFD5. С версии BIOS 2.1 декларируется поддержка RDC8830, версии 2.2 и 2.3 были написаны по нашим претензиям, т.к. FFD5 некорректно работал и с AM188ES. Сейчас нами найден очередной баг. А к поставщику я обратился, там цепочка долгая - казанский "Шаттл", "Прософт" и собственно Fastwel.

повторяю, cтоит только прописать на контроллер образ FFD5 вместо FFD7 то загрузка DOS падает по Unused opcode. Здесь дело даже не доходит по наших исходников. Всё,  что при этом используется, это утилиты от Fastwel и командная строка. А насчёт редких режимов - я бы никогда и не стал использовать FFD5, если бы поддержка файловой системы была написана приемлемо изначально. Любая операция с записью файла приостанавливает процесс выполнения программы на 5-6 секунд. И на этом софте предлагается крутить процессы реального времени?  Выбора нет, приходится работать напрямую с секторами flash напрямую, откладывая процессы записи в фон по прерываниям и используя для безопасности транзакции. 

Я и не собираюсь "ловить баги в конференции", процесс идёт независимо. У нас ранее был контакт с Prosoft по поводу версий 2.2 и 2.3, и тогда меня удивило нежелание разработчиков Fastwel выходить на прямую связь с нами, общение идёт только через поддержку в Prosoft`е. В общем-то я понимаю неизбежность подобных багов. Хотелось бы на этом форуме завязать обсуждение достоинств\недостатков этого контроллера, способов и секретов работы с ним, ведь те, кто его используют, вынуждены каждый изобретать велосипед самостоятельно.

Чтобы было яснее из-за чего весь сыр-бор поясню. Суть проблемы в том, что часть ПО определяет процессор RDC, стоящий на текущей версии платы, как 32-разрядный и пытается использовать соответствующий код, который вызывает фатальную ошибку.

Кардинально решить проблему скорее всего удастся только использованием другого типа процессора, но есть временное решение - компилируйте свои приложения в Ассемблере или ВС++ 3.х с явным указанием компилятору применять только 186 код.

Смотри в ветке

http://forum.cta.ru/forum_posts.asp?TID=1369&PN=1