Я вот не так давно разбирал документацию по волновому синтезу музыкальных звуков. Так вот, структура файлов там явно ориентирована на 16-разрядный процессор с выравниванием всего, что угодно, на 2 байта.
Раз ее в свое время выбрали в качестве “общего знаменателя” для включения в стандарт, значит, она была достаточно распространенной. Возможно, в классе DSP.
Применить MODBUS и никаких проблем. 100% гарантия передачи. Даже если что то глюкнет, Сам протокол повторит.
Это как? Читал я библиотеки на ночь - ретрейнов в них не видел.
Это у кого какие библиотеки . В мои даже параметр есть для настройки - количество ретраев до возврата ошибки. Мне обычно 10 хватает, чтобы килобайтные массивы на 115200 на 15 метров пересылать. Ну а где нет ретраев, возврат статуса передачи по любому есть. Вот блок ошибок передачи из первой попавшейся библиотеки:
[details="Спойлер"]
//Exception Codes
//Custom result codes used internally and for callbacks but never used for Modbus responce
enum ResultCode {
EX_SUCCESS = 0x00, // Custom. No error
EX_ILLEGAL_FUNCTION = 0x01, // Function Code not Supported
EX_ILLEGAL_ADDRESS = 0x02, // Output Address not exists
EX_ILLEGAL_VALUE = 0x03, // Output Value not in Range
EX_SLAVE_FAILURE = 0x04, // Slave or Master Device Fails to process request
EX_ACKNOWLEDGE = 0x05, // Not used
EX_SLAVE_DEVICE_BUSY = 0x06, // Not used
EX_MEMORY_PARITY_ERROR = 0x08, // Not used
EX_PATH_UNAVAILABLE = 0x0A, // Not used
EX_DEVICE_FAILED_TO_RESPOND = 0x0B, // Not used
EX_GENERAL_FAILURE = 0xE1, // Custom. Unexpected master error
EX_DATA_MISMACH = 0xE2, // Custom. Inpud data size mismach
EX_UNEXPECTED_RESPONSE = 0xE3, // Custom. Returned result doesn't mach transaction
EX_TIMEOUT = 0xE4, // Custom. Operation not finished within reasonable time
EX_CONNECTION_LOST = 0xE5, // Custom. Connection with device lost
EX_CANCEL = 0xE6, // Custom. Transaction/request canceled
EX_PASSTHROUGH = 0xE7, // Custom. Raw callback. Indicate to normal processing on callback exit
EX_FORCE_PROCESS = 0xE8 // Custom. Raw callback. Indicate to force processing on callback exit
};
[/details]
Надеюсь прочитать код ответа и в случае ошибки послать ещё раз труда не составит?
Про exception response я знаю.
Но вот, похоже, что ретрейнв - это “расширение” от автора конкретной библиотеки, равно как и коды 0xEn.
В “MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b3, April 26, 2012”. Такового не наблюдается.
Я, конечно рад за ваши ретрейны, но справедливости ради - они не протокольные.
MODBUS over Serial Line
Specification & Implementation guide
V1.0
Из объяснений рис.7
When a reply is received, the Master checks the reply before starting the data processing. The checking may result in an error, for example a reply from an unexpected slave, or an error in the received frame. In case of a reply received from an unexpected slave, the Response time-out is kept running. In case of an error detected on the frame, a retry may be performed.
If no reply is received, the Response time-out expires, and an error is generated. Then the Master goes into “Idle” state, enabling a retry of the request. The maximum number of retries depends on the master set-up.
Особенно последнее предложение. У меня как раз присутствует настройка максимального числа повторных попыток.
А в “MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b3, April 26, 2012”. при объяснении ошибки 08 - MEMORY PARITY ERROR - говориться что при возникновении этой ошибки может быть инициирована повторная попытка передачи данных.
Ну, понятно - на откуп реализации.
Императивного требования к осуществлению ретрейна нет, поэтому где-то делается, где-то нет.
вот, а если бы был выбран контроллер под задачу и темы бы не было )))
Modbus - это хорошо. Но эти его интервалы в 1,5 и 3,5 символа… А если я не могу их выделить или же обеспечить, тогда чего?
Ответ давно известен - переходи на ассемблер!на нем-то вообще что угодно сварганишь.
2 лайка
С блэкджеком и ш…шшш… шариками )))
Тише, тише… не дразни дедиван-а.)