Lem

У меня тоже сначала не работало. Нужно изменить размер буфера в хедере usbd_cdc.h #define CDC_DATA_FS_MAX_PACKET_SIZE 64

актуально

Ищу удалённую работу (подработку). Москва Опыт разработки устройств на МК (автоматизация, охранные системы, измерения и др.), разработка схемотехники, разводка плат (аналог, цифра, lvds) в Altium Designer и pcad. Программирование ПК (c/c++, VB, C# - управляющие утилиты (за большие программы не возьмусь в силу отсутствия времени)) Готов участвовать на всех этапах, от обсуждения до изготовления образца.

-n$CUR_LINE$ $FILE_PATH$

а конкретнее? нужно генерировать ток развёртки

Нужно масштабировать токовый сигнал с нагрузке в пределах от 1А до 1 мА. отношение сигнал-шум > 1000. нагрузка индуктивная 400 мкГн, 3 Ом сигнал - до 50 кГц Пока идеи - несколько выходных каскадов на разные диапазоны. Была идея включать резистор последовательно с нагрузкой, но шуметь он будет сильно

при любом положении фузов при подаче внешнего тактового сигнала работать кристалл будет (программироваться)

подключите внешнее тактирование и запрограммируйте правильно фьюзы

см выше, задача была специфическая. особенности: getchar неблокирующий в целом, приём данных по терминалу блокирующий, но с таймаутом парсились цифровые аргументы, возвращаемые at командой Там пара файлов, если будут вопросы, другие файлы могу выложить пример использования функции WaitForAnswer(): //----------------------------------------------------------------------------- //try to set memory as mem1 in gsmModem (suggest connection is open): unsigned char TestPhoneMemoryAsClass1(const PHONE_MEMORY *pmemToTest) { //send: AT_CPMS=memToTest[CRLF] FlushUartRxBuffer(); SendAtCommandWithArgsF(&cpmsComm, pmemToTest->pmemString); if(WaitForAnswer(atMemoryTimeoutMs, "\r\n+CPMS", 0) == WAIT_OK) { __delay_cycles(1000000); return SUCCESS_CODE; } return ERROR_CODE; } //----------------------------------------------------------------------------- Использование функции GetAtAnswerArgs(): //----------------------------------------------------------------------------- //listTactics affects on at_commands, used for listing //ppsubmitPosBuf - address of ptr to the smsPosBuffer //ppdeliveryPosBuf - address of ptr, used to return deliveryPosBuf start address unsigned char ListSmsToBufRef(LIST_DATA *plistData) { WaitUntilNoUartInput(WAIT_UART_NO_INPUT_MSECONDS); FlushUartRxBuffer(); unsigned char buf[6] = {0}; unsigned char submitIndex = 0; unsigned char deliveryIndex = 0; SMS_POSITION pos = {0}; unsigned char listedCounter = 0; const unsigned char listedBufSize = plistData->submitListedNumb; //const unsigned char maxPos = plistData->minPos + listedBufSize; unsigned int maxReceivedPos = plistData->minPos; UIntToStr(plistData->tactics, buf, sizeof(buf)); SendAtCommandWithArgs(&cmglComm, (char*)buf + 5); if(WaitForAnswer(atTimeoutMs * 4, "\r\n", 0) != WAIT_OK) { return ERROR_CODE; } //for each +cmgl answer:*/ while(1 /*listedCounter < listedBufSize*/) { if(WaitForAnswerDual(atTimeoutMs, "+CMGL: ", "\r\nOK\r\n", 0) != WAIT_OK_1) { break; } AT_ANSWER_ARGUMENT argBuf[5] = {0}; unsigned char receivedArgs = sizeof(argBuf) / sizeof(AT_ANSWER_ARGUMENT); if(GetAtAnswerArgs(argBuf, &receivedArgs, atTimeoutMs * 4) != SUCCESS_CODE) { break; } //now we can get info from args: if(argBuf[0].isSet != 1) { break; } pos.position = argBuf[0].argVal; //pass message if it is out of range or listedBuf is full if((pos.position < plistData->minPos) || ((deliveryIndex + submitIndex) == listedBufSize)) { if(PassPduRest(atTimeoutMs * 3) != SUCCESS_CODE) { //return ERROR_CODE; } continue; } if(maxReceivedPos < pos.position) { maxReceivedPos = pos.position; } //here we analyze pdu type (submit or delivery) //and place pos info to appropriate buffPart (head or tail) if(PassSMSCNumber(atTimeoutMs * 10) != SUCCESS_CODE) { break; } unsigned int typeCode = 0; if(ReceivePduTypeCode(&typeCode, atTimeoutMs) != SUCCESS_CODE) { break; } if((typeCode & 0x01) != 0) { //submitPdu (plistData->psubmitPosBuf)[submitIndex++] = pos; } else if((typeCode & 0x03) == 0) { //deliveryPdu const unsigned char deliveryShift = listedBufSize - deliveryIndex++ - 1; (plistData->psubmitPosBuf)[deliveryShift] = pos; plistData->pdeliveryPosBuf = plistData->psubmitPosBuf + deliveryShift; } else { //error: unknown typeCode for pdu return ERROR_CODE; } ++listedCounter; if(PassPduRest(atTimeoutMs * 3) != SUCCESS_CODE) { return ERROR_CODE; } }//while(listedCounter < listedBufSize) //endReceive: if((deliveryIndex + submitIndex) == listedBufSize) { //listedBuf is full, we should do next list Iter: plistData->minPos = maxReceivedPos + 1; } else { plistData->minPos = 0; //indicate that listing is finished } plistData->submitListedNumb = submitIndex; plistData->deliveryListedNumb = deliveryIndex; return SUCCESS_CODE; } //-----------------------------------------------------------------------------

монструозно - это правильно, такое чувство, что эти команды специально разрабатывались для самой неудобной их обработки. Я не работал с модемами, работал с SMS. поэтому не уверен, что мой опыт вам пригодится atcommands.rar

одним из авторитетов для меня является Герб Саттер,ну, там ещё куча умных опытных людей, которые много поработали с БОЛЬШИМИ системами и знают, какова цена тех или иных ошибок при отладке и сопровождении проектов, создаваемых коллективами за длительные сроки и большие деньги

На меге 162 делал так: TCNT1 = 0x0000; TCCR1A = 0xf2; TCCR1B = 0x19; OCR1A = 0x0000; OCR1B = 0x0000; ICR1 = 0x4fff; TCNT1 = 0x0000;

препроцессором не рекомендуется пользоваться именно из-за проблем с поиском ошибок (в основном), так как во что разворачивается макроопределение выяснить практически нереально (достоверно), отлаживаться и искать ошибки крайне неудобно. Поэтому были введены в язык средства, позволяющие практически полностью исключить использование препроцессора. Список случаев, когда препроцессор оправдан уже был озвучен. Правда, я лично использую его неправильно, надо отучаться... Для маленьких проектов, например, для микроконтроллеров типа АВР, разницы никакой, но привычка переносится и на большие, а там проявляются все эти кажущиеся надуманными проблемы.

Я лично работал и с Mega48, и с Mega88, и c Mega168, всё везде отлаживается, хотя не без глюков. Честно, иногда это похоже на шаманство: не с первого раза отключается/включается dwenable, после отключения режима отладки приходится перезапускать студию (иногда), чтобы изменения вступили в силу. Особенно, если контакты в разъёме SPI не совсем хорошие :). Главное - студия не очень чётко работает с этими делами, если ошибки происходят, не всегда правильно определяются. Да и сам JtagIce зависает иногда... Если совсем не отзывается - проверяйте RESET, нет ли там кондёров, смотрите осциллом, что происходит. Если сброс притягивается к земле, но передачи данных нет, значит, что контроллер вообще в режиме SPI программирования. Проверяйте и контакты...

Имелось в виду, видимо, что функция sprintf не может использоваться из-за ограниченных ресурсов МК :)