Современные тенденции развития языков программирования ведут к инкапсуляции, абстрагированию от реализации. Грубо говоря - есть функция - она работает, а как она работает нас не интересует. В ООП - это один из основных принципов.
Просто мне кажется лишним переписывать то, что уже написано. Хотя в том, что вы говорите про понимание сути процесса есть много здравого.
понимаете в чем дело... С# работает на .net framework...
framework установлен пока не на кажой винде...
Пока рано полностью переходить на него.
Мне вот приходится писать приложения для Win32, и никакого прикола в написании на бэйсике нет
Ну допустим я пишу проги для Win32 на бейсике и нормально получается
Проги компактные от 2-кб и для их работы не нужны никакие внешние файлы.
За счёт встроеный функций (число которых можно пополнить) можно разработывать проги даже слабо представляя работу компа и системы и не зная API.
Так что "прикол" есть!
Выбор среды програмирования определяется поставленными задачами. Как правило Борланд используют для написания приложений работающих с различными СУБД. А тут уж не обойтись без внешних модулей и Win API. Сомневаюсь что програмка на бейсике в 2 кило может подключится к базе SQL
AndyWorld писал(а):Выбор среды програмирования определяется поставленными задачами.
Абсолютно верно!
AndyWorld писал(а):Как правило Борланд используют для написания приложений работающих с различными СУБД.
Весьма сомнительное утверждение - выбор в пользу Борланда чаще связан с тем, что это действительно визуальная среда, в отличие от M$ Visual, который, несмотря на название, довольно долго ничего визуального не предлагал вовсе.
Огромное число приложений разработаны на Билдере или Дельфи без малейшего намека на работу с БД. Его преимущество, скорее, заключается в том, что с его помощью приложения делаются быстро, так как в основном строятся из крупных блоков VCL'я. Из под него тоже можно подергать винду заа... за ВинАПИ, но это уже из другой оперы - скорее исключение из упомянутого выше правила. Для небольших команд, которые заняты созданием относительно небольших приложений, Билдер и Дельфи могут оказаться единственным средством, позволяющим выпустить готовый продукт до того, как необходимость в нем отомрет.
AndyWorld писал(а):...с различными СУБД. А тут уж не обойтись без внешних модулей и Win API.
Бог мой, а зачем же здесь WinAPI-то (не к ночи будь помянута )?
AndyWorld писал(а):Сомневаюсь что програмка на бейсике в 2 кило может подключится к базе SQL
Согласен - растянуть подключение на целую пару страниц, задачка не из простых - "тут без помощника не обойтицца"!
Но если такие тяжелые ограничения не накладывать, то задача оказывается вполне посильной:
Dim ws as Workspace
dim db as database
dim strConnection as string
set ws=DBEngine.Workspaces(0)
let strConnection= "ODBC;DSN=" & DatabaseName & ";UID=" & UserName
& ";PWD=" & UserPassword
set db=ws.OpenDatabase("", False, False, strConnection)
framework установлен пока не на кажой винде...
Пока рано полностью переходить на него.
Ну Вы даете
В 2003 году появилась MSVS2003.NET
С тех пор можно было установить. Тем более что большинство программ сейчас пишущихся пишется на фрэймворке. Это быстрее лучше и качественнее.
Раньше борланд чтото предлагал. Теперь ничего хорошего в нем нет. Один Borland C# Builder чего стоит...
За счёт встроеный функций (число которых можно пополнить) можно разработывать проги даже слабо представляя работу компа и системы и не зная API.
А Вы на каком бэйсике пишете, на 6?
Насчет встроенных функций - в фрэймворке их больше. )
Кстати .net даж под линуксом есть - моно называется.
В общем вот так. Я б на вашем месте попробовал .NET. Очень прогрессивная технология. И можете на любимом бэйсике писать. Но лучше на C#. Примеров больше.
Бывает что юзер даже не знает что такое .NET и видя что прога не стартует, тупо сбрасывает её в корзину.
Вот когда на подавляющем числе компов будет установлена ОСь с интергированым .NET'ом, вот тогда его время придёт.
А Вы на каком бэйсике пишете
На PureBasic
В его составе больше 800 встроеных функций и при необходимости можно добавить свои, написанные на PureBasic, Си, или асме.
Так что даже при разработке сложных проектов почти не требуется юзать API.
Ребятки!
Да чего вы спорите?!
Ну yhjfdbncz мне лимонный сок а ему виноградный кислый ну и кто кому что докажет? в любом случае это всё сделано для того чтоб люди работали и оно работает так или иначе....а что именно каждый будет использовать - дело вкуча каждого - каждый сексом по-своему занимается )
У меня вот какая проблема с КОМ портом вышла
Есть у меня на компе прога которая в отдельном потоке читает строки из МК, анализирует их и швыряет данные в локальные переменные.
И есть основная программа в которой по таймеру раз в 2 секунды в КОМ порт для МК пишется строка типа "x1p1HelloWorld!" при этом х команда очистки строки за которой следует номер строки а р - это указатель начала печати всего что прийдёт дальше с порта в экранчик до появления символа "}"....
приём в МК организован по прерыванию и побайтово заполняется буфер 25 символьный. Там же есть процедурка - обработка буфера ком-порта которая вызывается примерно раз в милисекунду ина собственно разбором данных из буфера и занимается....фокус в том чно первое время всё идёт по плану...тоесть все строки которые кидаются в МК чётко доходят до него и выводятся на экран...но вот бывает "МАНА НЕБЕСНАЯ" и резко строки перестают в полном размере доходить и отображаться(ну вот именно с МК дело) - я в этот момент пробывал слать не строку в Ком порт с компьютера а посимвольно с паузами в несколько микросекунд - ну может тормозит чтото там в нём дак нет
ни скорости и стоб биты ни размеры буферов ничего не помогает...
только простая перезагрузка МК!!!
Кто бы подсказал возможна ли одновременная передача и приём данных из ком-порта в микроконтроллере - ну например он шлёт строку "t1(234) = +23.343200"
это же занимает время....и вот например на символе = компьютер начинает передавать свою строку. Но в компьютере-то чтние порта - отдельный поток и вродебы проблем не должно быть....с другой стороны в МК - прерывание на завершение передачи и очень быстрый обработчик - занесение в буффер....
не могу чтото понять....может дело с кварцем или с МАКсой....я с её кандёров снял милиампер 10 для светодиодной подсветки через резюк....может в этом дело?
Фокус в том что с командами типа "r1" небыло вообще никаких проблем - клацал по кнопке раз 20 в секунду - ниразу сбоев небыло.....а вот с длинными строками засада какаято
Вот примеры программ
ПС - только отправил сообщение на форум эта падла ПЕРЕЗАГРУЗИЛАСЬ......прям на моих глазах - стерлась строчка - дальше видимо олжен был быть размер свободного места на винте и клац - с нуля программа пошла...
Пока что количество(ну или вероятность) этого явления уменьшил простым поднятием скорости до 115200 кбпс......но всёравно....каким-то образом стерлась первая строчка...значит уже был сбой....может это связано с ошибками передачи - ибо при 115200 - 8% ошибки заявлены на частоте 16 мегагерц
...и резко строки перестают в полном размере доходить и отображаться...
Что доходит? Что отображается?
У вас есть очень тяжелые прерывания. Могут и они влиять.
Таймер, который проверяет принятое, срабатывает каждые 4ms. Так проверка пакетов не делается. Лучше это делать по таймауту (20-30ms). Каждый раз запускаете таймер по приходу нового байта. Сработало переполнение – проверяете буфер приёма.
Доходит наверное - судя по экрану - чтото типа "х1p1Progra" и ни больше....другой раз не дойдёт знак завершения строки - и новая команда вывода допишет до текущей х1р1....
не могу по переполнению
а если мне пришла команда х2 ? это разве вызовет переполнение буфера? нет....строка не очистится и реакции не будет
да и что вы подразумеваете под тяжелым прерыванием? кроме как внешнего второго - которое есть тсоп и не работает 99.999% времени.
а обработка КомИнтерфейс делдает всего 8 тактов если нету в буффере приёма ничего.... если есть - отрабатывать пока не иссякнет
или Вы хотите сказать что в этом то и проблема - запуск этой процедуры по прерыванию таймера?
на время выполнения этого прерывания (ну и вызов функции КомИнтерфейс) приём и заполнение буффера разве прерывается?
П.С.
Почему-то проблема решилась как-то вот таким способом -
if((temp=='p')||(temp=='P'))
{
// запрошена печать букв в дисплей - очень срочно - буфера может не хватить
// первая после р цифра - номер строки
unsigned char x;
DispBusy = 1;
TCCR2=0x00; // тормозим таймер чтоб не мешал
lcd_gotoxy(0, getchar()-48);
for(x=0;x<LcdBufSize;x++)
{
a2[x] = ' ';
}
/*
temp = getchar();
while(temp<125)
{
lcd_putchar(temp);
temp = getchar();
}
*/
temp=0;
x = getchar();
while(x<125>=LcdBufSize)
x = 255;
}
//x = temp;
// выводим накопленное
for(x=0;x<temp;x++)
{
lcd_putchar(a2[x]);
}
DispBusy = 0;
TCCR2=0x07; // стартуем таймер
return;
}
тоесть я не по одной букве принимая тут же отправлял её в spi() через функции вывода на экран а сначала символы для вывода собрал в массиве чаров и оттуда по окончании приёма залпом выпалил в экран....
ну и естественно уже была поднята скорость до 115200
С поднятой скоростью но в старом(побуквенном) варианте если раз 20 в секунду поотправлять строку типа "x1p1{111{111{111{111}" получалось иногда зависание иногда недохождение пол строки как и раньше......а сейчас вродебы проблема снялась....но я на всякий случай сделал ещё и изменения в прерываниях таймеров и вместо обязательного вызова функции КомИнтерфейс я теперь её вызываю в случае только если буффер приёма переполнен - тоесть так
//если буффер приёма КОМ порта переполнен и вывод на экран разрешен - надо срочно его отработать
if(rx_buffer_overflow&!DispBusy)
ComInterface();
Ну а основное тело программы оставил как есть - скорость обновлений температуры не критично к задержкам на отработку строк из Ком порта и их вывод
но всёравно не понятна причина почему реально такие страшные глюки ловило это дело и как работало иногда и почему иногда не работало...это же цифровая техника в любом случае 2 устойчивых состояния - или работает или нет
не могу по переполнению
а если мне пришла команда х2 ? это разве вызовет переполнение буфера?...
По переполнению таймера. Вы его и так делаете. Переполнение буфера - это ошибка обмена.
или Вы хотите сказать что в этом то и проблема - запуск этой процедуры по прерыванию таймера?
И в ней может быть. Тщательно не разбирался, но очень похоже.
на время выполнения этого прерывания (ну и вызов функции КомИнтерфейс) приём и заполнение буффера разве прерывается?
При входе программы в обработчик прерывания аппаратно запрещаются глобальные прерывания. И, соответственно, ни какие "буферы заполнятся" по другим прерываниям не смогут.
Ну тогда в принципе понятно - иза скорости получилось так что в большинстве случаев промежутка в 4 милисекунды хватит для забивания всей строки до прихода прерывания по таймеру....ну да ладно....вродебы теперь проблем быть не должно - ночь отработало нормально
хотя хардварный же буффер-то есть? он то не по прерыванию заполняется а по факту приёма битов.....короче в принципе-то проблема решена но....немнога не догоняю в чём собственно была - то проблема
а если мне завтра понадобится пулять не буквы в ком порт а строки байт для графического вывода в ЛСД - так єто ещё бОльший поток данных....тогда наверное прийдётся типа синхронизироваться - запрашивать разрешение передачи и ждать контрольного ответа от контроллера а уже потом начинать передачу а в самом МК после отправки разрешения на передачу нужно повыключать все прерывания и чтения 1Wire ?
dc`nfrb проблема не исчерпана.....только что вот cyjdfnnnn фигня какая-то получилась.....
верхняя строка(которая заполняется только при включении) очистилась - значить туда была попытка записывать чтото(тоесть вместо "х1" дошло "х0")....и снова не выводятся на экран строки полные.....как вроде какой-то буффер переполнился....ничего не понимаю... перегрузил ,МК - всё пошло как надо
Может всему виной помехи?
У меня на постоянную через 2 килоома подключены к ножкам порта Д Vrirb 2 транзюка 815(или 817) которые эмиттером в массу а коллектором через обмотку релюхи (РЭС 10) в +12...15 от компьютерного блока(с этих же 12-ти кренкой я 5 вольт делаю для меги макса тсопа и 3.3 вольтного стаба на экран) а релюха контактами замыкает цепь 220 для более мощного пускателя в соседней комнате(сеть никак не связана с платкой - разве чтто через ёмкость изолятора между выводами релюшки)...
Но на меге у меня кандёры по питанию и электролит и керамика прямо на самих выводах питания - то же самое и с максой и с тсопом...
может на пины порта которые транзюком дёргают тоже поставить керамики?
А с другой стороны не только же регистры и программа при передергивании питания сбрасываются но и кварцеерый ренератор.....может в нем собака порылась - кварц у меня фуфло или кандеры не те? Я на выводы кварца, кандеров и МК с обратной стороны платки(ну где они припаиваются) налил молекулярного клея из пистолета но он жеж вроде не проводит ток....наоборот....хотел сделать так чтоб при любых случаях никакие провода даже рядом не проходили.....
Кварц у меня маханький и низенький на 16 мгц....а есть как на видеокартах - такой же по посадочному месту но высокий - раза в 4 выше - и на 20 мегагерц....может мне на него пересесть? А какие кандеры надо ему?
вопервых вопрос - зачем эти переменные чаровские - только время отнимают
второе....всё бы хорошо но что будет если буффер переполнился?
индекс чтения стаёт резко равным нулю, количество прочитанных символов тоже ноль и поднимается флаг переполнения.....почему??
ну например у меня есть вызов чтения из буффера по переполнению
char getchar(void)
{
char data;
while (rx_counter==0);
data=rx_buffer[rx_rd_index];
if (++rx_rd_index == RX_BUFFER_SIZE) rx_rd_index=0;
#asm("cli")
--rx_counter;
#asm("sei")
return data;
}
что будет с этой фигнёй если получится флаг переполнения?
да оно просто подвиснет и будет ждать нового символа....а если я на скорости 115200 всё выпалил? получсается подвисание? до следующего пакета....мдям....вот и писец прерыванию получился...
ну чтож сейчас перепишу по-нормальному
вот нормальный код переделанный прерывания на приём
вопервых отрабатывать стало очень быстро после выноса переменных в глобальные - вместо 27 символов получалось вывести 29 хотя буффер размером только 25 во вторых и вправду проштые проблемы тут же возникали при переоплнении буффера и чтение из него было уже бесполезным - переменную зачем-то обнуляли(программист написавшие КодВижнАВР и пример прерывания приёма) в общем теперь приём по ком порту супер стабильный
а буффер переполнялся когда пультиком клацал я издалека и некоторые прерывания не доходили делая обработку более задерживающейся так как приходилось проходить все условия.....теперь и это не проблема - ну...бывает раз на пол часа непрерывного клацания из 3-х пультов последняя буква часов(строка "x1p1{12:00:00{}") не доходила - прошлые часы ещё в буффере сидели не обработанные.....пипец проблемы с многозадачностью возникают...ну да ладно - поборол!
Всем спасибо за внимание.
Сори за оффтоп. Не могли бы Вы подсказать чем MAX232IN отличается от другого множества МАХ'ов. или в схемотехники это особой роли не играет. Мне просто надо соединить PC и ATmega8 по СОМ-порту а из имеющихся в наличии есть только MAX232IN.
Отличий в них нет со стороны схемотехники распайки и т.д.
разницу можно увидеть в табличке .
У меня всётаки проблемы с ком портом есть!
Проблема осталась той же только крайне редко встречается - подвисает контроллер и всё тут
Убрал уже даже в прерывании ТСОПа чтение из еепром и зашил значения в флешку...опять таки оптимизировал программу на компьютере....и всёравно получается какая-то фигня непонятная....
Поделитесь пожалуйста кто как боролся с такой проблемой?
Спасибо. Тогда еще маленький вопрос, в некоторых схемах вместо электролитических конденсаторов на 10uF или 1uF ставят обычные на 0.1uF. Такое внесение изменений в схему как нибудь влияет на ее работоспособность и для чего это делается?
Это делается не для того а от того что есть максы новые работающие на сверхвысоких частотах и как следствие ей можно меньшие кандёры ставить - в принципе чем меньше тем дешевле компактней и так далее в любом случае если поставить 1 микрофарад на микруху нового поколения - ей от этого ну никак плохо не станет...а вот если простой микрухе втулить 0.1 - она может не справиться и не развивать нужные напряжения
У меня от +- 9 вольт максом создаваемых питается подсветка экранчика через полевик как стабилизатор тока 10 милиампер - проседания нет вообще! канёры по 1 микрофараду боченки
на передачу никак не влияет ток до 80 милиампер - больше - начинают напряжения падать и....всё...крякозябры в терминале лезут
