Back-Seat Driver

Today the students will hopefully finish their C code for the input-capture datapath driver, while I pester them with constructive criticism as to how best they can approach this design problem.  I gave them one hint at the end of my last blog post, and have offered to give them more today if they get stuck or have problems.

Meanwhile, I can continue writing other modules, like the serial port setup and/or the command-line interpreter.

In other news, there was a screw-up in payroll processing so I didn't get paid last Friday as expected, but they have set me up for off-cycle processing, so I should get the 3 weeks of back pay I am owed (1st 3 weeks of July) on Wednesday.  So that's good.  Chris Cruikshank was also affected, but when I last spoke to payroll, they were having trouble finding his appointment paperwork; but they will continue working with Ms. Richardson to track it down.

Realized I need a new module linebuf.{c,h} to encapsulate my nonblocking line-buffered input capability, and another one command.{c,h} to encapsulate higher-level command-line parsing/dispatching.

Here are also some more functions that should be prototyped for the input-capture datapath.  These don't need to be implemented yet; we just need function prototypes for them.

• icdp_run() - Start or unpause the input-capture datapath.
• icdp_pause() - Pause the input-capture datapath.  (Time counter keeps running though.)

These are not mission-critical but could be handy to choke off the data flow while debugging.

I think most of my skeleton application code is done now.  We just need the actual input-capture datapath driver, and some real commands, and a real interrupt handler for pulse data.  However, in the meantime, I can test the JTAG and serial I/O and command-line processing.  Doing a test compile now...

Moving overall system state variable (which was in main.c) out to its own module, fedm_state.{c,h}, since it's referenced in a couple of different places.

OK, got everything to compile, and meanwhile David finished the icdp_pull_pulsedata() function, and is writing an output stub (unit test) for it.

My code (even without the icdp driver implementation) overflowed the 64K memory limit.  I tried doubling the memory to 128K, but there was not enough room on the device.  Tried 96K, still not enough room.  Tried 80K, still not enough.  Now trying 68K.  Keep fingers crossed...  OK, it fits now, but, that size leaves only about 1K for user data + heap... This is likely not enough to avoid stack overflows.  I might be able to bump it up a little, like maybe to 72K... Yeah, that leaves 5K free at least... But, if that doesn't work, then what I may have to do is look into partitioning the memory into a ROM for program text and a RAM for working memory, in hopes that this will fit more easily on the device, but I haven't done that with the Nios environment before.  Also, I need to play with different fitter options.  Anyway, do that tomorrow...