RDB

From RepRapWiki
Jump to: navigation, search
RDB Build Documentation


Farm-Fresh lightbulb.png RDB comes from Reprapped Development Board. This is meant to integrate a generic development board for reprap purposes. So these are support electronics for "a" generic development board, and not the board itself.

The distinct feature of RDB is that it uses a commercial development board, and connects to it by use of wires. Sort of speaking RDB is a "breadboard" approach, meant to be universal, easy to debug, and to have full features.

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.

  • Integration of everything: 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. For a fully integrated solution, the complexity grows fast and in the end perhaps many features got cut off for the simplicity.
  • Also there are shields for development boards such as ramps. Nicer solution overall, less complexity but currently still no advanced features. Also one reccuring issue is that mostly this case hide or cover the development board itself making it less accessible and sometimes as a result the shields have to duplicate the hidden features like leds, debug, icsp header, etc.


Vision

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. Perhaps it should be better to use an commercial development board for this part of the circuitry, with cusom made extensions. If extensions are made in a manner that are completelly independent from the board, then development boards can be independently changed or upgraded. Or the extensions can be reused in other projects. This is just one aspect that shows that the properties of the entire setup depends on the way such extensions are made physically.


RDB particularities

1) use of old school wiring instead of form factor shields

  • This means using wires as in "breadboard style" wiring of development board input/output pins, which means freedom against form-factor. Additional benefits: easy detachment and all pins definitions can be fully user-customized. Without being constrained by an inherited shield form factor, the additional boards have no space restrictions for advanced features, and still benefit from a higher degree of simplicity and easier routing.

2) physical separation at logic level abstraction

  • Taking inputs at logic level abstraction provides a high degree of universality. Boards just need to keep a good track of logic levels and functions just need a fairly simple explanation. Ability to change the logic levels further contributes to universality.


Note on structure and modularity

  • Board structure and layouts should be defined by the functionality they provide, since only that remains characteristic. Elementary functions that are required by reprap for basic functioning could be separated or together 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 as much as possible on separate boards, in terms of modularity and functionality.
  • 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 needs to work together with some form of input, in order 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 necesarily known: 5v or 3.3v.