Tuesday, February 2, 2010


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.

No comments:

Post a Comment