Michael Baisch

As I mentioned in #59, I wrote a [preprocessor](https://github.com/michaelbaisch/uDino-Preprocessor), which also combines all Arduino source files.

I wrote a [preprocessor](https://github.com/michaelbaisch/uDino-Preprocessor), because I needed that feature for an App I'm working on. It could be used to create prototypes before using the Makefile. It's written in ruby...

The fundamental Problem seems to be that there is no eeprom map for sailfish v4.7 in GPX. I tried to add one for v4.7 and I ran into a few...

1. b. I looked into the unsigned part a bit more. the values in `response` in `batcheeprom` are already signed. So onto `py_read_eeprom`, I added some debugging prints: `gpxmodule.c:732` ```...

2. Another thought of mine was, if we could access the sailfish version in js, we could simply use the appropriate scale factor for that version.

1. Yeah makes sense that those are pointers… If I log in `batcheeprom()` directly what `gpx.read_eeprom(eepromid)` returns like: ``` self._logger.debug("gpx.read_eeprom(eepromid) = %s" % gpx.read_eeprom(eepromid)) ``` I'm getting values like `4294964755`....

2. So, you mean that calling eg `gpx.read_eeprom(AXIS_STEPS_PER_MM_X)` does not return the actual eeprom data but a already scaled float?

Now it would be nice to be able to simply select it in OctoPrint - https://github.com/markwal/plugins.octoprint.org/pull/1

I've been looking into documenting my responses properly and came across this problem. In general, how should one document the same HTTP status code with different response schemas and descriptions?...

I guess for this to work, there should be serializers for all the DRF error responses, pretty straightforward for most of them (only `detail` property) but the default ValidationError response...