Вобще реально рабочий день разработчика ПО 4-5 часов, это уже сто раз обсуждалось. А думать он не перестает все 19 часов. )))
Дополню, с вашего позволения: в эти 4-5 часов не значит, что разработчик ишачит по клавишам шо та дурная обезьяна - он может половину времени сидеть с отсутствующим видом, или - бродить с цыгаркой в зубах. Потому как идёт процесс унутре коробушки, и в этот момент главное - не тыркать :)
А ещё - хуже нет, когда надо "уже вчера", да ещё и без продумывания архитектуры: это тааакой попадос... Вот в эти редкие случаи и приходится делать как просят, а не как надо :) Это такой душевный крик в сторону маркетологов и всяких менеджеров проектов, которые не понимают внутренней сути.
Ага. Складывается ощущение, что ЕвгенийП имеете ввиду 5 часов подряд. Конечно нет! Это же просто никак нельзя, ведь обед - святое!! 5 часов за сутки суммарно.
А если совсем серезно, так 5 часов это максимальное время в течении которого взрослый тренированый человек может концентрировать внимание. Если посадить человека решать простые задачи типа 2+3 то часов через 5 начинает ошибатся сильно чаще. Это такой же физиологический факт, как возможность тренированого поднять 200кг, и не поднять 500. У нетренированых все понятно хуже.
Вот просто интересно. Если надо хранить какие-то данные в энергонезависимой памяти и тут кого-то может напугать гарантийное ограничение в 10.000 циклов, почему тогда не хранить эти данные, тупо, на SD?
И еще один вопрос: этот "EEPROM" и та область памяти, куда пишется сам скетч - в чем между ними отличия?
Я так понимаю что те 32кб, куда пишется скетч предназначен только для скетча. Как бы - винчестер, "EEPROM" - только для хранения каких-то величин, созданных скетчем и которые не должны быть утеряны после отключения питания. Типа - флешка или тоже винчестер с произвольным доступом из самого скетча. Кроме того есть еще где-то область памяти для оперативных расчетов. Такой себе "RAM".
Память программ - не "винчестер" ни разу. Больше как раз соответсвует ОЗУ "команд" с практически запрещенной записью. Ибо даже несколько шустрее чем собственно "такая себе рам" для вычислений: команда из памяти команд считывается за 1 такт 2 байта, а "так себе рам" читает 1 байт за 2 такта .. Да, и памяти команд чутка поболее: 256 килобайт. Против 8 килов "для вычислений и стека". :)
А вот ЕЕПРОМ - ваше ни разу не "с произвольным доступом", а как раз таки "а-ля винчестер" с последовательным: хочешь байтик? Скажи откуда.
SD и прочие "внешние" винчестеры по SPI или чему ещё тут не рассматриваются по причине их внешности к кристаллу, а соответственно своей исключительной тормознутости и необходимости "городить огород". Как понимаю, вопрос как и как долго (мой) можно заюзать то что есть на самом кристалле. Вясняется что Не очень и долго, ежели стараться. :(
Ну тогда всё как я и думал: ардуина это такой себе самодостаточный мини-компьютер со своим CD-ROM для скетча, EEPROM-последовательным винчестером и небольшой RAM... И вся фишка в том, что бы использовать эти возможности, не цепляя ничего извне, не "городя огород" и оставляя как можно свободных пинов именно для датчиков и исполнительных цепей, для которых они все, собствтенно, и предназначены.
Да, именно так: это полноценная SoC система (1кристальный МК), но даже ещё "однокристальнее": на борту есть куча "периферии", которая как раз и предназначена для УПРОЩЕНИЯ управления. То есть, не надо городить и "программные огороды" тоже .. вся "программная эмуляция" - от непонимакния что Atmel - это SoC в квадрате. :)
То есть, не надо городить и "программные огороды" тоже .. вся "программная эмуляция" - от непонимакния что Atmel - это SoC в квадрате. :)
ебануться!
Вот оно - искуство ТЗ )))
На основании расплывчатого пожелания высказаного в чисто гуманитарной, образной форме, причем форме отрицания, с использованием только что придуманой терменологии, понятныой только автору да и то только во время произношения делается краткий и предельно конкретный вывод о работе, которую нужно выполнить для достижения результата )))))
дятел, включи мосги - нахуя мне публиковать самокритику?
если это самокритика, то я космонавт, сбитый турками.
Во первых: я с "тобой" свиней не пас, поэтому попрошу без перехода на личности.
Во вторых: откуда я знаю с чего это "тебе" вздумалось нести чушь в свой адрес? Это вопрос не ко мне. В зеркало иди загляни и повтори туда.
В третьих: "Космонавт сбитый турками" на порядок порядочнее и более желателен как собеседник. И отсюда -
В четвертых: если Вы думаете (в чем я сильно сомневаюсь) что я буду продолжать полемику с каждым вонючем троллем, встреченным в инетах, так Вы так уже не думайте.
Во первых: я с "тобой" свиней не пас, поэтому попрошу без перехода на личности.
Во вторых: откуда я знаю с чего это "тебе" вздумалось нести чушь в свой адрес? Это вопрос не ко мне. В зеркало иди загляни и повтори туда.
В третьих: "Космонавт сбитый турками" на порядок порядочнее и более желателен как собеседник. И отсюда -
В четвертых: если Вы думаете (в чем я сильно сомневаюсь) что я буду продолжать полемику с каждым вонючем троллем, встреченным в инетах, так Вы так уже не думайте.
Во первых: стань на колени и попроси ещё раз, алень.
Во вторых: не знаешь - не фантазируй чушь.
В третьих: мёртвый космонавт - хороший космонавт.
В четвертых: ок. съеби с горизонта и не отсвечивай.
Блин, qwone, ну от Вас не ожидал! Зачем ещё один буфер заводить и дублировать туда строку? Она же совершенно спокойно адрес родного буфера возвращает (метод c_str()).
За рекомендации спасибо. Пут и гет использовать для записи бита имхо неоправдано. Эти функции удобны для записи значений длиннее байта, чтобы не делить побайтово вручную. Апдейт удобно, но в моем случаии инвертации бесполезно, т.к. непосредственная инвертация перед записью априори меняет значение не совпадающее со значением в памяти. Мне важнее отследить чтобы инвертация была разовой, но эту проблему вроде решил.
#include <EEPROM.h>
int i = 0;
String in = "+71234567890";
void setup() {
Serial.begin(9600); //Скорость порта для связи Arduino с компьютером
Serial.println("Go");
}
void loop()
{
char Buf[in.length()+1];
in.toCharArray(Buf, in.length()+1);
Serial.println(" ");
for (int i = 0; i < in.length(); i++){
Serial.print(Buf[i]); //выводим в порт посимвольно строку с номером
EEPROM.write(0, in.length()); //сохраняем количество символов
EEPROM.write(i+1, Buf[i]); //сохраняем символы в память
delay(500);
if (i == in.length()-1) {
Serial.println (" ");
int iepr = EEPROM.read(0); //читаем количество заполненых ячеек памяти
Serial.println (iepr);
for (int p = 1; p <= iepr; p++){
Serial.print (char (EEPROM.read(p))); //читаем ячейки и выводим в сериал char
Serial.print (" ");
delay(500);
}
}
}
}
2) жалко конечно, но других вариантов я не нашел, к сожелению....
Так Вы поищите.
Вот что у Вас делает 18-ая строка внутри цикла по i? Она как-нибудь от i зависите? Если нет. то что она делает внутри цикла? Для чего она там?
Хотите я отвечу? Она там для того, чтобы длину строки записать в нулевую ячейку не один раз а столько раз, сколько символов в Вашем номере.
Нафига? Это только Вы знаете.
Думаете записать длину один раз недостаточно?
Кроме того, номера телефонов такая вещь, что очень часто на одни и те же места будут попадать те же самые цифры (типа +7495...). так нафига их перезаписывать? Используйте update вместа write и они не будут перезаписываться. Е ещё проще просто используйте нотацию массива.
Запись в еепром: EEPROM[addr] = value;
Чтение из еепром: byte b = EEPROM[addr];
Уберите многократную запись длины и замените write на update - всё станет гораздо кошернее.
Два месяца все работало как часы. Но теперь стал замечать, что после выключения/включения питание байт UPR может сам сбрасываться не в ноль (конкретно не смотрел что туда прописывается, т.к. плата спрятана под торпедой). Вкратце на "событие" реагирует адекватно, делает "действие 1", и либо делает "действие 2", или перестает его делать. Если выключить когда в UPR была записана единица, то при включении всегда делается "действие 2", т.е. единица не сбрасывается, или сбрасываетя в любое другое значение, но не нулевое.
А если выключить когда в UPR был записан ноль, то при включении может начаться выполнение "действие 2", т.е. UPR считывается как не ноль.
Что может быть? Может я "нехорошую" ячейку с нулевым адресом выбрал для хранения UPR и она может случайно перезаписываться иными аппаратными функциями?
При компиляции всего скетча расход ресурсов таков:
Скетч использует 2866 байт (9%) памяти устройства. Всего доступно 30720 байт.
Глобальные переменные используют 59 байт (2%) динамической памяти, оставляя 1989 байт для локальных переменных. Максимум: 2048 байт.
Это мне известно. По адресу 0 я произвел пару десятков записей во время отладки. И по две записи каждые две недели (это максимум) в течении двух месяцев. Итого 20+2*4=28. Ну пусть даже три десятка. Всё, память просится на кладбище?
1. Это может быть из-за температуры эксплуатации (под торпедой авто может нагреваться до 60°С)?
2. Это может быть связано с адресом переменной (первая ячейка с номером 0)?
3. Это может быть связано с хранением булиевого значения в переменной типа байт?
Это мне известно. По адресу 0 я произвел пару десятков записей во время отладки. И по две записи каждые две недели (это максимум) в течении двух месяцев. Итого 20+2*4=28. Ну пусть даже три десятка. Всё, память просится на кладбище?
1. Это может быть из-за температуры эксплуатации (под торпедой авто может нагреваться до 60°С)?
2. Это может быть связано с адресом переменной (первая ячейка с номером 0)?
3. Это может быть связано с хранением булиевого значения в переменной типа байт?
Вариант 1 возможен, но маловероятен, 2 и 3 исключаются если кристал не подвергался экстремальным воздействиям температуры и напряжения. Стоит проверить источник питания процессора (выбросы, просадки напряжения) добавить дроссель, конденсаторы, бортовая сеть авто это большая кака. Запись в EEPROM у Вас в лупе идет по условию, а если процессор дуркует из-за сбоев по питанию то говорить что за 2 два месяца всего было 30 записей в EEPROM вряд-ли можно.
Стоит проверить источник питания процессора (выбросы, просадки напряжения) добавить дроссель, конденсаторы, бортовая сеть авто это большая кака.
Про бортовую сеть я в курсе. Там же по ссылке защитился как мог (и токоограничивающий резистор, и супрессор, и дроссель, и электролиты). Конечно надежнее только отдельное питание от внешней батарейки.
oleg_kazakof пишет:
Запись в EEPROM у Вас в лупе идет по условию, а если процессор дуркует из-за сбоев по питанию то говорить что за 2 два месяца всего было 30 записей в EEPROM вряд-ли можно.
Вот это условие в лупе сопровождается внешним действием с использование делай (т.е. с остановкой скетча), а именно это мырг фарами с щелканьем реле . Такое действие я конечно пропустить разок мог, но не несколько тысяч раз. А поверить в то, что в этом условии выполняется только одна строка (запись), без остальных строк (мырг на делау), выше моего понимания. Даже если это теоретически возможно, то ради такого я готов поменять последовательность выполнения условия - сначала мырг фарами с использованием делай, а только потом запись. Надеюсь при такой последовательности запись не может быть произведена без мырга?
1. Не пишите ничего в EEPROM по первым адресам, так как есть известные проблемы порчи данных по этим адресам при снятии/просадке питания. Начинайте осмысленное использование EEPROM с адреса 0х10.
2. Считайте контрольную сумму EEPROM (своего записанного блока) при старте программы, тогда неприятность можете отловить раньше, а не тогда когда она уже случилась. Чтение из EEPROM на ее ресурс не влияет.
1. Не пишите ничего в EEPROM по первым адресам, так как есть известные проблемы порчи данных по этим адресам при снятии/просадке питания. Начинайте осмысленное использование EEPROM с адреса 0х10.
2. Считайте контрольную сумму EEPROM (своего записанного блока) при старте программы, тогда неприятность можете отловить раньше, а не тогда когда она уже случилась. Чтение из EEPROM на ее ресурс не влияет.
Спасибо за дельные советы.
0х10 - это с 17-го?
На конрольную сумму натыкался в форуме. Но не могу осознать как сделать контрольную сумма на битовое данное принимающее значение 0 / 1. К тому же контрольная сумма не поможет восстановить утерянное значение. Приходит мысль записывать значение бита как не тривиальное значение байта (например 107 / 230) в три ячейки одновременно (или больше) и считывать значения которые повторяются в этих ячейках. Если повторов нет, то всё - фаталеррор, узнать ранее записанное значение невозможно.
Код накидался такой
int UPR = 0;
void setup() {
for (int i = 60; i < 65; i++){ //Считываем 5 ячеек еепром .
if (EEPROM.read(i) == 230) UPR++;
if (EEPROM.read(i) == 107) UPR--;
}
if (!UPR){ //Если ни одна ячейка не соответствуют 107 или 230
"моргаем фарами";
}
if (UPR < 0) UPR = 0; //Если насчитали "+" - оставляем, если "-" - обнуляем
}
void loop() {
if("условие") {
"моргаем фарами";
UPR = !UPR; //переключаем флаг
for (int i = 60; i < 65; i++) //запоминаем в 5 ячеек
EEPROM.write(i, 123*UPR + 107);
for (int i = 60; i < 65; i++) //контрольно считываем
if(EEPROM.read(i) != 123*UPR + 107){ //если ячейка не соответствует записанному
"моргаем фарами" //на каждую неудачно записанную ячейку
}
}
}
1. Не пишите ничего в EEPROM по первым адресам, так как есть известные проблемы порчи данных по этим адресам при снятии/просадке питания. Начинайте осмысленное использование EEPROM с адреса 0х10.
1. Не пишите ничего в EEPROM по первым адресам, так как есть известные проблемы порчи данных по этим адресам при снятии/просадке питания. Начинайте осмысленное использование EEPROM с адреса 0х10.
Если можно, сылку на даташит, где есть различие в работе EEPROM с адреса 0x00 и после 0x10
Различия как такового нет, есть особенность AVR портить EEPROM. Чаще всего это адрес 0. Поэтому я на всякий случай не использую адреса до 0х10, чего и посоветовал. Ссылка на AVR FAQ ровно постом выше Вашего.
Чтение и запись в EEPROM. Опишите последовательность действий, которые необходимо выполнить, чтобы обеспечить запись данных в ячейку внешней памяти. Приведите фрагмент программного кода.
Чтение и запись в EEPROM. Опишите последовательность действий, которые необходимо выполнить, чтобы обеспечить чтение данных из ячейки внешней памяти. Приведите фрагмент программного кода.
Чтение и запись в EEPROM. Опишите последовательность действий, которые необходимо выполнить, чтобы обеспечить запись данных в ячейку внешней памяти. Приведите фрагмент программного кода.
Чтение и запись в EEPROM. Опишите последовательность действий, которые необходимо выполнить, чтобы обеспечить чтение данных из ячейки внешней памяти. Приведите фрагмент программного кода.
Очень похоже на задание для нерадивого студента. Щас все прям кинуца исполнять, да прям с основ всё тебе разжовывать.
Обычно деление на степень двойки реализуется сдвигами. Поэтому ответ: "вправо".
А вообще, если хотите плучить конкретный ответ, следует позаботиться, чтобы те, кто может дать такой ответ, имели возможность что-нибудь прочитать на экране. Обычно это делается вставкой текста, а не картинкт. Но если уж картинки - то вставлять такой фрагмент, который не будет масштабироваться.
Люди, подскажите пожалуйста, как правильно считать и записать двухмерный массив в EEPROM ? Перерыл весь интернет, но толкового примера так и не нашел.. :( Задача: Хранить в памяти двухмерный массив. При загрузке считывать из него данные, а так же обновлять их во время выполнения скетча. Данные выводятся на терминальную программу и в графическом виде редактируются.
#include <EEPROM.h>
byte sel = 0,
sel_2 = 0,
inr,
g,
i,
k,
f,
testbyte;
int address = 0;
int address_1 = 0;
byte value;
int bytes[10][16] ;
void setup() {
for (address = 0; address < 10; address = address +1) {
for (address_1 = 0; address_1 < 16; address_1 = address_1 +1){
bytes[address][address_1] = EEPROM[address_1+address];
}}
Serial.begin(57600);
}
void loop() {
Serial.println("Bar ");
Serial.print("\033[36m 0 1 2 3 4 5");
Serial.println();
Serial.println(" Rpm");
for (i = 0; i < 10; i = i +1) {
for (k = 0; k < 16; k = k +1){
bytes[i][k]= constrain( bytes[i][k],10,99);
Serial.print("\033[36m[");
if(i == sel && k == sel_2){Serial.print("\033[32m");
g = bytes[i][k] ;bytes[i][k] = bytes[i][k] + (inr - 1);}
else{Serial.print("\033[37m");}
Serial.print(bytes[i][k]);
}
Serial.println("");
}
Serial.print("\033[0;0H");
Serial.print(" \033]2;map VNT pos.at exht. press.\007");
inr = 1;
if (Serial.available() > 0){
testbyte = Serial.read();
//if(testbyte == 32){ m_munu_flag = 0; }
if(testbyte == 61&& g <98){inr = 2 ;}
if(testbyte == 45&& g >11){inr = 0 ;}
if(testbyte == 39 && sel < 9){sel = sel + 1;}
if(testbyte == 93 && sel > 0){sel = sel - 1; }
if(testbyte == 46 && sel_2 < 15){sel_2 = sel_2 + 1;}
if(testbyte == 44 && sel_2 > 0){sel_2 = sel_2 - 1; }
while (Serial.available()) Serial.read();
}
}
int iBytes[x][y] может быть представлен как byte bBytes[sizeof(iBytes)] , т.е. если взять привести указатель на iBytes к (byte*), то его содержимым такого массива можно оперировать как содержимым одномерного массива размерностью x*y.
Вобще реально рабочий день разработчика ПО 4-5 часов, это уже сто раз обсуждалось. А думать он не перестает все 19 часов. )))
Дополню, с вашего позволения: в эти 4-5 часов не значит, что разработчик ишачит по клавишам шо та дурная обезьяна - он может половину времени сидеть с отсутствующим видом, или - бродить с цыгаркой в зубах. Потому как идёт процесс унутре коробушки, и в этот момент главное - не тыркать :)
А ещё - хуже нет, когда надо "уже вчера", да ещё и без продумывания архитектуры: это тааакой попадос... Вот в эти редкие случаи и приходится делать как просят, а не как надо :) Это такой душевный крик в сторону маркетологов и всяких менеджеров проектов, которые не понимают внутренней сути.
Ага. Складывается ощущение, что ЕвгенийП имеете ввиду 5 часов подряд. Конечно нет! Это же просто никак нельзя, ведь обед - святое!! 5 часов за сутки суммарно.
А если совсем серезно, так 5 часов это максимальное время в течении которого взрослый тренированый человек может концентрировать внимание. Если посадить человека решать простые задачи типа 2+3 то часов через 5 начинает ошибатся сильно чаще. Это такой же физиологический факт, как возможность тренированого поднять 200кг, и не поднять 500. У нетренированых все понятно хуже.
А можно вопрос дилетанта?
Вот просто интересно. Если надо хранить какие-то данные в энергонезависимой памяти и тут кого-то может напугать гарантийное ограничение в 10.000 циклов, почему тогда не хранить эти данные, тупо, на SD?
И еще один вопрос: этот "EEPROM" и та область памяти, куда пишется сам скетч - в чем между ними отличия?
Я так понимаю что те 32кб, куда пишется скетч предназначен только для скетча. Как бы - винчестер, "EEPROM" - только для хранения каких-то величин, созданных скетчем и которые не должны быть утеряны после отключения питания. Типа - флешка или тоже винчестер с произвольным доступом из самого скетча. Кроме того есть еще где-то область памяти для оперативных расчетов. Такой себе "RAM".
Память программ - не "винчестер" ни разу. Больше как раз соответсвует ОЗУ "команд" с практически запрещенной записью. Ибо даже несколько шустрее чем собственно "такая себе рам" для вычислений: команда из памяти команд считывается за 1 такт 2 байта, а "так себе рам" читает 1 байт за 2 такта .. Да, и памяти команд чутка поболее: 256 килобайт. Против 8 килов "для вычислений и стека". :)
А вот ЕЕПРОМ - ваше ни разу не "с произвольным доступом", а как раз таки "а-ля винчестер" с последовательным: хочешь байтик? Скажи откуда.
SD и прочие "внешние" винчестеры по SPI или чему ещё тут не рассматриваются по причине их внешности к кристаллу, а соответственно своей исключительной тормознутости и необходимости "городить огород". Как понимаю, вопрос как и как долго (мой) можно заюзать то что есть на самом кристалле. Вясняется что Не очень и долго, ежели стараться. :(
Ну тогда всё как я и думал: ардуина это такой себе самодостаточный мини-компьютер со своим CD-ROM для скетча, EEPROM-последовательным винчестером и небольшой RAM... И вся фишка в том, что бы использовать эти возможности, не цепляя ничего извне, не "городя огород" и оставляя как можно свободных пинов именно для датчиков и исполнительных цепей, для которых они все, собствтенно, и предназначены.
Ну тогда всё как я и думал: ардуина это такой себе самодостаточный мини-компьютер
Правильный термин SOC-система (System On Crystall)
Замечательный вывод, поздравляю.
Да, именно так: это полноценная SoC система (1кристальный МК), но даже ещё "однокристальнее": на борту есть куча "периферии", которая как раз и предназначена для УПРОЩЕНИЯ управления. То есть, не надо городить и "программные огороды" тоже .. вся "программная эмуляция" - от непонимакния что Atmel - это SoC в квадрате. :)
То есть, не надо городить и "программные огороды" тоже .. вся "программная эмуляция" - от непонимакния что Atmel - это SoC в квадрате. :)
ебануться!
То есть, не надо городить и "программные огороды" тоже .. вся "программная эмуляция" - от непонимакния что Atmel - это SoC в квадрате. :)
ебануться!
Вот оно - искуство ТЗ )))
На основании расплывчатого пожелания высказаного в чисто гуманитарной, образной форме, причем форме отрицания, с использованием только что придуманой терменологии, понятныой только автору да и то только во время произношения делается краткий и предельно конкретный вывод о работе, которую нужно выполнить для достижения результата )))))
делается краткий и предельно конкретный вывод о работе, которую нужно выполнить для достижения результата )))))
делается эмоциональная оценка шизофренической пурги, которая бушует в голове оппонента.
делается краткий и предельно конкретный вывод о работе, которую нужно выполнить для достижения результата )))))
делается эмоциональная оценка шизофренической пурги, которая бушует в голове оппонента.
Вот оно - исскуство самокритики.
Ну тогда всё как я и думал: ардуина это такой себе самодостаточный мини-компьютер
Правильный термин SOC-система (System On Crystall)
Еще одна монетка в копилочку. Спасиб.
Вот оно - исскуство самокритики.
дятел, включи мосги - нахуя мне публиковать самокритику?
если это самокритика, то я космонавт, сбитый турками.
Вот оно - исскуство самокритики.
дятел, включи мосги - нахуя мне публиковать самокритику?
если это самокритика, то я космонавт, сбитый турками.
Во первых: я с "тобой" свиней не пас, поэтому попрошу без перехода на личности.
Во вторых: откуда я знаю с чего это "тебе" вздумалось нести чушь в свой адрес? Это вопрос не ко мне. В зеркало иди загляни и повтори туда.
В третьих: "Космонавт сбитый турками" на порядок порядочнее и более желателен как собеседник. И отсюда -
В четвертых: если Вы думаете (в чем я сильно сомневаюсь) что я буду продолжать полемику с каждым вонючем троллем, встреченным в инетах, так Вы так уже не думайте.
Во первых: я с "тобой" свиней не пас, поэтому попрошу без перехода на личности.
Во вторых: откуда я знаю с чего это "тебе" вздумалось нести чушь в свой адрес? Это вопрос не ко мне. В зеркало иди загляни и повтори туда.
В третьих: "Космонавт сбитый турками" на порядок порядочнее и более желателен как собеседник. И отсюда -
В четвертых: если Вы думаете (в чем я сильно сомневаюсь) что я буду продолжать полемику с каждым вонючем троллем, встреченным в инетах, так Вы так уже не думайте.
Подниму старую тему.
Мне нужно хранить в энергонезависимой памяти битувую переменную (флаг управления):
Вопросы:
1. Правильно ли написан код?
2. Знаю что циклы записи ограничены - писаться будет по нажатию кнопки. А чтение из еепрома тоже ограничено?
3. Обязательно ли для еепрома применять переменную типа byte или можно boolean?
Lomonosov . Для записи, чтения, обновление рекомендую использовать
update()
get()
put()
Уважаемые форумчене, прошу Вас подсказать как можно сохранить строку с набором символов (с номером телефона) в память EEPROM?
Есть предположение разбить на символы и преобразовать их и int (командой n.length()), посоветуйте пожалйста как сделать.
Есть предположение разбить на символы и преобразовать их и int (командой n.length()), посоветуйте пожалйста как сделать.
Неверное предложение. String надо переводить в char ,а чары побайтно пихать в память http://arduino.ua/ru/prog/StringToCharArray
Блин, qwone, ну от Вас не ожидал! Зачем ещё один буфер заводить и дублировать туда строку? Она же совершенно спокойно адрес родного буфера возвращает (метод c_str()).
update()
get()
put()
Большое спасибо за помощь, получилось, работает.
Ну, может, конечно и работает ("может" - потому. что прдробно не смотрел), но при двух условиях
1) длина строки не более 255 символов
2) Вам совсем не жалко Вашу Ардуину и Вы готовы убить её ускоренными темпами
:)
1) длинна строки не будет превышать 255 символов, т.к. используется только для номера в международном формате.
2) жалко конечно, но других вариантов я не нашел, к сожелению....
2) жалко конечно, но других вариантов я не нашел, к сожелению....
Так Вы поищите.
Вот что у Вас делает 18-ая строка внутри цикла по i? Она как-нибудь от i зависите? Если нет. то что она делает внутри цикла? Для чего она там?
Хотите я отвечу? Она там для того, чтобы длину строки записать в нулевую ячейку не один раз а столько раз, сколько символов в Вашем номере.
Нафига? Это только Вы знаете.
Думаете записать длину один раз недостаточно?
Кроме того, номера телефонов такая вещь, что очень часто на одни и те же места будут попадать те же самые цифры (типа +7495...). так нафига их перезаписывать? Используйте update вместа write и они не будут перезаписываться. Е ещё проще просто используйте нотацию массива.
Запись в еепром: EEPROM[addr] = value;
Чтение из еепром: byte b = EEPROM[addr];
Уберите многократную запись длины и замените write на update - всё станет гораздо кошернее.
Спасибо за дельный совет, согласен с Вами полностью, буду переделывать
Слетает байт в еепроме. Упрощенный код такой:
Полный код в теме:
http://arduino.ru/forum/proekty/upravlenie-zakrytiem-dverei-avtomobilya-...
Два месяца все работало как часы. Но теперь стал замечать, что после выключения/включения питание байт UPR может сам сбрасываться не в ноль (конкретно не смотрел что туда прописывается, т.к. плата спрятана под торпедой). Вкратце на "событие" реагирует адекватно, делает "действие 1", и либо делает "действие 2", или перестает его делать. Если выключить когда в UPR была записана единица, то при включении всегда делается "действие 2", т.е. единица не сбрасывается, или сбрасываетя в любое другое значение, но не нулевое.
А если выключить когда в UPR был записан ноль, то при включении может начаться выполнение "действие 2", т.е. UPR считывается как не ноль.
Что может быть? Может я "нехорошую" ячейку с нулевым адресом выбрал для хранения UPR и она может случайно перезаписываться иными аппаратными функциями?
При компиляции всего скетча расход ресурсов таков:
Скетч использует 2866 байт (9%) памяти устройства. Всего доступно 30720 байт.
Глобальные переменные используют 59 байт (2%) динамической памяти, оставляя 1989 байт для локальных переменных. Максимум: 2048 байт.
Ресурс EEPROM - 100000 циклов.
Это мне известно. По адресу 0 я произвел пару десятков записей во время отладки. И по две записи каждые две недели (это максимум) в течении двух месяцев. Итого 20+2*4=28. Ну пусть даже три десятка. Всё, память просится на кладбище?
1. Это может быть из-за температуры эксплуатации (под торпедой авто может нагреваться до 60°С)?
2. Это может быть связано с адресом переменной (первая ячейка с номером 0)?
3. Это может быть связано с хранением булиевого значения в переменной типа байт?
Это мне известно. По адресу 0 я произвел пару десятков записей во время отладки. И по две записи каждые две недели (это максимум) в течении двух месяцев. Итого 20+2*4=28. Ну пусть даже три десятка. Всё, память просится на кладбище?
1. Это может быть из-за температуры эксплуатации (под торпедой авто может нагреваться до 60°С)?
2. Это может быть связано с адресом переменной (первая ячейка с номером 0)?
3. Это может быть связано с хранением булиевого значения в переменной типа байт?
Вариант 1 возможен, но маловероятен, 2 и 3 исключаются если кристал не подвергался экстремальным воздействиям температуры и напряжения. Стоит проверить источник питания процессора (выбросы, просадки напряжения) добавить дроссель, конденсаторы, бортовая сеть авто это большая кака. Запись в EEPROM у Вас в лупе идет по условию, а если процессор дуркует из-за сбоев по питанию то говорить что за 2 два месяца всего было 30 записей в EEPROM вряд-ли можно.
2 совета
1. Не пишите ничего в EEPROM по первым адресам, так как есть известные проблемы порчи данных по этим адресам при снятии/просадке питания. Начинайте осмысленное использование EEPROM с адреса 0х10.
2. Считайте контрольную сумму EEPROM (своего записанного блока) при старте программы, тогда неприятность можете отловить раньше, а не тогда когда она уже случилась. Чтение из EEPROM на ее ресурс не влияет.
2 совета
1. Не пишите ничего в EEPROM по первым адресам, так как есть известные проблемы порчи данных по этим адресам при снятии/просадке питания. Начинайте осмысленное использование EEPROM с адреса 0х10.
2. Считайте контрольную сумму EEPROM (своего записанного блока) при старте программы, тогда неприятность можете отловить раньше, а не тогда когда она уже случилась. Чтение из EEPROM на ее ресурс не влияет.
0х10 - это с 17-го?
На конрольную сумму натыкался в форуме. Но не могу осознать как сделать контрольную сумма на битовое данное принимающее значение 0 / 1. К тому же контрольная сумма не поможет восстановить утерянное значение. Приходит мысль записывать значение бита как не тривиальное значение байта (например 107 / 230) в три ячейки одновременно (или больше) и считывать значения которые повторяются в этих ячейках. Если повторов нет, то всё - фаталеррор, узнать ранее записанное значение невозможно.
Код накидался такой
2 совета
1. Не пишите ничего в EEPROM по первым адресам, так как есть известные проблемы порчи данных по этим адресам при снятии/просадке питания. Начинайте осмысленное использование EEPROM с адреса 0х10.
0х10 - это с 17-го?
http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_eeprom_corru...
1. Не пишите ничего в EEPROM по первым адресам, так как есть известные проблемы порчи данных по этим адресам при снятии/просадке питания. Начинайте осмысленное использование EEPROM с адреса 0х10.
Если можно, сылку на даташит, где есть различие в работе EEPROM с адреса 0x00 и после 0x10
Различия как такового нет, есть особенность AVR портить EEPROM. Чаще всего это адрес 0. Поэтому я на всякий случай не использую адреса до 0х10, чего и посоветовал. Ссылка на AVR FAQ ровно постом выше Вашего.
Здравствуйте, нужна помощь.
Чтение и запись в EEPROM. Опишите последовательность действий, которые необходимо выполнить, чтобы обеспечить запись данных в ячейку внешней памяти. Приведите фрагмент программного кода.
Чтение и запись в EEPROM. Опишите последовательность действий, которые необходимо выполнить, чтобы обеспечить чтение данных из ячейки внешней памяти. Приведите фрагмент программного кода.
Распишите пожалуйста.
Какой смысл еще раз расписывать то, что уже сотни раз расписано?
Куда уходит остаток при деление числа 8654 на 4?
на склад. в ячейку остатков деления на 4.
можнопо подробнее про эту ячейку
Чтение и запись в EEPROM. Опишите последовательность действий, которые необходимо выполнить, чтобы обеспечить запись данных в ячейку внешней памяти. Приведите фрагмент программного кода.
Чтение и запись в EEPROM. Опишите последовательность действий, которые необходимо выполнить, чтобы обеспечить чтение данных из ячейки внешней памяти. Приведите фрагмент программного кода.
Очень похоже на задание для нерадивого студента. Щас все прям кинуца исполнять, да прям с основ всё тебе разжовывать.
Щас все прям кинуца исполнять, да прям с основ всё тебе разжовывать.
не все, а Винипух своих классов во все отверстия навтыкает бесплатно.
Ну, Пух-то дааа....
Куда уходит остаток при деление числа 8654 на 4?
Обычно деление на степень двойки реализуется сдвигами. Поэтому ответ: "вправо".
А вообще, если хотите плучить конкретный ответ, следует позаботиться, чтобы те, кто может дать такой ответ, имели возможность что-нибудь прочитать на экране. Обычно это делается вставкой текста, а не картинкт. Но если уж картинки - то вставлять такой фрагмент, который не будет масштабироваться.
Люди, подскажите пожалуйста, как правильно считать и записать двухмерный массив в EEPROM ? Перерыл весь интернет, но толкового примера так и не нашел.. :( Задача: Хранить в памяти двухмерный массив. При загрузке считывать из него данные, а так же обновлять их во время выполнения скетча. Данные выводятся на терминальную программу и в графическом виде редактируются.
int iBytes[x][y] может быть представлен как byte bBytes[sizeof(iBytes)] , т.е. если взять привести указатель на iBytes к (byte*), то его содержимым такого массива можно оперировать как содержимым одномерного массива размерностью x*y.
Люди, подскажите пожалуйста, как правильно считать и записать двухмерный массив в EEPROM ?
Точно также, как и трёхмерный, как и одномерный, и как и всё остальное.
В чём проблема-то?
Люди, подскажите пожалуйста, как правильно считать и записать двухмерный массив в EEPROM ?
Точно также, как и трёхмерный, как и одномерный, и как и всё остальное.
В чём проблема-то?
Дык, не я шаман - это же всё описано в документации на домашнем сайте ардуино. RTFM, так cказать :)
Вот так обычная наука превращается в черную магию...