возможно есть баг с перечислением этих настроек через двоеточие, а с нулями - это критический момент видимо, Марк не предполагал, что так делать будут
вообще ему надо было свойства проекта не выводить текстом, точнее хранить всё в том же файле бейсика, но эти настройки не отображать как текст, а выводить их в отдельное свойство проекта, причем идею можно развить дальше, скажем добавить туда в зависимости от типа МК конфигурацию ножек под типы задач, чтобы была небольшая стандартизация по названиям констант в проекте/программе

Это будет, категорически не правильно!
Кому не нравится пусть не читает!
Не обращайте внимания!

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

Отредактировано sasha_1973 (2013-08-01 02:04:12)

1 записывается, например, "s as string * 10". 10 означает, что в программный стек будет записано десять байт (символов), а затем четыре байта для следующих переменных (типа byte), определенных в прототипе твоей функции. Если размер не указать, то записанные данные не попадают по назначению (попадают не по назначению). Не получив значение размера строки компилятор справедливо может полагать, что ее длина равна 0 или 255 с одинаковыми последствиями
2 использование локальных переменных в Bascom совершенно не оправдано, так как он не располагает их в регистрах общего назначения как многие компиляторы СИ. В результате имеем:
- неоптимальный дополнительный код из-за загрузки-разгрузки стека, необходимости дополнительной подготовки данных для операторов языка, как правило рассчитанных обработку статических переменных;
- трудновылавливаемые ошибки, а следовательно затраты времени на отладку и проверку;
- сокращении места под переменные?, но происходит равнозначное увеличение размера программного стека;
- рискованный стиль программирования (заработает или нет или вдруг произойдет недопустимое сочетания операторов?). 
из плюсов - только возможность применения, вроде бы, более простой формы записи исходного текста - круто и крупно-квадратно.

Сколько просматривал код "C"  в AVR Studio не заметил чтобы они сильно
использовали регистры общего назначения. В основном X,Y,Z, R24, R25 и иногда
ещё пару тройку и всё. Все переменные в ОЗУ.
И кто мешает делать вставки на ASM в критичных местах и писать нормальный код,
чтоб потом без головной боли.

На самом деле, при назначении переменой string значения 10 в реале резервируется 11 байт, т.к. +1 байт это всегда 0 (конец строки).

если написать Lcdtext "Строка 1", то архитектура кода будет выглядеть так: код выводит данные по определенному алгоритму из флеша МК (память программы, т.е. "Строка 1" будет храниться/прошивать вместе с HEXом)
если это будет функция "Sub Lcdtext(byval S As String....", то здесь речь идет уже о динамических данных, S - это область в SRAM МК и всё, что гоняется через неё требует места, если не контролировать значение этой переменной, то чревато последствиями (память переполнится), да эта переменная не задается прямым образом, как в этом случае компилятор формирует область ОЗУ - не разбирался (мне это и не нужно), для этого головные настройки и нужны (по этой причине я не использую функции, т.к. процесс полностью идет не контролируемый мной, что там компилятор и как распихает - темный лес (и так проблем хватает, зачем ещё усложнять))

1 bascom-омском хелпе предлагается обязательно указывать размер строки передаваемой переменной.
2 что там залеплено у марка с передачей параметров функциям даже не разбирался. после пары неприятностей - вообще перестал ими пользоваться. и не жалею.
3 нормальном СИ все очень строго:
   - сколько байт загрузил в программный стек при вызове функции - столько внутри функции и извлеки. иначе он разбалансируется
   - в коде загрузка выглядит приблизительно так так
     LDI R24, "С"
     ST Y+,R24
     LDI R24, "т"
     ST Y+,R24
     LDI R24, "р"
     ST Y+,R24
     LDI R24, "о"
     ST Y+,R24
     LDI R24, "к"
     ST Y+,R24
     LDI R24,"а"
     ST Y+,R24
     LDI R24, " "
     ST Y+,R24
     LDI R24, "1"
     ST Y+,R24
     LDI R24, 0
     ST Y+,R24
     LDI R24, 0
     ST Y+,R24
   - в коде выгрузка выглядит так
     LDI XL, Low(S)
     LDI XH , High(S)
     LD R24,Y-
     ST X+,R24
     LD R24,Y-
     ST X+,R24
     LD R24,Y-
     ST X+,R24
     LD R24,Y-
     ST X+,R24
     LD R24,Y-
     ST X+,R24
     LD R24,Y-
     ST X+,R24
     LD R24,Y-
     ST X+,R24
     LD R24,Y-
     ST X+,R24
- десять записал затем десять считал. ошибиться с количеством байт нельзя. иначе последующие переменные будут повреждены. и это независимо от реальной длины строковой переменной. компилятор должен знать сколько передается и ему необходимо об этом сообщить;
- в bascom иначе быть не должно (и не может). отсылки на то, что все равно работает или не работает несерьезны!
- выгрузка параметров из функции даже в СИ реализуется по разному. иногда через служебные переменные. поэтому обычно используется только стандартные возможности. В bascom здесь вообще темный лес с оврагом
- чтобы действительно эффективно использовать механизм функций необходимо отчетливо представлять как он реализуется

так это выглядит в командах ассемблера

1 Когда после компиляции обнаруживается не тот результат, что ожидался, то есть только два выхода: исправить программу или переписать компилятор под собственные «залепухи». Второй вариант, очевидно, не самый реальный. Значит нужно писать в программе так, чтобы получался необходимый результат.

2 Mrshilovу!  Да, я не знаю, как помочь человеку, который залез головой вперед в узкое глухое отверстие. Нужно сдать назад и поискать другой путь, без «заморочек». Для твоей программы нужно просто все переменные сделать обычными, глобальными.

мужики, заканчиваем
иначе Василий влепит всем по бану и я умою руки...