Аз като цяло съм бос в програмирането за бозата.
Преди години имах някакви забежки по MFC понаписах няколко програми, ама после не остана време и .......

Сега имам една такава болка. Имам си едно устройство. То си комуникира със друго устройство (HOST) по UART.
Сега трябва да се емулира HOST-a на компютер. Аз навремето съм писал една програмка на любимия ми "син" BC 3.0, за под ДОС естествено, която си работи, аз си я разширявам периодично и ок. Да ама се налага да се мине на бозата.


Сега проблема е че протокола за комуникация е псевдосинхронен (поне аз така си го наричам).

Синхронноста му идва от това че хардуера генерира фрейм на всеки 100ms. И ако до следващите 100ms (следващия фрейм) не получи отговор - почва да бичи грешка в комуникацията и отказва да се подчинява на команди по серийния канал.

Иначе фрейма е на 9600 и е 15тина байта.

Са на въпроса - може ли да се гарантира във бозата, че в момента на пристигането на фрейма, приложението ще получи възможност да композира ответния фрейм и да го изпрати обратно - и всичко това да се свърши за 100ms, независимо от това с какво точно е решила бозата да се занимава в момента. Щото си спомням че на времето се мъчих малко с това, ама така и не стигнах до идея как да накарам тъпия Winbouz да си изплюе серийния буфер, когато аз искам, без да съм го напълнил достатъчно.

Как ви се вижда, изпълнимо ли е едно таквоз приложение и изисква ли кое знае какви познания?

Може да се направи да получаваш всеки байт, имам написани такива приложения. Нооо...
Времето за реакция не е гарантирано, независимо какъв приоритет дадеш на серийната си нишка. Ако точно тогава бозата е решила да свърши нещо друго и се налижи да се рови в диска ( най-често се налага ), просто забрави да получиш отговор за милисекунди. Ако някой Гуру е успал да се наложи над Win и го е накарал да се държи като операционна система, да каже.. И на мен този проблем ми е интересен, а нямам решение.
Иначе ползвам Delphi и Assync32. Става перфектно. Последното е Free компонент за серийна комуникация. Има го на www.torry.net

Ами и аз съм ползвал Assync, хареса ми, но за най-добрия мултитаскинг който видях беше на SerialNG, някъде в предишните си постове го прикачих. Значи не е проблем чрез тоя компонент да си нагласиш входния буфер на 15 байта, и при напълване ти се извиква Event (OnRecieveString), при който си обработваш фрейма и отговаряш адекватно. А тука за бозата не съм съгласен че ще пречи като си човърка в диска, тоя компонент работи изцяло background (както примерно Local Area Connection-a на Windows). Все пак нищо не ти пречи да опиташ, писането програма с тоя компонент ще ти отнеме по-малко от 10 минути.

Може би няма да е много удобно, но за да си абсолютно сигурен във времената ще трябва да използваш REALTIME PRIORITY защото нямаш гаранция, че друго приложение няма да го използва на моменти и да ти обърка комуникацията.

Пробвал съм, пак не е сигурно. Става в 99.9% от случаите, но в останалите 0.1% се тутка. Ако това ти е фатално, просто промени протокола или не ползвай боза. Windows НЕ Е Realtime OS. Там нищо не се гарантира. Статистически е много вероятно да стане както искаш, но това е статистика, а не правило. А за Бил Гейтс 100ms са RealTime

Е все пак това ще се ползва само при тестване на платките. Няма проблем да се избере съвременен компютър с чиста инсталация на бозата. Това би облекчило нещата.

Да променям проткол който се ползва от 5 години в устройствата, само за да се приспособя към бозата - НИКОГА. По скоро бих си хвърлил трудовата книжка в кофата.

Само дето сега ще трябва да се чете. Уф.

Абе гледам че повечето ще се ориентирали към Борланд. Що? Не се ли очаква от пройзводителя на бозата да може да предложи най-ефективната среда за разработка на приложения под бозата? MFC и VC++ визирам.

Прозорците не са риъл-тайм ОС. Нямаш гаранция за каквото и да било, че ще бъде свършено в строго определено време. Но от друга страна, 100 ms са страшно много време. Вероятността да се свърши твоята задача по изпращането на данните за този интервал, клони към 100%. И все пак не е зле да си промениш малко протокола.

На въпроса защо Борланд - много удобен интерфейс и няколко функции на IDE-то които много те улесняват - code completion. Напоследък все по-рядко ги ползвам, но дори и да си абсолютно бос в програмирането, пак ще можеш да си напишеш това което си решил. Нямам намерението да си губя времето с четене на дебелите книги на MS...или поне не в скоро време.

Както казах - Никога. Не и заради тъпата боза. Това са устройства които работят от години, лицензирани са за надежност (което включва и протокола и точно частта му за синхронизирани пакети) и като цяло нямат никаква нужда от бозата за да работят. Програмата за тестване на платките работеше перфектно под ДОС. Някоя мързелива кратуна обаче е решила, че да зарежда DOS от дискетка и е несравнимо трудно, та е изревала - искам Windows. Ако може - ще го направя. Ако не - ще маат под ДОС до припадък. Да се учат.

А тя между другото ДОС програмката си работи добре даже и под 98/МЕ. Естествено под NT (2000/XP) неще. Но това че при 98 се справяше, ме кара да мисля че ако си е чисто виндоуско приложение би трябвало да работи стабилно.

А по въпроса за реал-тайма, то ясно че ни Linux, ни бозата са такива. Ама оди го обясни тва на оная същата тъпа кратуна.

Ами то и VC++ имаше некъф wizard дето си правеше скелета на приложението. Ама колко е читав - ба ли го.

Абе аз от разни гурута съм чувал, че Борланд бил много по лесен и интуитивен. Лесно се мятало от делфи на С (аз обаче делфи, така или иначе не отбирам).

Ама пак от тия гурута знам, че "майсторите" на "критични" приложения маали на VC. Щото имало неща които Борланда не можел да направи, или поне не толкоз ефикасно ???

За читавото - е читаво си е. Абе нямам по-ръка Borland, да ти демонстрирам програма каквато искаш да напишеш, довечера ще ти пусна една да ти покажа, че тия 100ms въобще не са critical. Не съм опирал до няколко микросекунди, затова и не съм хванал VC...естествено че няма да седна да пиша драйвери за WIN със Borlad Delphi или Borland C++ Builder.

Е не се мори да пускаш код. Както казах, малко не съв в час с бозата и програмирането под него, та трябва да почета малко.

Няма да се уморя ве, ще ми отнеме 10 мин., и повече бих пожертвал заради тебе

ДОС е еднозадачна. И все пак, ако някое прекъсване реши, че трябва да запише, примерно, 100 МБ на диска, гориш.

Неще защото NT-тата недават да се бъзикаш директно с хардуера на ниско ниво. Аз също ползвам основно Delphi 7 и CPort v2.64 на Dejan Crnila и досега също нямам проблеми с никакви комуникации. Както казаха и другите 100ms са достатъчно много време и не би трябвало да е проблем да се реализира.