![]() Next up is setting up two other pieces of the M4’s peripherals: I need the DMA controller to pick up all those delicious pixelreadings from the ADC. I was hoping to see exactly during which of the four clock cycles the CCD would feed me the output, but I don’t really feel smarter Īs with women there are still many things I don’t quite understand about CCD’s. Here’s a plot of the CCD master clock (running at 1.4 MHz) with the output signal at every 4th clock cycle: The datasheet finally makes more sense to me (though I still find it confusing that ICG period is called the readout time, when clearly all reading is done 10.6 ms after each ICG pulse). The SH is not shown but here it runs with a period of only 400 µs.Īpparently the SH and ICG need only fulfill the requirements when both trigger, and SH does indeed control the integration time. It’s my first 1D-selfie! The red line is the ICG-pulse running with a period of 40 ms and the blue is the output from the CCD. On two other GPIOs not shown here are the master clock, running at 1.4 MHz, and the ADC clock at 350 kHz. The blue line is the SH pulse and the red is the ICG pulse. However, having the Cortex-M4 timers, it proved quite manageable, and after waking up one night remembering an ARM timing register called something-Polarity and only a few trial runs, I finally had this: However, these application notes from Toshiba explain the different pulses a little better, and the datasheets for similar chips – namely the TCD1254 and TCD1103 – are also instructive.Įven though I felt smarter after reading I still had a nagging suspicion it would be a small nightmare to fulfill the timing criteria of the chip. This, together with the timing diagram in the previous post, is about as much information the datasheet provides. Here are the timing requirements for the TCD1304: And as with women timing is everything with CCD’s. For an up-to-date version and a more well structured presentation go to tcd1304.wordpressĬCD’s are just like women, demanding but wonderful creatures. Thanks! Will update with visual-theremin code if/when I get it to work.This post from 2015 introduced the very first firmware for driving the tcd1304dg. though I was able to get a busy-loop with a delay to effectively dim an LED. So does this mean that USB_VCP is useless for the F401? It seems LED.intensity is also broken or not implemented. Thanks, I figured as much, having some prior experience with microcontrollers and JTAG. You'll need to connect Tx from the USB-serial adapter to Rx on the F401, Rx on the USB serial adpater to Tx on the F401, and GND from the USB-serial adapter to GND on the F401. If you're going to use UART-6 then you need to connect a USB-to-serial adapter to the appropriate pins on the board and also use the appropriate /dev/ttyACMx for the usb-to-serial adapter. Note: If you're going to use UART-2 then you need to quit whatever program you were using for the REPL before running your host program. now back to co-routine mutlitasking for a GPIO cap-sense to LED-brightness visual-theremin! I changed the device program back to UART 2, and prepended a 'print' on the client-side and voila! You also don't print anything in your host program - you just read the data over and over in an infinite loop.ĭ'OH! That was the key here. Yeah I was trying all sorts of things, with ser.read() and sending different strings from the MCU side. Now your host program calls readline, which waits for a newline, and since you don't send any, it will wait forever. Strangely it seems like pyb either carries over from boot.py, or it just magically is there, as I find pyb calls to work from the non-boot.py scripts that boot.py calls. I also uncommented he import of pyb which you'll need since you call pyb.delay: That's why I tried both USB_VCP, thinking well, I guess maybe that sends JTAG-encapsulated commands when you call write on it, while the UART would have its RS232-style protocol wrapping the data. Yeah that is what I figured when I was going through the schematic from STM, and also suspected it from eyeing the traces on the board for PA2 and PA3 (they looked unconnected, as in the schematic, and by default being routed to the ST-LINK TDI and TDO pins) It would be useful to describe what you're connecting to where.īy default, UART-2 is connected to he stlink processor, which will be advertised as /dev/ttyACM0 when plugging in the NUCLEO board
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |