Page 8 of 10 FirstFirst ... 45678910 LastLast
Results 71 to 80 of 92

Thread: Open Laser Show DAC (USB)

  1. #71
    Join Date
    Feb 2009
    Location
    East Coast of Southern Virginia
    Posts
    536

    Default

    Quote Originally Posted by aszasza View Post
    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.

  2. #72
    Join Date
    Jan 2019
    Posts
    10

    Default

    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.



    Attached Thumbnails Attached Thumbnails OLSD.jpg  


  3. #73
    Join Date
    Feb 2009
    Location
    East Coast of Southern Virginia
    Posts
    536

    Default

    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 View Post
    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.




  4. #74
    Join Date
    Jan 2019
    Posts
    10

    Default

    Quote Originally Posted by cfavreau View Post
    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 View Post
    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 View Post
    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.

  5. #75
    Join Date
    Feb 2009
    Location
    East Coast of Southern Virginia
    Posts
    536

    Default

    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.

  6. #76
    Join Date
    Jan 2019
    Posts
    10

    Default

    Quote Originally Posted by cfavreau View Post
    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 View Post
    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 View Post
    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

  7. #77
    Join Date
    Feb 2009
    Location
    East Coast of Southern Virginia
    Posts
    536

    Default

    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.

  8. #78
    Join Date
    Jan 2019
    Posts
    10

    Default

    Quote Originally Posted by cfavreau View Post
    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 View Post
    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.

  9. #79
    Join Date
    Jan 2019
    Posts
    10

    Default

    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.


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

    Now I can make and upload any modified firmware to the 16u2 chip.
    Last edited by aszasza; 01-13-2019 at 10:36.

  10. #80
    Join Date
    Feb 2009
    Location
    East Coast of Southern Virginia
    Posts
    536

    Default

    Quote Originally Posted by aszasza View Post
    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.


    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •