код, который Вы привели - показывает, что Вы совершенно не понимаете сути проблемы. Приведение к типу float внутри Serial.print() - это уже использование вычислений с плавающей точкой, и соответвующее увеличение размера кода
Сравните:
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
}
void loop() {
// put your main code here, to run repeatedly:
byte x = Serial.read();
Serial.println( (float) x/100 );
}
Скетч использует 3212 байт (9%)
Глобальные переменные используют 200 байт
Скетч использует 1834 байт (5%)
Глобальные переменные используют 190 байт
примечание - операция чтения х из сериал добавлена, чтобы компилятор не заменил значение х/100 заранее рассчитанной константой
Спасибо за подсказку. Поясните, если не сложно - куда делись 10 байт ОЗУ? Хочу понять сам принцип, потому что аналогично автору темы испытываю дикий дефицит памяти, причем в основном динамической.
Да куда-нибудь их съела работа с запятой, дизассемблировал оба примера, там очень много чего добавляется при работе с float.
Повторюсь, сейчас идёт 2019 год и проблем с дефицитом памяти практически никогда быть не должно. Не хватает UNO - бери Мегу, stm32, esp8266, esp32, raspberry, x86, x64.
проблем с дефицитом памяти практически никогда быть не должно. Не хватает UNO - бери Мегу, stm32, esp8266, esp32, raspberry, x86, x64.
гладко было на бумаге, да забыли про овраги. Дефицит памяти проявляется не в начале разработки, а ближе к концу. Представляете себе процесс миграции с уно на х64, когда почти все готово, платы запаяны код написан или даже годами устройство работает, иногда выпущено и серией, а надо еще добавить коду но некуда?
Конечно представляю, и даже заложил на это целый 1% случаев. Только конкретный текущий случай к ним не относится, ибо вряд ли люди, у которых серийно разработанное их же устройство работает годами, придут на форум ардуино поинтересоваться, как убрать из кода плавающую точку для оптимизации.
Конечно представляю, и даже заложил на это целый 1% случаев.
Ты не заложил, ты положил на опыт других. Именные грабли тебя подправят ;)
negavoid пишет:
Только конкретный текущий случай к ним не относится,
А почитать стартовое?
Ictic_Step пишет:
...Уже почти дописал прошивку для своего проекта, но .... будет определенно недостаточно для описания логики считывания и записи на sd-карту, а мне еще нужен запас памяти под еще несколько модулей.
negavoid пишет:
вряд ли люди, у которых серийно разработанное их же устройство работает годами, придут на форум ардуино поинтересоваться, как убрать из кода плавающую точку для оптимизации.
Нет. Не придут. Но от этого проблема оптимизировать древний софт на древнем железе или похерить все и переходить на новое не исчезнет.
Ты не заложил, ты положил на опыт других. Именные грабли тебя подправят ;)
И правильно сделал, все прыгнут с крыши - и мне что, за ними? А именные грабли... Опыт у меня поменьше вашего, но не то, чтобы особо намного, не испытываю подобных затруднений, значит что-то, видимо, делаю по-другому.
Logik пишет:
А почитать стартовое?
Ictic_step уже два месяца не посещает тему, диалог ведётся с cyberman, которому нужно оптимизировать флоаты и который явно делает не серийное, а домашнее хоббийное изделие, где благодаря ардуино допустима лёгкая замена контроллера на более современный.
Logik пишет:
Нет. Не придут. Но от этого проблема оптимизировать древний софт на древнем железе или похерить все и переходить на новое не исчезнет.
Проблемы других меня не интересуют. Если таковая возникнет у меня и будет возможность оптимизировать - оптимизирую, а если надо будет переходить - перейду. Время, деньги, люди - гораздо дороже железок.
Нефиг за гуманизм прятаться. В любом случае, что оптимизация, что переход на новое железо - людям работать. Мантры про "2019 год и проблем с дефицитом памяти практически никогда быть не должно. " им ничем не помогут. А cyberman всего лишь интересовался подробностями ухода от плавающей точки, очевидно мысль про смену платформы ему ни к черту. И если уж проблемы других вас не интересуют - то какого с своими взглядами лезть. Не интересуют - свалил по своим граблям танцевать, тут тусуются не безразличные и готовые обмениваться опытом.
А cyberman всего лишь интересовался подробностями ухода от плавающей точки, очевидно мысль про смену платформы ему ни к черту.
Да, платформу я менять не собираюсь (пока). Потому что ради хобийного девайса покупать мегу или еще что-то из перечисленного - это как-то не очень рационально. Поэтому буду оптимизировать, байтики выкраивать! negavoid - спасибо за идею.
Хобби - это то, что как раз съедает деньги и/или время, но приносит удовольствие, поэтому в вашем случае это вполне нормально и допустимо (хотя мега всего на пару баксов дороже уны). А вот если бы у вас была цель побыстрее доделать и запустить девайс, и стоимость разницы между мегой и уной не превышала бы стоимость часа вашей работы с выкраиванием байтиков, то имел бы смысл мой подход.
На наш флейм не смотрите, на форуме считается признаком хорошего тона придираться к каждой запятой. Все по-своему правы, но признавать, что не ошибочное может быть и не только твоё мнение, никто не будет. :)
гладко было на бумаге, да забыли про овраги. Дефицит памяти проявляется не в начале разработки, а ближе к концу. Представляете себе процесс миграции с уно на х64, когда почти все готово, платы запаяны код написан или даже годами устройство работает, иногда выпущено и серией, а надо еще добавить коду но некуда?
Выявление дефицита памяти в процессе (на любом этапе) разработки - грубейшая ошибка проектирования. Вряд ли кто может столкнутся с этим более одного раза. Ну разве что патологический любитель ходить по граблям, в принципе не способный обучаться даже на собственных ошибках.
Второй случай, - когда код уже годами работает, еще менее правдоподобен: обычно первой мыслью при проектировании следующей версии проекта с существенно измененной функциональностью - а не перейти ли на другую элементную базу. Кстати, подтверждения этому можно найти и в разделе "Проекты" настоящего форума.
Ага, "640 КБайт хватит для всех!". Памяти ВСЕГДА будет не хватать!) Особенно, если писать в стиле Win приложений.
Считаю что дисциплина должна быть всегда. Но и без фанатизма, если на то нет необходимости.)
Стиль win-приложений - это while(getmessage) { translatemessage, dispatchmessage } ? Если в таком стиле писать, то хватало бы и 640 кб, очень много чему :) Но катастрофически увеличилось бы время разработки и требуемая квалификация, поэтому сейчас тащат кучу библиотек, а над ними ещё куча, вот и получается бинарник (и это без секций ресурсов) на несколько мегабайт. Обсуждаем же память, обычно [в среднем] требуемую для работы [средней 2019 года] win-программы?, а то можно быстренько сделать allocmem(64Gb) под текстурки и аллес. А вот ещё есть прожка, массивы флоатов перемножает, ей требуется 94 Гб под эти массивы с данными, своп на ссд пердит и стонет, но софтина таки едет. Сделают через 10 лет по терабайту памяти в средней машине - ну дык к тому времени и алгоритмы понапишут, утилизирующие по 50 терабайт ))
Выявление дефицита памяти в процессе (на любом этапе) разработки - грубейшая ошибка проектирования. Вряд ли кто может столкнутся с этим более одного раза. Ну разве что патологический любитель ходить по граблям, в принципе не способный обучаться даже на собственных ошибках.
Звероид, вылезь с ПК. Мы здесь эмбадедом занимаемся, а в этом деле дефицит памяти - постоянная составляющая на любом этапе. От ТЗ и до металолома. Потому как память - деньги заказчика и даже при составлении ТЗ заказчик всегда жмется (Из реального "А чего эта добавили 1МБ памяти аж 10$ цена выросла?! Да я за такие деньги гиг в комп поставлю! Наеб..аете?!"). Это в ПК системные требования определил и хот трава не кури, хочеш играть (рендерить, серфить и т.д.) - докупай память. Но здесь вам не там.
andriano пишет:
Второй случай, - когда код уже годами работает, еще менее правдоподобен: обычно первой мыслью при проектировании следующей версии проекта с существенно измененной функциональностью - а не перейти ли на другую элементную базу. Кстати, подтверждения этому можно найти и в разделе "Проекты" настоящего форума.
Даже думал не коментить, ты не от мира сего видно. Или дальше ПК нос не совал по работе. Банкоматы видел? А терминалы в магазинах? Сколько лет они там стоят? Раскажи их владельцам про "проектировании следующей версии проекта с существенно измененной функциональностью" и сразу иди, не жди иначе они пошлют. Расширенная (чувствуешь разницу с измененной) функциональность всегда добавляется в старое железо до тех пор пока оно хоть как-то тянет. И это вопрос денег, причем очень больших, не те что в разделе "Проекты" (вот уже нашел на что ссылатся!!). И если группа товарищей может добавить новые хотелки в старое железо без его замены/апгрейда то их труд оплачивается c оглядкой на цены нового железа, так, чтоб не голословить https://tehpos.ru/katalog/pos-terminaly/ . Вот и прикинь в уме, если у паршивенького банка тысячи постерминалов по магазинам розтыкано. Не сложно понять что держать пару програмеров для "вковыривания" новых идей безумных менеджеров в старое железо оказывается взаимовыгодным. А новое железо докупается на расширение сети и замену неремонтопригодного. И вот когда масса нового станет существенной, вот тогда... тогда это новое уже устареет порядком ))))
ПС. Один из первых проектов по работе делал на pic16c84. Сделал, но шеф решил потом перейти на 12f508. А там ассемблер урезаный и стек на два вызова (памяти как раз хватало в обрез). Ниче, месячишку ковыряний моих оплатили. Зато он почти на бакс дешевле, и площадь платы можна урезать. А продавали их штук 500 в месяц. Вот и считай. Просто хобийные проекты, - не серийные. Потому и отношение бабок на железо и на разработку специфичное, отсюда и мировозрение свое. А на ПК - тоже свое, писал уже.
Выявление дефицита памяти в процессе (на любом этапе) разработки - грубейшая ошибка проектирования. Вряд ли кто может столкнутся с этим более одного раза. Ну разве что патологический любитель ходить по граблям, в принципе не способный обучаться даже на собственных ошибках.
Звероид, вылезь с ПК. Мы здесь эмбадедом занимаемся, а в этом деле дефицит памяти - постоянная составляющая на любом этапе. От ТЗ и до металолома. Потому как память - деньги заказчика и даже при составлении ТЗ заказчик всегда жмется (Из реального "А чего эта добавили 1МБ памяти аж 10$ цена выросла?! Да я за такие деньги гиг в комп поставлю! Наеб..аете?!"). Это в ПК системные требования определил и хот трава не кури, хочеш играть (рендерить, серфить и т.д.) - докупай память. Но здесь вам не там.
andriano пишет:
Второй случай, - когда код уже годами работает, еще менее правдоподобен: обычно первой мыслью при проектировании следующей версии проекта с существенно измененной функциональностью - а не перейти ли на другую элементную базу. Кстати, подтверждения этому можно найти и в разделе "Проекты" настоящего форума.
Даже думал не коментить, ты не от мира сего видно. Или дальше ПК нос не совал по работе. Банкоматы видел? А терминалы в магазинах? Сколько лет они там стоят? Раскажи их владельцам про "проектировании следующей версии проекта с существенно измененной функциональностью" и сразу иди, не жди иначе они пошлют. Расширенная (чувствуешь разницу с измененной) функциональность всегда добавляется в старое железо до тех пор пока оно хоть как-то тянет. И это вопрос денег, причем очень больших, не те что в разделе "Проекты" (вот уже нашел на что ссылатся!!). И если группа товарищей может добавить новые хотелки в старое железо без его замены/апгрейда то их труд оплачивается c оглядкой на цены нового железа, так, чтоб не голословить https://tehpos.ru/katalog/pos-terminaly/ . Вот и прикинь в уме, если у паршивенького банка тысячи постерминалов по магазинам розтыкано. Не сложно понять что держать пару програмеров для "вковыривания" новых идей безумных менеджеров в старое железо оказывается взаимовыгодным. А новое железо докупается на расширение сети и замену неремонтопригодного. И вот когда масса нового станет существенной, вот тогда... тогда это новое уже устареет порядком ))))
ПС. Один из первых проектов по работе делал на pic16c84. Сделал, но шеф решил потом перейти на 12f508. А там ассемблер урезаный и стек на два вызова (памяти как раз хватало в обрез). Ниче, месячишку ковыряний моих оплатили. Зато он почти на бакс дешевле, и площадь платы можна урезать. А продавали их штук 500 в месяц. Вот и считай. Просто хобийные проекты, - не серийные. Потому и отношение бабок на железо и на разработку специфичное, отсюда и мировозрение свое. А на ПК - тоже свое, писал уже.
...Банкоматы видел? А терминалы в магазинах? Сколько лет они там стоят? Раскажи их владельцам про "проектировании следующей версии проекта с существенно измененной функциональностью" и сразу иди, не жди иначе они пошлют.
Лоджик, Вы всерьез собираетесь устанавливать в каждый из эксплуатируемых банкоматов по SD-ридеру? Причем так, чтобы поддержка этого ридера обязательно уместилась в установленный в нем контроллер?
Перечитайте исходный пост темы.
Ну и вообще, - не нужно путать DIY с серийно выпускаемыми устройствами. Это - практически не пересекающиеся ниши.
Всех поздравляю с единственным праздником, кроме дня рождения, который в приниципе стоит отмечать! Сегодня 256-ой день в году, так-что желаю жить без багов и ошибок, а еще успехов вам всем и хорошего настроения. С днём программиста друзья!!!
А рациональные и иррациональные числа не страшны.
особенно иррациональные не страшны. Их просто не бывает в ИТ ;)
Ну окей, хоть и не думаю, что это очень страшно.
код, который Вы привели - показывает, что Вы совершенно не понимаете сути проблемы. Приведение к типу float внутри Serial.print() - это уже использование вычислений с плавающей точкой, и соответвующее увеличение размера кода
Сравните:
Скетч использует 3212 байт (9%)
Глобальные переменные используют 200 байт
а теперь заменим вывод на целочисленный
Скетч использует 1834 байт (5%)
Глобальные переменные используют 190 байт
примечание - операция чтения х из сериал добавлена, чтобы компилятор не заменил значение х/100 заранее рассчитанной константой
Спасибо за подсказку. Поясните, если не сложно - куда делись 10 байт ОЗУ? Хочу понять сам принцип, потому что аналогично автору темы испытываю дикий дефицит памяти, причем в основном динамической.
Да куда-нибудь их съела работа с запятой, дизассемблировал оба примера, там очень много чего добавляется при работе с float.
Повторюсь, сейчас идёт 2019 год и проблем с дефицитом памяти практически никогда быть не должно. Не хватает UNO - бери Мегу, stm32, esp8266, esp32, raspberry, x86, x64.
Спасибо, понял
проблем с дефицитом памяти практически никогда быть не должно. Не хватает UNO - бери Мегу, stm32, esp8266, esp32, raspberry, x86, x64.
гладко было на бумаге, да забыли про овраги. Дефицит памяти проявляется не в начале разработки, а ближе к концу. Представляете себе процесс миграции с уно на х64, когда почти все готово, платы запаяны код написан или даже годами устройство работает, иногда выпущено и серией, а надо еще добавить коду но некуда?
когда почти все готово, платы запаяны код написан или даже годами устройство работает, иногда выпущено и серией, а надо еще добавить коду но некуда?
Конечно представляю, и даже заложил на это целый 1% случаев. Только конкретный текущий случай к ним не относится, ибо вряд ли люди, у которых серийно разработанное их же устройство работает годами, придут на форум ардуино поинтересоваться, как убрать из кода плавающую точку для оптимизации.
скорее, сначала убьют бутлодыря.
Конечно представляю, и даже заложил на это целый 1% случаев.
Ты не заложил, ты положил на опыт других. Именные грабли тебя подправят ;)
Только конкретный текущий случай к ним не относится,
А почитать стартовое?
...Уже почти дописал прошивку для своего проекта, но .... будет определенно недостаточно для описания логики считывания и записи на sd-карту, а мне еще нужен запас памяти под еще несколько модулей.
вряд ли люди, у которых серийно разработанное их же устройство работает годами, придут на форум ардуино поинтересоваться, как убрать из кода плавающую точку для оптимизации.
Нет. Не придут. Но от этого проблема оптимизировать древний софт на древнем железе или похерить все и переходить на новое не исчезнет.
когда почти все готово, платы запаяны код написан или даже годами устройство работает, иногда выпущено и серией, а надо еще добавить коду но некуда?
Или еще. Про фиаско. Приезжает VL53LOX, цепляеш "Adafruit_VL53L0X.h" и в пошти голом проекте, токо в сириал результат пихает.
А я вот на него надеялся.. Вот шо они, сука, накрутили в той либе чтоб по i2c так опросить датчик?
Там, наерно, Пуховы лямбды с шоблонами.
И правильно сделал, все прыгнут с крыши - и мне что, за ними? А именные грабли... Опыт у меня поменьше вашего, но не то, чтобы особо намного, не испытываю подобных затруднений, значит что-то, видимо, делаю по-другому.
А почитать стартовое?
Ictic_step уже два месяца не посещает тему, диалог ведётся с cyberman, которому нужно оптимизировать флоаты и который явно делает не серийное, а домашнее хоббийное изделие, где благодаря ардуино допустима лёгкая замена контроллера на более современный.
Нет. Не придут. Но от этого проблема оптимизировать древний софт на древнем железе или похерить все и переходить на новое не исчезнет.
Проблемы других меня не интересуют. Если таковая возникнет у меня и будет возможность оптимизировать - оптимизирую, а если надо будет переходить - перейду. Время, деньги, люди - гораздо дороже железок.
Нефиг за гуманизм прятаться. В любом случае, что оптимизация, что переход на новое железо - людям работать. Мантры про "2019 год и проблем с дефицитом памяти практически никогда быть не должно. " им ничем не помогут. А cyberman всего лишь интересовался подробностями ухода от плавающей точки, очевидно мысль про смену платформы ему ни к черту. И если уж проблемы других вас не интересуют - то какого с своими взглядами лезть. Не интересуют - свалил по своим граблям танцевать, тут тусуются не безразличные и готовые обмениваться опытом.
Личные мнения других меня не интересуют даже более, чем их проблемы :)
А cyberman всего лишь интересовался подробностями ухода от плавающей точки, очевидно мысль про смену платформы ему ни к черту.
Да, платформу я менять не собираюсь (пока). Потому что ради хобийного девайса покупать мегу или еще что-то из перечисленного - это как-то не очень рационально. Поэтому буду оптимизировать, байтики выкраивать! negavoid - спасибо за идею.
Хобби - это то, что как раз съедает деньги и/или время, но приносит удовольствие, поэтому в вашем случае это вполне нормально и допустимо (хотя мега всего на пару баксов дороже уны). А вот если бы у вас была цель побыстрее доделать и запустить девайс, и стоимость разницы между мегой и уной не превышала бы стоимость часа вашей работы с выкраиванием байтиков, то имел бы смысл мой подход.
На наш флейм не смотрите, на форуме считается признаком хорошего тона придираться к каждой запятой. Все по-своему правы, но признавать, что не ошибочное может быть и не только твоё мнение, никто не будет. :)
Атнють. Тут разные люди.
Ну ладно, дида будет, но многие "аффтаритеты" - ни-ни :)
гладко было на бумаге, да забыли про овраги. Дефицит памяти проявляется не в начале разработки, а ближе к концу. Представляете себе процесс миграции с уно на х64, когда почти все готово, платы запаяны код написан или даже годами устройство работает, иногда выпущено и серией, а надо еще добавить коду но некуда?
Выявление дефицита памяти в процессе (на любом этапе) разработки - грубейшая ошибка проектирования. Вряд ли кто может столкнутся с этим более одного раза. Ну разве что патологический любитель ходить по граблям, в принципе не способный обучаться даже на собственных ошибках.
Второй случай, - когда код уже годами работает, еще менее правдоподобен: обычно первой мыслью при проектировании следующей версии проекта с существенно измененной функциональностью - а не перейти ли на другую элементную базу. Кстати, подтверждения этому можно найти и в разделе "Проекты" настоящего форума.
Мантры про "2019 год и проблем с дефицитом памяти практически никогда быть не должно. " им ничем не помогут.
Дело не в мантрах.
Пока на Ардуино не будет 640 кбайт памяти, последней всегда будет не хватать.
Ага, "640 КБайт хватит для всех!". Памяти ВСЕГДА будет не хватать!) Особенно, если писать в стиле Win приложений.
Считаю что дисциплина должна быть всегда. Но и без фанатизма, если на то нет необходимости.)
Стиль win-приложений - это while(getmessage) { translatemessage, dispatchmessage } ? Если в таком стиле писать, то хватало бы и 640 кб, очень много чему :) Но катастрофически увеличилось бы время разработки и требуемая квалификация, поэтому сейчас тащат кучу библиотек, а над ними ещё куча, вот и получается бинарник (и это без секций ресурсов) на несколько мегабайт. Обсуждаем же память, обычно [в среднем] требуемую для работы [средней 2019 года] win-программы?, а то можно быстренько сделать allocmem(64Gb) под текстурки и аллес. А вот ещё есть прожка, массивы флоатов перемножает, ей требуется 94 Гб под эти массивы с данными, своп на ссд пердит и стонет, но софтина таки едет. Сделают через 10 лет по терабайту памяти в средней машине - ну дык к тому времени и алгоритмы понапишут, утилизирующие по 50 терабайт ))
скорее, сначала убьют бутлодыря.
зачем убивать, можно перейти на miniCore, включить опцию LTO и глядишь сэкономленной памяти как раз и хватит
Выявление дефицита памяти в процессе (на любом этапе) разработки - грубейшая ошибка проектирования. Вряд ли кто может столкнутся с этим более одного раза. Ну разве что патологический любитель ходить по граблям, в принципе не способный обучаться даже на собственных ошибках.
Звероид, вылезь с ПК. Мы здесь эмбадедом занимаемся, а в этом деле дефицит памяти - постоянная составляющая на любом этапе. От ТЗ и до металолома. Потому как память - деньги заказчика и даже при составлении ТЗ заказчик всегда жмется (Из реального "А чего эта добавили 1МБ памяти аж 10$ цена выросла?! Да я за такие деньги гиг в комп поставлю! Наеб..аете?!"). Это в ПК системные требования определил и хот трава не кури, хочеш играть (рендерить, серфить и т.д.) - докупай память. Но здесь вам не там.
Второй случай, - когда код уже годами работает, еще менее правдоподобен: обычно первой мыслью при проектировании следующей версии проекта с существенно измененной функциональностью - а не перейти ли на другую элементную базу. Кстати, подтверждения этому можно найти и в разделе "Проекты" настоящего форума.
Даже думал не коментить, ты не от мира сего видно. Или дальше ПК нос не совал по работе. Банкоматы видел? А терминалы в магазинах? Сколько лет они там стоят? Раскажи их владельцам про "проектировании следующей версии проекта с существенно измененной функциональностью" и сразу иди, не жди иначе они пошлют. Расширенная (чувствуешь разницу с измененной) функциональность всегда добавляется в старое железо до тех пор пока оно хоть как-то тянет. И это вопрос денег, причем очень больших, не те что в разделе "Проекты" (вот уже нашел на что ссылатся!!). И если группа товарищей может добавить новые хотелки в старое железо без его замены/апгрейда то их труд оплачивается c оглядкой на цены нового железа, так, чтоб не голословить https://tehpos.ru/katalog/pos-terminaly/ . Вот и прикинь в уме, если у паршивенького банка тысячи постерминалов по магазинам розтыкано. Не сложно понять что держать пару програмеров для "вковыривания" новых идей безумных менеджеров в старое железо оказывается взаимовыгодным. А новое железо докупается на расширение сети и замену неремонтопригодного. И вот когда масса нового станет существенной, вот тогда... тогда это новое уже устареет порядком ))))
ПС. Один из первых проектов по работе делал на pic16c84. Сделал, но шеф решил потом перейти на 12f508. А там ассемблер урезаный и стек на два вызова (памяти как раз хватало в обрез). Ниче, месячишку ковыряний моих оплатили. Зато он почти на бакс дешевле, и площадь платы можна урезать. А продавали их штук 500 в месяц. Вот и считай. Просто хобийные проекты, - не серийные. Потому и отношение бабок на железо и на разработку специфичное, отсюда и мировозрение свое. А на ПК - тоже свое, писал уже.
Выявление дефицита памяти в процессе (на любом этапе) разработки - грубейшая ошибка проектирования. Вряд ли кто может столкнутся с этим более одного раза. Ну разве что патологический любитель ходить по граблям, в принципе не способный обучаться даже на собственных ошибках.
Звероид, вылезь с ПК. Мы здесь эмбадедом занимаемся, а в этом деле дефицит памяти - постоянная составляющая на любом этапе. От ТЗ и до металолома. Потому как память - деньги заказчика и даже при составлении ТЗ заказчик всегда жмется (Из реального "А чего эта добавили 1МБ памяти аж 10$ цена выросла?! Да я за такие деньги гиг в комп поставлю! Наеб..аете?!"). Это в ПК системные требования определил и хот трава не кури, хочеш играть (рендерить, серфить и т.д.) - докупай память. Но здесь вам не там.
Второй случай, - когда код уже годами работает, еще менее правдоподобен: обычно первой мыслью при проектировании следующей версии проекта с существенно измененной функциональностью - а не перейти ли на другую элементную базу. Кстати, подтверждения этому можно найти и в разделе "Проекты" настоящего форума.
Даже думал не коментить, ты не от мира сего видно. Или дальше ПК нос не совал по работе. Банкоматы видел? А терминалы в магазинах? Сколько лет они там стоят? Раскажи их владельцам про "проектировании следующей версии проекта с существенно измененной функциональностью" и сразу иди, не жди иначе они пошлют. Расширенная (чувствуешь разницу с измененной) функциональность всегда добавляется в старое железо до тех пор пока оно хоть как-то тянет. И это вопрос денег, причем очень больших, не те что в разделе "Проекты" (вот уже нашел на что ссылатся!!). И если группа товарищей может добавить новые хотелки в старое железо без его замены/апгрейда то их труд оплачивается c оглядкой на цены нового железа, так, чтоб не голословить https://tehpos.ru/katalog/pos-terminaly/ . Вот и прикинь в уме, если у паршивенького банка тысячи постерминалов по магазинам розтыкано. Не сложно понять что держать пару програмеров для "вковыривания" новых идей безумных менеджеров в старое железо оказывается взаимовыгодным. А новое железо докупается на расширение сети и замену неремонтопригодного. И вот когда масса нового станет существенной, вот тогда... тогда это новое уже устареет порядком ))))
ПС. Один из первых проектов по работе делал на pic16c84. Сделал, но шеф решил потом перейти на 12f508. А там ассемблер урезаный и стек на два вызова (памяти как раз хватало в обрез). Ниче, месячишку ковыряний моих оплатили. Зато он почти на бакс дешевле, и площадь платы можна урезать. А продавали их штук 500 в месяц. Вот и считай. Просто хобийные проекты, - не серийные. Потому и отношение бабок на железо и на разработку специфичное, отсюда и мировозрение свое. А на ПК - тоже свое, писал уже.
Я жду еще историй от вас)) Интересно читать
...Банкоматы видел? А терминалы в магазинах? Сколько лет они там стоят? Раскажи их владельцам про "проектировании следующей версии проекта с существенно измененной функциональностью" и сразу иди, не жди иначе они пошлют.
Лоджик, Вы всерьез собираетесь устанавливать в каждый из эксплуатируемых банкоматов по SD-ридеру? Причем так, чтобы поддержка этого ридера обязательно уместилась в установленный в нем контроллер?
Перечитайте исходный пост темы.
Ну и вообще, - не нужно путать DIY с серийно выпускаемыми устройствами. Это - практически не пересекающиеся ниши.
Ну Вы же начали обобщать, про процесс разработки.
//DIY с серийно выпускаемыми устройствами. Это - практически не пересекающиеся ниши.
Об том и речь.
У меня нет своего банкомата для опытов. Но на сколько я знаю туда любую переферию от ПК запросто поцепить, был бы софт.
// Я жду еще историй от вас)) Интересно читать
Так спрашуйте, если че интересует.))
Всех поздравляю с единственным праздником, кроме дня рождения, который в приниципе стоит отмечать! Сегодня 256-ой день в году, так-что желаю жить без багов и ошибок, а еще успехов вам всем и хорошего настроения. С днём программиста друзья!!!
Присоединяюсь! Спасибо Ictic_Step, что напомнили!