inventor

вобщем перепрошил эти модули, сначала написал в поддержку тримбл: > We've bought around 100 pcs of these items. After April 7, 2019 the date rolled over to 1980. We do not have access to the software that works with this module, so we cannot adjust the number of weeks. Is it possible to reflash this module to remove this error. Can I flash via the NMEA port? Sylvana has no other ports. What are the options for flashing this module? прислали несколько файликов, пре-лоадер, прошивку, 2 файла перевода времени (для работы с неправильным модулем) и ... 2 файла с функциями, в общем надо самому написать прогу, используя эти файлы я пошел другим путем (если кому надо). Модуль GPS Trimble Sylvana на микросхеме Condor_C1919A) 1) в DockLight на скорости 9600 посылаю команду $PMTK180*3B<r><n> - переход в режим программирования 2) Закрываю порт в DockLight 3) Открываю TrimbleStudio и прошиваю модуль этими двумя файлами на скорости 115200 прошивка занимает примерно около 3 минут, начинает мигать лампочка, а потом процесс идет После прошивки сбрасываю питания с модуля-он работает и показывает правильное время и дату

Интересно У ГЛОНАСС модулей или при Перестройке на прием только глонас Тоже будет такой косяк? Не говорю про сильвану, она только gps

У нас в оборудовании стоит модуль Sylvana-Anapala от Trimble работало с 2013 года, вчера заметили такую странную вещь-станция не хочет запускаться по времени которая берется с модуля. стал разбираться с логом и вот что заметил: R 04-10-2019 16:40:27.366 NMEA:->$GPRMC,164034.000,A,5540.6204,N,03734.1676,E,0.05,0.00,180200,9.4,E,A*03 R 04-10-2019 16:40:28.358 NMEA:->$GPRMC,164035.000,A,5540.6195,N,03734.1661,E,0.01,0.00,180200,9.4,E,A*0B R 04-10-2019 16:40:29.359 NMEA:->$GPRMC,164036.000,A,5540.6193,N,03734.1652,E,0.02,0.00,180200,9.4,E,A*0D R 04-10-2019 16:40:30.366 NMEA:->$GPRMC,164037.000,A,5540.6190,N,03734.1645,E,0.04,0.00,180200,9.4,E,A*0F R 04-10-2019 16:40:31.357 NMEA:->$GPRMC,164038.000,A,5540.6188,N,03734.1638,E,0.01,0.00,180200,9.4,E,A*06 R 04-10-2019 16:40:32.367 NMEA:->$GPRMC,164039.000,A,5540.6187,N,03734.1629,E,0.03,0.00,180200,9.4,E,A*0A R 04-10-2019 16:40:33.358 NMEA:->$GPRMC,164040.000,A,5540.6186,N,03734.1617,E,0.03,0.00,180200,9.4,E,A*08 R 04-10-2019 16:40:34.351 NMEA:->$GPRMC,164041.000,A,5540.6185,N,03734.1606,E,0.03,0.00,180200,9.4,E,A*0A R 04-10-2019 16:40:35.347 NMEA:->$GPRMC,164042.000,A,5540.6187,N,03734.1591,E,0.04,0.00,180200,9.4,E,A*01 R 04-10-2019 16:40:36.360 NMEA:->$GPRMC,164043.000,A,5540.6188,N,03734.1569,E,0.04,0.00,180200,9.4,E,A*08 R 04-10-2019 16:40:37.377 NMEA:->$GPRMC,164044.000,A,5540.6190,N,03734.1548,E,0.08,0.00,180200,9.4,E,A*09 R 04-10-2019 16:40:38.375 NMEA:->$GPRMC,164045.000,A,5540.6191,N,03734.1532,E,0.02,0.00,180200,9.4,E,A*0E R 04-10-2019 16:40:39.378 NMEA:->$GPRMC,164046.000,A,5540.6192,N,03734.1516,E,0.03,0.00,180200,9.4,E,A*09 R 04-10-2019 16:40:40.357 NMEA:->$GPRMC,164047.000,A,5540.6192,N,03734.1513,E,0.05,0.00,180200,9.4,E,A*0B R 04-10-2019 16:40:41.366 NMEA:->$GPRMC,164048.000,A,5540.6192,N,03734.1512,E,0.04,0.00,180200,9.4,E,A*04 R 04-10-2019 16:40:42.361 NMEA:->$GPRMC,164049.000,A,5540.6193,N,03734.1510,E,0.01,0.00,180200,9.4,E,A*03 время правильно, а число и год 18 02 2000. причем есть 3dfix такое на трех модулях.кто нибудь сталкивался с таким?

Альтиум подглюкивает. Делаю полигоны из частей потом объединяю. Если в полигоне отверстие, то все полигоны внутри отверстия становятся прозрачными и не восстанавливаются. Теперь сохраняю каждые 20 минут, чтобы вернуться к предыдущему. Сегодня потерял работу за полдня из за этого.

Такое дело? альтиум 17.1 - пытаюсь залить полигонами область но он не соединяет все цепи уже в правилах менял - ничего не выходит не хотелось бы руками цепи соединять у меня два полигона: +3V0A и AGND я ожидаю, что полигон во время заливки соединит перемычками цепи если делаю relief - то получается дырка в полигоне, где стоит одна нога кондера сплошная заливка работает получше квырялся в правилах - не помогает

У миландра есть пак для iar. Ставится на все иар от 6.5 до7.5 и вероятно выше. Контроллеры шьются st link. Коробки от stm. В этом случае при прошивке выбирается unspecified cortex m1 для ве3 или m3 для 9x. Все хорошо прошивается и дебажится.

нашел ошибку в разводке: перепутаны 2 ноги шины данных контроллера на шине данных сидят мл данные RAM, FPGA и FLASH сейчас работает, никаких проблем нет, на FPGA просто переименовали эти линии как проект будет разрастаться - будут выскакивать ошибки, которых сейчас нет. меня интересует какой нибудь простой тест, чтобы определить, что линии перепутаны то нибудь подобное: void test(void) { static u32 data0 @ ".slowdata" = 0xa5a5a5a5; /* внешняя память*/ static u32 data1 @ ".fastdata"; /* внутренняя память */ data1 = data0; for(int i = 0; i < 1000; i++) { data0 <<= 1; data1 <<= 1; *****

Я шью его обычным st link ом. Перепрошил его на jlink. В качестве оболочки iar. Все остальное-кал

Да... понял. Из вывода пикселя убираю проверку на допустимость И расчет адреса. Это можно сделать В начале функции вывода картинки. Все адреса идут подряд. Так что можно вычислить начальный и конечный адрес. Вместо двух циклов будет один. Через 8.

Ну так как вывод пикселя оптимизировать?

/** * Вывод пикселя на экран с координатами x, y и с заданым цветом */ IDEF void display_put_pixel(u16 x, u16 y, u16 col) { volatile u32 addr; if (x < DISPLAY_WIDTH && y < DISPLAY_HEIGTH) { /* расчитаем координаты точки */ addr = DISPLAY_START_ADDR + (((DISPLAY_HEIGTH - y - 1) * DISPLAY_WIDTH + x) << 2); /* Выведем точку */ *((u32 *) (addr)) = col; // printf("%d, %d; ", x, y); } } IDEF это static inline убрал u16 h = DISPLAY_HEIGTH - y;

это просто запись в память (*((volatile u32 *) (addr))) = col; вероятно сама плис долго выводит решили сделать 2 адресных пространства 1-е попиксельное рисование в цветах 2-е вывожу двойное слово где каждый бит- ч/б пиксель так будет быстрее работать

это я уже убрал и сделал так: for (int y = 0; y < height; y++) { for (int x = 0; x < width; x += 8, k++) { pix = *(bmp + k); p0 = pix & 1; p1 = pix & 2; p2 = pix & 4; p3 = pix & 8; p4 = pix & 16; p5 = pix & 32; p6 = pix & 64; p7 = pix & 128; display_put_pixel(x, DISPLAY_HEIGTH - y, p0 == 0? 0xFFFF: 0); display_put_pixel(x + 1, DISPLAY_HEIGTH - y, p1 == 0? 0xFFFF: 0); display_put_pixel(x + 2, DISPLAY_HEIGTH - y, p2 == 0? 0xFFFF: 0); display_put_pixel(x + 3, DISPLAY_HEIGTH - y, p3 == 0? 0xFFFF: 0); display_put_pixel(x + 4, DISPLAY_HEIGTH - y, p4 == 0? 0xFFFF: 0); display_put_pixel(x + 5, DISPLAY_HEIGTH - y, p5 == 0? 0xFFFF: 0); display_put_pixel(x + 6, DISPLAY_HEIGTH - y, p6 == 0? 0xFFFF: 0); display_put_pixel(x + 7, DISPLAY_HEIGTH - y, p7 == 0? 0xFFFF: 0); } } но все равно скорость не достаточная

есть контроллер кортекс, подключенный к нему через FPGA дисплей вывожу картинку старого формата XBM на экран монитора DMAнет и выводить нужно попиксельно экран долго рисует, что ожидаемо /** * Вывести файл XBM (ширина должна делиться на 8!!!) */ void bitmap_draw_xbm(const char* bmp, int width, int height) { u32 k = 0; u8 m = 0, pix; for (int y = 0; y < height; y++) { for (int x = 0; x < width; x++) { pix = bmp[k]; pix = (pix >> m) & 1; display_put_pixel(x, DISPLAY_HEIGTH - y, pix == 0? 0xFFFF: 0); m++; if (m == 8) { k++; m = 0; } } } } формат XBM такой, если кто не знает: #define x_width 512 #define x_height 512 static char x_bits[] = { 0x28, 0x8a, 0xe2, 0x3f, 0xfe, 0xf3, каждый бит в байте и сдвигать выводя попиксельно

решили радикально, без танцов с бубном-заказали клавиатуру с отдельной кнопкой