After taking a look at the new feature-set for Eagle V6 I got quite excited, but then it hit me… Will they ever make this version available with a lite license? And which features will be cut out?

I’m not a fan of XML but it’s certainly a step into the right direction. The more you open your formats the wider the acceptance of your package will be, generally speaking.

About the new features

Being able to have assisted design tools for differential pairs also sounds good (and I’ve struggled with their trace length script in the past, let’s just say there is no assistance whatsoever for complex designs currently). But what about guard rings and other important design aspects?

One thing I’d like to see is being able to have a “script scheduler” where you can queue scripts and schedule them to a certain refresh interval, then you’d have a window where the output of the scripts will be featured. This would make extending the application a lot simpler and flexible, but perhaps their scripting engine would need to be optimized beforehand.

“Design Reuse” is also another much-needed feature, the consistency part is key here, you don’t want new part numbers if you want to keep your documentation concise and accurate. Kudos for that!

The necessary rant

What really bothers me about Eagle is the back-annotation system and how it’s nearly impossible to solve most issues related to it. I’ve heard about people having to nearly redesign entire sections of their project because of this. It really isn’t very flexible at all.

There’s also no functionality to quickly package and backup projects. I’d like to see a lite versioning system; a meaningful one that is. As for packaging, ideally you’d rather click a button to have the entire project and all of it’s dependencies packaged so you can email it to someone, instead of having to do it by hand. This type of functionality isn’t hard to implement at all, so I question why it isn’t there ( or I haven’t found it yet? – I’ve been using my own scripts )

Another feature I wish to see would be a background image option on the library / symbol designer. The idea being you could draw on top of the image and then the only required adjustment would be the scale ratio for the entire part, which you can easily adjust by taking one measurement on the real part using a caliper, for example.

Recently I needed this feature for an LCD footprint I was working on, it had several mounting holes and a specific header; It would’ve been much simpler if I could just load an image of it and draw on top… Oh well.

Hopefully the new features will be made available to the lite users as well. – Sadly there doesn’t seem to be a release date at this point in time.

Eagle still lacks several key points to become usable for most complex designs, but overall it’s a step in the right direction and I’m glad for Eagle! — Now let’s drop those license fees a notch and we’ll all be happy!
 

References:

• http://www.cadsoftusa.com/eagle-pcb-design-software/new-in-v6/?language=en

My first entry is the FindChar() routine. Unlike the official FindString(), this one only searches for a single character. In situations where you’ll be dealing with single character string searches rather than multi-character, this routine will give you up to 2x speed increase in both Ascii and Unicode modes. Worst case scenario, you’ll get equal results speed-wise.

The FindChar() code can be found at > here <

Due to the fact that Unicode characters are 2bytes long, we must use SizeOf() to perform certain displacement operations. However, this implies the use of at least one division for our final result, this will slow things down in the long-run. So, instead, we hack ourselves into a nastier method and we thank the FPU for it (granted, multiply by 0.5, since we know the character size is constant at 2) As nasty as it is, this allows us to outperform the official routine by almost 2x, still in Unicode.

There are certain things to take care of before doing anything with my routines, and this includes making sure we pass a valid string pointer, while ensuring we never pass negative displacement values and that we don’t attempt to displace over the limits of the string. Any self-respectable coder will do this before calling any routine, though. If you want an extra push of speed, get rid of the main IF statement in the routine.

The ideal solution for this language would be to trash the actual string library and replace it with a proper one, but I fear this is a task for the author, not us. I also fear, we won’t be seeing this any time soon. So we might as well keep on sharing our solutions and “hope” the author reads a few books on proper software development, and that he understands them.

For those of you using Unicode, please beware that this routine has not been extensively tested on a production level. Even though it behaves equally to FindString(), I recommend you to perform at least a few tests before plugging this routine right into your main-code. It’s worth noting though, most of my string routines work on 0-based displacements but output equally to the official PB ones.

One of this days I’ll probably end up ranting quite badly on the fact that this sort of languages lack standad support for some really important routines… On the bright side, they provide quick means of prototyping small pieces of code before getting into production with your main language. Even so, theres no escape on the fact that the author lacks the real-world development experience to provide better solutions for his own product.

That’s it for now, I’ll be sharing more as I find time to post in here. Most of the rutines are being used on my in-house XML parser, just so you know. All benchmarks were done on multiple processors and results were averaged on a set of 20 tries per test.

Cheers.