RDB

RDB Build Documentation

Generic pages: | Introduction | Naming convention | Complete inferfaces | TS Interfaces | Steppers Interfaces | Feature Interfaces | RDB_calibrations | RDB_DIY_tips |

Specific pages: | TS-001-G-DIY | STP-001-G-DIY |

RDB comes from Reprapped Development Board. This is meant to integrate a generic, or a targetted development board into reprap. So these are accessory electronics for "a" development board, and not the board itself. The distinct feature of RDB is that it aims to keep the development board fully accessible. Even by means of old fashion physical wires, or otherwise.

Disclaimer: Board(s) being separated at logic level abstraction, means it takes in GPIO as wires from the development board and provides whatever function(s) required. This kind of setup offers extremely high flexibility and compatibility. Term "function" is used instead words like input/output, to avoid confusion about what is output for one board and input to the next.

The RDB approach is perhaps better for the long run, at least in understanding and dealing with electronics at logic 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.

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.

Once functions of what reprap needs as peripherals are well understood, making some additions, hacking, further developing 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 wires as "breadboard style" wiring or perhaps could place the development board like in a socket placement (mbed boards or modules with pins on bottom layer).

2) separation @ logic level abstraction

• The only way to interface with a generic, unknown board is at the logic level abstraction. Hence, all the RDB development needs to keep a good track of logic levels and functions value in appropriate tables.

3) flexibility

• Use of features like adjustable voltage regulators, alternative layouts and other techniques to increase adaptability to more than one situation or requirement.

4) functionality & modularity

• 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 logic level, thermistor interface, endstops headers.
• 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 little or 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), to provide stand alone capability. Only lcd cant provide anything by itself: the pc already has a display. On the other hand in a generic interface, the SD-card is fair game to be singled out, mostly because the logic level is not considered known (5v or 3.3v), but also at some point some users may use usb host / otg function, lets say with a usb stick instead of a sd card.