Но статья же не про архитектуры вычислительных устройств, а про ОЗУ в общем смысле, разве не так? По крайней мере в заголовке статьи ни слова о узкозаточенности материала. Тут было бы полезнее вспомнить про динамическое и статическое ОЗУ, двухпортовое озу, совмещение циклов чтения и записи, поскольку среди заявленных хабов есть Схемотехника и Электроника для начинающих.
Ну если уж подхватить тему занудства, то
Гарвардская архитектура подразумевает всего лишь разделение потока команд и потока данных. И называть ОЗУ в рамках этой архитектуры просто буфером будет ошибкой. Да, гарвардская архитектура и её модификации успешно используют в потоковых вычислениях, в частности в сигнальных процессорах. Однако кроме буферизации входного потока данных ОЗУ в этой архитектуре используется и для сохранения результатов вычислений.
С другой стороны, все эти ОЗУ, ПЗУ, регистры и кэши, как и прочие устройства хранения - просто устройства для запоминания информации, имеющие функциональные отличия только в рамках предусмотренного инженером-конструктором применения. Например, как Вы и указали, РОН вполне справляется с функцией ОЗУ, коим по сути и являются, а SD-карточка в некоторых условиях вполне неплохо справляется с буферизацией данных.
В процессе работы память выступает в качестве буфера между накопителем и процессором, то есть данные сперва считываются с жесткого диска (или другого накопителя) в оперативную память и уже затем обрабатываются центральным процессором.Такая схема применяется, потому что процессор - очень быстрое устройство и ему требуется быстро получать доступ к нужным данным и командам, иначе он будет простаивать и производительность системы уменьшится, а так как жёсткий диск и SSD не могут обеспечить необходимую скорость, все нужные данные считываются и перемещаются в более быструю оперативную память и хранятся там, пока не понадобятся процессору для обработки.
Уважаемый автор! Спешу Вас расстроить, но оперативная память это несколько больше, чем буфер между HDD и процессором.
Большой Взрыв это одномоментная раскатка базового бэкапа из распределенных систем хранения данных в виде черных дыр
Ну отчего же одномоментная. Просто по окончании бэкапа на нашу систему подали сигнал от тактового генератора. Небыло ничего и вдруг- БВ, и все закрутилось.
И кстати, если поставить наш мир на отладку, заметим ли мы это после возобновления работы? :)
:) Да все разве вспомнишь. У меня был комплект Абеля и Григорьева основным. И хотя у меня основное направление было разработка цифровых вычислительных устройств, асм-ом тоже баловался. Ндя, прикольное время было! ))))
Надеюсь, этого руководства было достаточно, чтобы вы сориентировались в общем принципе устройства архитектуры x86
Нда… Видимо, новое поколение гораздо умнее, статьи достаточно. Это мы изучали х86 по четырёхкнижию Григорьева " Микропроцессор i486. Архитектура и программирование".
ЗЫ: Не обижайтесь, просто улыбнуло, юность вспомнил. Григорьев настольной книгой был, аки Библия для верующего. И Абель, конечно же. Труд Григорьева до сих пор считаю лучшей книгой для понимания «как оно работает», и пофиг что 486 — многое актуально и сейчас
ЗЗЫ: А по-настоящему понял «как оно работает» когда на предвыпускном курсовике спроектировал на машкомплекте специализированный процик. И спасибо Пьявченко Алексею Олеговичу за полученные знания.
Странно, что в списке SCADA-систем делает CoDeSys? Ну да, есть возможность визуализации, но не SCADA же.
ЗЫ: К ответу на опрос — давно уже пользуемся SCADA КАСКАД
В конце 90-х такой задачей занимался в коллективе СКБИМ, начинали на 10-тонной машине для испытаний на растяжение ИР100. Задавались параметры испытания, на образец навешивался тензодатчик и запускали испытания. Перед разрывом тензодатчик убирался и образец дорывали уже по индуктивному датчику перемещения. Программа определяла момент разрыва, запускался автоматический расчет по ГОСТ1497 и прога в графическом виде показывала все пределы текучести, модуль упругости и пр. А оператор ли соглашался с авторасчетом, или имел возможность в графическом же режиме ввести коррекцию, т.е. получался некий полуавтомат. К сожалению, за давностью лет никаких картинок привести не смогу.
В «Ленэлектронмаше» мы делали АСУ для Краснодарского завода измерительных приборов. 15 000 человек, 5000 номенклатурных приборов. Крупнейшее градообразующее предприятие, оно существует до сих пор
По факту — ЗИП как предприятие давно не существует
Интересная особенность обозначений на АЭС — включенные и открытые элементы подсвечивают красным, а выключенные и закрытые — зеленым
Не только на АЭС, а в целом в электроэнергетике на «светлых» щитах красным обозначают элементы, которые включены/замкнуты/под напряжением, зеленым — отключенные/обесточенные/разомкнутые. Красный — цвет опасности. «Светлый» щит подразумевает, что и включенные, и выключенные элементы( коммутационные аппараты) всегда светятся, но разными цветами. На светлом щите удобно отображать неисправности и изменения состояния элемента. Например, при изменении состояния из «выключено» во «включено», элемент будет привлекать внимание оператора морганием красным цветом до тех пор, пока оператор не подтвердит квитированием, что он увидел ситуацию.
Микроконтроллер и процессор — более высокий уровень, уровень использования вычислительного устройства. То, что описано в статье — уровень разработчика архитектуры вычислительного устройства; на этом уровне реализуется исполнение скомпилированного машинного кода внутри вычислительного ядра (декодирование команд, выборка и подготовка операндов, исполнение команды и пр.).
По моему мнению, предложенный в статье вариант — наиболее наглядный и простой способ почувствовать как реализуется выполнение команд внутри ядра процессора на уровне декодирования и исполнения микрокода. Ширины в 8 бит — вполне достаточно для этих целей.
Все подчиненные устройства сидят на одном порту, соответственно параметры порта общие для всех подключенных к нему устройств. А вот адрес и таймауты — для каждого свои (а так же некоторые специфичные для протокола параметры — тоже свои). PS: на значения таймаутов и совпадение адресов не обращайте внимания, картинки только для примера.
rsashka, не совсем так. Я не стал указывать на необходимость соблюдения таймаутов по причине того, что вопрос был о другом. Человек, реализовавший протокол ModBusRTU должен знать и о таймаутах. И хотя бы открывал wiki, где сказано:
Сообщения разделяются по паузе в линии. Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов.
Shpiler
Нет никаких проблем подключить разные протоколы типа «запрос-ответ», давно и успешно используем разнородные в плане протокола подключения где это обосновано. Только убедитесь, что запросы и ответы в Вашем протоколе не будут восприняты другими устройствами как запросные (корректные или не корректные — не суть). Для ModBusRTU достаточно, чтобы первый байт Ваших запросных и ответных посылок не совпадал с адресом ModBus-устройств (первый байт посылок) и не был бы широковещательным.
Но статья же не про архитектуры вычислительных устройств, а про ОЗУ в общем смысле, разве не так? По крайней мере в заголовке статьи ни слова о узкозаточенности материала. Тут было бы полезнее вспомнить про динамическое и статическое ОЗУ, двухпортовое озу, совмещение циклов чтения и записи, поскольку среди заявленных хабов есть Схемотехника и Электроника для начинающих.
Ну если уж подхватить тему занудства, то
Гарвардская архитектура подразумевает всего лишь разделение потока команд и потока данных. И называть ОЗУ в рамках этой архитектуры просто буфером будет ошибкой. Да, гарвардская архитектура и её модификации успешно используют в потоковых вычислениях, в частности в сигнальных процессорах. Однако кроме буферизации входного потока данных ОЗУ в этой архитектуре используется и для сохранения результатов вычислений.
С другой стороны, все эти ОЗУ, ПЗУ, регистры и кэши, как и прочие устройства хранения - просто устройства для запоминания информации, имеющие функциональные отличия только в рамках предусмотренного инженером-конструктором применения. Например, как Вы и указали, РОН вполне справляется с функцией ОЗУ, коим по сути и являются, а SD-карточка в некоторых условиях вполне неплохо справляется с буферизацией данных.
Уважаемый автор! Спешу Вас расстроить, но оперативная память это несколько больше, чем буфер между HDD и процессором.
Далее, извините, читать не стал.
Ну отчего же одномоментная. Просто по окончании бэкапа на нашу систему подали сигнал от тактового генератора. Небыло ничего и вдруг- БВ, и все закрутилось.
И кстати, если поставить наш мир на отладку, заметим ли мы это после возобновления работы? :)
А Дао тоже был, да. По обложке вспомнил.
Нда… Видимо, новое поколение гораздо умнее, статьи достаточно. Это мы изучали х86 по четырёхкнижию Григорьева " Микропроцессор i486. Архитектура и программирование".
ЗЫ: Не обижайтесь, просто улыбнуло, юность вспомнил. Григорьев настольной книгой был, аки Библия для верующего. И Абель, конечно же. Труд Григорьева до сих пор считаю лучшей книгой для понимания «как оно работает», и пофиг что 486 — многое актуально и сейчас
ЗЗЫ: А по-настоящему понял «как оно работает» когда на предвыпускном курсовике спроектировал на машкомплекте специализированный процик. И спасибо Пьявченко Алексею Олеговичу за полученные знания.
Предлагаю начать с оголтелых либералов.
ЗЫ: К ответу на опрос — давно уже пользуемся SCADA КАСКАД
По факту — ЗИП как предприятие давно не существует
По моему мнению, предложенный в статье вариант — наиболее наглядный и простой способ почувствовать как реализуется выполнение команд внутри ядра процессора на уровне декодирования и исполнения микрокода. Ширины в 8 бит — вполне достаточно для этих целей.
rsashka, не совсем так. Я не стал указывать на необходимость соблюдения таймаутов по причине того, что вопрос был о другом. Человек, реализовавший протокол ModBusRTU должен знать и о таймаутах. И хотя бы открывал wiki, где сказано:
Нет никаких проблем подключить разные протоколы типа «запрос-ответ», давно и успешно используем разнородные в плане протокола подключения где это обосновано. Только убедитесь, что запросы и ответы в Вашем протоколе не будут восприняты другими устройствами как запросные (корректные или не корректные — не суть). Для ModBusRTU достаточно, чтобы первый байт Ваших запросных и ответных посылок не совпадал с адресом ModBus-устройств (первый байт посылок) и не был бы широковещательным.