Jump to content

    

Bpovov

Участник
  • Content Count

    29
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Bpovov

  • Rank
    Участник

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Огромное спасибо! А зачем для R5 Vitis? Зачем библиотеки? Там ведь все равно "руками" все прописывать желательно... просто как я понял Vitis - это для тех кто не хочет особо париться и разбираться с аппаратной частью, много унификации, которая обычно очень плохо натягивается на "железные" проекты с жестким реалтаймом... может я конечно не прав... только начинаю... поправьте если что...
  2. Добрый день! Очень тупой конечно вопрос, но я уже несколько часов пытаюсь найти что то вменяемое и все мимо... Только начинаю осваивать указанный SoC, как я обычно изучаю новый камень? - сначала читаю/изучаю в общих чертах основные вещи где то чуток углубляюсь, что то ,что считаю не важным для текущей задачи пока пропускаю, затем качаю простые примеры на близкие к моей задачи темы(или ее части), и подробно изучаю, разбираю, копаюсь, попутно привыкая к новой среде разработке... Ну дальше потихоньку начинаю свое пописывать и уже полноценно углубляться в тему... С Vivado так пока не выходит... Почитал, поизучал, наметил в чем нужно разобраться в первую очередь... мои задачи первого этапа требуют писать фактически под голое железо, никаких операционок и тонн библиотек с непонятными исходниками, т.е. максимально прозрачно для аппаратной части... пытаюсь искать примеры и демо-проекты... и ничего, нахожу - только запутанные вещи под предустановленный линукс, какие- то специфические библиотеки, которые нафиг мне не нужны... а даже банального демо-проекта где к примеру ты сам "ручками" принудительно часть кода делаешь на одном ядре, а другую на другом... или где ядра взаимодействуют с DSP, или FPGA... нет... или где ты с кэш на несколько ядер раскидываешь... да блин хотя бы одной ножкой дрыгаешь)))) и то нет))) Подскажите где такие "железные" примеры для Vivado в большом количестве на данный камень добыть можно? т.е. что то простое небольшое, и про железо... короче близкое к низкоуровнему... спасибо!
  3. Вот я тоже пока в метании на что сесть на VS, или на Qt ни то ни то не знаю, думаю что осваивать... Вроде по отзывам сейчас VS обходит, по удобству, функционалу, вроде даже кроссплатформенность на уровне Qt...
  4. Огромное спасибо за комментарии! Искал эту свою тему, что то не нашел - подумал удалили)) Начинаю разбираться) К-Ц, К-В точно не прокатит, так как такое будет часто и нужно что бы к схеме привязка была.
  5. Добрый день! Хочу еще только начать освоение Zynq Ultrascale+(поэтому вопрос будет наверное глупый), для будущих задач эта серия SoC-ов точно подойдет. Но сомневаюсь получиться ли адекватно решить на нем одну текущую задачу. Опишу как я вижу цинк ультру в этой задаче. Два кортекса R5 + ПЛИС управляют одной высоконадежной системой реального времени на чистом bare-metal. Одно ядро А53 помогает им в некоторых расчетах. Оставшееся ядро/ядра работает под Linux. Приложение написанное на Visual Studio крутиться в Linux, получает данные от кортексов R5 производит простую обработку и визуализирует полученное на монитор-HMI в виде графиков, возможно простого 3D-моделирования и т.д. Приложение и весь Linux не может вмешиваться в работу bare-metal. Общение между ними только через изолированный шлюз/шину который контролирует bare-metal. Т.е. весь Linux жестко ограничен по сути выходом на монитор/мониторы, клавиатура/мышка(USB?), частью памяти и свои ядром/ядрами, все остальное ему недоступно. Это нужно для того что бы можно было легко корректировать визуализацию(она будет меняться часто) и HMI, без опасности что то задеть в реал-таймовой части. Так же если в Linux, что то собьется/зависнет на работу высоконадежной системы это не повлияет. Под Zynq из Linux это PetaLinux, как понимаю. Развернуть на нем классический Linux сходу вряд ли смогу, еще б с PetaLinux справиться бы)) (а долго копаться нет возможности). Насколько возможно адекватно писать приложения в Visual Studio именно для PetaLinux? Почему именно VS - потому что это же приложение должно быть частью другого комплекса уже под Винду. Опытные пользователи Zynq'а прокомментируйте, пожалуйста, насколько выше описанное адекватно реализуемо, или там совсем закопаешься в "отгораживании" PetaLinux, от всей системы, и оптимизации приложений для него? Заранее спасибо всем кто откликнется!
  6. Добрый день! Пока у меня нет опыта работы на Zynq Ultrascale+, но ближайшее время мне нужно будет начать с ним ковыряться, вопрос простой, но я нигде не нашел на него ответа, может кто-нибудь подскажет. В нем есть 2 CAN контроллера, написано, что они соответствуют стандартам CAN 2.0B и т.д., но я нигде не нашел непосредственные значения скорости работы которые поддерживают эти контроллеры. Например я хочу подцепить к ним микрушку физ. уровня со скоростью 2-5Mbit (естественно с уменьшением длины линии передачи), смогу ли я на такой скорости работать с Zynq ом, ведь по стандартам CAN это не более 1Mbit (хотя огромное число микрух CANа физ. уровня. до 10Mbit). Подскажите пожалуйста, если у кого информация по данному вопросу. П.С. сам проверить это не могу, т.к. пока ко мне еще не пришел Zynq, а железо уже нужно делать, по этому хочу определиться с интерфейсами. Тем более что даже если заработает у меня, будет ли это штатный для него режим со всеми вытекающими температурными вещами и повторяемостью на изделиях. Спасибо, заранее!
  7. Все верно, но long по длине также больше int, как и в AVR. Дело не в переносимости, она в моем случае не нужна. Я смотрел ассемблер этих выражений, там все четко.
  8. Вот такая штука к примеру, в кейле даже на кортекс М работает верно, без залезания в асм int A, B; long C; А = B*C; при условии что результат и значения операндов не вылезают за int
  9. Короче что бы я не делал компилятор ни явно ни неявно не захотел адекватно приводить int к long и наоборот, т.е. пришлось где то все на long делать - потерял быстродействие, а где то на асме вручную прописывать байтовые действия с постоянным держанием в нулях старших байтов и контроль знака для int... Просто уже отвык от такого)) во всяких современных кортексах А-шках, с этим проблем нет)))
  10. Добрый всем день! Есть небольшой вопрос. На одной ПП есть схема в десятком абсолютно одинаковых прецизионных ЦАПов и одним процом управления, рисунок на ПП для каждого ЦАПа должен быть абсолютно одинаковым, только линии интерфейса к процу отличаются соответственно. Отсюда вопрос такой: сделал схему для одного ЦАПа, развел ее на ПП, как дальше ее максимально эффективно десять раз дублировать (т.е. и на схеме и на плате)? Что бы не перерисовывать по 10 раз всё! Заранее спасибо, друзья!
  11. Вот собственно весь кусок кода что наассемблир комплилятор, как мне кажется тут косяк уже даже в самом выражении (напомню промежуточные значения ну то есть (Current_Position_uV - Mas_position[9])*100)) могут быть больше signed int. #define TIME_DELAY_MEAS 416 signed long Current_Speed_actuator_Buf; signed int Current_Speed_actuator, Current_Position_uV, Mas_position[10]; ////////////////Current_Speed_actuator_Buf = (((Current_Position_uV - Mas_position[9])*100) / TIME_DELAY_MEAS); __GETW1MN _Mas_position,18 LDS R26,_Current_Position_uV LDS R27,_Current_Position_uV+1 SUB R26,R30 SBC R27,R31 LDI R30,LOW(100) LDI R31,HIGH(100) CALL __MULW12 MOVW R26,R30 LDI R30,LOW(416) LDI R31,HIGH(416) CALL __DIVW21 CALL __CWD1 STS _Current_Speed_actuator_Buf,R30 STS _Current_Speed_actuator_Buf+1,R31 STS _Current_Speed_actuator_Buf+2,R22 STS _Current_Speed_actuator_Buf+3,R23 /////////////////////////Current_Speed_actuator = (signed int)Current_Speed_actuator_Buf; LDS R30,_Current_Speed_actuator_Buf LDS R31,_Current_Speed_actuator_Buf+1 STS _Current_Speed_actuator,R30 STS _Current_Speed_actuator+1,R31 .MACRO __GETW1MN LDS R30,@0+(@1) LDS R31,@0+(@1)+1 .ENDM __ANEGW1: NEG R31 NEG R30 SBCI R31,0 RET __LSLW2: LSL R30 ROL R31 LSL R30 ROL R31 RET __CWD1: MOV R22,R31 ADD R22,R22 SBC R22,R22 MOV R23,R22 RET __MULW12U: MUL R31,R26 MOV R31,R0 MUL R30,R27 ADD R31,R0 MUL R30,R26 MOV R30,R0 ADD R31,R1 RET __MULW12: RCALL __CHKSIGNW RCALL __MULW12U BRTC __MULW121 RCALL __ANEGW1 __MULW121: RET __DIVW21U: CLR R0 CLR R1 LDI R25,16 __DIVW21U1: LSL R26 ROL R27 ROL R0 ROL R1 SUB R0,R30 SBC R1,R31 BRCC __DIVW21U2 ADD R0,R30 ADC R1,R31 RJMP __DIVW21U3 __DIVW21U2: SBR R26,1 __DIVW21U3: DEC R25 BRNE __DIVW21U1 MOVW R30,R26 MOVW R26,R0 RET __DIVW21: RCALL __CHKSIGNW RCALL __DIVW21U BRTC __DIVW211 RCALL __ANEGW1 __DIVW211: RET __CHKSIGNW: CLT SBRS R31,7 RJMP __CHKSW1 RCALL __ANEGW1 SET __CHKSW1: SBRS R27,7 RJMP __CHKSW2 COM R26 COM R27 ADIW R26,1 BLD R0,0 INC R0 BST R0,0 __CHKSW2: RET
  12. 16 , 15 числовых 1 знаковый ну кстати и логично что ничего не меняет скомпилированный кусок асма одиноков и для final = (signed int)a; и для final = a; .......... LDS R30,_a LDS R31,_a+1 STS _final ,R30 STS _final ,R31 .......... т.е. ничего не поменялось и насколько я понимаю, как раз копируются просто два младших байта, а информация о знаке которая храниться в 4 байте long'а (переменной "a") теряется.... вроде верно мыслю?
  13. Спасибо! Это первое что в голову пришло - попробовал, но тоже самое никакого эффекта на железе
  14. Добрый день друзья! Уже лет 15 не писал для AVR-ных камней, но тут потребовалось вспоминать атмежку8)) ностальгия блин) но возникла проблема.... есть выражение signed long a; signed int b, c, final; unsigned char d; a= ((b-c)*100)/d; final = a; Внутри выражения(a=....) промежуточные значения могут быть на бОльшую часть диапазона signed long, но гарантированно без переполнения. Конечное же значение записываемое в a, гарантированно без переполнения попадает в диапазон signed int. Поэтому чтобы дальше работать с более короткой переменной, я решил переписать результат в final, который signed int. При проверки на железе в final по факту ахинея, а в "а" все верно. Т.е. косяк в преобразовании типов. В unsigned там все просто преобразовывается. А с signed что то не придумать. Подскажите пожалуйста, заранее спасибо!
  15. На данный момент он не известен, тем более в данном диапазоне частот. Известно только что на определенных частотах начинается активное поглощение примесными центрами. А вот насколько активное, это в том числе одна из задач исследования.