• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Возможна ли запись в файл на "малом ВебСервере"?

saho

New member
Привет всем труженикам . Вопрос , собственно из названия темы . Понимаю , что записывать данные в файл , скажем data.txt , скомпилированном и залитом во флеш малого вебсервера вряд ли можно , но возможно кто то решал проблемму записи результатов измерений датчиков в файл на сервере для последующего создания логов и построения графиков мониторинга ?
 

pvvx

Активный участник сообщества
Для логов и мониторинга обычный файл не эффективен для Flash. Применяют кольцевой буфер и представление его как файла. Полная зависимость от типа носителя. Для применяемой SPI-flash выделяют большой непрерывный кусок и пишут в него последовательно, по кругу, с меткой времени или номером. При старте находиться самый старый и последний записанный блок - это и будет началом и концом файла.
Обычно буфер содержит объем на N дополнительных замеров, которые вычитаются из динамических указателей на начало и конец файла, с расчетом на стираемый сектор для новой записи и что за время работы с файлом новые записи не затрут "начало"...

Ну а т.к. у большинства используются Flash с малым размером (менее 4 МБ), исходных кодов не опубликовано – нет смысла, кроме протирания дырки в таких flash для задач с реальными датчиками и дискретности сохранения лога в хотя-бы раз в минуту.
 
Последнее редактирование:

saho

New member
...спасибо за ответ . Внимание занятого человека на сегодня дорогого стоит . Однако простого ответа на мой вопрос нету . Побродив предварительно по форуму , понял , что и SD карту подружить с ESP вебсервером пока проблематично . Печально - я понадеялся , что можно поселить на борт прибора с UARTом ESP вебсервер и мониторить датчики с прорисовкой графиков - благо имеется чертовски простой набор инструментов :
grafic.zip
В связи с такими обстоятельствами очень прошу ответить на следующие вопросы :
1.
ESP вебсервер не понимает РНР и python ?
2. Как достучаться до сервера с наружной сети , потому что он отвечает , что нету файла ? На форуме читал про измененние значения МТU и последующую компиляцию , а нельзя ли изменить МТU на роутере - в моём так :
mtu.jpg .
3. Существует ли переменная , в которой хранится строка буфера с UARTа , что бы её можно было использовать в последующем ?
 

Вложения

pvvx

Активный участник сообщества
В связи с такими обстоятельствами очень прошу ответить на следующие вопросы :
1. ESP вебсервер не понимает РНР и python ?
Нет. Парсинг выходящих файлов со вставкой значений переменных и команд - имеется. Кодировка переменных у всех разная.
2. Как достучаться до сервера с наружной сети , потому что он отвечает , что нету файла ? На форуме читал про измененние значения МТU и последующую компиляцию , а нельзя ли изменить МТU на роутере - в моём так :
mtu.jpg .
MTU не влияет на "нету файла". Изначально ставится необходимый размер MTU, проект собирается и всё работает.
Нету файла - обычно это значит, что не записан Web-диск. Ограничение MTU сказывается по другому...
3. Существует ли переменная , в которой хранится строка буфера с UARTа , что бы её можно было использовать в последующем ?
В моем варианте web-сервера такого нет. Причина в многопользовательском варианте, а UART не поддерживает адресацию (привязку пакетов ответов и запросов к пользователю), а так-же разграничений на блоки приема-передачи. Это всё возможно только при навешивании протокола уровнем выше. Стандартных протоколов по этому делу нет, поэтому пользователь должен описывать его сам. Так-же возникает множество неопределенностей из-за разного типа - UART это поточное устройство, а WiFi - блочное. Так-же WiFi требует использование RTS/CTS сигналов, говорящих о активности соединения внешнему устройству и возможности приема-передачи...
Есть вариант из стандартных, но уже не UART, а Modbus RTU с RS-485 и там протокол работает блоками с идентификаторами транзакции (к каждому запросу-ответу) (существует в стандарте для варианта Modbus TCP и поддерживается в ModBus TCP реализации) и адресацией устройств...
 

saho

New member
...первое - понято . Третье - понято , буду рыть в сторону Modbus TCP . А вот второе ... Из наружной сети из всех страниц меню доступны только эта :
Остальные - соответственно "Page not found" . В локальной сети всё работает , по 12345 порту данные UART получаю (удалённо) , а к ВЕБ доступа нету . Может чего то упускаю ?
 

Вложения

rst

Member
Ну а т.к. у большинства используются Flash с малым размером (менее 4 МБ), исходных кодов не опубликовано – нет смысла, кроме протирания дырки в таких flash для задач с реальными датчиками и дискретности сохранения лога в хотя-бы раз в минуту.
Даже если раз в минуту писать, это не значит раз в минуту стирать. На одно стирание может быть много операций записи если один элемент журнала лога кольцевого буфера имеет небольшой размер. Одна запись с какого-нить датчика вполне может быть всего пару байт. А уж если данные с такого датчика меняются медленно, то и вообще можно дельту считать (например), а полученные значения упаковывать оптимально (в битовый поток) с учётом размера полученной дельты.
В пределе (если например это датчик температуры/давления/etc с отброшенными ненужными младшими разрядами), при неизменных его показаниях, можно получить всего 1 бит на один замер.
А временнЫе метки не нужны если например измерения идут с одним периодом от одного источника тактирования. Можно периодически (раз в неск. суток в зависимости от требуемой точности времени лога и точности используемого тактирования) запрашивать время с SNTP, писать его дополнительно в лог и потом, при отображении данных, пересчитывать временнЫе метки исходя из этих точек синхронизации.
Итого: даже если возьмём флешь 4 МБ (типичный размер секторов стирания в такой флешь - 4кБ) и допустим должны быть 2 стёртых сектора в кольце и писать будем 1 раз в минуту 2 байта данных (без сжатия), то:
(4*2^20-4*2^10*2)/2/60/24/365 = 3.982 - одного кольца лога хватит на почти 4 года.
А теперь умножим на ресурс страницы этой флешь по стиранию - получим, что устройство сможет доработать до далёких потомков автора через много-много поколений. :eek:

PS: Да и если уж так нужно часто писать в лог, то можно вместо FLASH применить FRAM.
Как-то делал проектик на MSP430FR5739 (он вместо FLASH программ имеет FRAM программ/данных) . Он работал от батарейки и писал в лог во FRAM каждые несколько минут температуру/давление/влажность/напряжение. Кольца лога хватало примерно на неделю. Даже с учётом того, что FRAM всего-то там 16кБ и часть её занята кодом.
 
Последнее редактирование:

vad7

Active member
saho, все зависит от ваших возможностей в программировании.
Вот график по данным из флеши esp8266 (кольцевой буфер):
upload_2017-5-19_10-27-17.png

Вот функция пере-записи файла на вебдиск (без увеличения его размера):
PowerMeter-IrDA/webfs.c at master · vad7/PowerMeter-IrDA · GitHub
Ее можете дописать, при необходимости, под ваши нужды.
 

pvvx

Активный участник сообщества
Даже если раз в минуту писать, это не значит раз в минуту стирать.
Угу - для людей имеется в виду стандартное время кольцевого буфера для таких систем - 1 год. Устройство, кроме данных пишет ещё всякие флаги. Итого, обычно, для малого устройства записывайемый блок, для кратности, выходит 32 байта. Вот и считайте - получите 5 минут и flash более 4-х MБ c учетом размещения всех скриптов и HTTP на web-диске в ней-же.
Один байт никто не пишет, т.к. данные с таким разрешением никому не нужны.
Некоторые флаги нужны обязательно - для подтверждения валидности записи (во время записи значений произошло отключение питания и данные не корректны - флаг валидности пишется после проверки записи...). Другие для ускорения алгоритма выборки и поиска нужной по дате и времени. Плюс состояние системы и желательно весовые коэф. для усредненных значений с уточнением пропусков замеров за период и всяких ошибок в системе. Иначе это не измеритель, а игрушка. В отказоустойчивой системе один из датчиков может быть сломан, а остальные корректны и это не должно приводить к отказу от логирования...
На практике всё это замечательно упаковывается в блок записи от 32 до 64 байта, если логируется до десятка датчиков и счетчиков... Т.е. все эти накладные расходы оправдываются. А запись в два байта никому не нужна.
Ну и т.к. лог годовой, то запись по одному адресу происходит один раз в год и о дыре в flash можно будет поговорить спустя 1000 лет. :)
Посчитайте разницу в цене flash в 16 МБ и 4 МБ и опросите пользователя – готов ли он оплатить эту разницу для увеличения буфера до года. Всегда получите ответ – да, т.к. разница в центах или менее банки самого дурного пива (кому что). :)
 
Последнее редактирование:

rst

Member
Один байт никто не пишет, т.к. данные с таким разрешением никому не нужны.
И какая связь между разрешением данных объёмом одной записи? Что такое алгоритмы сжатия - в курсе? Это когда одна последовательность бит (более длинная) может быть заменена другой последовательностью (более короткой) из словаря.
А в простейшем случае - можно просто вычислять дельту и полученное значение меньшей разрядности упаковывать в битовый поток.

Некоторые флаги нужны обязательно - для подтверждения валидности записи (во время записи значений произошло отключение питания и данные не корректны
Это не обязательно. В зависимости от аппаратной поддержки.
1. Устройство может содержать супервизор питания, заранее предупреждающий об аварии питания.
2. Устройство может содержать другой тип энергонезависимой памяти (FRAM/MRAM/батарейную RAM/RAM с внутренним супервизором питания и флешкой, куда сбрасывается при аварии/...). Тогда перед модификацией FLASH создаём бэкап-запись в этой памяти, модифицируем FLASH, удаляем бэкап-запись). При старте ПО проверяем наличие бэкап-записи и, если есть, проводим корректировку FLASH.
Это гораздо удобнее чем получить кольцевой массив из валидных/битых записей и разбираться потом со смещениями записей.

Другие для ускорения алгоритма выборки и поиска нужной по дате и времени.
Если кольцо состоит из одинаковых блоков, то для быстрого поиска никакие дополнительные флаги не нужны. Раз известно, что минимальный размер распределения памяти под кольцо - один блок стирания, то просто просматриваем заголовки всех этих блоков, пока на найдём два блока, между которыми находится искомая дата. Количество блоков стирания во флешь невелико - поиск займёт очень мало времени. да и таблицу можно в ОЗУ держать, создаётся в ОЗУ после старта за неск. мсек.

Плюс состояние системы и желательно весовые коэф.
А если ни то ни другое не нужно? o_O

один из датчиков может быть сломан, а остальные корректны и это не должно приводить к отказу от логирования...
Зарезервировать одно значение под спец. состояние - никак? ;)

На практике всё это замечательно упаковывается в блок записи от 32 до 64 байта,
Какие-то среднепотолочные цифры... А почему не 33 и 65? :confused:
Размер записи должен быть таким, какой нужно. У меня бывали журналы (во вполне себе коммерческих изделиях) с размером записи 8 байт. 4байта - метка времени + 2 байта - полезные данные + 2 байта - CRC. И что не так?
А можно было и меньше сделать.

Посчитайте разницу в цене flash в 16 МБ и 4 МБ и опросите пользователя – готов ли он оплатить эту разницу для увеличения буфера до года. Всегда получите ответ – да
Да уж.... А Вы когда-нить разрабатывали серийное изделие? Это которое хотя-бы по несколько десятков тысяч шт в год выпускается?
Так вот - там экономят даже на разъёмах копеечных и на резисторах. И каждую неделю совещания собираются и обсуждается очередное предложение по замене краски для маркировки на более дешёвую. Или как более оптимально и с меньшими затратами времени вставлять один разъём в другой. И проверяются разные способы с секундомером :eek:
А уж реализовывать поддержку в изделии разных чипов FLASH с разной ёмкостью в зависимости от заказанных заказчиком функций - мне приходилось делать лично. И это было только ради экономии. Потому что пользователь как раз как правило выбирает более дешёвое. Ну если речь не идёт об айфоне :D
 
Последнее редактирование:

pvvx

Активный участник сообщества
А если ни то ни другое не нужно? o_O
Значит это игрушка.
Да уж.... А Вы когда-нить разрабатывали серийное изделие?
Вы за кого меня держите? На ESP8266? :) ?
Зачем их разрабатывать, если они уже более 20 лет трудятся (?), некоторые непрерывно (без отключений) более 10 лет... Сложно посчитать сколько их активных в данный момент, т.к. информация с них поступает во внутреннюю сеть предприятий.
При начальной стоимости всего оборудования куда они входят от нескольких лимонов краску мы не считаем уже более 25 лет...
Пересогласование с заказчиком - это уже сотни тысяч рублей и какой нафиг таймер?:)
Маржи от пересогласования хватит на тысячу устройств - столько нет предприятий в России :)
Какие-то среднепотолочные цифры... А почему не 33 и 65? :confused:
Потому, что кратно сектору и проверку перехода на новый сектор для его стирания делать проще...
В общем понятно - у вас пока мечты и мечты, о серийном девайсе на ESP8266 :) Я подсталом :)

Откуда берется 1 год - вы наверно не догадываетесь, что это стандартный гарантийный срок. А устройство может быть обесточено или не иметь непрерывный режим эксплуатации, по тому пустых блоков за время отключенного состояния оно не пишет и первоначальный поиск осуществляется не за несколько мкс, даже если стоит FRAM. А она стоит всегда, т.к. требуются графики текущих показаний на производственный цикл с дискретом от 1 сек (и то только для сервисного персонала). Статистика при этом точнее 5 минут никому не требуется. Пока не встречал, тем более в домашних применениях. Средние за пол часа - самый тот размерчик для логов :) Успешно годиться для наказаний смены, эксплуатирующей установку. Да и распечатка более чем среднее за час на лист не влезает, чтобы посмотреть как тама работнички работали... Смены на заводах России обычно около 8 часов, на печатном листе сколько строк - смотрите справочники, начальники появляются не чаше одного раза в сутки... А без распечатки пальчиком тыкать некуда - тыкать в очко айфона? :)
Супервайзер на питание и поддержка на время записи сектора стоит гораздо более увеличения Flash и простой FRAM. А как известно, чем система проще, тем меньше ошибок и отказов.
Тем более вы забываете, что кроме аналоговых значений всегда пишутся и дискретные.
Вам домашнее задание - логгер для бытового холодильника. Основные цели и назначение - снятие сервисных и эксплуатационных характеристик для производителя и отказа от гарантии пользователям. :) Посмотрим, как вы в 8 байт всё вместите :) :)
А пока ваши выдумки походят на желание продаж каких-то игрушек на али, или подпольного производства на кухне алкоголиками. Там наверно действительно надо считать краску и искать разъем… Тем более где спорят о краске, там программисту и разработчику ничего не платят...
Всё это завязано на других принципах выживаемости предприятия в России. Или вы даете местные рабочие места, или пролетаете, или работаете на зарубежного заказчика и выезжаете к нему навсегда – там и будите экономить на байтах и краске :)
----
Как правило, в сетях DIY отсутствуют товары премиум-сегмента: вся линейка подбирается в определенном ценовом диапазоне (low cost и medium). Эксперт: Российский рынок DIY остается одним из самых привлекательных

А проще сказать, что там продают одно г… и в сегменте электронных устройств только китайщину, которую и разрабатывают там местные аборигены, под условия производителя-штамповщика.

По этой причине получить какую-то прибыль разработчику в данном сегменте, в России, нет возможности. Всю прибыль получит продавец и он напрямую заинтересован в неоплате разработки. Для этого существует масса методов, в том числе законных :). Поэтому никакого серийного изготовления электроники, да ещё по описываемым вами принципам в России не существует. Семью вы не прокормите с такими критериями.

В сегменте, где можно заработать на разработках, никогда не поставят ESP8266. На диком западе для аналогичного логгера быстрее поставят какой многоядерный проц и дорогущие пром. исполнения PCMCIA карты, что выльется в сотни раз дороже, чем упрощенная и описываема тут система. Далеко ходить не требуется – рассмотрите данный сегмент сами. :p

Это полный ответ на ваши заявы о серийном производстве и логгере :)

Тему логгеров для приборов измерения, особенно переносных, тут не затронута, но и c ними есть более 25-летний опыт :) :p

Это всё не к качеству программ, алгоритмов и прочего – а к целесообразности и получаемому итого.
 
Последнее редактирование:

saho

New member
@vad7
Вот функция пере-записи файла на вебдиск (без увеличения его размера): [URL='https://github.com/vad7/PowerMeter-IrDA/blob/master/app/web/webfs.c#L442' написал(а):
PowerMeter-IrDA/webfs.c at master · vad7/PowerMeter-IrDA · GitHub[/URL]
...
...огромное спасибо уважаемый друг за эти материалы . Буду пытаться приспособить . Если коротко , использовав этот код , можно организовать процедуру цикличной перезаписи файла с обновляемыми данными на диске ?
 

saho

New member
@pvvx и @rst , мне очень , очень интересно ваше обсуждение нюансов разработки и внедрения в России , правда , но давайте помнить , что причины применения ESP в наших работах различны и не будем смешивать дела серьёзные и "тамагочи" . Предлагаю постепенно , но стремительно вернуться к обсуждению вопроса . Я понимаю, что для вас это уже не вопрос , но для нас , рядовых граждан этого мира , сей , на первый взгляд простой девайс , хранит много тайн.
1 . Итак , обнаружил такую возможность - если делать некое колличество раз запрос http://192.168.1.130/web.cgi?hexdmpb0x60000000=1 , то по этому адресу(0х60000000) , по одному символу будут считываться мои данные из UART . Сколько раз сделать запрос , столько символов получим . Нужно только оформить эту конструкцию в цикл и из символов определённого порядкового номера создать строку .
2. Теперь вопрос - как использовать для этого прямую команду ~hexdmpb0x600000000~ , а то что то у меня выскакивает пустая страница , как только где то в ЯВЕ вставляю ~hexdmpb0x600000000~ .
3. Второй вопрос можно ли эту строку(а затем и строки) записать в некую ячейку - например ~0x600080000~ и затем представить её как файл ~hexdmpb0x600080000~ просто вставив это выражение в него ? Ведь , если я правильно понимаю обрабатывающие файлы ЯВА примут это , как массив данных и построят график .
4. И вообще - в какие области можно записывать данные
 

pvvx

Активный участник сообщества
1 . Итак , обнаружил такую возможность - если делать некое колличество раз запрос http://192.168.1.130/web.cgi?hexdmpb0x60000000=1 , то по этому адресу(0х60000000) , по одному символу будут считываться мои данные из UART . Сколько раз сделать запрос , столько символов получим . Нужно только оформить эту конструкцию в цикл и из символов определённого порядкового номера создать строку .
2. Теперь вопрос - как использовать для этого прямую команду ~hexdmpb0x600000000~ , а то что то у меня выскакивает пустая страница , как только где то в ЯВЕ вставляю ~hexdmpb0x600000000~ .
1/2 - нелады с javascript или уже описанное - каким образом будет заполняться новая строка из UART и опустошаться - по факту считывания?
А если в момент чтения "строка символов" ещё не вся передана - получите пол строки?
Если запросы строит javascript и открыты две страницы броузера, считывающие вашу предполагаемую строку - какой символ из поступающих в UART выводить на одну и другую страницу? По очереди или "ходом коня"? :)
3
"файлы ЯВА примут это , как массив данных и построят график" - в очень далеком смысле.
Ответ по поводу вывода данных UART на HTTP страницу вам дан - нет стандартов и описать это невозможно. Предлагаемые вами решения конфликтуют с основами.
Есть куча терминальных программ и скриптов на Java/JavaScript - они позволяют создать монитор типа Tera Term с уже имеющимся TCP2UART портом.
4. И вообще - в какие области можно записывать данные
На такой вопрос ответ невозможен. На него возможна только куча встречных вопросов, для выяснения ваших знаний, чтобы создать понятный вам ответ.
Предлагаете создать тут бесплатную школу вашего обучения самым основам программирования или игру в телепатию?
Общий телепатический ответ - данные можно сохранить в области буфера обмена ячеек Modbus. Таковой существует в прошивке и в Info (Help) (ссылка на главной странице web-сервера) даны краткие описания имен запросов...
 
Последнее редактирование:

saho

New member
@pvvx , мерси за потраченное на ответ время .
Предлагаемые вами решения конфликтуют с основами.
1. Да , действительно фигня получается ... Эти моменты я не учитывал . :oops:
Есть куча терминальных программ и скриптов
2. Да , конечно же , тот же ТЕЛНЕТ замечательно справляется , но как это сделать просто и удобно для простого пользователя , как говорится - всё в одной кнопке . :(
4.
Общий телепатический ответ
- как раз этот ответ - то , что нужно , я схватываю всё на лету :) , мне главное задать вектор ...
 

rst

Member
Супервайзер на питание и поддержка на время записи сектора стоит гораздо более увеличения Flash и простой FRAM.
...
Тему логгеров для приборов измерения, особенно переносных, тут не затронута, но и c ними есть более 25-летний опыт :) :p
Почти всё - полная чушь... Можно почти все утверждения опровергнуть или привести контрдоводы. Даже что-то обсуждать с Вами нет смысла - абсолютно не разбираясь в вопросе - с огромным апломбом порете чушь.
Как видно из этого письма - опыт у Вас - только в работе языком.
Делать какие-то выводы о чужих системах - как и для чего там что делается (логгится с какими размерами и т.п.) - такое безаппеляционное невежество редко встретишь. Да ещё и попытки судить о чужом опыте... Рано Вам судить - Вы даже просто не поймёте что делают и могут сделать другие.
Логи пишутся хоть с одной минутой хоть меньше - кому как надо, найти границы кольца в памяти - не проблема, вне зависимости от того, сколько времени было выключено устройство, насчёт "поддержки во время записи" - откройте например страничку Cypress с их чипами и посмотрите цены.
И т.д. и т.п.

PS: Заводы с параходами и прочий бред поскипан...
 
Последнее редактирование:

pvvx

Активный участник сообщества
Почти всё - полная чушь... Можно почти все утверждения опровергнуть или привести контрдоводы. Даже что-то обсуждать с Вами нет смысла - абсолютно не разбираясь в вопросе - с огромным апломбом порете чушь.
Как видно из этого письма - опыт у Вас - только в работе языком.
Делать какие-то выводы о чужих системах - как и для чего там что делается (логгится с какими размерами и т.п.) - такое безаппеляционное невежество редко встретишь. Да ещё и попытки судить о чужом опыте... Рано Вам судить - Вы даже просто не поймёте что делают и могут сделать другие.
Логи пишутся хоть с одной минутой хоть меньше - кому как надо, найти границы кольца в памяти - не проблема, вне зависимости от того, сколько времени было выключено устройство, насчёт "поддержки во время записи" - откройте например страничку Cypress с их чипами и посмотрите цены.
И т.д. и т.п.

PS: Заводы с параходами и прочий бред поскипан...
Открыл, облазил "страничку Cypress с их чипами" и ничего дешевле описываемого решения не нашел.
Не соизволите ли показать Российскую фирму производителя, где считают краску и прочие ваши утверждения, при разработанной у них серийной системой и нормальной оплатой разработчику-программисту. :) В магазинах что-то тоже не видать...
Наверно на пароходах они серийно стоят? :)
Старейший в России действующий колёсный пароход «Н. В. Гоголь» сейчас находится в городе Северодвинске (Архангельская область) и ходил с круизами по реке Северная Двина до 2012 года, став в 2013 году, со слов владельцев этого судна, лишь банкетоходом.

Если уж ссылаетесь на других, то покажите хоть одно их решение :)

Замечтались, насмотрелись популистской фантастики? :) Ближе к реальности надо быть, а то ничего и не создадите.

Тут, на форуме, есть только одно решение и оно построено именно так, как и описал. Серийное изделие, очень похожее на описываемое (там изернет разъем вместо WiFi) мы выпускаем более десяти лет, а мониторинг рынка на данную тематику имеет ещё больший временной промежуток и производиться досих пор. С решениями от разных “брендов” уж знакомы не понаслышке… :) И уже давно нет проблем в себестоимости изделия. Можем позволить ставить хоть NAS серверы, но текущее решение мне больше нравиться – оно дает рабочие места тут – его собирают тут и на этом получают зарплату.
Сядьте, как вам было сказано – в больничный стационар :), да посчитайте что лучше – поставить несколько блоков Siemens c ценниками каждый в сотню т. руб и покупки ещё пакетов ПО на них на сотни тысяч, или сделать это самим, переведя эти средства на оплату работающему персоналу и вливанию разницы в экономику страны? Одно такое изделие в месяц, и уже можно добавить не менее одного рабочего места. Вот вам и серийность и расширение фирмы, да оплата разработчику. А ваши байки – используйте где на черном рынке… Нахватались г...на с пропагандой... По ним всё сразу видно, какие итого у вас и "серийность" :)
 
Последнее редактирование:

sharikov

Active member
Не соизволите ли показать Российскую фирму производителя, где считают краску и прочие ваши утверждения, при разработанной у них серийной системой и нормальной оплатой разработчику-программисту. :) В магазинах что-то тоже не видать...
Есть такие формы, сам работал в такой. Готовы удавиться за доли цента, проводят многочасовые совещания на тему выбора разъема чтобы сократить время втыкания и т.п. Комплектация у них как правило китай 3 эшелона (т.е подделка под нонаме). Продукция низкорентабельная, прибыль маленькая, конкуренция лютейшая. У таких фирм есть один недостаток: либо не платят разработчикам вовсе либо платят копейки. Работа с такими фирмами - время вычеркнутое из жизни.
 

pvvx

Активный участник сообщества
Есть такие формы, сам работал в такой. Готовы удавиться за доли цента, проводят многочасовые совещания на тему выбора разъема чтобы сократить время втыкания и т.п. Комплектация у них как правило китай 3 эшелона (т.е подделка под нонаме). Продукция низкорентабельная, прибыль маленькая, конкуренция лютейшая. У таких фирм есть один недостаток: либо не платят разработчикам вовсе либо платят копейки. Работа с такими фирмами - время вычеркнутое из жизни.
У них жизненный цикл мал - год, два и кратны. Да и время их давно прошло. В перестроечные времена люди без головы, типа rst, нанимались и на хуже варианты, под установку, что гарантийный ремонт будет вычитаться из зп :) Первые два-три месяца такой получает зп, а далее оплачивает грантийку до полного минуса и долгов, затем пинками выкидывается... :) Я на таких фирмочках больше всего заработал - жадный всегда платит больше :) :)
Метод простой – они всегда не могут что-то сделать, т.к. не разорятся на оборудование и прочее. И эту часть можно предоставить им дешевле и качественее, чем у них себестоимость. Но в реалии оно отдается с наценкой, т.к. специальное производство в десятки раз дешевле. В итого выходит, что с каждого их серийного изделия, при перепродаже им этой эксклюзивной части набирается прибыли больше, чем получает их руководство :) Работать при этом не требуется – надо всего то договориться с поставщиками и принимать разницу в наличке :) Как-то была такая конторка – вышло $1.5..1.8 с каждого произведенного ими товара при производительности в десятку тысяч шт. в месяц… :) И что ещё интересного - исходные коды на ту часть остались и существуют только у меня...
Есть ещё несколько маневров, как раз связанных с тем, как они желают (совещания по удешевлению :)) Но это уже сикрет, т.к. дает ещё больше прибыли и всем хорошо…
Жалко, что такие конторы уже вымерли :)
 
Последнее редактирование:

rst

Member
Открыл, облазил "страничку Cypress с их чипами" и ничего дешевле описываемого решения не нашел.
Называется Serial nvSRAM на их сайте. По крайней мере раньше была дешевле FRAM и позиционировалась ими (и их представителями) как дешёвая альтернатива FRAM.

Если уж ссылаетесь на других, то покажите хоть одно их решение :)
Я ссылаюсь? Где? Я пишу только на основани своего опыта.
Это как раз Ваш стиль - голословно утверждать всякую чушь.
Итак, Ваше утверждение: "Статистика при этом точнее 5 минут никому не требуется" - где подтверждения этого утверждения? Со статистическими данными, собранными на основе анализа всех устройств, где ведётся статистика?? Приведите - ответьте за свои слова.
Ещё: "Всё это завязано на других принципах выживаемости предприятия в России." - так каковы они эти принципы? Просветите нас, всезнающий?? А то мы тут простые люди, работающие (работавшие) на этих самых предприятиях (и даже руководящие ими или являющиеся ведущими разработчиками) не знаем... :D
Вы то конечно про всех всё знаете лучше их самих...
Ещё: "никакого серийного изготовления электроники, да ещё по описываемым вами принципам в России не существует" - да ладно? А если я Вам приведу адреса конкретных предприятий, Вы ответите за это своё утверждение? И не так как тут обычно - пустым трёпом (на который Вы только и способны) - а реально, скажем своими деньгами? И ответите за это каждому, кто приведёт адреса таких предприятий? Или Вы только трепаться способны?

PS: Остальной пустой трёп и смысла нет читать. Лучше не лезьте в то чего не понимаете. Сидите себе тихо на своей ардуине да поучайте чайников. Вы как видно кроме ардуины ни с чем реальным и не имели дела, всё только по наслышке....
 
Последнее редактирование:

rst

Member
Есть такие формы, сам работал в такой. Готовы удавиться за доли цента, проводят многочасовые совещания на тему выбора разъема чтобы сократить время втыкания и т.п. Комплектация у них как правило китай 3 эшелона (т.е подделка под нонаме). Продукция низкорентабельная, прибыль маленькая, конкуренция лютейшая. У таких фирм есть один недостаток: либо не платят разработчикам вовсе либо платят копейки. Работа с такими фирмами - время вычеркнутое из жизни.
Ну насчёт вычеркнутого времени - это не всегда так, хотя бывает. И насчёт комплектации - тоже, в моей прошлой конторе конторе обычно покупали у официальных поставщиков, но бывали случаи когда снабженцы пытались сэкономить и покупали левые партии, но обычно это выявлялось и наказывалось потом.
А товарища pvvx лечить похоже бесполезно - болезнь уже в запущенной форме. Чел похоже не работал ни в одной серьёзной конторе ни в одном серьёзном проекте (не брали видимо ;) из чего делает вывод, что таких контор нет, что все вокруг лохи и только он один крут. Видно, что он перебивается случайными халтурками в шарашкиных конторах, колхозит свои поделия на ардуйне всякой и что с али заказать удастся... Ну что-ж - "по сеньке и шапка" :D
Остаётся только разве посочувствовать.
 
Сверху Снизу