WHILE

Господа, купили PICkit 3. Вроде все хорошо, но на одной железке понадобилось перешить PIC24FV32KA304, и выяснилось, что PICkit 3 этот чип не поддерживает.Хотя вроде-бы, судя по даташиту, чип не из самых новых. Это как-то лечится или только покупка другого программатора?

Мне предстоит повозиться с ядром М3 и отпишу с удовольствием. Одна просьба -не могли бы вы выложить хоть один тестовый пример. Он же наверняка у вам есть, вы же не на боевом проекте порт отлаживали. З.Ы. И если не сложно поправьте в шапке фалов порта оставшееся TOOLKIT: ARM GCC на ARM IAR. Спасибо и с праздником.

Спасибо за подсказку. Вопрос- установка только программатора это бесплатно или лечить все равно придется.? И еще - pic kit4 в моём случае никаких преимуществ не даст?

Здравствуйте, господа пиководы. На работе появилась многоблочная железка, в которой кроме всего прочего применяется с десяток пик-микроконтроллеров различных серий: pic16 -pic18-pic24. Время от времени требуется им обновлять ПО, пару раз они банально мерли. Имеется купленный лет 10 назад PIC-KIT2 lite, но часть из этих кристаллов он не поддерживает. Что вы можете посоветовать оптимальное по соотношению цена-стоимость? Хотелось-бы поддержка максимального количества кристаллов и более-менее адекватная графическая оболочка программатора, т.к. ставить под это дело что-то MPLAB сильно не хотелось-бы. Отладка не нужна, только программирование встроенной флэш и еепром. Спасибо.

Cпасибо. Так заработало.

Здравствуйте. Не бей больно, моя первая попытка поработать с STM32. Никогда раньше не редактировал линкерные файлы, но вот понадобилось... Нужно во внутренней флэш-памяти STM32F051 создать для очень редко изменяемых калибровочных констант свою секцию. Для этого определяю в icf: define symbol __PAGE_SIZE_FLASH = 0x400; define symbol MY_EEP_start_adress = __ICFEDIT_region_ROM_end__ - __PAGE_SIZE_FLASH + 1; define region MY_EEP_region = mem:[from MY_EEP_start_adress to __ICFEDIT_region_ROM_end__]; place in MY_EEP_region {readonly section .iapMem}; do not initialize {section .iapMem}; export symbol __PAGE_SIZE_FLASH; export symbol MY_EEP_start_adress; в сpp. файле extern const uint32_t MY_EEP_start_adress; __no_init const uint16_t data_cal_adc[CH_ADC_MAX]@".iapMem"; Если судить по map-файлу, то вроде бы все создается : MY_EEP_start_adress {Abs} 0x800'fc00 "P3": place in [from 0x800'fc00 to 0x800'ffff] { ro section .iapMem }; Но в срр файл константа MY_EEP_start_adress передается как 0xFFFFFFFF. При попытке чтения uint16_t TFlash_Eep:: Read_Data (const uint32_t index) { return (*(__IO uint32_t*) (MY_EEP_start_adress + index)); } я падаю в хардфаулт. и проверочный printf("adr=%x\r\n", MY_EEP_start_adress); таки тоже выдает 0xFFFFFFFF. Где я лажанулся?

Извиняюсь за подъем старой темы, но я сейчас думаю над такой-же проблемой. Уважаемый Alechek, вы эту проблему как-то решили?

Присоединяюсь к Александру. Сравните с этой корейской писаниной mbed-овский стэк для WIZNET.

Я работал с W7500. Примеров с ним они дают вдвое меньше чем вы перечислили.Да и насчет прекрасной библиотеки и отлаженного кода у меня совсем другое впечатление сложилось. Сделано на отвяжись, и самое хреновое что написано все в жестком однопоточном варианте, который там просто прибит гвоздями. При работе с РТОС практически все надо переписывать.

Унутре W7500p неонка абсолютно стандартный кортекс М0. IAR кстати про W7500P ничего и не знает.Все компилируется в режиме ядро М0 + icf файл от производителя. Вы будете смеяться но TCP стэк я дернул таки из mbed, потому что тот софт что дают в качестве примеров корейцы совсем уж унылое гамно. Ну и да, варианты с двумя NV памятями с двумя-тремя-четырьмя копиями прошивки, имхо, перебор.

Спасибо, примерно понятно

Вы производителям железа совсем не доверяете? В частности errate? З.Ы. Встроенная собака в нем работает нормально. Да я и в AVR не жаловался...

2 Arlleex - а зачем из основного приложения деинить контроллер и перешивать. Установить признак во флэше и уйти на перезагрузку - а при старте смотреть кого стартовать-бутлоалер или рабочее приложение?

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

Запускать обмен по ARP, устанавливать TCP-сессию и прочее-прочее - всё равно нужно. То что "унутри железный" - это наоборот минус. Когда обнаружится баг в нём железном, то исправить Вы его уже не сможете. Поэтому такое "железное" лучше не использовать. Ни ARP поддерживать, ни устанавливать TCP сессию на нем не надо. Все это реализует железка. Для TCP cервера надо поднять серверный сокет( прописать его MAC, IP и порт для прослушивания.И активировать парочку клиентских сокетов. Дальше или ручной опрос сокетов на наличие данных или включить прерывания.