[mantech 132]

41 минуту назад, _pv сказал:

на его месте должен был быть electron

Ну так там всякие жабаскрипты и пр. интернет-быдлокодерство, я приведол пример исполнительного ехе файла, он вроде как априори должен быть неск. мегабайт максимум с учетом кутэшной либы в комплекте...

[jcxz 359]

4 часа назад, mantech сказал:

Неудобный интерфейс, по сравнению с SPI

"По сравнению с SPI" этот интерфейс требует всего 2 ноги МК и два провода. Для подключения и датчика и дисплея. SPI же потребует как минимум 3 ноги/цепи на дисплей + 2 ноги/цепи для датчика. Итого: вместо 2 цепей, получаем 5! И какое решение наиболее оптимально? Вопрос риторический...

И "неудобный" для кого? Для программиста? Если так, то это скорей такой программист "неудобен", а не I2C. Из-за которого приходится принимать неоптимальный для проекта выбор.

16 часов назад, dimka76 сказал:

Какой-нибудь STM32F0xx будет гораздо дешевле и ОЗУ будет килобайтами исчисляться.

Мы не знаем всех требований/условий ТС. А может он имеет опыт с PIC, но не имеет опыта с STM32? И хочет дальше сам продолжать проект и дописывать код.

Или например может быть - это предприятие? Которое в других разработках использует главным образом PIC-и. И даже имеет лицензионный софт для PIC, но не имеет его для ARM. И расширение номенклатуры используемых чипов без серьёзного обоснования - нежелательно.

ТС пишет "менее желательны к применению" - значит их выбор вместо PIC16 должен быть обоснован.

 

Если уж говорить об ARM, то какой-нибудь PY32 будет гораздо дешевле STM32F0xx и компактнее по корпусу. При вполне достаточных размере flash/RAM.

[EdgeAligned 143]

23 часа назад, ElectroProject сказал:

МК PIC16 (менее желательны к применению, но допустимы: STM

Прикольно 🙂 Обычно бывает наоборот

23 часа назад, ElectroProject сказал:

готовый рабочий проект в MPLab

Вероятно, курсовик у студера

22 часа назад, r_dot сказал:

В PIC16 памяти не хватит разместить протокол обмена с датчиком и вывод на дисплей, даже если писать на ассемблере.

Чой-то не хватит? Просто не берите древние PIC16F84. Хотя я даже в те далекие годы делал на PIC16F876 всякие мелкоприблуды даже с дисплеем 128х64, которые еще от Винстар были.

[dimka76 91]

On 11/21/2025 at 2:07 PM, jcxz said:

Если уж говорить об ARM, то какой-нибудь PY32 будет гораздо дешевле STM32F0xx и компактнее по корпусу. При вполне достаточных размере flash/RAM.

Да, и диапазон питаний как у PIC16, и цена 14 рублей в розницу.
Я примерно к тому и веду, что зачем сегодня эти куцие PIC16 и AVR, когда дешевле Cortex и ресурсов в нем побольше за меньшие деньги.
И лицензионный софт для Cortex не нужен. Для него есть свободное ПО.

[artemkad 167]

18 часов назад, Driver_GV сказал:

Целевой контроллер  PIC16F1823 2K FLASH и  128 байт RAM. Информация от ТС.

2К слов или иначе говоря - до 2 тысяч операций. Влезет, возможно даже место останется.

15 часов назад, izerg сказал:

А что не так с i2c ?

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

17 часов назад, mantech сказал:

Блин, это ж аналог самой "дохлой" АВРки 90S2313, да, ну пусть попробует кто в это уложить))))))

2313 имела 1К слов кода. т.е. примерно вдвое меньше. И даже в нее в свое время мы умудрились засунуть полноценную автосигналку с  честной(почти -без автосинхронизации при выходе за допустимое окно) обработкой KeeLoq-а и полтора десятками пунктов меню настроек.

[jcxz 359]

20 минут назад, artemkad сказал:

Конечно можно часть, которая связана, к примеру, с арбитражем нескольких ведущих на шине можно забить

Не "можно", а "нужно". Так как ведущий в задаче ТС - единственный.

Также заранее известны какие ведомые. А значит - известны необходимые операции и переходы состояний для них. И если не лепить "коня в вакууме" на все случаи жизни, то обрабатываемых состояний шины останется - с гулькин нос.

 

49 минут назад, dimka76 сказал:

Я примерно к тому и веду, что зачем сегодня эти куцие PIC16 и AVR, когда дешевле Cortex и ресурсов в нем побольше за меньшие деньги.

В реальном проекте может быть уже имеются такие же PIC. На других платах рядом в том же изделии. И одного этого обоснования (уменьшение номенклатуры комплектации) - уже вполне достаточно для выбора PIC16.

Есть изделие. Уже работающее и в серии. Нужно добавить функционал. Например: Уже есть 10 плат других датчиков. Уже в производстве, в серии. На таких же PIC16. Нужно добавить ещё одну плату, с новым датчиком (или новое исполнение того же устройства). Предложите 10 одних делать на PIC16, а 11-ю - на чём-то ином? Или все остальные 10 переделать???

У нас сейчас в текущем проекте - несколько плат. На одной плате нужно много ресурсов - поставили жирный STM32F767. На нескольких других платах - задачи простые, достаточно самого мелкого STM32. Но везде ставим аналогичный STM32F767. Пусть и будет использоваться он на 1-2%. Так как уменьшение номенклатуры - важнее.

 

PS: Я ни в коем случае не топлю за PIC16. Сам их нигде не использую давно.

[artemkad 167]

48 минут назад, dimka76 сказал:

Я примерно к тому и веду, что зачем сегодня эти куцие PIC16 и AVR, когда дешевле Cortex и ресурсов в нем побольше за меньшие деньги.

Вот только почему-то это "побольше ресурсов" быстро заканчиваются. В результате чего пишущие на Cortex-ах не понимают как можно задачу сложнее мигания светодиодом запихнуть в менее чем 16К кода. Иначе говоря "побольше ресурсов" это не преимущество, а необходимость.

11 минут назад, jcxz сказал:

Также заранее известны какие ведомые. А значит - известны необходимые операции и переходы состояний для них. И если не лепить "коня в вакууме" на все случаи жизни, то обрабатываемых состояний шины останется - с гулькин нос.

Само собой. Но это надо делать, а не взять как-то написанную библиотеку из Инета  и вставить ее в проект.

[jcxz 359]

7 минут назад, artemkad сказал:

В результате чего пишущие на Cortex-ах не понимают как можно задачу сложнее мигания светодиодом запихнуть в менее чем 16К кода.

Понимаем. Не надо говорить за всех.  

Задачу ТС даже на Cortex-M и даже на си вполне можно упихнуть в 16КБ. Не говоря уже про PIC16 (там система команд ещё компактнее должна быть).

[IJAR 1]

А измерением концентрации H2 и О2 никто не занимался?

Интересуют датчики.

[Plain 384]

Такой примитив в такой МК влезет без проблем, но исходник это дорого, и разумеется вряд ли кто согласится его заслать куда-то там, лишь очно, ещё и тг не у каждого первого есть.

[dimka76 91]

On 11/21/2025 at 3:01 PM, jcxz said:

В реальном проекте может быть уже имеются такие же PIC. На других платах рядом в том же изделии. И одного этого обоснования (уменьшение номенклатуры комплектации) - уже вполне достаточно для выбора PIC16.

Сталкивался с кофемашиной PHILIPS, в которой стояло два разных МК от разных производителей - Kinetis от NXP и PSoC от Cypress. Оба Cortex-Mxx.
Одни на основной плате, другой на плате кнопок.
Как-то не побрезговали расширением номенклатуры.

[mantech 132]

2 часа назад, jcxz сказал:

Для подключения и датчика и дисплея. SPI же потребует как минимум 3 ноги/цепи на дисплей + 2 ноги/цепи для датчика. Итого: вместо 2 цепей, получаем 5! И какое решение наиболее оптимально? Вопрос риторический...

И остальные 10 ног просто будут болтаться в воздухе, если что-то коротнет на шине, то даже на дисплей ничего не выведешь, чтоб показать ошибку. И какое решение наиболее оптимально? Вопрос риторический...

[jcxz 359]

14 минут назад, dimka76 сказал:

Kinetis от NXP и PSoC от Cypress. Оба Cortex-Mxx.
Одни на основной плате, другой на плате кнопок.
Как-то не побрезговали расширением номенклатуры.

Не зная всех исходных - невозможно судить. Здесь может быть сокращение номенклатуры компонентов разных выпускаемых изделий: Есть разные изделия, содержащие одинаковые компоненты = плата индикации/кнопок есть готовая, её и поставили. С тем МК, что там был.

А основную плату было проще сделать на чём-то другом. Так-же может просто невозможно было реализовать на одинаковых МК - периферия и возможности у всех разные. Как и требования ТЗ.

4 минуты назад, mantech сказал:

И остальные 10 ног просто будут болтаться в воздухе

А в ваших изделиях нет "болтающихся в воздухе ног"? Вы их кусачками выкусываете???  

4 минуты назад, mantech сказал:

, если что-то коротнет на шине, то даже на дисплей ничего не выведешь, чтоб показать ошибку.

Здесь вообще не поняол о чём речь...

Изделия должны разрабатываться так, чтобы не "коротило на шине". Ежли что...

[mantech 132]

2 часа назад, dimka76 сказал:

Я примерно к тому и веду, что зачем сегодня эти куцие PIC16 и AVR, когда дешевле Cortex и ресурсов в нем побольше за меньшие деньги.
И лицензионный софт для Cortex не нужен. Для него есть свободное ПО.

Вы знаете серийность, которую предполагает ТС? Я не знаю, может он сделает сотню своих штуковин и поймет, что с китайцами на этом рынке конкурировать глупо, а ваш PY32 я даже не знаю, как к нему подойти, где доки, как прошивать, какой софт, исходники и пр. Для АВР у меня все есть, и я могу сделать эту прогу в разы быстрее, а значит дешевле и лучше, так что не все так однозначно...

Ну и для АВР уже давным давно есть свободный софт.

4 минуты назад, jcxz сказал:

А в ваших изделиях нет "болтающихся в воздухе ног"? Вы их кусачками выкусываете???  

Разумеется выкусываю, как иначе-то)))))))))))

Вы ж сами написали, что на одной шине - экономия ног, так, а зачем их экономить, если свободных полно, не?)))))

5 минут назад, jcxz сказал:

Изделия должны разрабатываться так, чтобы не "коротило на шине". Ежли что...

Датчик выносной, может что перевихаться и коротнуть...

[jcxz 359]

43 минуты назад, mantech сказал:

Вы ж сами написали, что на одной шине - экономия ног, так, а зачем их экономить, если свободных полно, не?)))))

Например для того, чтобы взять мелкий 8-ногий PY32F002AL15S и всё упихнуть в минимальный размер платы. 

Если всё повесить на один I2C, то 8-и ног PY32F002AL15S хватит на всё: и на датчик+дисплей и на SWD и даже на пару кнопок, про которые ТС возможно "забыл" упомянуть.

А вот с вашим SPI+I2C - не хватит ни на что.

ЗЫ: Среди PIC-ов вроде тоже есть мелкие 8-ногие корпуса.

43 минуты назад, mantech сказал:

Датчик выносной

Это только ваши фантазии. ТС такого не писал.

А если судить по тому, что выбран I2C, а не UART, то датчик скорее встроенный, а не выносной. Для выносного следует выбирать UART.