Форум РадиоКот

Доброго времени суток! У меня вопрос, может кто и занимался протоколированием шины I2C на МК(если у МК нет готовой шины I2C). Tiny13 имеет 1К Flash. Есть 6 портов из них 2 хочу использовать под шину I2C. Остальных 4 порта мне вполне хватит для работ, мне не хватает Flash памяти. У меня следующее:

1) Могу в МК выделить 500байт под протокол I2C, остальное пространство мне нужно для других целей.
2) Могули я целиком записывать готовые функции в EEPROM и во время работы МК по очереди считывать эти функции и работать с ними?
3) Сколько приблизительно весит готовая функция протокола I2C?

Всё это мне нужно для RGB переключений светодиодов. Если идея такая бредовая - то разясните это пожалуйста вескими аргументами, чтобы я не возвращался к этой теме. А то думаю над этим давно! Ну а если технически это возможно, то буду очень рад это реализовать в своем производстве. Спасибо!

500 байт - хватит. Функции небольшие.

Спасибо! А со следующим как обстоит дело?

2) Могули я целиком записывать готовые функции в EEPROM и во время работы МК по очереди считывать эти функции и работать с ними?

SPM - Store Program Memory - описание в help'е AVRStudio. Т.е. считывать из внешки, записывать во флеш и передавать на нее управление.

Спасибо! Посмотрю описание AVRStudio!

king-live писал(а):Доброго времени суток! У меня вопрос, может кто и занимался протоколированием шины I2C на МК(если у МК нет готовой шины I2C). Tiny13 имеет 1К Flash. Есть 6 портов из них 2 хочу использовать под шину I2C. Остальных 4 порта мне вполне хватит для работ, мне не хватает Flash памяти. У меня следующее:

1) Могу в МК выделить 500байт под протокол I2C, остальное пространство мне нужно для других целей.
2) Могули я целиком записывать готовые функции в EEPROM и во время работы МК по очереди считывать эти функции и работать с ними?
3) Сколько приблизительно весит готовая функция протокола I2C?

1) могешь
2) МК может работать только с тем, что у него во флеш-памяти программ. Нет однозначно. Если через бутлодер, так под него еще целую секцию выделять надо, да еще под работу с внешней EEPROM-кой. Овчинка выделки не стоит. Лучше МК взять чуть потолще.
3) посмотри на сайте Atmel в секции Appnotes - там есть примеры с программной реализацией I2C. Номера, кажется, 300 и 302. Не найдешь - скину из своих закромов .
Сам делал лет 15 назад, подзабыл, так что звиняй.

Если I2C мастер, то элементарно делается программная реализация, весит порядка 400-500 байт. Если нужно I2C slave - настоятельно рекомедую контроллер с аппаратным TWI (у тини - USI) на борту, тк с программной реализацией очень сильно поколдовать прийдется, особенно учитывая, что Ваше устройство помимо I2C, еще что-то делать должно Посмотрите на tiny25 - вместо 13-й по ногам совместима полностью, а если плата не сделана еще, то возможности выбора расширяются

считывать из внешней EEPROM функции и исполнять их вы не сможете, и SPM вам не поможет хотя бы по следующим двум причинам: а) число циклов записи в FALSH очень ограниченно и б) накладные расходы по "самопрограммированию" сожрут остатки памяти тиньки.

что такое вы собрались пихать в тини13 для управления RGB, что вам еще внешнее ПЗУ требуется?! я свободно на этой тиньке делал управление RGB светодиодом с плавным (и случайным) изменением цвета, причем даже с определенными извращениями (в смысле - излишествами).

что такое вы собрались пихать в тини13 для управления RGB, что вам еще внешнее ПЗУ требуется?! я свободно на этой тиньке делал управление RGB светодиодом с плавным (и случайным) изменением цвета, причем даже с определенными извращениями (в смысле - излишествами).

Хотел 20-30 вариантов переключения сделать (не только плавного) У меня вмещается около 7-8 вариантов. Не хочется писать всё время на заказ, отнимает время. хотел загнать во внутрь больше вариантов, чтобы клиент сам выбирал по вкусу и оставил нужные. (с помощью кнопки на плате сохранять номер функции (вариант программы) во Flash) Вроде как получилосьбы что клиет сам прошил МК с теми вариантами которые ему нужны. Ну это чисто теоретические расчёты. В жизни бывает намного сложнее что-то реализовать. Эта разработка былабы сильным конкурентом, к китайским готовым устройствам. Стоимость готового китайского $5-$6, но выходной ток у них слабый. Вот и хотелосьбы его заместить на рынке. attiny13 это единственная дешёвая МК которая поставляется к нам на рынок Узбекистана. Всё остальное уже не конкурентноспособна.

king-live писал(а):Эта разработка былабы сильным конкурентом, к китайским готовым устройствам. Стоимость готового китайского $5-$6, но выходной ток у них слабый. Вот и хотелосьбы его заместить на рынке. attiny13 это единственная дешёвая МК которая поставляется к нам на рынок Узбекистана. Всё остальное уже не конкурентноспособна.

Потеснить ценой китайцев? Хотя есть способ: Вы свои изделия будете штамповать большими партиями (десятки тысяч) в Китае. Это не шутка. Мы сами так делаем.

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

king-live писал(а): Всё это мне нужно для RGB переключений светодиодов. Если идея такая бредовая - то разясните это пожалуйста вескими аргументами, чтобы я не возвращался к этой теме. А то думаю над этим давно! Ну а если технически это возможно, то буду очень рад это реализовать в своем производстве. Спасибо!

Когда я такое делал( на мк51) я использовал систему макроязыка для описания эффектов. Суть сводилась к следующему: если старший бит 1, то все остальные являются командой, если 0 - остальные биты - описатель состояния выходного порта. Среди команд было:
- управление скоростью
- описатели циклов (количество воспроизведений заданного участка световой программы) и еще какие-то,уже не помню
Делалось устройство на 4 канала.
Обработчик элементарный. Сама программа переключений в виде таблицы легко пишется и модифицируется.

Выдрал модуль и2с из одного проекта на авр. Может чем поможет.

coredumped писал(а):с программной реализацией очень сильно поколдовать прийдется

Это почему?

Спасибо! Начну писать, а там посмотрим. Если даже не получится что я задумал, то хотябы знания останутся. А знание на сегодняшний день - это сила.

Dmitry Dubrovenko писал(а):

coredumped писал(а):с программной реализацией очень сильно поколдовать прийдется

Это почему?

Вы slave программный делали? Если у Вас транзакции идут с паузами, то все более-менее работает, а если на шине полно устройств, с разными адресами, и обмен идет интенсивный? Если у Вас есть готовое, работающее, решение - снимаю шляпу!

вообще-то спор излишен
есть прекрасно проработанные варианты исполнения светодинамики на 8-20-выводных кристаллах (AVR,PIC&MCS51)
притом базовый фрагмент программы весьма короткий. а переписывать приходится исключительно прикладной участок по эаранее заданным характеристикам ДЛЯ КОНКРЕТНОГО ПРИМЕНЕНИЯ, что весьма быстро и просто(хош встроенный. хош из внешнего ПЗУ - но такого еще не требовалось на практике)
однако... пока что это коммерческий проект... хотя и потребность не очень велика 2-3 конструкции в год...

BOB51 писал(а):а переписывать приходится исключительно прикладной участок по эаранее заданным характеристикам ДЛЯ КОНКРЕТНОГО ПРИМЕНЕНИЯ, что весьма быстро и просто(хош встроенный. хош из внешнего ПЗУ - но такого еще не требовалось на практике)
однако... пока что это коммерческий проект... хотя и потребность не очень велика 2-3 конструкции в год...

Да, хорошая идея Написать интерпретатор, а сценарии можно держать и во внешней епромине.

в большинстве случаев даже tiny12 вполне достаточно
а вот для ПИКов - весьма плохо, разве что для 16f688-подобных

coredumped писал(а):Вы slave программный делали? Если у Вас транзакции идут с паузами, то все более-менее работает, а если на шине полно устройств, с разными адресами, и обмен идет интенсивный?

Так будет ограничение по скорости, это - да.
А в остальном-то, в чём проблема?

Dmitry Dubrovenko писал(а):Так будет ограничение по скорости, это - да. А в остальном-то, в чём проблема?

В этом как раз и проблема. TWI/I2C и без того не быстрая шина.