RDB
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, typically by using wires instead of shields. |
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. Wiring 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, increasing in number and diversity. It becomes increasingly hard to keep track of things.
-1- 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.
-2- Also there are shields for development boards such as ramps. Nicer solution, still no advanced features because the board does not provide such. One reccuring issue is that mostly this case hide or cover the development board itself making it less accessible 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 extra things like track impedance, stray capacitance and inductance, etc. In some sense probably as frequency goes up, such boards become less and less "DIY-able" with common methods. And perhaps for same reasons it should be better to use an commercial development board for this part of the circuitry, with cusom made extensions. But the way such extensions are made, directly influences the properties of the entire system.
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
- This means using wires as in "breadboard style" wiring, which means true freedom against form-factor. Additional benefits: easy detachment and all pins are fully user-customized.
2) physical separation @ logic level abstraction
- Probably 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
- Board structure and layouts should be defined by the functionality they provide.
- For example elementary functions that are required by reprap for basic functioning could 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 could 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.
- Functionality has some cris-cross implications. 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.
