Orangutan: the missing manual?

Support A-Star and Orangutan
1

I’m loving the Orangutan controller, but there are many questions not answered in the “quick-start sheet” – which seems to be the only documentation. (It’s odd – seems like they spent months designing the board, and half an hour documenting it.)

For example:

  1. What voltage comes out of the motor ports? Regulated 5V or unregulated (direct battery) voltage?

  2. Similarly, will the buzzer be louder on a 10V supply than on a 5V one?

  3. Eight of the 12 I/O ports have selectable power sources, which you select with a jumper. But if I don’t install any jumper at all, which mode are they in?

  4. Is the on-board voltage regulator linear or switching? More to the point, if I connect (say) a 9V input, how much current is being wasted by the regulator, and do I need to worry about heat dissipation?

  5. What size screws do I use with those mounting holes?

  6. What sort of overcurrent protection is included on the board? If my motors connections short out for example, what’s going to burst into flames first: the board, the batteries, the motors, or nothing? (Trying to determine whether I need to add an external polyswitch reset between the batteries and the board.)

That’s all I have for now… any answers would be great, and even better would be a pointer to the missing manual which surely somebody has already written! :slight_smile:

Thanks,
- Joe

2

Motor ports are battery voltage minus whatever losses the H-bridge chip has (not a lot of loss).

Pretty sure the buzzer comes straight off the I/O port. The processor is fed regulated +5V, so it shouldn’t depend on battery voltage.

If there’s no jumper installed, there’s no power coming out that bank of ports. Essentially whatever goes in the center hole determines what goes out that bank of jumpers. So if it’s jumpered one way, you get +5V regulated. If it’s jumpered the other you get Vbatt. If it’s not jumpered you get nothing. BUT! As I found out in another thread, if you want to feed some other power source to that center pin, that bank of I/O headers gets whatever you feed it. So you could get a 250mA 7805 regulator and that bank of four headers would have 250mA of regulated +5V available (the onboard regulator only does 100mA). Or you could use a programmable voltage source and those four pins would supply a user-settable voltage. (The Atmel STK500 uses a setup like this to supply power to the target device, so you can change your Vcc on the fly.)

4 - No clue.

5 - The ones that fit. Sorry for the lame answer. I think I used #4-40 screws the last time I bolted mine down. But I came to that conclusion by standing in front of my screw cabinet and trying them out. I used the biggest ones that fit.

6 - Also no clue, though the H-bridge does have thermal shutdown on it. I’ve tried very very hard not to push my luck here, though.

Sorry, no pointers to an owner’s manual. Working on an introductory programming guide, though.

Tom

3

Hi, Joe.

We’re working on improving our documentation. By the way, most of your questions are answered in the schematic:

1. The motor driver is the LB1836M, which is shown under the microcontroller. Pins 4 and 11, VS1 and VS2, are the supplies for the H-bridge, and they are tied to VBAT, which comes in at the upper left of the page as either the direct input voltage (on TP1) or with a diode drop if you use the two adjacent pins that are populated on the board. What voltage you actually get out depends on the load, but the motor driver datasheet gives some values.

2. The buzzer is connected to PB0, which means that it is driven at the voltage of the microcontroller, which is 5 V.

3. The voltage select jumpers are shown on the lower-right of the schematic. The middle pins (#2) are all tied together and if you don’t put in the connection to VBAT (pin 1) or Vcc (pin 3), they won’t be connected to anything. As Tom noted, you can even connect them to some other node of your own.

4. The regulator is the LP2950, in the upper part of the page. Even if you don’t look it up, you can tell it’s not a switcher since those are more complicated. You would at the very least see one or more inductors, and the IC would have more terminals. By the way, it’s not the current that you’re wasting: it’s the voltage drop times whatever current you’re using that is your wasted power (i.e. the current out the ground pin is negligible).

6. There is no over-current protection. For the motors, the LB1836M has a thermal shutoff that will kick in if necessary (although we did replace one for Tom, so it is possible to blow it out!). If you have a resettable fuse, it wouldn’t hurt to use it, but I don’t think you really need one.

The mounting holes are about 0.086"; the intended screw size is 2-56.

- Jan

4

DOH! Thanks for the screw size info. It’s been a while since I’ve looked at the screws I used. Jan’s right: #2-56. #4-40 won’t fit through the holes.

And yeah, I did manage to blow the LB1836M on my Orangutan. (Thanks again for fixing that, Jan!) Which is why I asked about running a heater on my Orangutan before I plugged one in. Paranoia’s a good thing. Sometimes it is, anyway…

Tom

5

Well yes, in the same way that questions about the open-source software I write can be answered by studying the source code. :slight_smile:

Thanks for spelling it out for me, though; this is very helpful.

Now that I understand more about how the Orangutan works, I have a more application-specific question. The bot I’m currently working on runs on 8 NiMH cells. These measure about 10.3V when fully charged. The quick-start says that I need to provide 5-10V input. How forgiving is that 10V limit? I actually did go look up a LP2950 datasheet, and it claims that the maximum input supply voltage is 30V. So why the 10V limit, and would you expect me to be OK with 10.3V?

If you wonder why I don’t just regulate this down myself, or use a smaller battery pack, it’s because I need the full 10V or so for the motors.)

Thanks,
- Joe

6

I don’t think that’s quite fair, for two reasons:

  1. Your source code is the implementation, not (necessarily) the documentation, so I think the analogy would have been more appropriate if I had suggested you figure out the answers to your questions by looking at the traces and components on your PCB.

  2. Because some form of source code is necessary for the final product to exist, there is an implication that releasing it, and therefore the analogous schematic, requires no work. If you want to do a hardware/software analogy, I think the schematic corresponds better to a flowchart.

The question of documentation is important and interesting to me, but I’m not sure how best to approach it. From what I’ve seen, there are two general groups of Orangutan users: those who have experience with AVR microcontrollers and electronics, and those who don’t. The first group has generally been quite happy since they see a familiar AVR with a few simple devices attached to it. The second group is migrating from something like a Basic Stamp and need to learn the AVR architecture, a new IDE, and possibly a new language. There are already thousands of pages of documentation about those topics, and it’s not clear to me how much we could condense that to make it more presentable to a newcomer. It also changes the task from documenting the Orangutan to teaching embedded design with the AVRs, which we would like to do but cannot afford right now.

Can you let me know what kinds of things you would like to see in the documentation? For instance, it wouldn’t have occurred to me that someone would wonder about a switching regulator yet not see the answer in the schematic. Have you seen the X2 documentation we have so far? What would you like to see added to that?

The 10 V limit comes from the motor driver. In my experience, a charged 8-cell NiMH pack will be over 11 V, and you will see the motor driver start cutting out, so 7 cells is usually the limit.

Regulating voltage to motors is generally not a good idea. It will probably cost a lot get a regulator that can handle the current and variation in the load; throwing some big diodes is an option if you only need to drop less than a few volts. Otherwise, using a motor driver that can handle the target voltage is the best option. I understand that it kind of defeats the point of using the Orangutan, but do you have space for something like a SN754410 motor driver?

- Jan

7

I’m also curious what the response is on the documentation question. (And I’m interested to hear what you guys have planned since I’d rather not double up efforts.)

I’d say there are three groups of users for your products. One is folks with AVR experience, as you said. Another is folks with some background in embedded processors. I was aiming somewhere between these two: explaining some of the quirks of AVRs, but mostly focusing on what could be done with the hardware in-hand.

There’s a third group: folks with no exposure to programming at all who are jumping in in the middle of a robotics project.

Odd though that last group might sound, that’s what a lot of academic programs are: people learning programming for the first time, using an embedded processor. This is a tough group to write for.

One book I’ve got on AVR programming in C is the one offered by smileymicros.com that focuses on using the AVR Butterfly with WinAVR. The author (who’s a very active poster on AVRFreaks) makes no bones about what group he’s writing for: people with some experience programming in C. Very early on he basically says if you don’t understand a coding concept, pick up Kernighan & Ritchie and figure it out.

Rather than re-invent that particular wheel, that might be a good route to go: K&R for C, Joe’s book for embedded design with AVRs, and Pololu docs for the Orangutans.

But I’d be curious to hear what audience people would like documentation to be aimed at.

Tom

8

Off Topic: “C Programming for Microcontrollers” (from smileymicros.com) was a great help to me (thanks for the recommendation Tom!). I had spent about a year working with AVRs on and off, cobbling together my knowledge of C and PIC C with example code and what information I could get out of the humongous AVR datasheets. I borrowed a Butterfly, but I ended up just reading the book through in about a week, without going through the activities. It doesn’t tell you how to do everything you’ll want to do, but it was an excellent starting framework, and now the data sheets seem a lot closer to English to me.

On Topic: Personally I like the Pololu documentation style. The guides are short enough to read in a sitting and get the important basic information from. Then, if I need to know something more, I can usually get it just from looking at the schematic, or from looking up part numbers listed on the schematic!

For whatever reason, most places won’t publish schematics of their electronics. Either they’re afraid of encouraging hacking of their devices, or so you won’t just build one yourself instead of buying from them, or whatever. Some will go so far as to file the text off the tops of chips so you can only guess what they are! When I wanted to know last week what the maximum current I could draw from the Baby-O’s voltage regulator was, I could just go to the schematic, find the part number, and look it up. Written documentation gets big and bloated, and still will never contain all the information I want to know.

The Pololu documentation isn’t absolutely complete, but no documentation ever is? When something is missing (i.e. the part number of the ceramic resonator on the Baby-O) you can usually find out much faster from the forum or sending an e-mail than you could get a response out of most large electronics companies.

-Adam

9

Well, just listen to your newcomers. I have several examples above of things that really ought to be included in the documentation. A one-page quick-start is nice, but splurge on a couple more pages and I think you’ll have no trouble filling them up.

I don’t expect you to teach me how to program AVRs, but I do expect you to tell me everything I need to know about the board, from what voltage comes out of the various ports to what hardware I must use to mount it.

I really don’t think you should expect someone to study the schematic for answers to their questions, any more than I would expect you to read my source code and then go look up documentation on the libraries I’m using. For a software guy, reading a schematic is just as hard (if not harder) as reading source code must be for an EE.

So, this is a good start to an answer to your question. Any time you find yourself saying, “oh, the user will need to know this, which they can easily see from the schematic…”, stop yourself and write a sentence or two about it in the docs.

Of course, it’s great that you provide the schematic for people who can make some use of it. I wouldn’t suggest you stop doing that. Just supplement it with text documentation.

No, I confess that I haven’t looked at the X2 much, and I can understand that your attention is probably focussed on that now. I’m glad to hear that you’re putting effort into documenting it. I’m really digging the original Oragutan at the moment, though. :slight_smile:

OK, thanks, that’s very helpful. So if I’m not using the motor driver, I could provide up to 30V? (This is the sort of thing that should go into the documentation section discussing supply power!)

I’m now picturing a setup where I use the Orangutan as just the brains of my robot, and use your Micro Dual Serial Motor Controller to drive the motors. Then I could use the full 8-cell pack, I believe, and get the maximum speed from the motors.

Right; I never planned to do that. I was just explaining why I wanted to provide more than 10V to the Orangutan board: this is how much voltage I need for my motors.

Best,
— Joe
[/i]

10

I kinda have to second Jan’s and Adam’s take on the schematics: I’ve referred to the schematics for all three Orangutans over and over and over. For a lot of the stuff in the library, that really was the best way to find out what I needed to know.

And I wholeheartedly second Adam’s appreciation that you guys make the schematics available! I’d have been lost without them! Add to that that in another thread on debugging the Baby-O with an AVR Dragon, Jan also posted the board layout as well.

Unfortunately I don’t think you can get away from reading a schematic. Not for something that is inherently electronic in nature. Take the case of the LCD on the Orangutan. It’s doing double-duty with the three pushbutton switches. If you’re not aware of that, it’s easy to write LCD software that makes it impossible to use the pushbuttons. (Trust me, I know. DOH!)

Another source of information is the datasheet for each device on the board. I know that reading them the first time is a lot like looking at the back of a tapestry and trying to figure out what the front looks like, but that really is where the buck stops. Atmel’s datasheets tend to be novel-length behemoths, but they really do contain the bulk of what you need to know about how the things work. For the same reason I keep a copy of the H-bridge datasheet around, too.

One more point on the whole schematic / datasheet thing and I’ll drop it: It’s well worth reading the Atmel datasheet for the ATmega168. Page two has all the function overlays for all the I/O pins, which are further elaborated on in section 12.3. Fair warning, Atmel overlays a LOT. For example, PD4 is a general-purpose digital I/O line. But it also serves as the USART’s synchronous clock output, it’s the input source for timer/counter 0, and if you enable the right bits it’ll generate pin change interrupt 20 on a state change of the pin. Combine that with the schematic so you know where that pin actually comes out to a header, and you’ve got a whole bunch of things you can do with it. It’s impossible to know what everyone wants to do with their Orangutan. The possibilities really are incredibly broad.

I’m not arguing in favor of less documentation, mind you. But I also think it’d be a pretty rough job to get everything in there. Not without duplicating the ATmega168 datasheet, anyway. The danger lies in documenting enough that people don’t feel inclined to look farther, but not enough that all the bases aren’t covered.

Tom

P.S. To answer your question about using the Micro Dual Serial Motor Controller, I’d be tempted not to over-drive the Orangutan’s H-bridge, even without motors plugged in. I’ve killed one, though I still haven’t quite sorted out how. One easy approach, since the Baby-O won’t be driving any motors, would be to stick something like a 7808 between your batteries and your Orangutan. It’d get 8.00V which it would then regulate down to 5.00V, and your motors would get the full wallop of whatever your battery pack can put out. At that point there’s practically no chance of killing anything on the Orangutan because of overvoltage.

11

Ummm… All of my classmates at my college have taken two courses on C++. By the end of September I will have no doubt that they would be able to program the Avrs except for the differences in programing a computer versus programing a micro controller. In reality you should learn how this works because otherwise you might break something. What type of examples would you include? You’d actually have to rewrite the code every single time because each compiler is different.

12

Adam, you’ve put your finger on a couple of things. I’ll try to answer a couple of them:

It’s the differences between programming a computer and programming a microcontroller that make up the bulk of the problem. Not just the differences between a CPU and an MPU, but the differences in what you want to do with them. The AVR coding I’ve done so far is a lot less like the traditional exercises I got in my CS classes (data structures, data sorting, etc.) and closer to writing a device driver for a funky piece of hardware.

But as for them being able to program it? Shoot, I’d start now. My guess is they could’ve been playing around with the AVRs in parallel with their classes, and the knowledge transfer would’ve been great.

As for code re-write, that’s probably not 100% necessary. There are only a handful of compilers/assemblers that’ll build AVR code. Almost all of them are commercial. The one big huge exception is also the most platform-independent: gcc. I know this leaves out ImageCraft users, but if you cast all the examples in terms of AVR Studio / WinAVR (the Windows port of avr-gcc), you’ve covered 90% of the ground. And since this is the IDE/compiler used for the bulk of the application notes from Atmel, it’s a good choice to use in a manual as well.

What examples to include? Now that’s tough. It really is, because you don’t know what someone’s going to want to plug into one of these things. Blinking LEDs is good, and lends itself well to the Orangutan because they all have onboard LEDs. Spinning motors is another good choice because they all include a dual H-bridge. (Ok, so it’s an option on the X2.)

Past that? The cynical side of me says it all boils down to bit-fiddling, so the more examples that cover bit-fiddling, the better. (I swear, I see |= (1 << ?) and &= ~(1 << ?) in my sleep now.) But it helps to have more examples.

For the most part what’s left leans a lot less on programming and a lot more on how you view the world around you and tackle the tasks at hand. Good case in point: Making a motor spin at a particular speed. Simple enough. To tie this back to the whole device driver analogy, you’d expect there to be a motor(rpm) command. But on a micro there’s not. This one example would touch on speed control, pulse width modulation (and why you’d want to do that rather than simply varying the supply voltage or current for the motor), the concept of encoders, how to take the blinking LED example and turn it around to tack a counter onto an input pin to count pulses (the encoder), how to take the counter and a free-running system counter and turn it into a frequency, and how to go from that frequency to an RPM value for the motor. THEN the example would have to launch off into some sort of control loop theory so that the RPM reading from the motor could be used as feedback to the routine that’s generating the pulse width modulation for the motor. It stops being simple in a hurry.

One could take the easy way out and say this is all part of any good class on control loop theory, with some sensing thrown in for good measure. But at that point you’re left with a manual that essentially does what Joe was talking about: something that requires the user to go look up the textbooks for each of these fields.

Which is all my long-winded way of saying this isn’t easy, by any stretch of the imagination. Even Joe Pardue’s book stopped at reading the motor’s RPMs, and didn’t dive into control theory. So far his book is one of the better ones I’ve seen, and keep in mind it’s a book on programming microcontrollers, not a manual for the AVR Butterfly.

Tom

13

Yes but you’d have to know how to get the motor turn slower in the first place which is an understanding of electronics. Otherwise you wouldn’t realize that it’s as trivial as using the code to turn the LED on and off. Unfortunately, the way the motor driver on the Baby Orangutan works you can only have full forward or reverse.
Here is some code to actually turn a motor over on Motor 1 and Motor 2 on the Baby Orangutan: It’s incomplete because it only makes it go in one direction:

#include <avr/io.h>

 void main(void)
  { 
	DDRB  |=(1<<1);
	PORTB |=(1<<1);

	while(1)
    {
    
    }}

I can think of three different ways that you can actually accomplish that using Winavr. Four if the LED is attached to the right pin.:slight_smile: Unfortunately, I gave up on the easy way and used interrupts. I would give you my code.

14

I’m not sure what you mean about the Baby-O only being able to drive a motor full forward or full reverse. It’ll do PWM speed control really nicely. There’s been a lot of discussion about this, and Jim Remington has posted several sets of code. If I remember right two use onboard timers in PWM mode to directly drive the motor pins. A third uses interrupts to do a software PWM, with the advantage of having symmetric behavior forwards and reverse.

And yeah, there are lots of ways to blink the LED. Too many to count. But they all boil down to setting and clearing a bit. That’s why it’s the microcontroller version of the “Hello, World!” program. Everything else goes back to that.

The LED on the Orangutan and Baby-O is on PD1, so it doubles as a traffic light for the UART. Good choice of placement for the thing.

Tom

15

Reading the truth table for the data sheet pretty much says that. Then again the truth table makes little sense so I could be wrong. It’s right about reversing directions but brake/standby mode is really what doesn’t make any sense.

16

Mmmmok, I get where you’re coming from.

But that’s where pulse width modulation comes into play. That’s how you do speed control. It’s not inherent in the H-bridge circuitry. That is either on or off, forward or reverse, as the truth table indicates. But you can still use that to get speed control on a motor using PWM.

Brake/standby mode is easiest to see just by plugging in a motor and testing. If both your IN lines go low, both your OUT lines are left open-line (not connected to either power rail) and the motor can free-spin.

If both your IN lines go high, both OUT lines are tied to one of the power rails (some H-bridges offer you both options). This basically puts the motor in a closed loop, so it feeds back into itself. The motor slows down a lot faster this way. It’s not a physical brake (no pads are rubbing), but it does work to slow things down. Not the best description in the world, but I hope it’ll serve.

Testing this is pretty straightforward. At one point I had a program that basically turned on each motor full forward, wait for 1 sec, coast, wait 1 sec, full forward, wait 1 sec, brake. Repeat. You could really tell when it was coasting and when it was braking.

Jim Remington’s web page has good info on the various PWM modes you can use on the Baby-O and Orangutan:

uoxray.uoregon.edu/orangutan/

He’s got a cautionary note about brake mode: it’s power hungry.

Tom

17

Hi, Folks:

A couple of years ago I started to complain to Pololu about not supporting their products with documentation and examples–in my opinion, they would be way ahead in the hobby business if they did. To be sure, the documentation and software examples for the X2 are a dramatic improvement over previous offerings, but all of these pale before Parallax Inc., to note one extremely successful example.

However, after speaking with Jan personally at a robot show, I now understand that hobby robotics is not paying the bills and that making custom boards for other customers is. What is misleading is the way this site is presented–most people do not realize that hobby robotics is largely a hobby for the Pololu people. I understand that the Orangutan was originally designed as a favor for a local robotics group.

A separate issue is that Pololu cannot distribute or take any responsibility for AVR C compilers (Parallax provides and maintains PBasic). For a beginner to become comfortable with any of the several C tools that are available usually entails a separate and equally steep learning curve.

The Pololu folks are fine engineers and produce a flexible, reliable product that is easy to use once you have mastered some of the basics. However, the learning curve is very steep and I can only stress that a great way to learn is to study examples. A blinking LED is a MAJOR accomplishment, and that is where it all begins. This is how I learned microcontroller programming, but as I teach electronics as part of my living, the other half (reading the schematics) was trivial.

Tom Benedict, I and others have taken it upon ourselves to contribute hopefully useful examples (LED blinkers, motor speed control, LCD routines, RS232 & I2C routines, buzzer control, etc.) We have posted the examples on this forum as well as on other web venues. We are all happy to answer questions about our own code and sometimes that of others, so fire away!

If you want to know how to do something with an Orangutan, it has probably been done and a method posted. Please use the search function and try out the examples that surface.

Cheers, Jim

PS: Adam Y: you are correct, any digital motor controller can drive only forward or reverse. However, by taking advantage of rapid pulse width modulation (PWM), the motor speed can be anything you want. The brake and coast modes require some knowledge of electronics to appreciate, but they are both useful in different contexts. There are some good tutorials on digital motor control on the web. The Atmel documentation is also useful, as dense as it is.

1 Like
18

Actually, the reason why I bought the baby-o is because of the fact that it’s an Atmega controller. I didn’t really care that they didn’t provide any code because avrfreaks pretty much has everything I could possibly need.

Never mind. I read the truth table incorrectly. That was really quite stupid. All the while I was confused because I thought the outputs were inputs. I retract my pervious statment. Very simple to do PWM with the Baby Orangutang.

19

Jim’s comment about our discussion is generally correct, but our commitment to hobby robotics is stronger than he makes it sound. It’s not necessarily an all or nothing (pays the bills/doesn’t pay the bills) issue; it’s an allocation of resources problem, and we do work on documentation more than some of you think. I think the Orangutan in particular probably has the worst documentation to features ratio among our products, but even within the scope of the project, there were higher-priority issues than application notes:

  • We had to be able to manufacture the actual product. The Orangutan was our most complicated product at the time due to having surface-mount components on both sides and many through-hole components.

  • We were planning on using the mega168 soon (original design had a mega8), but availability kept being delayed, and we wanted to do documentation on the final version.

  • The AVRISP was unavailable (from Atmel) for many months. This led us to compatibility testing with other programmers and looking into providing our own. (That experience contributed to the Orangutan X2 having an integrated programmer.)

  • Meanwhile, the IDE status kept changing, with various updates to the WinAVR package and AVR Studio. We wanted to have one environment we could officially support in our documentation, but AVR Studio didn’t have the gcc support back then.

  • Perhaps the biggest hurdle to having any product at all was the discontinuation of the LCD, which was originally made by Optrex. We looked all over and bought what we could from excess inventory dealers we could find, but there were many months where we believed that we would have to discontinue the Orangutan because the form factor was so dependent on that LCD. (You can again see the influence of this experience on the X2, which is not committed to any particular display.)

The point here is not to make excuses, but to show you some of the challenges in making a product and how much we actually are trying to deliver something to the hobby robotics world that we believe is unique and useful. Even without all of the usual tasks of getting a business going and managing multiple projects and their priorities, there’s much more to our products than design and documentation.

The breakdown is actually more like weeks designing the Orangutan, days documenting it, and months getting it made. Products with no firmware like Orangutan or special chip carriers like the USB adapter or motor drivers don’t take that long to design; it’s the production that’s the most work: our (semi-) automatic testers are among our most complicated designs!

We really appreciate everyone’s feedback about this, and we will certainly continue to work on improving our documentation.

- Jan

20

Jan, thanks for sharing this. This, along with the article on Sparkfun about product R&D, and bringing a product from napkin drawing to market really helps fill in some of the gaps.

It’s good to know the plan was to use the ATmega168 right from the get-go. I knew there were earlier revs of the Orangutan that used the mega8, but until now I’d kinda been living with the concern that the Orangutan was a moving target, and that it might switch to another processor in the future. (I’m trying to keep processor-specific stuff at least marginally nailed down in Orangutan-lib, but supporting multiple revs of multiple boards would be a pain.)

Neat to hear the story on why the X2 has an integral programmer! I’d wondered about that. I’m guessing this is also what led to you guys developing your own programmer as well?

What you say about the IDE leads me to ask something: I got into AVRs late. The Baby-O I bought from you guys about a year ago was my first foray into these beasties. At the time AVR Studio 4 worked well with WinAVR, so I never saw the period leading up to integration between the two. From where I’m sitting the integration looks really good. This latest rev of Studio 4 just plain works. All the threads on AVRFreaks about installation issues with earlier revs don’t seem to apply any more. So do you guys consider the IDE stable enough that you can start aiming your docs at it? (And by extension, am I putting myself out on a limb by aiming Orangutan-lib at it as well?)

GLAD YOU GUYS FOUND A CRYSTALFONTZ LCD THAT FIT! Please don’t discontinue the Orangutan!

Again, thanks for sharing.

Tom