andrewlekar

DMA при работе с UART позволит вам снизить нагрузку на процессор при передаче больших объёмов данных. Если ресурсов процессора хватает или объём данных небольшой, то вам без DMA вполне можно обойтись. Отправляйте байт, в цикле дожидайтесь пустого передатчика, повторяйте.

Человек под бомбами пишет, его можно понять.

Вы там поаккуратнее с частым переподключением GPRS. Есть мнение, что некоторые операторы за это банят. У меня было такое, что модуль напрочь отказывался цепляться к GPRS, а на следующий день работал как ни в чём не бывало.

10 евро дороговато. Мы SIM900R в 2 раза дешевле берём. Но у нас опт, пусть и небольшой и РФ. Брака пока что не встретил, всё работает как часы. Почти 10000 устройств работает и в ремонт из-за модуля попадает только после удара молнии.

Если экономия денег не имеет максимального приоритета, то присмотритесь всё же к модулям 3G. С точки зрения потребления есть преимущества: - ток в пике ниже, чем у GPRS. - приоритет у 3G трафика выше, чем у GPRS. - скорость передачи выше. В итоге быстрее подключитесь к серверу, быстрее передадите и раньше уснёте. Цены на 3G модули падают, поэтому рентабельность решения будет расти.

Кстати, вы учли, что IAP использует немного вашей ОЗУ? Вот из даташита:

Почему не работает, не знаю, но прокомментирую саму реализацию. Размещать бутлоадер в конце вполне разумно, у меня так же сделано. Но идея вызывать загрузчик из приложения не очень хорошая. Тут многие сталкивались с проблемами при таком подходе и в итоге переходили к другой схеме: сначала всегда стартует загрузчик и проверяет, нужно ли обновлять приложение или стартовать имеющееся.

Я не работал с 9602, только с 9603. Но когда мы исследовали этот вопрос при выборе модуля, то решили, что 9602 на самом деле не умеет GPS. Вот выдержка из даташита:

У меня в своё время на прерывания драйвер тоже не заработал (LPC1768). Разбираться особо не стал и сделал на поллинге очереди DMA.

Через семафор. Однако если лень и производительность не критична, можно тупо читать битовый флаг. А также можно читать флаги и переменные без опаски до тех пор, пока они не превышают размера регистра процессора.

Это оптимальный вариант.

Довольно противно. Можно неделю убить на всякие тонкости.

Так clear() и в первоначальном коде был.

Я, честно говоря, не понял, что имел в виду demiurg_spb. Наверное, что у него всё работает как надо. Я могу подсказать по поводу версии с закрытием. Сделайте так: fin.close(); ifstream fin2("f.txt "); while (fin2.getline(buff, 50)) { . . . . };

Храните то, что пользователь ввёл. Другим способом восстановить из польской записи первоначальный ввод не получится.

Лучше запретите прерывания глобально, а то у вас в стеке какая-то чушь останется после прыжка. В FreeRTOS после инициализации явно разрешите прерывания.

Думается мне, что обратная польская запись не имеет однозначного выражения в скобочной форме. Поэтому стоит задуматься, зачем вам обратное преобразование. Храните в обычной форме, преобразовывайте при интерпретации.

Ну вам виднее. У меня с периферией проблем не было, а у запускаемого приложения - были. Когда стал прыгать до старта оси, всё стало работать как надо.

У меня то же самое было. SysTick я поборол, а вот прыжок из работающей ОС у меня так и не завёлся. То есть бут у меня работает под осью, как и основное приложение, а ось, вероятно, постоянно сидит в режиме обработчика прерывания и прыгнуть толком не может.

В C99 тоже можно переменную непосредственно перед использованием объявлять. Тоже есть bool. Ссылки полностью перекрываются указателями. Более-менее ценно в C++ - перегрузка функций и неймспейсы.

У вас UDP пакеты длиной 32КБ? Фрагментация касается разбиения отдельных пакетов, когда они не влезают в MTU. Если у вас пакеты небольшие, то без фрагментации всё будет прекрасно работать на любых потоках.

Можно. Только в вашем примере data будет недоступен.

В scmRTOS посмотрите как обработчики сделаны. У меня опыта нет упихивания С++ в контроллер. В Си вы пишете в module.c: static int data; И эта переменная у вас будет инициализирована нулём. В С++ вы пишете в module.h: class Module { private: int data;}; И эта переменная у вас инициализирована не будет.

Во-первых, ООП вы напрасно определяете через термины C++. Классическое определение: ООП - это объекты обменивающиеся сообщениями. Цитата из вики: Object-oriented programming (OOP) is a programming paradigm that represents the concept of "objects" that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs. То, что предлагает C++ изрядно запутывает программистов. Я бы посоветовал сначала хорошо изучить Си, а потом уже потихоньку залезать в С++, если так хочется. ТС рекомендую не углубляться в архитектуру наследования. Гораздо проще сделать так: 1. Выделить сущности в отдельные модули. Пускай датчик будет в отдельном модуле. 2. Если сущность бывает в единственном экземпляре, то можно оставить как есть - модуль с экспортируемыми функциями. Если вы большой любитель классов, то можно обернуть в синглтон. 3. Если сущность может существовать в нескольких экземплярах, то оборачивайте в класс. Например, датчиков может быть много - делаем класс датчиков. 4. Не заморачивайтесь с наследованием. Сделайте разные датчики копипастой. Когда всё заработает, одинаковый код можно вынести в базовый класс. 5. Чтобы единообразно обрабатывать разные датчики, можно сделать для них общий интерфейс. Когда у вас все датчики будут написаны, общий интерфейс написать будет тривиально. 6. Без динамической памяти писать будет больно. Поля в классах нужно инициализировать руками. Инкапсуляция работает хреново потому как приватные поля светятся в заголовках модулей. Подумайте ещё раз, надо ли вам это, потому что Си гораздо гуманее, чем С++.

Можно, но только через UART0 через встроенный загрузчик. Если свой загрузчик напишете, то хоть через что прошивайте. Про использование встроенного загрузчика читайте мануал на LPC17XX, глава Flash memory interface and programming, конкретно про ISP.