panda381 / picolibsdk Goto Github PK

Hi, thank you for your awesome projects!

I have just tried running the PicoinoMini Monoscope, and it looks like it doubles the 320x240 output to give a 640x480 signal. I understand that this is the common minimum requirement for VGA monitors.

I am interested in displaying video on an old SD CRT TV, which can only display 15kHz signals. Is it possible to configure the library to output real 320x240? Or would that require modification?

Thank you!

Hello, I am trying compile source files using c_all.bat with make debug mode, but I have this error

======== Compiling group Pico ========

======== Compiling Base ========

======== Compiling Led ========
Device: pico
GNU Make 4.2.1_st_20190816-0744_longpath
Built for x86_64-w64-mingw32
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles....
Updating goal targets....
 File 'all' does not exist.
   File 'createdirs' does not exist.
  Must remake target 'createdirs'.
  Successfully remade target file 'createdirs'.
   File 'elf' does not exist.
     File 'build/Led.elf' does not exist.
       File 'build/boot2_w25q080_bin.o' does not exist.
      Must remake target 'build/boot2_w25q080_bin.o'.
    ASM          ../../../_boot2/boot2_w25q080_bin.S
make (e=3): Systém nemůže nalézt uvedenou cestu. (File not found)
make: *** [../../../Makefile.inc:340: build/boot2_w25q080_bin.o] Error 3

But file boot2_w25q080_bin.S exist on correct location. Also I have ARM binaries at C:\ARM10

Summary

I have a CDC device that uses the very common FTDI-232 serial-to-USB chip. Part of the device descriptor shows:

*** Device descriptor ***

  bLength         18
  bDescriptorType 1
  bcdUSB          2.00
  bDeviceClass    0x00  <== this is a 0x00, ugh
  bDeviceSubClass 0x00  <== this is a 0x00, ugh
  bDeviceProtocol 0x00
  bMaxPacketSize0 8
  idVendor        0x0403  <== this is "FTDI" (the vendor)
  idProduct       0xcd18  <== this is "Abaxis Piccolo xpress" (the product)

Notice that the Class and SubClass are listed here both as 0x00, instead of what they should be for a normal CDC device. As a result, when the USB Host tries to enumerate this device, it's not quite sure what to do, so I think it just skips it. I would like for the USB Host to consider this device to be a CDC class device (which I think it is actually), even though it doesn't claim to be here. This capability was recently added to TinyUSB. Basically, I think TinyUSB is aware of this type of device and considers it to be a CDC class.

In addition, there are some USB control commands that need to be sent to the device to set it up properly. These are sent as a USB control transfer with the following:

# these are sent as: bmRequestType, bRequest, and wValue
cmd(0x40,  0,  0)      # resets device, purges RX/TX, clears DTR/RTS, data is 8N1, leaves baud
cmd(0x40,  1, 0x0303)  # enables DTR/RTS
cmd(0x40,  3, 0x4138)  # sets 9600 baud (3MHz/312.5)

Question

First, when trying to debug this, it would be nice to be able to do a little "printf() debugging". I am using the PicoPad/USB/USBUART example (appropriately adjusted for just the Pico). I've configured it so that I can upload code and connect to the Pico through the UART, while being able to use the on-board physical microUSB port to connect to the Piccolo (CDC device). From the main code, I can use Print("I'm here...\n"); statements, but I can't use them from sdk_usb_host.c, where I'm trying to debug to try to get this working for me. So my first question is, how can I use a Print() style message from withing sdk_usb_host.c to help me debug this?

Second, is there a way to send an arbitrary USB control transfer to the device to reset it and configure it's flow control, data bits, and baud as shown above? I think each of those cmd() calls (that code is actually in Ruby) just generate an 8-byte USB control packet that configures the device. My second question is, how can I send these packets to configure the device?

Thanks!

This project looks really incredible! Great job!

I am on macOS and would like to compile and test this out.

I followed the readme for Linux and made the shell scripts executable and I was able to compile the example in PicoLibSDK/Pico/USB/Hello.

The compilation died right at the end, because I don't have the LoaderCrc executable on macOS. Here's the message:

... lots of compilation output here ...

CC ../../../_devices/picopad/picopad_led.c
CC ../../../_devices/picopad/picopad_init.c
CC ../../../_devices/picopad/picopad_ss.c
C++ src/main.cpp
ld build/Hello.elf
bin Hello.bin
hex Hello.hex
lst Hello.lst
sym Hello.sym
siz Hello.siz
uf2 Hello.uf2

   text	   data	    bss	    dec	    hex	filename
  61524	      0	 156684	 218208	  35460	build/Hello.elf
../../../_c1.sh: line 94: ../../../_tools/PicoPadLoaderCrc/LoaderCrc: No such file or directory
ERROR!
09:20:26 PicoLibSDK/Pico/USB/Hello> ....

However, in the generated files, I do see that there is build/Hello.elf file and also a ./Hello.uf2 file. I assume that the .uf2 file is missing CRC information, which would normalled be added by LoaderCrc. I tried the following:

• I tried to directly push out the build/Hello.elf file with this: sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" -c "program build/Hello.elf verify reset exit". I assume that the *.elf file does not need the CRC check on it, but I'm not certain.
• I also tried to directly push out the Hello.uf2 file as-is, using picotool load -f -x Hello.uf2. I assume this will not work because it's missing the CRC information.
• I also tried using a program called bin2uf2 from @ataradov at his repo. This didn't work either.

Do you have any suggestions on other ways I could get the compiled Hello example to my Pico?

Thanks!

The USB Host support looks great!

Is there a short example of how to use this USB Host support to communicate with a CDC device?