Есть GSM-модуль, основу описания работы с которым составляют AT-команды для общения с МК. Обмен данными выполняется по UART, который настроен на определённую скорость обмена. Тут вопросов нет. Далее читаю мануал и некоторые статьи вроде этой Для меня пока непонятно, что собой представляет к примеру команда AT+CREG?
Как будет выглядеть одномерный массив для передачи в UART? Правильно я понимаю, что каждый символ из данной строки нужно перевести в ASCII-коды?
Т.е. руководствуясь вот этой таблицей имеем
A - 0x41
T - 0x54
"+"- 0x2B
C - 0x43
R - 0x52
E - 0x45
G - 0x47
"?" - 0x3F
В итоге для отправки команды AT+CREG? по UART микроконтроллер должен отправить строку {0x41, 0x54, 0x2B, 0x43, 0x52, 0x45, 0x47, 0x3F}. Мои представления правильные или где-то не так думаю?

Почти правильные. Микроконтроллер должен отправить строчку "AT+CREG?\r\n". Особое внимание - на перевод строки.
Перекодировкой этого безобразия в ascii-коды вручную заниматься ни в коем случае не надо - иначе этот код невозможно будут читать.

в тонкости пока не вникаю, хочу понять - команда AT+CREG? соответствует последовательности {0x41, 0x54, 0x2B, 0x43, 0x52, 0x45, 0x47, 0x3F}?

Да. Но чтобы модуль понял что это именно АТ команда надо еще добавить 0x0D,0x0A.

Немного поправлю:
Для того, чтобы GSM-модуль воспринял команду - в конце символьной последовательности должен быть символ (байт) с кодом 0x0D. Байт с кодом 0x0A в конце команды - избыточен.

т.е. команда AT+CREG? соответствует последовательности {0x41, 0x54, 0x2B, 0x43, 0x52, 0x45, 0x47, 0x3F, 0x0D}?
где можно подробнее на эту тему почитать? В мануале сразу начинают с АТ-команд без их представления в HEX

МК сам передаст HEX коды этих символов. Это работа компилятора.

Понятия не имею. Мне всегда казалось что это должно быть ясно интуитивно
Можно погуглить что-нибудь по поводу представления строк в памяти ЭВМ.

Представлять байты команды в шестнадцатиричном виде никому не приходит в голову, поскольку передача команды модему на языке Си обычно выглядит как-то так:

USART_WriteString("AT+CREG?\r");

Модемы также понимают utf-8 т.к. в utf-8 первые 127 символов (буквы латинского алфавита) совпадают с ascii и имеют размер 1 байт.

Хочется до сути докопаться. Напишу я эту функцию и как потом понять - она не работает или что-то с модемом? В самом начале мне проще сначала с осциллографом своими глазами байты смотреть для уверенности в совпадении своих представлений о работе функции. Иначе можно было бы всё запихать в одну функцию вроде DeviceInit(), Device_Rabota(), Device_Off();

И что вас смущает, функция вроде USART_WriteString() отправит в линию ASCII представление написанных символов, в таком виде вы их и увидите осциллографом. Таблицей можете перевести из ASCII в биты.
И если подтверждение модемом не выключено, то примите при верной посылке от модема OK.

смущает нестандартность функции. Для её использования нужно сначала подключить библиотеку(какую?) и выполнить соответствующие настройки. Простор для появления ошибок тут широкий, хотя появилась мысль прицепить параллельно линии COM-порт компа и смотреть обмен. В какой библиотеке следует искать функцию USART_WriteString()? И как её приспособить к LPC1778?

По LPC1778 полно информации. Настроить UART можно или силами хидера LPC177x_8x.h, что в CMSIS, по мануалу, или воспользовавшись библиотекой lpc177x_8x_uart.c, что находится в том же архиве CMSIS (папка lpc177x_8x\Drivers\), там же есть примеры по настройке и использованию периферии (lpc177x_8x\Examples). Сам пользовался для отладки через UART функцией printf() через вызов UARTPutChar из debug_frmwrk.c, т.к. там все настроено было из коробки в режиме 115200-8N.
Если боитесь ошибиться, разбейте работу на 2 этапа:
1. запустите UART, напишите функцию передачи строки и через мост UART<Virtual COM Port> проверьте, что все работает;
2. запустите управление модемом, и все должно получиться!
А USART_WriteString() есть не что иное, как посимвольная передача (функция UART_SendByte() из lpc177x_8x_uart.c) в цикле до тех пор, пока строка не станет равна 0.

Когда я начинал осваивать GSM модуль, использовал 4 простых адаптеров. 2 шт UART-COM и 2шт COM - USB. И два экземпляра программы advanced serial port monitor. И смотрел оба потока: из мк в модуль и наоборот. Очень помогло) И ни каких танцев с осциллографом.

А можно просто сниффером на порт встать и смотреть