Выскакивает вот такая ошибка Programmer's Notepad 2 has experienced an unexpected problem and is going to close, we apologise for this inconvenience.

Would you like to save a diagnostic file to aid the development team in fixing this problem?
Что делать

Переходить на нормальную IDE

Доброго всем времени суток!
Пользуюсь Microchip Studio 7.0.
При написании программ (ранее мучал только atmega8) обратил внимание, что при заполнении более 80% flash program memory начинаются всякого рода глюки.
Я пишу свои программы последовательно, т.е. - подсоединил индикатор, написал, скомпилировал, залил в микроконтроллер, проверил - работает. Далее подключаю (к примеру) энкодер, пишу, проверяю. Ну и так далее. И когда устройство полностью функционирует, пишу сервисное меню и прочие рюшечки, которые сжирают львиную часть памяти. И при написании которых и появляются те самые глюки которых раньше не было.
Закон четности ошибок? - Не думаю...
Сейчас бьюсь с программой для 3х канального регулятора мощности. И как всегда - основная программа работает, но требуется добавить при запуске измерение мощности нагрузки подключенной к каждому каналу. Пишу следующую функцию:

Спойлер

float Power_Measurement (void)
{
float power;
производит измерение напряжения, тока, мощности.
вычисляет произведение измеренного тока на измеренное напряжение и сравнивает с измеренной мощностью.
если разница межу измеренной и вычисленной мощностью меньше 1%, тогда:
power += измеренной мощности
счетчик++
И так 10 раз.
return power/10;
}

В основном тексте программы пишу:

Спойлер

float electric_power[3];
…………..
int main(void)
{
……………………………………………………………………………..
PORTB &= ~(1<<PB1); //включаем ТЭН1
electric_power[0] = Power_Measurement();
PORTB |= 1<<PB1; //отключаем ТЭН1
PORTB &= ~(1<<PB2); //включаем ТЭН2
electric_power[1] = Power_Measurement();
PORTB |= 1<<PB2; //отключаем ТЭН2
PORTB &= ~(1<<PB3); //включаем ТЭН3
electric_power[2] = Power_Measurement();
PORTB |= 1<<PB3; //отключаем ТЭН3
………………………………………………………………………………
Выводим на дисплей electric_power[0]
Выводим на дисплей electric_power[1]
Выводим на дисплей electric_power[2]
…………………………………………………………………………………
while (1)
{
...........
}
}

И на дисплее видим только мощность ТЭН1, а мощность ТЭН2 и ТЭН3 отображаются как -0,0.
При чем, видно, что нагрузка ТЭН2 и ТЭН3 - включаются и отключаются, функция Power_Measurement() - вызывается, замеры идут, а в electric_power[2] и electric_power[1] - не возвращаются значения из функции.
Понятно, что дело в драйвере руки.sys. Машина не виновата. Она делает то, что ей сказано.
Не уже ли волшебный volatile float electric_power[3] - поможет?
P.S. Сейчас проверить не могу т.к. до прочтения этой уже начал пользоваться этим девайсом и он у меня в гараже. В ближайшее время принесу домой и попробую. Но это не единственный глюк. Есть и более странные.

Никакого отношения к реальности. Программа ничего не знает о занятой памяти, поэтому это не может влиять на работу.

По программе, просто нужна отладка.
Или в железе или нп. в протеусе.

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

Нужно писать вот так:

Перечитайте про приведения типов и, особенно, про то, к какому типу по умолчанию приводятся числовые значения. И гляньте на сгенерированный компилятором код до правки и после.

По умолчанию к наибольшему типу из пары операндов. Если один из операндов float, то второй тоже будет приведен к float, и результат тоже будет float.

BDDW, еще обратите внимание, сколько ОЗУ у вас занято. Иногда бывает, что стек наползает на область данных и начинаются интересные глюки )

Ну вот, человек пишет на языке высокого уровня, а ему - про стек. "Не моё это царское дело, пусть у компилятора голова про это думает". Так?

Jack_A, а ЯВУ типа Си - он мазохист. И получает цифровое удовольствие, когда программист стреляет себе в ногу.
На самом деле вычислить, сколько стека максимум может отгрызть программа - нетривиальная задача....
У меня была ситуация, когда стек налазил на ОЗУ и немножко портил данные.
Пришлось переделать немного алгоритм, высвободив еще сотню байт.

А не надо вычислять. Это можно смотреть и об этом должно помнить. Ну или хотя бы знать

Martian, не всегда получается вычислять. А вот какие то средства мониторинга - заполнить ОЗУ значениями какими то и потом контролировать область "порчи" этих значений - можно... но опять же, когда есть нормальный отладчик, что позволяет заглянуть в МК - это одно. А когда нужно что то отдельно писать - это уже другое. Хотя в каком то NAKED-прерывании (для AVR) нарисовать на асме кусочек кода и раз в секунду пробегать по ОЗУ, контролируя первый и последний адреса, где сохранилось ожидаемое значение - и сохранять эти значения в еепромку - можно.

Поскольку для МК я всю жизнь пишу на асме - то для меня это и не задача вовсе
Не хочу в 100500й раз сваливаться в холивар asm vs ЯВУ . Как говорят в таких случаях художники: "Я так вижу"

Спойлер

Когда-то, на закате моей молодости работая в НИИ, я со своей командой делал софт для очень серьёзной АСК (военка). И весь программный комплекс писали на асме (СМ-4 = PDP-11). Конечно, для максимального быстродействия интерпретирующей системы асм - без вариантов, но компилятор можно было накропать и на ФОРТРАНЕ, и на только появившемся для этой платформы Си. А тогда почему? Спросите чего-нибудь полегче... Иногда потёмки - не только чужая душа, но и собственная.
Но в те благословеные года тема длилась не днями - годами

Jack_A, да не холивар это. Просто в нонешних реалиях гораздо проще и быстрее 99% кода нарисовать на ЯВУ, нежели вырисовывать его на асме ради 30% экономии размера кода.
А 1% остается на критичные задачи, когда их проще нарисовать на асме, нежели думать, как их компилер откомпилит.
Я на АВРках и сейчас иногда прибегаю к ассемлерным вставкам. Но только иногда. Обычно хватает ЯВУ и знаний, как тот или иной код должен работать и как он компилится в асм.

PORTB |= 0x03 компилится (-О1) в три команды - IN, ORI, OUT
а
PORTB |= 0x01;PORTB |= 0x02; - в две команды SBI

В нонешних реалиях, боюсь, придётся реанимировать Минск-32 с ЯСК и контроллеры Z80 (если ещё успеем, конечно) .

Спойлер

В те времена, когда я ещё работал на фирму по договору подряда, важна была экономия на всём, кроме качества: МК - подешевше, код соответственно, покомпактней и т.п. Экономия в несколько дней на кодинге была бы решающей, если бы выкатывали, как минимум, один новый дивайс в месяц. Ведь чисто кодинг в процессе разработки изделия занимает максимум процентов 10. Есть ещё выработка концепции (скажем так высокопарно ), разработка алгоритма, отладка софта и железа, тестирование, документирование, утверждение ТУ и пр.
Впрочем, я опять уклоняюсь в сторону от любительского форума, повёл речь о выпуске хоть небольшой фирмой, хоть ограниченным тиражом, но всё же промышленного изделия со всем вытекающим из-под него.
----------
А если учесть, что мне пришлось начинать работу с МК на камне, для которого какой уж там Си! - в нём самом даже команды сдвига вправо не было, не говоря уже об MUL, DIV - и на этом чуде техники надо было делать float, да ещё с функциями (Sin, Sqrt etc) пришлось стать акробатом ассемблера , и уже потом привычно...

Jack_A, но время то не стоит на месте. Конечно, если времени много, или если нравится, то можно и на Brainfuck-е писать. Никто запретить не может. Но, если нужна эффективность... додумайте сами.

Эффективность - комплексное понятие. Если у неё один критерий - писа'ть быстро - тогда конечно. Но в приведённой мной ситуации я действовал, IMHO, максимально эффективно, используя асм.

Спойлер

Ну и возьмём ситуацию "со шкурной стороны". Я написал прогу за неделю, вынудил заказчика покупать камень на 2$ дороже. "Ну всё. - говорит он мне - Сейчас ты пока погуляй месяца 4, мы будем доводить прибор до серии. Ну а потом заключим новый договор."
Конечно, это не значит, что я сознательно тормозил разработку. Я был полноправным участником разработки (кроме печатных плат - не моё это), и осциллограф на моём рабочем столе не просто занимал место рядом с компом. И разработчик "железа" не был для меня истиной в последней инстанции - порой приходилось ему менять что-то в схемах по моему предложению. Именно с целью эффективности.
Но этот случай, повторимся, не "радиокотный" .

Ну, от ситуации, конечно, зависит. Ну вот, писал я Х-модем 100 лет назад, на асм-е естественно. А тут мне он понадобился под другую архитектуру, и чё? Ну разве не дурная это работа? Какой тут КПД? А писал бы на ЯВУ - совсем другое дело.) Или нет?


Добавлено after 11 minutes 32 seconds:
Беда в том что Асм он под конкретную архитектуру, его не перенесёшь куда то. Вы это и так понимаете. Поэтому, всё что на Асм - пустая трата времени. КПД 0. Только алгоритмы. Ну и попробуй их перенести!

Ну тут тоже зависит...
Вот пришлось переходить с ST62XX на АВР. Напомню - на прежнем камне ЯВУ вообще не было, так что переход асм -> асм. Мнемоники процентов на 50 совпадали. Что не совпадало - написал преобразующие макросы. Ну и переход на другую платформу был не сам по себе, а со значительным расширением функционала. Так что писать пришлось практически с нуля. И пока заказывали корпуса, платы, комплектуху и пр. - без особой спешки накропал что надо. Ну сделал бы раза в 4 быстрее - и ? Следующий заказ маячил у шефа ещё где-то в потёмках.
И вообще - интересно бы послушать того, кто выдаёт новые сложные изделия хотя бы раз в месяц - ему точно без С++ никак - и где этот рынок, заваленный льющимся потоком новьём?

Спойлер

Кстати (я уже вроде об этом писал) - на прежней моей работе был затык с дивайсом на МК. Я мельком глянул и выразил сомнение в правильности проги. На что их шеф мне: "Программа написана на Си, компилируется, значит, неправильной она быть не может!". Ну ему простительно: хоть у него под началом были девчонки-программистки, сам он в жизни не написал ни строчки кода, поэтому не знает, что компилятор может пропустить синтаксически верную, но абсолютно дебильную в части логики прогу.

Я уже говорила - Язык Си - он мазохист. И получает цифровое удовольствие, когда программист стреляет себе в ногу.
uint16_t a = 40000, b = 30000;
uint32_t ab = a + b;
чему равно ab ?
Правильный ответ : 4464.

Да уж. Не очевидно. А так?
uint32_t ab = (uint32_t)a + (uint32_t)b;

Добавлено after 26 minutes 22 seconds:

Когда работаешь на дядю - это понятно. А если на себя? Да и если на дядю, всё равно своё время нужно беречь. Ведь можешь ещё чем то полезным заняться.)