Вообщем проблема в следующем. Создаю массив, забиваю его нулями. В последствии оказывается что там не везде нули. Никаких операций с указателями не делаю, переполсти за пределы массива тоже не должен. При изменении кода прокта (абсолютно постороних) значения в массиве меняются без видимых кореляций. Изменение опций оптимизации так же приводит к измению данных. Упростил код до безумия - не пойму. Второй день сижу, поглядите, плз.
При запуске в функции LoadRaspisanie зачищаем массив. В полсдествии в перерывании выводим значения. Байт часов, байт минут, далее три пары байт, второй байт - значения массива. Потом индекс массива который выводится. И вот в третьей паре второй байт он не ноль.
То есть ему оперативки не хватает? А как то написать об этом он не должен? Если массивы сделать побольше, то при компиляции winavr пишет, что .data столько то и в процентах, если перебор, то больше 100. Но тут вроде все в допусках.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
положил массивы в еепром, вроде все нормализовалось. Но я этого прикола не понял. В изначальном варианте я уменьшал размеры массива и winavr писал что data занято на 90%. С какого момента вообще нужно "начинать считать"? Почему компилятор перезаписывает переменные? Это ведь не такая уж и травиальная задача посчитать нужны объем памяти, я уж молчу про стек... "как жить, как страной управлять" (с)
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Карма: 29
Рейтинг сообщений: 645
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2694 Откуда: г. Чайковский
Рейтинг сообщения:0 Медали: 1
Трудновато будет стек посчитать программируя на ЯВУ. Надо смотреть скомпилированный код. Локальные переменные скорее всего там будут. В обработчике прерывания некое количество регистров будет скинуто. Кстати, можно поглядеть как скомпиллися вход в main, возможно командой rcall, а так как из main выхода не будет, можно поправить указатель стека, тем самым сэкономив два байта.
Если в еепром часто писать, то не долго проживет. У Вас "цветные" массивы какие значения могут принимать? Наверняка можно что-то с оптимизировать.
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
экономия двух байтов ничего не даст. Я уменьшил массивы на 20 байт - такая же петрушка осталась. Писать в еепром часто и не будется, там один раз записали и потом только читать. Просто чтение в прерывании и мне кажется более правильно с переменными работать. Там изначально предполагалось что массивы будут в еепром храниться, просто работать хотел с переменными.
значения от 0до255, оптимизировать можно первые два массива - часы и минуты. Можно там выкроить по паре бит, но это усложнит чтение и запись и я решил что оно того не стоит.
на самом деле меня больше сам факт удивляет: пишешь, компилируешь, все ок, а потом фигагс и пойми что там происходит. И это я еще заметил что что то не так, а если бы это вылазило бы не всегда (при некоторых изменениях он вроде нормально гонит, но я так понимаю это до поры до времени).
И самое главное - а как вот сейчас узнать что все в порядке. Массивы я убрал, оставил только один. винавр пишет что 40% озу занято...
PS Загнал проект в протеус (всмысле исходник), под отладчиком смотрел адреса переменных - не нашел что бы адреса совпадали, похоже реально стек рушит...
Карма: 29
Рейтинг сообщений: 645
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2694 Откуда: г. Чайковский
Рейтинг сообщения:0 Медали: 1
Не надо ждать чудес от компилятора, все он не просчитает. Если при 60% свободной памяти что-то не так, то это уже не стек. А константы лучше хранить в памяти программ, собственно они и так там.
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
всмысле? В ОЗУ? В виде переменных? У меня "по плану" так: все эти массивы хранятся в еепром. Массив со временем продублирован и хранится в ОЗУ в виде массива переменных. А значения RGB читаются из eeprom. чтение из eeprom не изнашивает же его? Запись туда очень редко,а вот чтение будет регулярно....
Проведи тестирование каждого фрагмента автономно, затем в комплекте (присоединяя по одному дополнительному модулю на тест). Где-то "накладка" имеется. Или банальный общий сбой работы МК.
Карма: 29
Рейтинг сообщений: 645
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2694 Откуда: г. Чайковский
Рейтинг сообщения:0 Медали: 1
alex1126 писал(а):
всмысле? В ОЗУ? В виде переменных?
Память программ - это память программ, та память в которой лежит программа, она же флешь. Если данные не планируется менять в процессе работы программы и не хватает ОЗУ, то зачем их дублировать в ОЗУ.
Код:
if (gS++>60) { gS=0; gM++; } _delay_ms(900);
Неудачный алгоритм счета времени. Не потому что у Вас в минуте 61 секунда. Время лучше считать от таймера, например в том же обработчике прерывания от него. А вот сличать текущее время с заданным можно и в основном цикле. Я там понимаю 900мс опытным путем навскидку подобрано?
-- ЕЕПРОМ от чтения не портится.
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Если данные не планируется менять в процессе работы программы и не хватает ОЗУ, то зачем их дублировать в ОЗУ.
планируется, но очень редко. Впринципе хранить их в еепром меня устаривает.
Цитата:
Неудачный алгоритм счета времени. Не потому что у Вас в минуте 61 секунда. Время лучше считать от таймера, например в том же обработчике прерывания от него. А вот сличать текущее время с заданным можно и в основном цикле. Я там понимаю 900мс опытным путем навскидку подобрано?
это типа заглушки. В реальности там с ds1307 берется время, но при поиски ошибки я отключил все модули который касаються часов и собственно i2c.
не читаем получается код Да и из 2кб можно много выжать, если постараться. Я туда запихивал софтовую реализацию юсб и еще на "работу" хватило. вот где битва за каждый байт была
Ну хорошо, скажу по другому - не так легко читаем. Вообще я стараюсь писать так, что бы одна функция помещалась на экране без перелистывания. На асме так сделать не просто. Там только написание цикла полэкрана займет - положим начальное значение, увеличим, сравним с конечным значением, переход туда, переход сюда... И вообще мы как то от темы отдалились.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 36
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения