I'm a bit late to this whole thing but if lookup table size is an issue, how about looking at the Cortex M4 processors? They are the basis of a number of teensys. For $20 you can get an Arduino IDE compatible board with 256K bytes of flash. For $30, you can get a Megabyte of flash. Lots of system resources as well.

Thanks, philba... but I'm doing what I'm doing with a single chip (and not a board) costing less than a couple of bucks , and I have complete control at the lowest possible level of what I'm doing ... that's why I'm not into the Arduino thing...

The Cortex M4 looks interesting though. So far, I've only got experience programming the 8051 architecture (I'm old school). But 8-bit MCUs are now almost a thing of the past, and I've been trying to make up my mind and venture into more recent technology. ARM is definitely one posibility, the other one is AVR ... and although I know how to program in C, I want to learn how to program them in assembly, as I'm currently doing it with the 8051 ... which one of the two techs would you suggest?

 

Thanks, philba... but I'm doing what I'm doing with a single chip (and not a board) costing less than a couple of bucks , and I have complete control at the lowest possible level of what I'm doing ... that's why I'm not into the Arduino thing...

The Cortex M4 looks interesting though. So far, I've only got experience programming the 8051 architecture (I'm old school). But 8-bit MCUs are now almost a thing of the past, and I've been trying to make up my mind and venture into more recent technology. ARM is definitely one posibility, the other one is AVR ... and although I know how to program in C, I want to learn how to program them in assembly, as I'm currently doing it with the 8051 ... which one of the two techs would you suggest?

So what chip did you choose?

 

So what chip did you choose?

I haven't chosen anything yet ... I'd like to know which architecture is better supported and versatile (easier to use and program) ... I've asked this same question in older threads, but no one here has answered me so far.

 

I haven't chosen anything yet ... I'd like to know which architecture is better supported and versatile (easier to use and program) ... I've asked this same question in older threads, but no one here has answered me so far.

YTou have me confused then

Thanks, philba... but I'm doing what I'm doing with a single chip (and not a board) costing less than a couple of bucks , and I have complete control at the lowest possible level of what I'm doing ... that's why I'm not into the Arduino thing..

 

The Cortex is an ARM. The M4 on the Teensy 3.2 (MK20DX256VLH7) looks like a relatively easy to solder SMD package and has 1/4 MByte of Flash. You'd need a programmer, I think a simple JTAG would do it but am rapidly exceeding my knowledge level.

 

YTou have me confused then

My bad ... I misunderstood your question then. As I mentioned on post #39, I'm currently using an AT89LP4052, which is based on the soon to become obsolete 8051 architecture. What I want is to choose a new chip, and abandon the 8051 altogether

 

The Cortex is an ARM. The M4 on the Teensy 3.2 (MK20DX256VLH7) looks like a relatively easy to solder SMD package and has 1/4 MByte of Flash. You'd need a programmer, I think a simple JTAG would do it but am rapidly exceeding my knowledge level.

Not in the habit of replying to myself but thought I'd provide a little more info.

There is a GCC compiler for the Cortex M4. I think there is an assembler too. JTAG programmers aren't super cheap so the $20 vs $8 kind of gets swamped by the programmer cost. Worth the investment if you are building a product, not so sure about that if building a one-off (or few-offs).

 

My bad ... I misunderstood your question then. As I mentioned on post #39, I'm currently using an AT89LP4052, which is based on the soon to become obsolete 8051 architecture. What I want is to choose a new chip, and abandon the 8051 altogether

Soon. Lol. The architecture was introduced by Intel in 1980! Kind of like the energizer bunny. Way long in the tooth but kind of like the lowly cockroach - impossible to kill off.

I would also look at the ST32 core based 32 bit processors. They are plentiful and cheap. You can buy modules for just a few dollars off ebay/aliX. I believe the Arduino IDE supports them as well though not sure how good the implementation is. It's appears to me support is a bit ragged.

 

Soon. Lol. The architecture was introduced by Intel in 1980! Kind of like the energizer bunny. Way long in the tooth but kind of like the lowly cockroach - impossible to kill off.

I would also look at the ST32 core based 32 bit processors. They are plentiful and cheap. You can buy modules for just a few dollars off ebay/aliX. I believe the Arduino IDE supports them as well though not sure how good the implementation is. It's appears to me support is a bit ragged.

I'd be very happy to find an MCU with single-cycle instructions such as the one I've been using. For a moment I considered using the 16-bit family of PICs. But then I thought, why learn an architecture that I'm not familiar with if that architecture is not among the most advanced to date?

 

Yeah, I would definitely move to a 32 bit architecture. Personally, I would only look at ARM based and I'd avoid ones that don't have full GCC for free.

 

Yeah, I would definitely move to a 32 bit architecture. Personally, I would only look at ARM based and I'd avoid ones that don't have full GCC for free.

I'm afraid you lost me there ... mind elaborating what GCC is? I already tried to google it, but its meaning escapes me.

 

Yeah, I would definitely move to a 32 bit architecture. Personally, I would only look at ARM based and I'd avoid ones that don't have full GCC for free.

Been working with the 18F family for years, what about the 32 bit PICs? Are they worth anything?

Not C conversant myself.

 

GCC is the Gnu Compiler Collection (used to be Gnu C Compiler). Linux is built with GCC, Arduino is based on GCC, GCC support X86, AVR, ARM, ... Something like 60 different architectures.

Here's an overview

As to PIC 32 - I would skip that. It's not an ARM based architecture.

 

Well, I'm in trouble now... all of the DDS chips that I could find at Digike are SMT, which is something that I'm trying to avoid. It's also bad that they have so many pins!
On the other hand, they output sine waves and work at very high output frequencies. I require square wave output, but I guess I could use a comparator to transform the sine wave into one. But the high frequency output will most probably require the use of a divide-by-x circuit. I'll have to work on that too.

The chip that I think could do the trick, among others, is the AD9833. But it doesn't look like it's easy to use... at all...

This little endeavor is looking much more complex than I thought at first...

One challenge with the DDS method is that it produces an approximation of a sine wave, while your post mentioned a square wave. But first there is the question about controlling the frequency. An analog control with a knob and probably a range switch is fairly simple, but the knob and frequency setting would not be calibrated, and not simple to reset. Using a digital method to set the frequency makessetting easier, but the circuit gets a lot more complicated. The simple way to have digital control and easy repeated settings is to use a frequency synthesizer with a phase locked loop. A digital number is used to determine the number that the oscillator frequency is divided by to produce the reference frequency. There are hundreds of PLL (phase locked loop) circuits and articles around, with frequency ranges available from sub-hertz up into the tens of gigahertz.

 

Not to bust a bubble but Mplab x xc32 is GCC

The Standard Library Files are derived from software developed by Microchip, MIPS Technologies

The rest is GCC

 

Not to bust a bubble but Mplab x xc32 is GCC
The rest is GCC

No bubbles burst. My objection to PIC32 is it's MIPS, not ARM.

 

@cmartinez
Have you sat down and done some math to understand the magnitude of your problem? I have not read through all the posts here but, before you get too far, I hope you realize that microcontroller tick at a constant frequency (f) so the period (1/f) is also constant.

Now, with that constant ticking, you want to be able to dial in at frequency A, 15000Hz and then adjust to frequency B, 15001 Hz.
That means frequency B is delivering 15001 cycles, each at just 1 part in 15000 shorter than Frequency A.

Do you see where I'm going here?

To have 1 Hz resolution at 15000 Hz, you will need a period of 1/(15000 *15001) or, 225M Hz.

By the time you get to 49999 Hz, you'll need 2.5 GHz.

 

@cmartinez
Have you sat down and done some math to understand the magnitude of your problem? I have not read through all the posts here but, before you get too far, I hope you realize that microcontroller tick at a constant frequency (f) so the period (1/f) is also constant.

Now, with that constant ticking, you want to be able to dial in at frequency A, 15000Hz and then adjust to frequency B, 15001 Hz.
That means frequency B is delivering 15001 cycles, each at just 1 part in 15000 shorter than Frequency A.

Do you see where I'm going here?

To have 1 Hz resolution at 15000 Hz, you will need a period of 1/(15000 *15001) or, 225M Hz.

By the time you get to 49999 Hz, you'll need 2.5 GHz.

Thanks, gopher. But I already solved the problem using a lookup table, as explained in post #31.

The calculations you've mentioned are among the first things I did when I started this little venture. And in the end, I had to make some compromises to make things work in an acceptable manner, such as imllementing a frequency resolution of about 23 Hz per increment. Which proved to be good enough for the motion control application that I'm currently working on.

My results could be significantly improved though, if I were to use a chip with the same performance, but with more program memory available. That's why (among other reasons) I'm considering learning a new mcu architecture, and eventually grow away from the good'ol 8051.

Tomorrow I'll be opening a new thread to ponder the available options.

nighty-nite...

 

Thanks, gopher. But I already solved the problem using a lookup table, as explained in post #31.

The calculations you've mentioned are among the first things I did when I started this little venture. And in the end, I had to make some compromises to make things work in an acceptable manner, such as imllementing a frequency resolution of about 23 Hz per increment. Which proved to be good enough for the motion control application that I'm currently working on.

My results could be significantly improved though, if I were to use a chip with the same performance, but with more program memory available. That's why (among other reasons) I'm considering learning a new mcu architecture, and eventually grow away from the good'ol 8051.

Tomorrow I'll be opening a new thread to ponder the available options.

nighty-nite...

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.

 

Thanks, gopher. But I already solved the problem using a lookup table, as explained in post #31.

The calculations you've mentioned are among the first things I did when I started this little venture. And in the end, I had to make some compromises to make things work in an acceptable manner, such as imllementing a frequency resolution of about 23 Hz per increment. Which proved to be good enough for the motion control application that I'm currently working on.

My results could be significantly improved though, if I were to use a chip with the same performance, but with more program memory available. That's why (among other reasons) I'm considering learning a new mcu architecture, and eventually grow away from the good'ol 8051.

Tomorrow I'll be opening a new thread to ponder the available options.

nighty-nite...

I've said it before and I'll say it again, if you are not trying to do something revolutionarily better than what is currently possible, your difficult challenge may be difficult because there are better ways to solve your problem.

Our brain power might be better used to help solve your problem instead of trying to solve your unusual soluti9n.

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