Ви не увійшли.
Интересно, какие именно ограничения накладывает использование слова struct по сравнению с использованием слова class?
А чем плохо использование мотыги в сравнении с трактором?
Правильно разбивать задачи на подзадачи, а не пытаться все сделать сразу при чем мудрённым путем когда в этом нет никакого смысла.
В коде в посте #19 явно видно что нет обновление T.Start= millis() именно по этому он не рабочий.
И кроме всего он еще не совсем ожидаемый, зачем ограничиваться структурами когда есть классы, зачем volatile?
ПоТамушта HTTP протокол, есть заголовки(headers) и тело(body). Заголовки идут строками(lines, т.е по разделителю CRLF). Соответственно логично анализировать именно по строкам, по крайней мере пока идут заголовки, тело потом можно читать как надо/угодно, но вообще в данном случае как правило можно тупо отбрасывать, игнорировать так как все интересное у нас содержится в самом URL в параметрах.
Вы имеете ввиду про сложение вместо вычитания?
С вычитанием должно нормально работать.
А читать по байтику не зависнет? Не несите чушь.
Ведь все равно нужен буфер куда складывать и все равно нужно читать до перевода строки.
У Вас бывает период больше чем в ~50 cуток? Нет никакой проблемы переполнения.
Так размер буфер нужно подбирать.
И именно поэтому стоит использовать Mega вместо UNO.
Если не ошибаюсь в строке HTTP запроса обычно не более 127 символов (Лучше посмотреть RFС) что должно вполне хватать под буфер для построчного чтения.
Тогда проблема не понятна.
Выводить значения на lcd наверное все же стоит в таймере, а не в loop что бы не наблюдать "скАчки"
Да и сам вывод наверно стоит оптимизировать как-то.
Но это конечно пустяки.
Если они крутят руками то думаю проблем не должно быть, но если там двигатели то проблемы вполне возможны.
И тут как ни "подталкивай" (без понятия что Вы имеете ввиду)
Я делаю примерно так:
//------------------------------------------------------------------------------
void serverLoop()
{
EthernetClient client = server.available();
client.setTimeout(10000);
if (client)
{
while (client.connected())
{
workWithClient(client);
client.stop();
}
}
}
//------------------------------------------------------------------------------
void workWithClient(EthernetClient& client)
{
// Read headers and get filepath
String path;
String content;
String token;
HttpMethod method;
while (client.available())
{
const int length = client.readBytesUntil('\n', buffer, bufferSize - 1);
if (length <= 0)
break;
buffer[length] = '\0';
String line = String((char*)buffer);
line.trim();
if (line.startsWith("GET"))
{
method = httpGet;
path = extractFirst(line, "GET", "HTTP");
path.trim();
}
// Дальнейшая обработка используя extractFirst
// ...
}
}
//------------------------------------------------------------------------------
String extractFirst(const String& text, const String& startWord, const String& endWord)
{
const int startIndex = text.indexOf(startWord);
if (startIndex == -1)
return String();
int endIndex = text.indexOf(endWord, startIndex);
if (endIndex == -1)
return text.substring(startIndex + startWord.length());
return text.substring(startIndex + startWord.length(), endIndex - startIndex);
}Может нужно задействовать сдвиговые регистры или побольше светодиодов?
Может нужно наконец задействовать мозг ?
Всякие "переходники-расширители" могут не поспевать опрашивать.
Тут ли нужно брать Mega или выдумывать свою схему на триггерах что бы подавить дребезг и уменьшить исп. кол-во контактов.
Контакты:
Icq: 673574224
E-mail: avazart.fl@gmail.com
Отзывы:
Kwork (мой профиль)
Киберфорум(моя тема с отзывами)
Клуб программистов(моя тема с отзывами)
Да дело в том что код по примерам - не лучший. Так непонятная фигня с чтением по одному байту и отловом конца строки.
Кроме того UNO для таких вещей маловато, лучше брать MEGA + модуль SD картридер.
С UNO будут проблемы как со свободными пинтами так и с объемом памяти. А при превышении памяти могут быть разные глюки в том числе подвисания.
В обще не практичная связка, как правило практичнее сразу брать ESP12E (NodeMcu, Wemos) и конектица в WiFi роутеру.
Кроме того есть новая плата ESP32.
Avazart пише:зачем еще один транзистор, если он там уже и так есть
На входе оптрон, транзистор после.
И что? Это как-то мешает запитать модуль от 12 В и управлять им ардуинкой?
Да схему нужно смотреть что бы ничего не спалить.
"Шидко" тоже понятие относительное. Но тут явное ограничение по скорости I2C интерфейса.
Контакты:
Icq: 673574224
E-mail: avazart.fl@gmail.com
Отзывы:
Kwork (мой профиль)
Киберфорум(моя тема с отзывами)
Клуб программистов(моя тема с отзывами)
Купить мосфет/оптрон/транзистор/резистор и спаять ту схему на макетке которая нужно тебе.
зачем еще один транзистор, если он там уже и так есть
На входе оптрон, транзистор после.
и минут через 10 понял что мое реле по идее с управляющим сигналом в 12 в верно?
Надо было покупать на 5V тогда такой проблемы не было бы. А еще стоит интересоваться на какое логический уровень срабатывает реле на HIGH или LOW (в конкретном в данном реле есть перемычка что бы задавать) и смотреть что бы был оптрон и диод.
Все это не имеет никакого отношения к "гальванической развязке".
Контакты ЭК (или контакты реле) зашунтируйте диодами в обратной полярности что бы избежать подгорания (залипания) контактов реле.
Сам то поняли что сказали? Явно что-то не то.
первую очередь имел ввиду миниПК типа "малинки" а на них как правило работают ОС на базе ядра Linux, и КОНТРОЛЛЕРЫ построенные на их базе.
Может и так, но в написанном миниПк Вы поставили рядом с контроллерами.
И еще скромный вопрос, зачем "козе баян"? В смысле бу упсу оригинальные батареи?
А какие нужны? Такие же полудохлые с Китая?
Я лажанулся, по ошибке не в тот пост, не в той теме добавил
Есть вообще какие-то весомые преимущества перед модулем на трансформаторе тока?