OK, I had not realized that the frequency generation was for a motion control project, or that the goal was to get programming exercise. My tendency is to always avoid the software approach because the code is always invisible when the thing is running, whatever that thing may be. AND also the software approach ALWAYS needs an external computer and a lot of additional hardware and none of that is really free, even if you don't need to pay cash for it. One more benefit of doing things in hardware is that with just a small bit of extra effort during the design phase it is possible to have every single part available from multiple sources. The grief of starting a big production run and then finding that some key part is not available because suddenly it is demanded for national defense is quite extreme. Using components available from multiple producers is the easy solution, and not having to load in code to make the boards work is also mighty nice. So designing is a string of choices. But we knew that all along.

Software approach seems good because you could implement it in maybe tens of similar micros. Isn't good enough, better than a maybe crowded BOM?

 

Software approach seems good because you could implement it in maybe tens of similar micros. Isn't good enough, better than a maybe crowded BOM?

My point exactly. I've ended up with a single component that does indeed have multiple sources. Of course my programming has been done around the AT89LP4052, but it's very easily transportable to other supplier's devices, such as Maxim, for instance. As for the computer part, yes it will need an external computer to do what I want to do, but that is unavoidable anyway, since all CNC programming (CAM) requires the use of CAD software anyway.

Do you care to share details on your motion control problem?

This is but a single piece of what I have in mind. The frequency generator is extremely important, though. I wanted a slave device that could instantaneously generate any frequency with an 11 bit resolution, and I've done it. My next goal at perfecting this thing is to raise the resolution to 14 bits, and the frequency range from 1 Hz to 65 KHz.

What I've already done (and this has been working just fine in my machines for the last 10 years) is implement the bresenham interpolation algorithm in those chips. That way the chip becomes a slave to a main MCU that also controls the master frequency generator. And the way I've done things, it allows for an unlimited number of axis of motion to be added to the system, by just using an additional $1.80 dlls MCU per axis.

My final goal is to interface what I've done to a USB device with enough memory and data transfer speed to allow the system to continuously concatenate every motion command. That is, to be able to trace complex motion commands in an uninterrupted way. It's called "routing capabilities"

The applications for this system are extremely varied. It can be used in CNC machinery, robot arms, and even to automate entire production lines.

 

My point exactly. I've ended up with a single component that does indeed have multiple sources. Of course my programming has been done around the AT89LP4052, but it's very easily transportable to other supplier's devices, such as Maxim, for instance. As for the computer part, yes it will need an external computer to do what I want to do, but that is unavoidable anyway, since all CNC programming (CAM) requires the use of CAD software anyway.


This is but a single piece of what I have in mind. The frequency generator is extremely important, though. I wanted a slave device that could instantaneously generate any frequency with an 11 bit resolution, and I've done it. My next goal at perfecting this thing is to raise the resolution to 14 bits, and the frequency range from 1 Hz to 65 Mhz.

What I've already done (and this has been working just fine in my machines for the last 10 years) is implement the bresenham interpolation algorithm in those chips. That way the chip becomes a slave to a main MCU that also controls the master frequency generator. And the way I've done things, it allows for an unlimited number of axis of motion to be added to the system, by just using an additional $1.80 dlls MCU per axis.

My final goal is to interface what I've done to a USB device with enough memory and data transfer speed to allow the system to continuously concatenate every motion command. That is, to be able to trace complex motion commands in an uninterrupted way. It's called "routing capabilities"

The applications for this system are extremely varied. It can be used in CNC machinery, robot arms, and even to automate entire production lines.

I was just thinking it would be easier and more accurate to work with either (1) wave period, or (2) duty cycle. Frequency and the 1/period adds a level of complexity, resolution challenges and calculation time - also, it becomes much easier to take advantage of counters and clocks onboard the microcontroller.

 

I was just thinking it would be easier and more accurate to work with either (1) wave period, or (2) duty cycle. Frequency and the 1/period adds a level of complexity, resolution challenges and calculation time.

I considered duty cycle for a brief moment. But I thought it was pointless to translate from analog to digital when I already had mastered the digital part. I think I forgot to mention that this whole thing is focused around closed-loop step motors.

 

Not to be a showoff ... but what the heck...