Cosmojam

http://zapas-m.ru/ сайт неплохой? Это мрак вообще. При попытке добавить в корзину товар, у которого нет цены возникает ошибка и вся корзина сбрасыватеся (ответ по телефону: у нас там что-то обновляется всё пучком не парьтесь). Для оплаты заказа прислали ссылку, которая открывается пустой страницей. Оказывается надо сначала сменить пароль для ими созданной учётки. Смена пароля происходит без каких-либо подтверждений, просто даже форма не сбросилась и никакой реакции на кнопку, но на самом деле оно сработало. Я такого днища давно не видел. Заказываю на пробу аккумы с зарядником, есть надежда что подойдёт и не придётся своё изобретать. Но сайт их вообще хочется развидеть и никогда не открывать больше

Прикольно, не знал даже что есть подобные конструкторы. Вот тут http://www.zapas-m.ru/UserFiles/Image/revi...n-their-own.php похоже вообще то что надо.

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

Визуально: https://docs.google.com/drawings/d/1x7bn0iV...dit?usp=sharing Батарейный БП аля бесперебойник. 6 аккумов 18650 (можно и любый другие, главное по размеру подходящие, но 18650 выбраны из-за универсальности и гарантируемой доставаемости). Выход 5В 500мА всегда независимо идёт зарядка или нет (максимальный ток на выходе 1А). От батарей должен выдавать 5В 500мА на протяжении 16 часов (обсуждаемо, детально всё не просчитывал возможно ли это, если невозможно - просто приближаемся к этому) Полная зарядка за 8 часов максиммум, лучше быстрее. На входе можно любой БП, например ноутбучный 19В 3.42А (из-за дешевизны и доставабелности), но можно и другой если необходимо для обеспечения заданного времени зарядки. Требуется: Схема+плата+ всё необходимое для мелкосерийного производства Пилотный образец (хоть ЛУТом сделанный) Производство первых 20-50шт Особые пожелания: Максимально доступная в РФ элементная база. Недорогая элементная база (при конфликте с п.1 будем посмотреть где зло по-меньше) Компактность (в обозначенные 85x170 должно влезть ещё одно устройство, которое отдельным топиком будет и там всё может быть сложнее, поэтому чем меньше тем лучше) Заранее назвать стоимость не могу т.к. не совсем в теме, надеюсь вас не затруднит примерно оценить работу и обозначить вилку. Территориально без разницы. Срок чем быстрее тем лучше. зы. Если знаете что-то готовое под такие нужды вознаграждение тоже будет

Написал, жду ответа.

http://www.st.com/web/en/catalog/tools/FM1...6?sc=stm32-java

В стартап файле из любого примера NXP. Там таблица векторов определена в этом массиве в виде указателей на функции. Правда это в примерах от NXP под GNU-тые средства разработки. Под другие может иначе сделано.

Ремапить в загрузчике и приложении можно так: SCB->VTOR = (unsigned long)&g_pfnVectors & 0x3FFFFF80; Сразу после вызова SystemInit(). Так указывается адрес таблицы векторов всегда на фактический её адрес независимо от абсолютного адреса куда линкер её положил.

Попробуйте отключить systick перед запуском приложения. В начале функции switchProgram(): SysTick->CTRL &= ~((uint32_t)(1<<0)); // отключает таймер SysTick->CTRL &= ~((uint32_t)(1<<1)); // отключает прерывание SysTick->CTRL &= ~((uint32_t)(1<<16)); // сбрасывает флаг

nRF24L01+ http://www.aliexpress.com/item/5pcs-NEW-NR...1151731070.html

На мой взгляд ошибка - отсутствие исходников. Таким образом Вы не приносите пользу другим людям кому потребуется выполнить аналогичную задачу. Ну есть бинарник, может как-то работает, а толку? Да ещё только под одну платформу. Покажите пример кода как это сделано - это гораздо ценнее и портировать на другие платформы можно. Никому в таком виде программа не понадобится с вероятностью 0.99, а когда потребуется писать свою под требования заказчика - Ваша программа никак не поможет. А будь исходники открыты - поможет, и слово благодарности получите от того кому пригодилась, особенно если документация к устройству мутная или в процессе столкнулись с недокументированными багами, которые удалось обойти. Заведите аккаунт на https://github.com/ или https://bitbucket.org (тут ещё и приватные репозитории бесплатно) и выкладывайте туда все собственные проекты с ридми желательно на инглише. Так создадите гораздо больше пользы чем выкладыванием бинарных блобов на форуме.

Ссылка битая. Ведёт на архив с бинарниками под виндоус, а должна вести на гитхаб с исходниками :)

Решил проблему грубой силой - отдельным преобразователем на передачу от МК.

Выяснилось что проблема не с процом, а с преобразователем RS232. Припаял переходник усб-шный напрямую на юарт и попробовал через него - всё работает. Из стартеркита ответили, оказывается я не первый с подобной проблемой http://starterkit.ru/html/index.php?name=f...ew&id=11731 Пробую найти 3.3В преобразователь на змену или вкрячить 5В. -=UPDATE=- Приспособил MAX232A от 5В с преобразователем 5->3.3 на диоде с резистором. Тоже самое поведение. Вот такая чушь творится на RS232 TX после моего ответа на Synchronized, отправленного процом в ответ на'?'': Что может в простейшем преобразователе RS232 так глючить? В схеме стоят конденсаторы 0.1. Пробовал допаять на 1мкФ.

Не, скорость верная остаётся если не добавлять \r\n к запросу '?' (вообще-то после ? и не должно быть новых строк, это просто случайно забыл отключить в терминале), только вот на этой скорости единственный раз верно приходит Synchronized, а всё что после него коверкается, т.е. проц отвечает какой-то лабудой на верной скорости. Другого экземпляра нет. Написал в стартеркит чтобы у себя проверили.

Осциллограф красивые прямоугольные импульсы показывает. Не докопаться. Отдельно битики вручную не считал. Длительность бита 17.2 мкс что верно соответствует скорости 57600. Это МК так отвечает, т.е. вряд ли проблема с тактовым генератором или определением скорости. Кстати заметил что если отправить вручную '?' без \r\n, то ответ "Synchronized" приходит верный. А если отправить "?\r\n", то скорость определится не правильно (в 2 раза меньше судя по ширине бита на осцциле). У LPC1788 без разницы - и так и так работает. Затем отправляю обратно ему "Synchronized" и в ответ получаю рандомную лабуду. Лабуда приходит на верной скорости если верить осциллографу и не зависит от наличия \r\n или выбранной скорости.

Не помогло :(

Линукс и винда дают одинаковые результаты. Под линуксом lpc21isp программка всегда работала с LPC17, а сейчас с LPC24 - нет. Винда на другом компе и там FlashMagic с теми же результатами. Перетыкаю кабель в плату с LPC17, меняю тип процессора и тут же всё начинает работать, т.е. не с компьютерами дело. На обоих компах нормальный RS232, никаких USB-конверторов. Скорость разную пробовал от 2400 до 57600 (раньше всегда на 57600 работал). RTS/DTR перемычками можно отключить от ресета. Отключал мычками, подключал кабелем у которого физически только 3 провода распаяно, без RTS/DTR. Хардварным снифером вижу что после ответа "Syncronized" начинается белиберда: Прошить через JTAG не имею возможности по причине временного отсутствия рабочего отладчика. Отдельная история с невезением на китайские и NXP-шные отладчики. При большом желании для проверки можно достать на недельку, но нет гарантии что это поможет решить проблему.

Прикольно :) Температура 24 гр.Ц. Попробовал слегка подогреть феном - без изменений.

LPC2478 на плате от стартеркита http://www.starterkit.ru/html/index.php?na...p=view&id=5 Пытаюсь прошить hex. Для LPC17xx использовал lps21isp, но не заработало тут. Flash Magic тоже не работает. Если не указывать тактовую частоту (для LPC17 никогда этого не делал в нём), то выдаётся ошибка: Если нажать "да", то потупит ещё немного и снова вывалится с ошибкой. Если указать частоту (14.748 МГц), то получаю: Тип проца естественно выбран верный. Скорость пробовал разную указывать - никаких изменений. Если придавить P[2]10 на землю, подать питание и отправить через терминал запрос автосинхронизации ('?'), то в ответ получаю как положено Syncronized на любых скоростях. Дальше команды ISP не проверял (и судя по беглому взгляду в даташиты они не отличаются от LPC17). А Flash Magic ни на какой скорости не работает. Одинаково не работает если вручную перевести проц в ISP перед попыткой прошивки, ни автоматически по RTS/DTR. С LPC17xx таких проблем никогда не было. Подскажите в чём может быть проблема?

Свой промежуточный сервер лишит необходимости в IP и NAT. Посмотрите в сторону протоколов MQTT, RabbitMQ - достаточно лёгкие для микроконтроллеров, публичных серверов в интернете хватает.

Изменились относитлеьные пути к сорцам. Раньше было ../ а теперь сорцы в том же каталоге где мейкфайлы До C_SRCS += \ ../lwIP/netif/etharp.c \ ../lwIP/netif/ethernetif.c \ ../lwIP/netif/lpc17xx_emac.c \ ../lwIP/netif/sys_arch.c OBJS += \ ./lwIP/netif/etharp.o \ ./lwIP/netif/ethernetif.o \ ./lwIP/netif/lpc17xx_emac.o \ ./lwIP/netif/sys_arch.o После C_SRCS += \ etharp.c \ ethernetif.c \ lpc17xx_emac.c \ sys_arch.c OBJS += \ etharp.o \ ethernetif.o \ lpc17xx_emac.o \ sys_arch.o

Было: project | |--src_folder1 | |--file.c | |--another.c | |--src_folder2 | |--file.c | |--yet_another_file.c | |--Debug |--makefile |--src_folder1 | |--subdir.mk | |--src_folder2 |--subdir.mk make запускал в Debug/ и всё работало Пренёс мейкфайлы так: project | |--makefile |--src_folder1 | |--file.c | |--another.c | |--subdir.mk | |--src_folder2 |--file.c |--yet_another_file.c |--subdir.mk make запускаю в корневом каталоге проекта. makefile просто перенёс, в subdir.mk исправил пути к исходникам и объектным файлам. Пути к subdir.mk сохранены т.к. они относительные и повторяют структуру каталогов с исходниками. Я лишь перенёс их в сами каталоги с исходниками.

Да именно так и сделано. Мейк запускаю в корневом каталоге исходников. Просто раньше он был в подкаталоге с названием конфигурации и все остальные mk в подкаталогах соответствующих названиям каталогов исходников, а сейчас вынес их в основное дерево исходников. Основной мейкфайл без изменений оставил, просто перенёс его на 1 каталог выше и запускаю оттуда.

Есть проект, собираемый эклиспсом. В нём мейкфайлы генерируются автоматически в подкаталоге с названием конфигурации и там гененрируются объектные файлы. Эти мейкфайлы можно использовать и для сборки вне эклипса. Теперь мне нужно вынести мейкфайлы из подкаталога где происходит сборка в собственно дерево исходников. Реальный пример Исходники размещены в подкаталоге lwIP/netif/. Эклипс генерирует основной мейкфайл Debug/makefile и мейкфайл для подкаталога Debug/lwIP/netif/subdir.mk. Вот так выглядит этот мейкфайл: C_SRCS += \ ../lwIP/netif/etharp.c \ ../lwIP/netif/ethernetif.c \ ../lwIP/netif/lpc17xx_emac.c \ ../lwIP/netif/sys_arch.c OBJS += \ ./lwIP/netif/etharp.o \ ./lwIP/netif/ethernetif.o \ ./lwIP/netif/lpc17xx_emac.o \ ./lwIP/netif/sys_arch.o C_DEPS += \ ./lwIP/netif/etharp.d \ ./lwIP/netif/ethernetif.d \ ./lwIP/netif/lpc17xx_emac.d \ ./lwIP/netif/sys_arch.d # Each subdirectory must supply rules for building sources it contributes lwIP/netif/%.o: ../lwIP/netif/%.c @echo 'Building file: $<' @echo 'Invoking: MCU C Compiler' arm-none-eabi-gcc -D__NEWLIB__ -D__USE_CMSIS -DDEBUG -D__CODE_RED -I"../Applications" -I"../FreeRTOS_portable" -I"../lwIP/include" -I"../lwIP/include/ipv4" -I"../lwIP/netif/include" -I"../FreeRTOS_include" -I"../CMSIS_LPC177x_8x/inc" -I"../lpc177x.lpc178x.cmsis.driver.library/inc" -I"../FreeRTOS-Plus-CLI" -O0 -g3 -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m3 -mthumb -MMD -MP -MF"$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -o"$@" "$<" @echo 'Finished building: $<' @echo ' ' В таком виде всё работает. Теперь я переношу Debug/lwIP/netif/subdir.mk в каталог с исходниками, т.е. lwIP/netif/subdir.mk и вместе с этим основной мейкфайл. В основном мейкфайле ничего не трогаю. В мейкфайле подкаталога (lwIP/netif/subdir.mk) исправляю так: C_SRCS += \ etharp.c \ ethernetif.c \ lpc17xx_emac.c \ sys_arch.c OBJS += \ etharp.o \ ethernetif.o \ lpc17xx_emac.o \ sys_arch.o C_DEPS += \ etharp.d \ ethernetif.d \ lpc17xx_emac.d \ sys_arch.d # Each subdirectory must supply rules for building sources it contributes %.o: %.c @echo 'Building file: $<' @echo 'Invoking: MCU C Compiler' arm-none-eabi-gcc -D__NEWLIB__ -D__USE_CMSIS -DDEBUG -D__CODE_RED -I"../Applications" -I"../FreeRTOS_portable" -I"../lwIP/include" -I"../lwIP/include/ipv4" -I"../lwIP/netif/include" -I"../FreeRTOS_include" -I"../CMSIS_LPC177x_8x/inc" -I"../lpc177x.lpc178x.cmsis.driver.library/inc" -I"../FreeRTOS-Plus-CLI" -O0 -g3 -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m3 -mthumb -MMD -MP -MF"$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -o"$@" "$<" @echo 'Finished building: $<' @echo ' ' Рассчитывая что теперь все объектные файлы будут генерироваться там же где исходники. Но при попытке сборки проекта получаю: make: *** No rule to make target `etharp.o', needed by ,,,, Моих скудных знаний мейкфайлов не хватает чтобы понять что не так.