andrewlekar

Для линуксов звонилки делают традиционно на базе астериска (http://www.asterisk.org/). Но это довольно крупная система. Если нужно совсем просто и примитивно, то открывайте ком-порт к GSM модулю и ком-порт к аудиоданным и звоните. Возможно есть поддержка telephony devices, но тут я не в теме.

Я поднимал DfuSe бутлоадер для такого дела. Если устройство единственное подключенное к компу, то можно заливать одним нажатием мыши, ничего не выбирая и не переключая никаких перемычек. Посмотреть можно тут: https://github.com/blackyblack/LPC-DfuSe-Bootloader Для пущего удобства можно интегрировать заливалку софта с прошивкой в один экзешник и отдавать в таком виде заказчику - будет круто. Заливалка доступна в опен сорс виде: https://gitorious.org/dfu-util

Комментарий про vi доставил, спасибо. 1. Если воткнёте андроид, то можете дальше работать на виндовом SDK. Системное программирование вам не понадобится. 2. Если поставите линукс, то читайте предыдущий комментарий.

Возможно так: RD - Read (RX) SD - Send (TX) RS - Ready to send (RTS) CS - Clear to send (CTS) SG - земля

Я так делаю. Именно потому что ноги процессора мультиплексируются и нужно смотреть, чтобы не пересекался функционал. В cmsis сделана настройка ног из соответствующих модулей. На мой взгляд, это неудобно и чревато хитрыми багами. По поводу оптимизации инициализации ног. Считаю, что бороться за чистоту листинга и прочую оптимизацию при первоначальной настройке ног нет никакого смысла. Сколько бы она тактов не съела, делается настройка один раз и больше на производительность кода не влияет.

Программным сбросом нужно переходить в загрузчик. А процедура перехода в приложение в любом случае должна присутствовать. Хотя я и не понял, что именно починил ТС.

Если дело в привязке IMEI к CCID у оператора, то симком ниче сделать не сможет. Не будут же они прикручивать регистрацию с фейковым IMEI для обхода косяков оператора. Если дело в совместимости с симкой, то симкому действительно стоит поднапрячься и сделать фикс, а не строить из себя самых умных. Такая ситуация уже была с симками TELE2 и симком таки выпустил фикс.

Ну вот в даташите написано, что с такими настройками как у вас, не должно ничё работать. 8 мгц с множителем 100 даст Fcco = 800, а это нельзя. Про PLL1 сказано, что он с кварцами до 10 мгц не стартует.

Резистор между +3.3 и D+? Открыл наконец доку по LPC1751. Блин, там всего 8к озу на всё. Вряд ли дело в памяти. А вот инициализация частоты у вас странная. Для PLL0 MSEL = 100, а NSEL = 4. При этом для PLL1 MSEL = 6, а PSEL = 2. Если у вас кварц 4 мгц, то сам проц работать будет, а вот 48 мгц для USB уже не получается. Если у вас кварц 12 мгц, как написано в комментариях, то у вас проц не должен запускаться.

Connect лапа дергается? У LPC1778 другие номера эндпоинтов используются. Память под USB дескрипторы правильно разместили?

С этим процессором вам путь один: ставить Linux для BeagleBone и больше там ничего не трогать. Всё остальное пишется как обычные приложения для линукса практически без ARM специфики.

SIM900 умеет в HTTPS: http://mt-system.ru/sites/default/files/si...d_set_v1_00.pdf. Если хочется руками, то LwIP в PPP режиме + polarSSL в 64к ОЗУ влазят точно. В 32к придётся пободаться.

Здравствуйте. Вместо старого доброго IAR я настроил на своей рабочей машине Sublime Text. Это красивый и удобный редактор с возможностями IDE. Если вы устали от уродливого интерфейса IAR, можете попробовать поставить Sublime Text 3 с моими настройками для работы с проектами IAR. Sublime Text 3 можно взять тут: http://www.sublimetext.com/3 или ломаный тут: [CENSORED]. Мои настройки для него доступны тут: https://github.com/blackyblack/TerminusSettings Красивая тема и мой любимый шрифт Terminus доступны тут: https://github.com/blackyblack/TerminusTheme и https://github.com/blackyblack/TerminusFont

Да, для STM8 должно ок получиться. Да. В общем-то ничем не отличается от char[], но меньше места займёт. :)

К сожалению, нельзя. Вы можете, и это довольно удобно, делать новый массив с новыми элементами на каждый чих. Например: const char *A= {'a', 'b', 'c', 0}; printf("%s", A); const char *B = {'d', 'e', 'f', 0}; printf("%s", B); Если это ARM, то инициализаторы массивов будут лежать во флэше и вы почти не потеряете памяти на таком трюке и это будет удобно и красиво. Если это AVR например, то лучше так не делать: будет съедаться стэк, если не ошибаюсь. А если вы будете делать не const char *A, а char A[], то память будет съедать одинаково в обоих случаях (поправьте меня если я не прав).

Можно: unsigned char string_to_LCD[]={'h','t','c'}; Если хотите менять динамически, то можно так: string_to_LCD[7] = 0x05; Если хотите менять динамически и сразу куском, то так: memcpy(string_to_LCD, new_data, 16);

Ну вот я собрал ваш код при помощи IAR AVR 5.3. Вот MAP файл: FILE NAME : D:\projects\avr\just_test\Debug\Obj\main.r90 PROGRAM MODULE, NAME : main SEGMENTS IN THE MODULE ====================== NEAR_I Relative segment, address: DATA 000000A0 - 000000A5 (0x6 bytes), align: 0 Segment part 7. Intra module refs: main ENTRY ADDRESS REF BY ===== ======= ====== str1 000000A0 ------------------------------------------------------------------------- NEAR_I Relative segment, address: DATA 000000A6 - 000000AB (0x6 bytes), align: 0 Segment part 10. Intra module refs: main ENTRY ADDRESS REF BY ===== ======= ====== str2 000000A6 ------------------------------------------------------------------------- NEAR_Z Relative segment, address: DATA 000000AC - 000000AD (0x2 bytes), align: 0 Segment part 12. Intra module refs: main ENTRY ADDRESS REF BY ===== ======= ====== ptr 000000AC ------------------------------------------------------------------------- CODE Relative segment, address: CODE 00000054 - 000000A3 (0x50 bytes), align: 1 Segment part 14. ENTRY ADDRESS REF BY ===== ======= ====== main 00000054 ?cstartup_call_main (?C_STARTUP) RSTACK = 00000000 ( 00000002 )

Ничего не делает. (void)a просто убирает предупреждение компилятора о неиспользованной переменной.

В вашем коде для AVR все переменные будут размещены в ОЗУ. Хотите их размещать во флэш - пишите __flash. У Viko константы были размещены во флэш потому что он пользовался компилятором для ARM.

Может уже хватит переливать из пустого в порожнее? То народ указатель на структуру от самой структуры отличить не может, то указатель на массив от самого массива, то общее адресное пространство от раздельного. Если константа на самом деле где-то может пригодиться, то можете делать глобальной. Все подряд делать глобальными не стоит - экспортируется много символов и размываются интерфейсы у модулей.

Что вы этим гениальным кодом хотите проверить? В ch сначала попадёт '5', затем в str1[0] запишется '5', затем в ch запишется '2', а строка ch=ch ничего не делает - она заоптимизируется почти всегда. Ах да, str1 и str2 будет размещено в ОЗУ. Если вы хотели str2 размещать во флэш, то надо было указать квалификатор __flash.

Что, вашему компилятору не хватает ума разместить глобальную переменную во флэше? Или вы просто не пробовали?

Ни для каких. static очевидно может изменяться во время выполнения программы и не может быть размещён во flash. const размещает переменные во flash независимо от квалификатора static - актуально для IAR для ARM.

При чём тут static вообще? На ARMах const в определении переменной заставляет компилятор (и линкер) размещать её во флэше. На AVR такое не работало из-за раздельного адресного пространства.

Кнопка делает Submit на страничку CGI. CGI вызывает функцию из вашей программы. Некоторые веб-сервера для embedded применений имеют SSI (server-side includes) фичу для динамического обновления страницы. Мне лично не нравится ни CGI, ни SSI, хотя это довольно простые штуки. Я бы сделал сайт на JQuery или просто java script, кнопочка бы делала POST, а веб-сервер обрабатывал бы POST/GET запросы как надо. Про AJAX почитайте например, но там нужен парсер XML. Ничто не мешает выкинуть XML и использовать чё-нить поприличнее.