Update

Last week disappeared, mainly in getting p14p up and running on the PIC. The code is now in reasonable shape; I'm doing some clean-up and documentation work before plunging into further development.

Interesting things: a HUD display on an iPhone to control a quad-rotor craft; this augmented reality idea is a great way to debug robots. I stumbled across a free book on robotics using Python running on a PC to control a robot. For embedded programming, Stack Overflow makes for interesting reading.

Things I'm working on:

• My overflowing inbox, still containing a fair amount of mail to sort through and reply to.
• I now have funding to build the Summer Bridge robot, so it's time to order parts!
• The continuum review paper was accepted pending a few revisions, so I need to get started on those.
• The limiting case paper is still languishing and needs attention. Sigh.
• I need to write the Micro test!
• Report lights to be replaced, arrange some tutoring, other misc stuff.
• Write recommendations.

I'd like to also think about how to structure a Python-based PIC24 hardware library. Thoughts:

• I'm not certain what the balance between writing in C and wrapping in Python vs. mainly writing in Python is.
• One approach: define readBits and writeBits functions in C, then call that from Python for all hardware access. Pros: less wrapping. Cons: slower, might take too much RAM space.
• Another approach: balance between Python and C, building Python classes on top of C functions. In essence, it's a rewrite of the existing PIC24 library plus lots of wrapping.
• The other extreme: wrap the existing library in Python. That's a lot of wrap with little Python structure to help.
• All the peripherals on all chip variants keep the same address in memory; duplicated peripherals have the same basic layout repeated at an offset. I'd like to take advantage of this by writing a function which can operate on any port instead of duplicating a function multiple times for each port.
• Port configuration needs the most redesign, since it's implemented as hundreds of C functions and macros. Thoughts:
• Create a digitalPins class. The constructor takes parameters of port, firstBit, numBits, isInput, isOpenDrain, isPullup and sets bits accordingly, issuing an error if the requested resources don't exist (on a nonexistant port or bit, a port with no pullup ability).
• This requires writes to PCFG, ODBC, TRIS, CNxPUE. What't the best way to keep a table of PCFG, CNxPUE mappings?
• Does it make sense to also provide a read back of these bits? I've never needed to do that in all my coding. In particular, reading back PCFG, CNxPUE bits through their mapping to port/pin combos would be complex. Probably not.
• Should this function also make sure no peripheral output pin is mapped to the pin? That's definitely additional complexity. I'm not sure how much.
• Override read and write: if the pins are all outputs, send writes to LAT, otherwise to PORT. Provide read access to PORT, LAT and write access to either PORT or LAT.
• Question: should each read/write check to make sure the port is still correctly configured? That means reading back PCFG bits, which is painful. Probably not.