Доброго времени суток всем Кошачьим и их родичам!
После просмотра ролика о новых «окошках» и лазания по рынкам в поисках удобоваримого варианта программатора ко множеству мелкосхемок вечнообновляемого сообщества забугорных производителей все чаще появляется мыслишка «а не послать бы их (производителей ПО и железок)…».
А вместе с тем и другая – пора собственную альтернативную железяку мурручить, да с подходом, позволяющим одинаково успешно пользоваться как любыми базовыми семействами, так и вновь появляющимися изделиями с учетом интересов ВЕЧНОЗЕЛЕНОЙ ЖАБЫ – хозяйки семейного бюджета.
Базовая платформа представляется как мультимикропроцессоное (мультимикроконтроллерное) ядро с «открытой» модульной структурой и, естественно, открытым кодом и схемотехникой.
Наращивание сложности и уровня системы может осуществляться постепенно по возникновению такой потребности у потребителя.
Ограничения на применение элементной базы:
Микросхемы, применяемые в базовом ядре должны быть свободно доступны к покупке на территории всех участников проекта (бывшего Союза).
Техническая документация к данным ИС должна быть свободнодоступна как на языке производителя ИС, так и на русском языке.
Не допускается (или ограниченно допускается) применение ИС, для написания программ к которым используются только ПЛАТНЫЕ среды разработки (или урезанные демо-версии).
Программное обеспечение для используемых в системе микроконтроллеров должно быть представлено исключительно свободнораспространяемыми полными версиями!
(Или версиями, требующими бесплатной регистрации).
При разработке схемотехники и печатных плат, а также программного обеспечения для использования на ПК для связи с ядром и/или модулями должно максимально применяться свободно-бесплатное общедоступное программное обеспечение (чего к сожалению нельзя сказать о системном ядре WIN98/WINXP – пока прийдется терпеть это вынужденное зло).
Проект может быть только на НЕКОММЕРЧЕСКОЙ основе.
Поскольку я, как автор данной темы изначально имел базовую подготовку на INTEL- совместимых семействах (8080-Z80-MCS51) и лишь затем перешел к работе с AVR-PIC, причем с проработкой их документации и структуры команд ассемблера с точки зрения специалиста MCS51, то данная тема в первую очередь может заинтересовать именно любителей данного семейства.
Возможно этот подход и консервативен, но глобально-корпоративные интересы производителей электронных компонентов и прикладного программного обеспечения явно направлены на привязку потребителя исключительно к своему продукту, что весьма плохо с точки зрения свободы выбора оптимальных решений при проектировании и изготовлении не только «любительских» конструкций.
Так сложилось, что вместо объективной оценки сильных и слабых сторон того или иного семейства МК на «постсоветском» (и не только) пространстве вместо нормального конструктивного обсуждения фанаты того или иного семейства МК весьма неадекватно воспринимают любое замечание специалиста, знакомого с другим семейством МК, сводя все в конце-концов к стандартному спору «кто покруче».
Подобный подход для работы в этой теме восприниматься не будет
(так же как и выяснение отношений на чем писать программы на С или на asmе)!
Каждый участник темы может предоставлять то, с чем он свободно разбирается, однако для удобства восприятия остальными участниками (особо в случае просьбы чего-то прокомментировать) следует учитывать возможности сообщества… и исходные требования ядра системы и/или автономных модулей (применяемые протоколы обмена, аппаратные средства для буферизации отдельных элементов системы, структуры шин связи) общего назначения чтобы его конструкция могла быть успешно использована другими.
Вот пока собственно и все.
В следующем сообщении выложу свое видение структуры ядра для обсуждения и приема замечаний.
После просмотра ролика о новых «окошках» и лазания по рынкам в поисках удобоваримого варианта программатора ко множеству мелкосхемок вечнообновляемого сообщества забугорных производителей все чаще появляется мыслишка «а не послать бы их (производителей ПО и железок)…».
А вместе с тем и другая – пора собственную альтернативную железяку мурручить, да с подходом, позволяющим одинаково успешно пользоваться как любыми базовыми семействами, так и вновь появляющимися изделиями с учетом интересов ВЕЧНОЗЕЛЕНОЙ ЖАБЫ – хозяйки семейного бюджета.
Базовая платформа представляется как мультимикропроцессоное (мультимикроконтроллерное) ядро с «открытой» модульной структурой и, естественно, открытым кодом и схемотехникой.
Наращивание сложности и уровня системы может осуществляться постепенно по возникновению такой потребности у потребителя.
Ограничения на применение элементной базы:
Микросхемы, применяемые в базовом ядре должны быть свободно доступны к покупке на территории всех участников проекта (бывшего Союза).
Техническая документация к данным ИС должна быть свободнодоступна как на языке производителя ИС, так и на русском языке.
Не допускается (или ограниченно допускается) применение ИС, для написания программ к которым используются только ПЛАТНЫЕ среды разработки (или урезанные демо-версии).
Программное обеспечение для используемых в системе микроконтроллеров должно быть представлено исключительно свободнораспространяемыми полными версиями!
(Или версиями, требующими бесплатной регистрации).
При разработке схемотехники и печатных плат, а также программного обеспечения для использования на ПК для связи с ядром и/или модулями должно максимально применяться свободно-бесплатное общедоступное программное обеспечение (чего к сожалению нельзя сказать о системном ядре WIN98/WINXP – пока прийдется терпеть это вынужденное зло).
Проект может быть только на НЕКОММЕРЧЕСКОЙ основе.
Поскольку я, как автор данной темы изначально имел базовую подготовку на INTEL- совместимых семействах (8080-Z80-MCS51) и лишь затем перешел к работе с AVR-PIC, причем с проработкой их документации и структуры команд ассемблера с точки зрения специалиста MCS51, то данная тема в первую очередь может заинтересовать именно любителей данного семейства.
Возможно этот подход и консервативен, но глобально-корпоративные интересы производителей электронных компонентов и прикладного программного обеспечения явно направлены на привязку потребителя исключительно к своему продукту, что весьма плохо с точки зрения свободы выбора оптимальных решений при проектировании и изготовлении не только «любительских» конструкций.
Так сложилось, что вместо объективной оценки сильных и слабых сторон того или иного семейства МК на «постсоветском» (и не только) пространстве вместо нормального конструктивного обсуждения фанаты того или иного семейства МК весьма неадекватно воспринимают любое замечание специалиста, знакомого с другим семейством МК, сводя все в конце-концов к стандартному спору «кто покруче».
Подобный подход для работы в этой теме восприниматься не будет
(так же как и выяснение отношений на чем писать программы на С или на asmе)!
Каждый участник темы может предоставлять то, с чем он свободно разбирается, однако для удобства восприятия остальными участниками (особо в случае просьбы чего-то прокомментировать) следует учитывать возможности сообщества… и исходные требования ядра системы и/или автономных модулей (применяемые протоколы обмена, аппаратные средства для буферизации отдельных элементов системы, структуры шин связи) общего назначения чтобы его конструкция могла быть успешно использована другими.
Вот пока собственно и все.
В следующем сообщении выложу свое видение структуры ядра для обсуждения и приема замечаний.
слева!