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.

Atmel

A student in Micro asked me if I'd considered Atmel's AVR when choosing a microprocessor for the book. I knew they didn't offer a C compiler and were limited to 8 bits, but little else. I did a bit of research and was impresssed:

• There's one AVR core; the various families (tinyAVR, megaAVR, etc.) add features but share the same core. See the diagram to the right. Nice!
• The AVR instruction set contains two 16-bit pointer registers for indirect addressing, compares and signed/unsigned branches, 16-bit addressing for data, a multiplier, and a stack. It's nice.
• As shown in the overview, there are lots of DIP packages, great for breadboarding.
• There are third-party C compilers, but no well-supported free ones. That's a big minus.

I realized that I need to use tags (i.e. labels to Blogger) to keep track of my posts, so I've started using them.

Getting organized for the new year

I'm back at work -- it's been two weeks. Wow.

Some random thoughts and links I haven't had time to really categorize yet: the MSU budget (where is research spending shown?). The ARM Cortex-M3 Technical Reference Manual gives general ARM info, but lacks and instruction set encoding. That's in the ARMv7-M Architecture Reference Manual, which ARM doesn't publicly post (annoying). Of course, it's findable via Google. I wonder if there's a good textbook for the ARM Cortex? I haven't found one yet.

PC fixes:

• Windows Defender kept complaining and couldn't auto-update. The manual install method worked fine (follow the link from here).
• To define a custom paper size in Windows, use File |  Server properties from the Windows Explorer when viewing Printers in the Control Panel (I'd never seen that one before!). However, the laser printer seems stuck on a max page size of 11x11 in. Grrr.
  
• After playing with it, I've decided that Photoshop Elements is a disappointment. I keep wanting to use tools from the full version, which I have on the laptop. Sigh.
• Perhaps this is why the laptop takes forever to resume after sleeping. We'll see.
  

To do:

1. A class schedule for Micro. I need to replace section numbers with page numbers for the reading assignments.
2. Better plans for what I'd like to accomplish this semester.
   

ARMed

I'm at home this morning. I tried using xUnit on my PC here and also ran into problems; it looks like xUnit is generating an "unable to load assembly" error. Sigh. I'll have to track that down. It might be easier just to create a console app and run that instead, though. I really miss not having a working test framework.

I did lots of clean-up yesterday, going through almost all the unread items in my inbox. Wow. That was really nice. I reviewed several SECON papers and was disappointed by the low quality.

Before I wrote Microcontrollers: From Assembly Language to C Using the PIC24 Family, I considered adopting an ARM instead of the PIC24. The main problem was the lack of prototype-friendly packing (all the parts were surface mount), but otherwise I really liked the parts. I ran across a nice ARM part again that I'm excited about, a family from ST, the STM32F series:

• It's based on an ARM Cortex-M3. I'd prefer an ARM Cortex-R4, since that has an optional FPU. While some companies have licensed it, I can't find any products from them yet.
• They have a small package (36 pins, QFN, 6mm x 6mm = 236 mils x 236 mils). Note that a standard DIP is 300 mils wide.
• Their best part in that package, the STM32F103T8, features a 72 MHz clock, 20 KB RAM, 64 KB flash, 2 UARTs, 4 timers, 10 channels sampled by two 12-bit 1 MSPS ADCs, 26 GPIOs, and one each of SPI, I2C, USB, CAN, PWM timer. The datasheet gives part-specific features, while the reference manual gives info common to all the STM32 parts. The programming manual discusses the core and its instruction set.
• They have what looks like an excellent standard peripheral library, which looks equivalent to the library I co-wrote for the PIC. It's well-documented and looks fairly useful. It comes with example code for every peripheral and seems to include clock config and everything!
• Their programmer/debugger, the ST-LINK, is $24. Wow. I like that. The user manual gives more details.
  
• They have a bootloader with dlls to link to plus a GUI; I haven't tried it, though.
• The errata list looks reasonable, a contrast to PIC24 errata.

The biggest cons:

• No DIP package. Doing a quick search, there's an adapter board out there, thought it's fatter than I'd like (600 mils). Here's another option. It would mean having someone build these boards; I bet SparkFun would do it for us.
• It's soooo painful to get another micro up and running. It's even more painful to turn this into a class. Writing another book adds another level of pain.
• There's no reason to do this. The PIC24 is fine for what I'm doing, even in the foreseeable future. I don't see any new things an ARM would enable me to do in terms of research.

Some getting started notes:

• Bootloading:
• To enter the system bootloader,  set BOOT[1:0] = 01. However, the STM32F103T8 has only a BOOT0 pin in the 48 and 36 pins packages.  It looks like BOOT1 is shared with PB2 per the pinout in the datasheet (page 27). I could do this via the FTDI cable with a weak pull-up on PB2 and RTS connected to BOOT0 (see e.g. page 14 of AN2586).
  
• Per AN2606 page 6, the built-in bootloader runs off the internal oscillator at 24 MHz. It uses PA10 and RX and PA9 as TX and operates at 8 data bits, even parity, 1 stop bit. Per page 8, it uses autobaud and works from 1200 to 115200 baud. It's possible that higher rates would work, though.
  
• AN2586 is a hardware getting started guide.
• The NRST (low-true reset) has a built-in pullup, per page 10; all that's needed is a pushbutton!
• Per page 52 of the datasheet, the internal clock is accurate to +/-2% at 0-70 degrees C.
  
• There are 5 pins for program/debug; however, user software can take control of them as code executes, disabling debug abilities. However, the standard connector is a 20-pin beast, only 5 pins of which must be used. There's a 2-pin mode, which would be nice. I'm still not sure how these work.
• From the clock tree (page 78 of the reference manual), it looks like picking the internal 8 MHz source / 2, then using an x18 on the PLL gives 72 MHz for full-speed operation.
• An odd thing: since the bootloader is permanently burned in the part, I don't need a programmer; I'd only want that for debugging support. That's nice.
  

I found a neat trick: to create outlines of text for laser cutting, Word plus Visio works: create WordArt in Word (Insert tab, click WordArt). After creating it, click on the shape, select the WordArt tab, then choose Shape Outline, Width, Weight of 0, color red, no fill. I can't figure out how to set the proportions correctly, though.

Now back to work. Forms to fill, e-mail to answer...