Open Laser Show DAC (USB)

Quote:

Originally Posted by aszasza

No, I mean like the lasershowgen, for example. When you hit the "search for dacs" button, its not showing up as a selectable device, only the soundcard dac. Also, the provided test software can't see it either. (olsd test.exe)
I do have all the drivers properly installed because I can use the arduino for other purposes, I can open serial monitor and communicate with the arduino if I upload my own sketches ect...

The software drivers are looking for a FT232R FTDI Usb To Serial chip. If it doesn't find one then it will not see your OLSD board. I have a modified version that works with the newer FT231X Chips as well since those come on some Arduinos. The reason for this is because I used the FTDI driver DLL to get more control, higher speeds (2Mbps). and simple auto detection. All of the software on my website currently requires the FT232R chip. The good news is it can be modified to run using the regular serial port API. I have been working on this since the FTDI chips have been falling out of favor for a while. It isn't done yet though. We can continue the conversation here. See my reply to your other post above.

1 Attachment(s)

Thank you for the fast replys, I can tell that you are really taking care of this project, its always nice to see people like you. :)

Currently I'm on an original arduino uno with the atmel mega16u chip as the serial interface, but I do have other arduinos in my workplace, just not at home with me at the moment. I also have some FTDI breakout boards at work so I can try to hook up that to the arduino and see what happens.
Can you please tell me how should I connect it? I mean the cts line, its not very clear to me at the moment.

I have also tried to use zadig (https://zadig.akeo.ie/) to change the usb description name of the arduino. It was showing up as "Arduino Uno" in the device manager, now its coming up as "FT232R USB UART" but I still can not manage to connect to the device, probably because of this control line thing.

Can you describe why we need this in the first place? The code for the mega16u is online and there are some free pins routed out on the UNO from that microcontroller, so I think I could probably modify the software on that one and maybe implement the needed CTS line.

Fun fact about my build is that I could not get 20k resistor arrays so I had to solder 0603 20k resistors one by one, sideways. *retardo

Nice soldering work! That is very impressive soldering the resistors like that.

The reason why it still doesn't get recognized is I use the FTD2XX.DLL for talking to the USB to serial chip which only works with FTDI chips. The DLL lets me do autodetection, something I am still working on with the Com port code.

For hooking up the CTS line I put it in the pinout table on my website (under the Arduino Port Map):
http://www.fab-favreau.com/index.php/Main/OLSDRev4

Here is the hookup:
J1 Digital 7 PD7 Output #CTS (needs jumper #CTS->FTDI)

The CTS line allows the arduino to control the flow of data so that it doesn't miss anything.

I am sure we can get the mega16u working if you are up for it. That would be a really cool thing to do. It probably will work even better than the other chips since we will have full control over it.

Quote:

Originally Posted by aszasza

Thank you for the fast replys, I can tell that you are really taking care of this project, its always nice to see people like you. :)

Currently I'm on an original arduino uno with the atmel mega16u chip as the serial interface, but I do have other arduinos in my workplace, just not at home with me at the moment. I also have some FTDI breakout boards at work so I can try to hook up that to the arduino and see what happens.
Can you please tell me how should I connect it? I mean the cts line, its not very clear to me at the moment.

I have also tried to use zadig (https://zadig.akeo.ie/) to change the usb description name of the arduino. It was showing up as "Arduino Uno" in the device manager, now its coming up as "FT232R USB UART" but I still can not manage to connect to the device, probably because of this control line thing.

Can you describe why we need this in the first place? The code for the mega16u is online and there are some free pins routed out on the UNO from that microcontroller, so I think I could probably modify the software on that one and maybe implement the needed CTS line.

Fun fact about my build is that I could not get 20k resistor arrays so I had to solder 0603 20k resistors one by one, sideways. *retardo

Quote:

Originally Posted by cfavreau

Nice soldering work! That is very impressive soldering the resistors like that.

The reason why it still doesn't get recognized is I use the FTD2XX.DLL for talking to the USB to serial chip which only works with FTDI chips. The DLL lets me do autodetection, something I am still working on with the Com port code.

Okay it makes perfect sense now.

Quote:

Originally Posted by cfavreau

For hooking up the CTS line I put it in the pinout table on my website (under the Arduino Port Map):
http://www.fab-favreau.com/index.php/Main/OLSDRev4

Here is the hookup:
J1 Digital 7 PD7 Output #CTS (needs jumper #CTS->FTDI)

The CTS line allows the arduino to control the flow of data so that it doesn't miss anything.

My bad, missed it. Thank you.

Quote:

Originally Posted by cfavreau

I am sure we can get the mega16u working if you are up for it. That would be a really cool thing to do. It probably will work even better than the other chips since we will have full control over it.

That way we could eliminate the need for the bodge wire, the mega16u2 is a really capable little thing so in theory it shouldn't be a problem to make it work. I'm up for it, already started looking into the code, but with that and with your code its just too much to digest at once.
https://github.com/arduino/ArduinoCo...uino-usbserial
This is the code for the usb serial stuff on the arduino, fortunately we can use the dfu bootloader so it should be simple-ish to make changes.

I think this will be fairly straight forward. I have an original UNO around here somewhere. I have to look up how to do the DFU bootloading.

The Atmega16u already handles the DTR line ...

Code:

void EVENT_CDC_Device_ControLineStateChanged(USB_ClassInfo_CDC_Device_t* const CDCInterfaceInfo){ bool CurrentDTRState = (CDCInterfaceInfo->State.ControlLineStates.HostToDevice & CDC_CONTROL_LINE_OUT_DTR); if (CurrentDTRState) AVR_RESET_LINE_PORT &= ~AVR_RESET_LINE_MASK; else AVR_RESET_LINE_PORT |= AVR_RESET_LINE_MASK; }

So that should give us a little clue as to how to handle the CTS. The CTS is an input and the code uses the LUFA library... there probably is an example for it.

I will take a peek around. I won't be able to work on it until this evening Eastern USA time ... so around 10pm or later. I will post when I have some more. Also I will look up my code for the COM port OLSD test program and driver. If you have a CH340 or CH341 knock off Arduino sitting around that will be pretty simple to get up and running I think.

Quote:

Originally Posted by cfavreau

I think this will be fairly straight forward. I have an original UNO around here somewhere. I have to look up how to do the DFU bootloading.

The Atmega16u already handles the DTR line ...

Code:

void EVENT_CDC_Device_ControLineStateChanged(USB_ClassInfo_CDC_Device_t* const CDCInterfaceInfo){ bool CurrentDTRState = (CDCInterfaceInfo->State.ControlLineStates.HostToDevice & CDC_CONTROL_LINE_OUT_DTR); if (CurrentDTRState) AVR_RESET_LINE_PORT &= ~AVR_RESET_LINE_MASK; else AVR_RESET_LINE_PORT |= AVR_RESET_LINE_MASK; }

Yeah, I've seen that too, they using it to reset the 328 so they can use the bootloader to upload scketches.

Quote:

Originally Posted by cfavreau

So that should give us a little clue as to how to handle the CTS. The CTS is an input and the code uses the LUFA library... there probably is an example for it.

I will have a look as well.

Quote:

Originally Posted by cfavreau

I will take a peek around. I won't be able to work on it until this evening Eastern USA time ... so around 10pm or later. I will post when I have some more. Also I will look up my code for the COM port OLSD test program and driver. If you have a CH340 or CH341 knock off Arduino sitting around that will be pretty simple to get up and running I think.

I'm in London, so there is a significant time zone difference, plus I'm on a holiday from tuesday... anyways I do have knock off arduinos, just need to pick one up from my workplace tomorrow.
On top of that I don't have a laser either just my scope in XY mode but that should be fine for testing...

EDIT:
https://www.arduino.cc/en/Hacking/DFUProgramming8U2
this is how you go about the DFU bootloader

A scope will work great! We just need to see if the vector image comes out OK.

As far as the code. I see how we can do it already. Here is the main loop:

Code:

for (;;) { /* Only try to read in bytes from the CDC interface if the transmit buffer is not full */ if (!(RingBuffer_IsFull(&USBtoUSART_Buffer))) { int16_t ReceivedByte = CDC_Device_ReceiveByte(&VirtualSerial_CDC_Interface); /* Read bytes from the USB OUT endpoint into the USART transmit buffer */ if (!(ReceivedByte < 0)) RingBuffer_Insert(&USBtoUSART_Buffer, ReceivedByte); } /* Check if the UART receive buffer flush timer has expired or the buffer is nearly full */ RingBuff_Count_t BufferCount = RingBuffer_GetCount(&USARTtoUSB_Buffer); if ((TIFR0 & (1 << TOV0)) || (BufferCount > BUFFER_NEARLY_FULL)) { TIFR0 |= (1 << TOV0); if (USARTtoUSB_Buffer.Count) { LEDs_TurnOnLEDs(LEDMASK_TX); PulseMSRemaining.TxLEDPulse = TX_RX_LED_PULSE_MS; } /* Read bytes from the USART receive buffer into the USB IN endpoint */ while (BufferCount--) CDC_Device_SendByte(&VirtualSerial_CDC_Interface, RingBuffer_Remove(&USARTtoUSB_Buffer)); /* Turn off TX LED(s) once the TX pulse period has elapsed */ if (PulseMSRemaining.TxLEDPulse && !(--PulseMSRemaining.TxLEDPulse)) LEDs_TurnOffLEDs(LEDMASK_TX); /* Turn off RX LED(s) once the RX pulse period has elapsed */ if (PulseMSRemaining.RxLEDPulse && !(--PulseMSRemaining.RxLEDPulse)) LEDs_TurnOffLEDs(LEDMASK_RX); } /* Load the next byte from the USART transmit buffer into the USART */ if (!(RingBuffer_IsEmpty(&USBtoUSART_Buffer))) { Serial_TxByte(RingBuffer_Remove(&USBtoUSART_Buffer)); LEDs_TurnOnLEDs(LEDMASK_RX); PulseMSRemaining.RxLEDPulse = TX_RX_LED_PULSE_MS; } CDC_Device_USBTask(&VirtualSerial_CDC_Interface); USB_USBTask(); }

Notice that it looks at the ring buffer to see if it is NOT full before reading more data from the USB buffer. We can just use that. So it will basically go... If CTS IO Pin is LOW then do not put any data in the ring buffer. That should work as the whole premise is that the USB is really fast and the UART can be really slow as in 300 bps. So this basically regulates the speed of the whole thing so that the UART doesn't get overwhelmed and is fed data at the proper rate.

Do you have any good references for doing the DFU boot loading? I will look it up on my own however I thought you might be more familiar with it.

Quote:

Originally Posted by cfavreau

A scope will work great! We just need to see if the vector image comes out OK.

As far as the code. I see how we can do it already. Here is the main loop:

Code:

for (;;) { /* Only try to read in bytes from the CDC interface if the transmit buffer is not full */ if (!(RingBuffer_IsFull(&USBtoUSART_Buffer))) { int16_t ReceivedByte = CDC_Device_ReceiveByte(&VirtualSerial_CDC_Interface); /* Read bytes from the USB OUT endpoint into the USART transmit buffer */ if (!(ReceivedByte < 0)) RingBuffer_Insert(&USBtoUSART_Buffer, ReceivedByte); } /* Check if the UART receive buffer flush timer has expired or the buffer is nearly full */ RingBuff_Count_t BufferCount = RingBuffer_GetCount(&USARTtoUSB_Buffer); if ((TIFR0 & (1 << TOV0)) || (BufferCount > BUFFER_NEARLY_FULL)) { TIFR0 |= (1 << TOV0); if (USARTtoUSB_Buffer.Count) { LEDs_TurnOnLEDs(LEDMASK_TX); PulseMSRemaining.TxLEDPulse = TX_RX_LED_PULSE_MS; } /* Read bytes from the USART receive buffer into the USB IN endpoint */ while (BufferCount--) CDC_Device_SendByte(&VirtualSerial_CDC_Interface, RingBuffer_Remove(&USARTtoUSB_Buffer)); /* Turn off TX LED(s) once the TX pulse period has elapsed */ if (PulseMSRemaining.TxLEDPulse && !(--PulseMSRemaining.TxLEDPulse)) LEDs_TurnOffLEDs(LEDMASK_TX); /* Turn off RX LED(s) once the RX pulse period has elapsed */ if (PulseMSRemaining.RxLEDPulse && !(--PulseMSRemaining.RxLEDPulse)) LEDs_TurnOffLEDs(LEDMASK_RX); } /* Load the next byte from the USART transmit buffer into the USART */ if (!(RingBuffer_IsEmpty(&USBtoUSART_Buffer))) { Serial_TxByte(RingBuffer_Remove(&USBtoUSART_Buffer)); LEDs_TurnOnLEDs(LEDMASK_RX); PulseMSRemaining.RxLEDPulse = TX_RX_LED_PULSE_MS; } CDC_Device_USBTask(&VirtualSerial_CDC_Interface); USB_USBTask(); }

Notice that it looks at the ring buffer to see if it is NOT full before reading more data from the USB buffer. We can just use that. So it will basically go... If CTS IO Pin is LOW then do not put any data in the ring buffer. That should work as the whole premise is that the USB is really fast and the UART can be really slow as in 300 bps. So this basically regulates the speed of the whole thing so that the UART doesn't get overwhelmed and is fed data at the proper rate.

Niiiice! That sounds like a win to me.

Quote:

Originally Posted by cfavreau

Do you have any good references for doing the DFU boot loading? I will look it up on my own however I thought you might be more familiar with it.

As far as I know, flip https://www.microchip.com/developmen...ctDetails/flip is the easiest way on windows. Check my previous comment as well.

I'm trying to build a working version of the original usb to serial firmware, but the provided makefile seems to be wrong, its 6 years old and its for the atmega8u2 chip. It seems like that I'm gonna have to dig up the internet to find a recent makefile for this. :mad:

Update: Found the solution: https://electronics.stackexchange.co...o-uno-firmware

Now I can make and upload any modified firmware to the 16u2 chip.

Quote:

Originally Posted by aszasza

I'm trying to build a working version of the original usb to serial firmware, but the provided makefile seems to be wrong, its 6 years old and its for the atmega8u2 chip. It seems like that I'm gonna have to dig up the internet to find a recent makefile for this. :mad:

Update: Found the solution: https://electronics.stackexchange.co...o-uno-firmware

Now I can make and upload any modified firmware to the 16u2 chip.

Cool! I found my modified drivers and test program last night. Were you able to find another Arduino with a CH34X chip on it? I will try to find my real Uno today and make a go at compiling the firmware for it.