Форум РадиоКот

To spy-tuning: Не-а, косяк не в протеусе... Как это там у Булгакова было?... "Разруха не в парадных - разруха в головах и в сердцах..."Ну ё-моё, да вынеси же наконец Т2=0 за тело подпрограммы и будет тебе щщщастье!!!

edm2007 писал(а):Этой строкой конфигурируется таймер. Ну в обучалке же есть пример подсчета:

В обучалке кстати пример не очень удачный, т.к. waitms даёт очень приблизительную выдержку времени, которая для более-менее точных измерений совсем не подходит.

Немного на другую тему: я тут был поражён, насколько большие возможности открывает BASCOM по оптимизации своего кода! У меня тут прошивка перестала помещаться в 8 кБ меги, начала ругаться на перезапись бутлоадера и на перебор в 124 байта. Занялся оптимизацией текста (в асм лезть не хотелось). Оказалось, одни только игры с заменой If-End If/Select Case-End Select, For-Next/Do-Loop, Call/Gosub и т.п. уже способны на многое. А если ещё грамотно работать с переменными и массивами.... В общем, за пару часиков мне удалось не только ужать прошивку до 96% FLASH, но и при этом втиснуть в неё три новых функции (=приличные подпрограммы).

я тут был поражён, насколько большие возможности открывает BASCOM по оптимизации своего кода!

Да, есть такой момент! Особенно хорошо помогает вставка в программу нужных библиотек. Например, какой-то код занял 102% Flash, вставляем в прогу библиотеку "mcsbyte.lbx", перекомпилируем, и..., о-чудо!!! Видим, что занято всего 73% Flash!!! Ну разве не здорово!!?
А если поколдовать с типами переменных, то ващще ГУД!!!

Секретный кот писал(а): я тут был поражён, насколько большие возможности открывает BASCOM по оптимизации своего кода!

аналогично! аж плакать хотелось ))

Igor_67 писал(а): собенно хорошо помогает вставка в программу нужных библиотек.

а вот с этого места поподробнее, пожалуйста
не понял...

А есть ещё такая фишка-

Секретный кот писал(а):В обучалке кстати пример не очень удачный, т.к. waitms даёт очень приблизительную выдержку времени, которая для более-менее точных измерений совсем не подходит.

Да разумеется !!! Ну это же пример, просто чтобы понять в чем суть. Было бы от чего оттолкнуться.

kip96 писал(а):есть ещё такая фишка

Галку Swap words лучше бы снять, а то не получится корректно прошить МК с помощью большенства программаторов.

aleksandr-zh писал(а):

Секретный кот писал(а): я тут был поражён, насколько большие возможности открывает BASCOM по оптимизации своего кода!

аналогично! аж плакать хотелось ))

Igor_67 писал(а): собенно хорошо помогает вставка в программу нужных библиотек.

а вот с этого места поподробнее, пожалуйста
не понял...

А чего тут непонятного???
Попробуй для профуры написать простенькую программку, например для считывания температуры с датчика DS18B20 по шине 1WIRE или по I2C прочитать какие-нить часики, например DS1307 и отобразить все это , ну хотя-бы на LCD 16x1 (куда уж проще). Только не используя встроенных библиотек, скомпилируй и посмотри сколько % flash заняла программа. Потом вставь в начале листинга, после $crystal=4000000 (например) строку: $lib "mcsbyte.lbx", снова скомпилируй и посмотри размер кода во флэш, даю гарантию, процентов на 15-20 будет меньше, если, конечно, в настройках выставлен флажок "оптимизация кода".
Удачи!

Igor_67 писал(а):в начале листинга, после $crystal=4000000 (например) строку: $lib "mcsbyte.lbx", снова скомпилируй и посмотри размер кода во флэш

Что забавно, в моём случае добавление библиотек mcsbyte и mcsbyteint не дали абсолютно никакого выигрыша (по крайней мере меньше минимально заметного 1% ). Т.к. они в основном для преобразований типов переменных, которые у меня сделаны с помощью overlay. А в основном всё стараюсь строить на переменных типа byte, как наименее затратных и наиболее универсальных.

Вопрос дилетанский: $crystal xxx - в доках сказано, что ххх - частота кварца, однако прогонка в симуляторе даёт противоположный результат - чем выше ххх - тем ниже скорость симуляции...? ( период, что-ли? )
Может где в настройках что-то есть?
(BACKOM ( 1.11.9.8 ) скачал вчера, поставил сегодня, обучался пару часов - короче чайник...)

svic писал(а):Вопрос дилетанский: $crystal xxx - в доках сказано, что ххх - частота кварца, однако прогонка в симуляторе даёт противоположный результат - чем выше ххх - тем ниже скорость симуляции...? ( период, что-ли? )
Может где в настройках что-то есть?
(BACKOM ( 1.11.9.8 ) скачал вчера, поставил сегодня, обучался пару часов - короче чайник...)

Частота кварца указывается для расчета временных величин в программе. Например, если в коде будет указано что кварц 1 МГц ($crystal = 1000000) а зашито все это будет под кварц 4 МГц, задержка в 1 сек (wait 1) уже таковой являться не будет (получится 250 мс). И наоборот.

Потрясающе! Выходит симулятором понятие "частота" воспринимается как некая продолжительность процесса - чем длиннее запись - тем дольше процесс?!
Странная какая-то формула расчёта временнЫх интервалов...

svic писал(а):Потрясающе! Выходит симулятором понятие "частота" воспринимается как некая продолжительность процесса - чем длиннее запись - тем дольше процесс?!
Странная какая-то формула расчёта временнЫх интервалов...

Указываем частоту для компилятора, он же не в курсе на какой частоте наше устройство работать будет. А в симуляторе все нормально, смотрите на счетчик времени внизу а не на наручные часы. Или Вас именно скорость СИМУЛЯЦИИ не устраивает? К реальной работе это никакого отношения не имеет. И вообще, удобнее на время симуляции "выключить" все задержки ($sim), так пошагово пробежаться можно и посмотреть что к чему... Главное, потом не забыть все обратно вернуть.

Да, именно в скорости симуляции всё и дело, цыкломер показывает правильные значения длительностей, а вот сам симулятор тормозит тем значительней, чем выше частота кварца. Просто по наивности я сразу забил расчетные величины и если-б не пошаговый режим, долго бы пришлось рабираться с "глюками в проге"...
Спасибо! ( А в целом редактор действительно удобен! )

P.S. $sim было первым, что применил, тем более, что проги чисто проверочные ( надо ж как-то пощупать возможности васика ) и без выяснений "как нельзя делать" просто не обойтись!

Скорость симуляции (например в Протеусе) сильно зависит от мощности компа и видюхи. Чем выше частота в проекте, тем мощнее должен быть комп. Проверял на двух разных компах: на одном стоит AMD Athlon-XP 2500 + 768MB RAM + ATI Radeon-9600Pro, на другом P4 core2Duo + 2GB RAM + ATI Radeon HD2650. Так на втором компе любая симуляция летает при частоте проекта от 16МГц,................. а на первом и при 8МГц тормозит...
Делайте выводы... Особенно это заметно, если частота не точная (допустим 12.000МГц), а дробная (11.0592МГц).

Ещё раз спасибо за разъяснения! По данному вопросу всё усёк - главное, что работе это не мешает. Просто при моих 2х2.8 + 2Г рамы чуток насторожило... В планах - организовать нечто вроде аккумулятора фазы, потому и нужны "быстрые" кварцы , но пока не дорос, надо разбираться с регистрами и счетчиками...

Igor_67 писал(а):Скорость симуляции (например в Протеусе) сильно зависит от мощности компа и видюхи...

Угу, я как-то на стареньком компе запустил симуляцию, так он (протеус) так и выдал что симуляция идет не в реальном времени.

Хм, а у меня почему-то если стоит галка "оптимизация кода", размер кода во flash получается наиборот на 1% больше...

Доброго времени суток. Проблему с мерцанием индикации термометра решил (писал об этом выше).

через равные промежутки времени индикация "дергается" (чуть пригасает).

Проверено в железе, все замечательно. Цепляю исходник и проект в протеусе. В проекте комментариев больше чем кода, так что проблем быть не должно. Хотелось бы услышать замечания и прочую критику. Ибо это первая работа с динамической индикацией и датчиком.

edm2007 писал(а): Хотелось бы услышать замечания и прочую критику. Ибо это первая работа с динамической индикацией и датчиком.

А не проще ли написать такую программу более простыми способами, без использования таймеров и других примудростей. Самым примитивным способом, тем более, что и код получается меньше. Ну, например, вот так (правда этот проэкт только в протеусе, и на быструю руку, в железе, естественно нужно будет отладить):