Saturday, March 29, 2008
Arduino chosen for next stage of RepRap development
We have chosen the open-source Arduino microcontroller for the next stage of RepRap development. Zach has been working on this for a while, and it gives a number of advantages:
- Direct USB connection to the host computer, hence no significant communications delays
- Easy-to-use platform-independent software development environment
- Faster
- More memory
We shall do a release of the entire RepRap system (hardware, firmware, and software) shortly that will be a stable platform from which people can take the current PIC microcontrollers forward if they wish.
We will then do a subsequent release with identical host software, but with the Arduino electronics and firmware. This will form the basis of our next set of developments.
Labels: arduino, microcontroller, PIC
Comments:
<< Home
Congrats to Zach and everyone else who has developed on this platform and made it viable. This is an exciting development that opens up new possibilities for the project.
This is pretty exciting. If you guys are using Arduino, then I know your stepper controllers (and code?) will work great with a totally unrelated project I'm working on.
du: thats one of the very exciting things about basing reprap on arduino.
you can take our modular boards and do something completely not related with them. we have stepper boards, temperature sensors, PWM drivers, DC drivers, opto switches, and soon cool things like thermocouple sensors, and rotary encoders.
you can take our modular boards and do something completely not related with them. we have stepper boards, temperature sensors, PWM drivers, DC drivers, opto switches, and soon cool things like thermocouple sensors, and rotary encoders.
I think that all the disadvantage of the pic version comes from a wrong choosen model.
The PIC 16F648 has only 18 pin while the arduino board(atmega168) has 28 pin.
If we had choosen from the beginning a more advanced pic model like16F877 or better a 18F4550 all the disadvantage would had disappeared.
As for the advantages:
* Direct USB connection to the host computer, hence no significant communications delays
It is false (as I see). The usb communication of the arduino board is nothing more, than an onboard integrated usb-serial converter (from FTDI). It is NOT a true usb communication.
* Easy-to-use platform-independent software development environment
That is true.
* Faster
The development? Maybe.
The hardware? Wrong PIC has been choosen.
* More memory
Wrong pic has been choosen.
I think the correct solution would be to design equivalent microcontoller boards.
And not to limit to an randomly choosen microcontroller platform.
Nophead use a yet another microcontroller (from TI?), while Forrest higgs use the 18F4550 pic.
All the two need to design a board for they microcontrollers. Would be much nicer, to have a
reference design which does not imply a specific microcontroller. And the specific microcontroller
could be inserted with an adaptor/or anything else.
I dont think either, that the PIC development is much harder than the arduino(atmega).
IF you have the correct tools (like an icd2 programmer and incircuit debugger).
Btw does the arduino support step-by-step debugger?
Oh and 28 pin is not too much either. If we want tools identification, and other function in the future, the
design (28pin) proven to fail.
In an ideal world we could mix the microcontrollers. So the extruder could have a pic, the main board
a yet another microcontroller.
Oh, and we need to think about communication with PC AND with the other boards around
(like an "intelligent" tool, which could identify themselve). The I2C is not a good choice.
(see nophead blog about noise).
RS485 is much better.
Just thinking aloud....
Khiraly
The PIC 16F648 has only 18 pin while the arduino board(atmega168) has 28 pin.
If we had choosen from the beginning a more advanced pic model like16F877 or better a 18F4550 all the disadvantage would had disappeared.
As for the advantages:
* Direct USB connection to the host computer, hence no significant communications delays
It is false (as I see). The usb communication of the arduino board is nothing more, than an onboard integrated usb-serial converter (from FTDI). It is NOT a true usb communication.
* Easy-to-use platform-independent software development environment
That is true.
* Faster
The development? Maybe.
The hardware? Wrong PIC has been choosen.
* More memory
Wrong pic has been choosen.
I think the correct solution would be to design equivalent microcontoller boards.
And not to limit to an randomly choosen microcontroller platform.
Nophead use a yet another microcontroller (from TI?), while Forrest higgs use the 18F4550 pic.
All the two need to design a board for they microcontrollers. Would be much nicer, to have a
reference design which does not imply a specific microcontroller. And the specific microcontroller
could be inserted with an adaptor/or anything else.
I dont think either, that the PIC development is much harder than the arduino(atmega).
IF you have the correct tools (like an icd2 programmer and incircuit debugger).
Btw does the arduino support step-by-step debugger?
Oh and 28 pin is not too much either. If we want tools identification, and other function in the future, the
design (28pin) proven to fail.
In an ideal world we could mix the microcontrollers. So the extruder could have a pic, the main board
a yet another microcontroller.
Oh, and we need to think about communication with PC AND with the other boards around
(like an "intelligent" tool, which could identify themselve). The I2C is not a good choice.
(see nophead blog about noise).
RS485 is much better.
Just thinking aloud....
Khiraly
You always have a conflict between a generalised solution that can easily go in any direction, but which takes a lot of work to set up and - more importantly - maintain, and a specific one that may limit your options but that is quick to set up and run.
To a certain extent we had that option-limit problem with the PIC; deciding to move to a different platform was both administratively and technically difficult. But if we had started with no specific microcontroller and tried to develop a general approach, we'd still be trying to get it working now...
The Arduino gives a clear unambiguous path for all that we want to do next. To an engineer, good enough is perfect, and more than good enough is inefficient...
To a certain extent we had that option-limit problem with the PIC; deciding to move to a different platform was both administratively and technically difficult. But if we had started with no specific microcontroller and tried to develop a general approach, we'd still be trying to get it working now...
The Arduino gives a clear unambiguous path for all that we want to do next. To an engineer, good enough is perfect, and more than good enough is inefficient...
Get free information and help about Multiport Serial Adapters, 8051 development tools, watchdog timer, Embedded C Compilers,8051 Free Info and Code, Multi Function Timers, World Class 8051 Trainers, PC-based Oscilloscopes and KS0718 C ibrary. visit:http://www.electronicsrobotics.com
Post a Comment
<< Home
