Posts Tagged ‘curses’

h1

Continuing work on “nano-curses”

2010/06/16

As part of the progression on my main contract (which has another rev of PCB’s and parts on their way), I’m diving back into my “nano-curses” project.  I’ve got the basic operations on stdscr working, including a semi-smart refresh() algorithm (it moves the cursor after any gap in changed characters, rather than any gap bigger than the size of the move-cursor command itself).  Now I’m figuring out how to do subwindows and scrolling, as those are the features that made me look to using curses in the first place.  The biggest problem is untangling the actual intended operation of the various functions and arguments.  For instance, when creating a subwindow, the documentation says nothing about what happens if the x,y,width,height places any of the window outside the parent window.  I have to dive into ncurses code in order to determine that such a situation is an error condition, and should fail to allocate the subwindow at all.  I  don’t yet have the faintest idea what’s supposed to happen in regards to refresh()ing the stdscr when a subwindow has been scrolled.  A naive form would just internally scroll the screen buffer and leave it to the refresh() algorithm to redraw it all.  However, that completely ignores the ability of the “physical” terminal to do subwindow scrolling.  I’m still tracking down how ncurses keeps track of child windows…

Advertisements
h1

Writing “nano-curses” for microcontrollers

2010/05/24

My main contract these days is developing into a software stack that needs to both send a lot of debugging and status data, and receive commands over the serial debug port (which in the next generation will be Bluetooth…).  The problem is, I need to be able to deal with this in the main codebase in a relatively sane manner.  That means using xterm command sequences, but hiding them behind some kind of API. The obvious candidate would be curses, of course.

So, I’m developing a microcontroller version of curses, that’s intended to be as lightweight as possible given the complexity of the problem.  The first major cost is the terminal buffer, which has to be at least a byte for every character on the screen.  I might experiment later with a non-buffered curses, especially as this is not intended to run over “slow” connections in the first place (at least for my application).  The real challenge is going to be figuring out things like subwindow scrolling rules, and all the quirks like keeping track of the cursor when a tab is inserted, etc.

I plan on releasing this code as open-source once it’s reasonably usable, and I have somewhere on my as-yet-nonexistant website to put it…