0
\$\begingroup\$

The data sheet can be found here.

I'm trying to select a micro-controller which will eventually run a Wireless 2D Laser Engraver/3D Printer/CNC Machine.

I have very little experience in selecting micro-controllers, and only a rudimentary understanding of the terminology. The micro-controller would need to fit the following requirements:

  1. Run on 5V
  2. Have at Least One Digital Input (I understand that this is called a UART port.)which will be used to interpret the output signal from a FM wireless receiver outputting digital data.
  3. Have at Least 13 I/O pins. 1 to run the object on/off (I.E. CNC bit, Plastic Extruder, Laser.) And 4 pins for each h-bridge which will run stepper motors running the x-y-z axis.
  4. Be able to house an approx. 16KB C++ program for interpreting the digital data sent by the radio receiver, and the ability to edit the on-board program.
  5. Occupy the smallest amount of board-space by having only the required pins.

I believe that the PIC18F14K50 meets these requirements because the datasheet shows (in the order above):

  1. Runs on 1.8V to 5.5V.
  2. Has an Enhanced Universal Synchronous Asynchronous Receiver
  3. Transmitter pin. Has 14 I/O Pins.
  4. Can house a 16KB program which is flash memory, I.E. I can rewrite code at will. (I'm not worried about RAM, as I don't store many variables. The program is almost real-time.)
  5. Has the minimum amount of pins/board-space to fulfill my needs. (20 Pins.)

I believe I have all the terminology correctly assessed, but I'm not sure enough to order the part without some more experienced input.

A few things I noted were included on the data-sheet and I'm unclear on how to assess my needs for:

  • CPU Speed
  • EEPROM (I believe this is the precurssor to flash memory...why would I need both?) Comperators
  • 8-Bit Architecture

EDIT

It's also worth mentioning that I will need to be sending output to all 13 of those parallel ports every 500ms or so, if that effects the specs I would need I would love an explanation as to how it does.

\$\endgroup\$
  • \$\begingroup\$ I have tried to follow the guidelines on a specific question, if I failed in anyway to meet the guidelines, I would ask that a moderator tell me what I did wrong so that I can edit, rather than have my question removed. \$\endgroup\$ – Allenph May 6 '15 at 18:59
  • \$\begingroup\$ FWIW, this is a really, REALLY broad question, and it will MASSIVELY depend on the expertise you can bring to the software side of the equation. It should theoretically be capable of the task, but you will probably need to put considerable effort into the firmware. \$\endgroup\$ – Connor Wolf May 6 '15 at 19:02
  • \$\begingroup\$ I'm pretty new to C, but I work professionally with PHP, Ruby on Rails, Python, and Java. The hardware side of things is going to prove more of a challenge I think. One problem I think I may have on the software side is the size of the program. When I code in the above mentioned languages, I'm not particularly concerned with super-space-efficient code. It's not uncommon for me to write 50,000 lines on a complicated PHP application. The 16KB was really just my best ball park, if you would suggest more, I'll take your advice. \$\endgroup\$ – Allenph May 6 '15 at 19:04
  • 1
    \$\begingroup\$ Programming for micros is really, REALLY different from any high level languages, and frankly it's quite different from "normal" C as well. Have a look at grbl for a good example of a high-performance motion control system. \$\endgroup\$ – Connor Wolf May 6 '15 at 19:12
  • 2
    \$\begingroup\$ "I will need to be sending output to all 13 of those parallel ports every 500ms or so" ... That's pretty slow considering you are controlling 3 stepper motors. How fast will those need to step? Will they be stepping at the same time? What sort of timing requirements does the laser control require? Consider the impact on the timing of one thing due to interrupt latency caused by other things being serviced. This can cause stepper motor slipping and possibly erratic marking from your laser. If this is too much to answer, you may want to err on the side of a more powerful processor. \$\endgroup\$ – Tut May 6 '15 at 19:28
4
\$\begingroup\$

This is a broad question, but yes, it seems you found a minimum micro that still does what you specified.

However, that may not be a good idea unless this is a volume product. Stuff happens, and unforseen things come up. You may very well wish you had a few more pins or a little more processing power as you get into the project.

I'll assume this is a personal one-off project (I told you in your meta question that this sort of thing is important context). I'd get a 33F with lots of ROM and RAM for the main controller, and separate micros for each of the stepper motors. It takes more than a single H bridge to control a stepper.

For firmware simplicity, get the same PIC for all four roles. These things are cheap, but having to handle only one motor per PIC will make things easier. The three motor driver PICs would run the same code. They can receive commands from the main controller via a on-board IIC or CAN or something.

The 33F series runs on 3.3 V, but the newer ones also have a lot of 5V-tolerant inputs. The things you control inside your own hardware will be fine with 3.3 V. The few things you need to control externally may be OK with 0 to 3.3 V levels. Lots of things use "TTL compatible" input thresholds. If not, add a 3.3 V to 5 V converter chip for the few signals that really require 4 V for a logic high.

500 ms makes no sense for stepper motor control. You will probably re-evaluate the PWM outputs driving the stepper at 10 kHz or more, with PWM frequency at least 25 kHz. That may sound fast, but 100 µs (1/10 kHz) is actually a long time for such a micro to compute what duty cycle to emit next. I'd probably aim for re-computing what to do to a stepper each PWM pulse running at 100 kHz or so.

\$\endgroup\$
  • \$\begingroup\$ Well, the idea was to reduce load on the micro-controller in a specific way. The system will be wireless. The Server (In this case my laptop) will have a USB dongle which transmits relative data to my engraver circuit. The software will convert g-code into a series of "steps." The microcontroller will need to store enough functions for every combination of object on/off and stepper clockwise/counterclockwise (All three axis.) The program will send each "step" in the form of a "number" or byte, which corresponds to the correct step function. Every 500ms the code will repeat for another step. \$\endgroup\$ – Allenph May 6 '15 at 21:06
  • \$\begingroup\$ I would be running in half-steps. This effectively doubles my resolution. While it makes torque uneven, it doesn't matter much because the load on the steppers will be negligible. I chose 500ms between steps because it gives the object time to do it's work, I.E. burn the media, cut the media, extrude the media. Forgive me if I'm wrong, but I could run at whatever interval I want between steps and I wouldn't be affecting resolution, just print time and possibly laser burn depth. \$\endgroup\$ – Allenph May 6 '15 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.