RDB
Generic pages: | Introduction | Naming convention | Main Interfaces | Feature Interfaces | Steppers Interfaces | RDB_calibrations | RDB_DIY_tips |
Specific pages: | RDB_G_001 |
Disclaimer: The RDB approach is perhaps better for the long run, at least in understanding and dealing with electronics at TTL levels. Also perhaps better suited to hacking. But beginners will probably have a bit more headaches than other solutions which are more integrated. Just a word of caution. For example the "generic" RDB should have adjustable voltage regulators which need to be set with voltmeter/multimeter, and wiring which may require the user to write in firmware his own customized pins definitions.
Contents
Background
Currently on reprap there is a plethora of electronics variations, and these keep on coming.
There are electronic types which integrate their own microprocessors. There is little advancement and i believe this are somewhat stuck at "rearranging same thing all over again". For example after a considerable number of years still there are no features like usb host, integrated ethernet, etc.
Also there are shields for development boards such as ramps. Nicer solution, still no advanced features because the board does not provide such. My main issue is that mostly this case hide or cover the development board itself and as a result the shields have to duplicate the hidden features like leds, debug, icsp header, etc. Such duplication should be avoided.
Motivation
In time reprap will probably move to higher clock microprocessors. Higher frequencies boards usually means accounting for track impedance, stray capacitance and inductance, etc. In some sense probably as frequency goes up, such boards become less and less "DIY-able" in house environment. And perhaps it should be better to use an commercial development board for this part of the circuitry.
And once the function of the reprap peripherals are well understood, making some additions to use it for reprap is rather easy.
Development Directives
There are certain characteristics that need to be kept in order to provide flexibility and hackability:
1) keep the development board fully accessible
There are many ways to embed a development board while still keeping it fully accessible. Could use physical pin wiring or sometimes could place the development board like in a socket placement.
2) separation @ TTL level abstraction
The only way to interface with a generic, unknown board is at the TTL level abstraction. Hence, all the RDB development needs to keep a good track of TTL levels and functions value in appropriate tables.
3) flexibility
-use adjustable voltage regulator to provide development board supply voltage in the range it requires. -use adjustable voltage regulator for TTL: to be able to work with either 5v or 3.3v TTL voltage.
4) modularity & functionality
All the elementary functions that are required by reprap for basic functioning should be on one single board: switching capabilities (extruder, bed, fans, etc), voltage regulators for board supply and ttl level, thermistor interface, min-max interface.
All other supplemental functions which are not vital for basic functioning are to be addressed in terms of modularity and functionality, as much as possible on separate boards, or if on the same board, to be kept in localized distinct groups with minimal or no entanglement to each other.
For example there is no point in making a LCD board with no means for input (no keypad), since the LCD and the eventual key input method will have to work together (sort of speaking).
On the other hand in a generic interface, the SD-card should be singled out, mostly because the TTL level is not considered known (5v or 3.3v). Also at some point at least some users will use usb function with a usb stick instead of a sd card.
RDB distinctions and flavors
RDB Generic: to be interfaced with generic unknown development board, for reprap purpose.
RDB Targetted or Specific: made for a specific board, or a range of development boards.
RDB Accessory: accessory functions such as lcd+keypad, sd card, etc.
RDB Stepper Drivers: the usual standard stepper driver(s), with step/dir/en interface (nothing different).
</br>
