Спасибо не мне, а ребятам которые придумали хороший протокол. Просто на компьютере можно не только по форумам вопросы печатать (это не Вам лично), а еще много интересных мест посетить
Я не дал ему рыбу - Вы говорите так, как будто я ему подорил 4-е платы - одна для РС, а на остальных гордо восседают мега8))). Я просто, чем бестолково объяснять, дал челу готовый документ, в котором довольно разжеванно говорится про все, что ему нужно, чтобы организовать относительно простой многопроцессорный обмен. Ну и пускакй не нравится, ребятам из Ford, BMW, Toyota, Nissan, Daewoo... продолжать? очччень нравится. И не только им, шахтерам, металлургам, нефтянникам ETC

Я уже писал - аргументы "у меня все работает" и "все используют" я не принимаю Эти аргументы не технические, а скорее демагогические (без обид )
Например, будь все шоколадно, перечисенные фирмы не занимались бы протоколом LIN.

Дадада - "А Баба Яга против", знаю

Проблем с программированием под Win32 нет.
Есть проблеммы у Windows

на скорости 115200 один байтик передается 87мкс
межбайтовый промежуток 4 байта = 347 мкс

а стандартные таймуты COM порта начинаются от 1мс
и Sleep тоже от 1 мс , и при этом еще и не отрабатывается
а такт операционки 10-20мс

а если вводить везьде большие задержки, то 115200 может чудесным образом
превратиться в 19200
да и контроль остается только по длинне пакета и по CRC

Вот собственно по этому и хочется найти исходники где реализован
хоть какой-то контроль.

Например можно для контроля промежутков использовать Performance Counters.
Просто очень не хочется наступать на все грабли на этом пути,
особенно если на них уже кто-нибудь наступил

Использовать выносного клиента, с достаточным объемом памяти, и скоростной шиной с РС - USB например))) Пример - pdiusbd12 + atmega8515 + 64k SRAM

К сожалению, по условию задачи, этот вариант не подходит

[quote name='singlskv' date='Jan 8 2007, 17:35' post='194214']

1. Работа на скоростях до 115200
6. Контроль межбайтовых и межпакетных промежутков в пакетах Modbus (ну конечно
на столько, на сколько это вообще возможно под Win)
[/quote]
на скорости 115200 один байтик передается 87мкс
межбайтовый промежуток 4 байта = 347 мкс

а стандартные таймуты COM порта начинаются от 1мс
и Sleep тоже от 1 мс , и при этом еще и не отрабатывается
а такт операционки 10-20мс

а если вводить везьде большие задержки, то 115200 может чудесным образом
превратиться в 19200
да и контроль остается только по длинне пакета и по CRC

Вот собственно по этому и хочется найти исходники где реализован
хоть какой-то контроль.

Например можно для контроля промежутков использовать Performance Counters.
Просто очень не хочется наступать на все грабли на этом пути,
особенно если на них уже кто-нибудь наступил
[/quote]Для начала: межбайтовый промежуток можно сделать и 1 мс - таймаут в порту отрабатывается аппаратно, а вот уведомлениие об этом событии приложению ОСь выдаст конечно с задержкой, но это уже не столь важно будет - главное таймаут будет зафиксирован

Ну а межкадровые таймауты поймать не так уж и сложно и обычными средсвами, хотя можно и аппаратный таймер задействовать



А какие у Вас требуемые межкадровые интерывалы? И что за контроллеры?

Подумал и решил что избавиться от программного контроля за лишней линией (RTS) было бы очень удобно. Попробовал сделать так как предложил Сергей Борщ, прошу посмотреть правильно-ли я все соединил:

Если все верно, то прошу объяснить какие номиналы должны быть у R1, R2, R3, R4, R5 и C1. И будет-ли данная схема работать на скорости 115200 бит/c?

Вы опять попутали выводы V- и GND у ST232. На GND подается земля, на V- минус С4, плюс С4 на землю. На выводе V- получается напряжение около -10в. Если есть возможность - используйте ST202 - ей достаточно керамических конденсаторов на 0.1 мкФ. R1 не нужен - ST232 не умеет переводить выход в третье состояние.
У меня работает на 115200. R2 - подтяжка, 1К...4К7 для 115200, при меньших скоростях сопротивление можно увеличивать, при этом снижается потребеление. R3 10К, C1 1нФ, R4 и R5 согласно документу, который привел ув. prottoss должны быть 450...650 ом.

Все исправил, схемы приняли вид:
RS232 to RS485:


AVR to RS485:


Если все верно, то 1/3 дела сделано, теперь бы еще программу для МК под эту схему придумать.

Сообщение отредактировал li4 - Jan 8 2007, 18:57

Мне тоже не нравится. Кажется устаревшим, излишне перегруженным и в то же самое время не полным. То есть объявление - "у меня тоже MODBUS" - абсолютно ничего не даёт. На сто процентов модбас нефтяников не будет работать с модбасом форд. Да я и не уверен что форд-тайота услышат друг-друга. Если, да то это только в случае, что они договорились м/у собой "кроме протокола". Хотя надо признать, что сама структура первого уровня - пакеты - формат пакетов - таймауты - CRC - придраться особо не к чему. К сожелению с LIN не разбирался и до CAN тоже руки не дошли. Хотелось бы конечно. Но пока не было такой задачи.

Компонента MODBUS у меня нет, но есть компонент COM порт и RS485. Я его использовал, но немного корректировал. У меня есть сомнения что под виртуалом вообще полностью можно создать MODBUS. singlskv совершенно точно перечислил причины. Только что с этим боролся.
Пробовал вот такой вот вызов таймера
TimerID:=timeSetEvent(ASpeed[Speed],0,@TimeProc,0,TIME_PERIODIC);
10мс отрабатывает нормально, но можно и меньше. Но тоже есть проблемы. Мне обещали подогнать правильную работу ч/з OPENGL. Буду пробовать.

Когда я говорил про Фордов, нефтянников и иже сними, я как раз и имел ввиду программный протокол, а физическая часть на вкус и цвет - Форд и Ко использует K-Line , нефтянники используют диф. пары, кто-то предпочитает радио потому как расстояния разные (одна из главных причин) и стимулы.



ЗЫ: Как OpenGL может помочь, что то я не догоняю??? Это которая с Direct3D дружит?

Опять почти. В документе "имени prottossa" в разделе 3.4.6 сказано (даже выделено), что резисторы растяжки должны быть только в одном месте на всю шину. В вашем случае без переходника 232-485 система не работает, поэтому их имеет смысл оставить именно в этом переходнике, а в "AVR то 485" R1 и R2 исключить.
Повод прочитать раздел 2.4 Master / Slaves State Diagrams упомянутого документа

Щаз лопну от гордости

prottoss Не надо,нам вас будет недоставать.