add comments

Firmware/MotorControl/axis.cpp

@@ -1,5 +1,6 @@
 
 #include "axis.h"
+#include <stdlib.h>
 #include "legacy_commands.h"
 
 //TODO: goal of refactor is to kick this out completely

tools/odrive/core.py

@@ -44,6 +44,13 @@ class SimpleDeviceProperty(property):
         return struct.unpack(self._struct_format, buffer)[0]
 
     def fset(self, obj, value):
+        #Oskar: Pythonic duck typing style means that you should pretend that types are
+        # compatible, and catch errors. So instead do something like:
+        # value = self._type(value)
+        # you could of course wrap this in a try/except block, but when it fails it
+        # raises a TypeError, just like the one you made below, so I'd just let that fire
+        # by itself.
+
         if not isinstance(value, self._type):
             raise TypeError("expected value of type {}".format(self._type.__name__))
         buffer = struct.pack(self._struct_format, value)

tools/test_communication.py

@@ -47,6 +47,14 @@ def print_usage():
   print("\tQuit Python Script:\n\t\tq")
   print("---------------------------------------------------------------------")
 
+#Oskar: This cli prompt loop emulates the old test_communication, but I don't think that's a requirement
+# We should instead do whatever is the easiest for people to start playing with the ODrive,
+# and that would probably be to find a device as per current main(args), but then just drop
+# the user into an interactive ipython prompt (like 'ipython -i test_communication.py')
+# To do that you just put the variable 'odrive' in the global namespace, then finish the script
+# that will leave that odrive variable in scope for the interactive session; just give the user some instructions
+# that they can then do stuff like odrive.[tabcomplete]
+
 def command_prompt_loop(device, history):
   """
   Presents the command prompt indefinitely until something goes wrong