microgeek.eu

Do połączenia z komputerem wykorzystane zostało oryginalne złącze, czy jakiś osobny, specjalnie spreparowany kabelek? Czy złącze, które widać na zdjęciu, można oprócz zasilania i podejrzewam programowania, można wykorzystać do komunikacji z komputerem?

Super, przyda się.

Na DiscoveryF4 do zabezpieczeń używany jest scalaczek "EMIF02-USB03F2" - w niezbyt przyjaznej obudowie do wytrawienia/lutowania.

Ma może ktoś jakiś sprawdzony w lepszej obudowie?

dziękować

już leci w zamówieniu

odpaliłem sobie wszystko i smiga elegancko - co do odbioru info znajdziemy tutaj: https://forbot.pl/blog/kurs-stm32-f4-11 ... sb-id13477 tylko jest mały błąd, tam w komentarzach też go wykryli zmienne muszą być typu volatile. Przerobię kod, żeby ładnie odbierał linie w uC z callbackiem i dorzucę

OK - przerobiłem wszystko w taki sposób, ze mamy ładnego callbaczka od odbioru linii z USB. Z tym, że dodałem bufor cykliczny itp, ale nie zawsze to się przyda - jak prześlemy "ciurkiem" linie z kompa - to sama biblioteka powinna nam zapewnić, że dostaniemy to w jednym buforze. Powinna, ale przetestowałem to spamując z kompa i czasem jednak linia dochodziła rozbita na 2 - były to 2 przypadki w ciągu kilkunastu minut spamowania, ale jednak, stąd ten sposób zapewni 100% bezawaryjność

Do pobrania projekt atollica na procek STM32F070F6P6 - tu fajny "tip" - można skorzystać z tych tanich chińskich płytek z 030F4P6 i przelutować scalaczka. Ten F070 w kamami kosztuje 6,23zł, a mamy w nim 32kB flasha, 6kB ramu no i odpada układ przejściówki USB->uart. Mega wygodna sprawa. Nadmienie jeszcze, że do działania USB na tym procku niezbędny jest zewnętrzny kwarc - musimy na zegarze USB mieć stabilne 48MHz ( na tych chińskich jest 8MHz + PLL i działa).

Mały fragment kodu z main - jak to zaimplementować:

Kod: Zaznacz cały

/* USER CODE BEGIN 0 */

void odebrano_linie_odeslij(char *wsk)
{
   // odeslanie odebranej wiadomosci:
   MessageLength = sprintf(DataToSend, "Odebrano: %s\r\n", wsk);
   CDC_Transmit_FS(DataToSend, MessageLength);

   switch( wsk[0] )
   {
   case '1':
   {
      HAL_GPIO_TogglePin(LED1_GPIO_Port,LED1_Pin);
      break;
   }
   case '2':
   {
      HAL_GPIO_TogglePin(LED2_GPIO_Port,LED2_Pin);
      break;
   }
   case '3':
   {
      HAL_GPIO_TogglePin(LED3_GPIO_Port,LED3_Pin);
      break;
   }
   }

}
/* USER CODE END 0 */

int main(void)
{
  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MCU Configuration----------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();

  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_USB_DEVICE_Init();

  /* USER CODE BEGIN 2 */

  // rejestracja callbacka dla odebranej linii
  CDC_register_rx_callback( odebrano_linie_odeslij );

  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
  /* USER CODE END WHILE */

  /* USER CODE BEGIN 3 */
     CDC_receive_event_check();
  }
  /* USER CODE END 3 */

}

i projekt:

USB_F0_test.zip

Edit:
przy okazji pytanko - biblioteka oferuje ładną funkcję, która wykrywa, że USB zostało zainicjalizowane. No i działa to ok - zapalam sobie diodkę, jest też funkcja która wykrywa Deinit - ale to juz nie działa tak fajnie. Tzn - nie wykrywa odpięcia USB, tylko moment kiedy to host USB wymusza ponowną inicjalizację. Więc mamy info, że coś się podłączyło, ale nie, ze nagle się odłączyło. Jeśli urządzenie jest zasilane z USB - żaden problem z wykrywaniem, jednak jeśli jest zasilane z zewnątrz to (czasem - zależy od użycia) - może to być problemem. Jakiś pomysł jak to sprytnie wykrywać?

dambo pisze:przy okazji pytanko

Po rozpoznaniu tematu wydaje mi się, że taka funkcjonalność w CubeMX Middleware istnieje dla procków z USB OTG. Dla µC ze "zwykłym" USB FS pozostaje chyba tylko monitorowanie napięcia na VUSB. W tym wypadku wykorzystanie do zabezpieczenia magistrali z USBLC6-4 wiąże się z problemem opisanym tutaj: http://www.keil.com/forum/59871/

microgeek.eu

UART bez FTDI/CP, tylko procesor i kabelek

Re: UART bez FTDI/CP, tylko procesor i kabelek

Re: UART bez FTDI/CP, tylko procesor i kabelek

Re: UART bez FTDI/CP, tylko procesor i kabelek

Re: UART bez FTDI/CP, tylko procesor i kabelek

Re: UART bez FTDI/CP, tylko procesor i kabelek

Re: UART bez FTDI/CP, tylko procesor i kabelek

Re: UART bez FTDI/CP, tylko procesor i kabelek