After implementing the code on hardware the following were the results:

I created a lookup table of around 100-256 samples with values increasing from 0-4095 to represent an incremental increase in the voltage of around (50-124px representing a pixel). Then that lookup table was fed to the DAC via Interrupt routine in stm32cubeide and also implemented on stm32duino with just a normal for loop to test the difference. However the results were almost the same. 

The scanning done horizontally was going quite good it showed a straight line and i confirmed that it is working by slowing the scan speed of the galvo so i could see it jumping to each different pixel. The problem was that it took quite a bit of time coming from top to bottom as expected because the y axis dac was supposed to increment after the horizontal (x-axis) scan was complete. I deleted all delays but still results were the same. 

It is my understanding that no matter what i do doing it through the CPU might be slow for whatever reason, maybe the DAC is being notified late or value executed late. I have my clock speed of the peripheral and system clock speed at 72Mhz (maximum available) but this is still the case.  the following are my assumptions without looking too deep into it. 

Some Calculations

To estimate the time it takes to output a single value from RAM to the DAC using a for loop on the STM32 F3 Discovery board, we need to consider several factors:

1. CPU Clock Speed: The STM32F3 Discovery board typically runs at a default clock speed of 72 MHz.
2. Instruction Cycles: The number of clock cycles required for each instruction in the for loop, including loading the value from RAM, and writing it to the DAC.
3. Memory Access: The time to access the RAM and the DAC registers.

Estimation Steps

1. CPU Cycles per Operation:
   • Load from RAM: Typically takes 2 cycles.
   • Write to DAC: Writing to a peripheral register usually takes 2 cycles.
   • For Loop Overhead: The loop counter increment, comparison, and branching take additional cycles (around 3-4 cycles depending on optimization).
2. Total Cycles per Loop Iteration: Let's assume each operation (loading and writing) takes around 2 cycles, and the loop overhead is about 4 cycles. This gives us approximately:$$\text{Total Cycles}=2(\text{load})+2(\text{write})+4(\text{loop overhead})=8\text{ cycles}$$
3. Execution Time Calculation:
   • With a 72 MHz clock, each cycle is 1/ (72×10^6)  seconds, or approximately 13.89 ns.
   • So, the time per loop iteration is:
   Time per iteration=8×13.89ns ≈ 11.1ns, So that's approximately 11.1 microseconds for a whole sweep of values.

But that is assuming that the galvo's can follow the speed at which signal is given. So i'm sure now that the microcontroller is not the issue. It has to be the bulky mirrors slowing everything down. I wouldn't be surprised if it skips a couple of values as it is reaching the specified position. 

Further Investigation:

My galvo's are the generic ones sold in amazon but i got it from aliexpress, Looking at the specification it has the rating of 15kpps so that should give us around 66.67 microseconds for each step. now that's still not surprising, our whole sweep which was running at full speed completely taking around 11.1 microseconds, the galvo is being a bottleneck which is around 6 times slower. 

In addition to that according to specifications my galvo can sweep an angle of +-20 degrees with an input signal range of +-5V, since my signal is only 0 - 3.3V that gives me an angle range of  ≈6.6 degrees for the whole range.  This is good because the smaller range it is the lesser momentum it will build and easier for it to put a stop to it's motion. 

There seems to be a problem in my understanding because if the galvo's response rate is truly 6 times slower that means the galvo should not even jump to the next point, instead should increment to the next value and 6 times and then draw another point on the 6th vertical line, that means we are probably going to be expecting a vertical scanning with 6 lines being illuminated at once and then the other 6 lines. 

That leads me to believe that galvos are faster than what is being advertised? or my calculations are wrong. I would have to determine how fast the galvo is moving by probably doing some classical measurements on it, i'm not sure how tho. But getting the time it takes the galvo to take a step is completely essential to the firmware. 

An idea, if i mark the initial and final position namely 0 and 3.3V laser positions and put a light detecting diode that will trigger the oscilloscope and with that i can measure the time taken from initial to final. and this way can divide the time into individual pixel drawing time. I'll be trying this next.