cancel
Showing results for 
Search instead for 
Did you mean: 

Software on Silicon Blog

Moderator
Moderator

We Did It Your Way

That’s the idea, anyway. Greetings, fellow geeks.

The previous blog was a bit philosophical about monolithic vs. modular. Bottom line, with ModusToolbox we took a traditional SDK and turned it into a flexible collection of smaller pieces. In that context, let’s talk about libraries.

ModusToolbox implements a project creation system built on GNU make. See It's Make Time. If you become master of the make system, you can do remarkable things. I think I’ll add that to my list. But for now, libraries.

To implement flexibility, the project creation system locates and parses .lib files. What is that? Here’s an example. This is the entirety of a .lib file. It is a one-line URL to a git repository (we use GitHub) and a specific commit within that repo.

https://github.com/cypresssemiconductorco/TARGET_CY8CPROTO-062-4343W/#latest-v1.X

You use the Project Creator to pick a BSP and an example application. There are hundreds of examples. The project creation system reads the .lib file(s) in the application folder. It goes to GitHub, downloads the code, checks out the specified version, and a local copy of that code appears in your project folder. It then recursively searches that new library for more .lib files. In this way any library can ensure that other libraries it depends upon are included. In the end, all the source files appear in your project folder. Done.

I need this library. Aha, but that needs these other libraries. No problem, let’s get those ingredients. All the ingredients are identified and fetched.

1280px-Libum_Sweet_Cheesecake_ingredients_&_recipe_(8411812870).jpg

I might have to make this. Roman-era sweet cheesecake ingredients; image credit: Carole Raddato, Wikimedia Commons

Like any good cookbook, the potential for creativity is immense. In this case each ingredient is a library. Over time, most have multiple releases. There are some amazingly great things that flow to you from this design.

You can use the Library Manager to add, remove, or update libraries. It’s trivially easy.

If you want a specific version of a library, it’s easy to do that in the .lib file or the Library Manager. You can lock on a “known good” version rather than the latest and greatest, whatever works for you.

Because each library is released separately, they update asynchronously. That’s good, you get improvements faster. It can be bad if incompatibilities appear: version Y of a library no longer works with version X of some other library. That does happen. The flexibility of the build system gives you an easy fix. Lock down on versions that you know work together.

You can add your own .lib files. Obviously writing a .lib file is trivial. It does not need to point to our GitHub presence. The system is based on git, so the file can point to any git repository. If you have a preferred library for some task or problem domain, use it and don’t use ours. Unless there is a dependency among our libraries, this is no muss, no fuss, no worries.

Bottom line, this approach is limitless. Each library, or dependent collection of libraries, is self-contained and self-defining. If you add the WiFi Connection Manager library, all the required libraries just appear in your project. You don’t need to know subtle dependencies, which is brilliant.

I think our build infrastructure is a fabulous tool and it just works. That’s not trivial! But there are side effects.

For one thing, it replicates each library in each project every time. A project can have thousands of files, and many of them are the same from project to project. I suspect most developers won’t like that. “I’ve got four projects going, I don’t need four local copies of your driver library!” EDIT: after I wrote this blog, we fixed this. You can share a library among multiple projects if you want. See Faster Leaner More Flexible – ModusToolbox v2.2 and Lock and Load

Your company may have its own server full of approved libraries and code with which you create your magic. Not a problem.

We like the ModusToolbox make infrastructure. We think you’ll like it. We designed it to be immensely flexible. See It's Make Time.

If it doesn’t work for you, don’t use it! You don’t need to use our build infrastructure if it doesn’t work for you. The build infrastructure and examples show you what you need. Once you understand that, go to GitHub, get what you want, and use it as you see fit. One library or a dozen; whatever version, low-level drivers or a high-end solution. The choice is yours. A design that enables that is a very cool design.

Take the path that works for you.

ThisWay.jpg

Kyoto garden path; image credit: me

2 Comments
Contributor II

Hi Mr. JamesT,

  I agree with most of the approach Cypress is taking with the Modus Toolbox, which follows the unix concept.  Under that paradigm, stringing together lots of smaller programs to accomplish big tasks is de rigueur, and each modular piece can be replaced to do something new.  Kudos! You guys are headed in the right direction.

However, there are two things I miss with Modus Toolbox as compared to Creator, and one thing I miss in your new product line that keeps me on your older chip line (which is still fantastic!). 

First, the visual schematic editor.  It is still a great way to put together trivial (or even non-trivial) circuitry.  As you may well know, men are visual creatures.  Losing that ability with Modus Toolbox has kept me from using it for the majority of my work.  My job is high pressure, we need results NOW!, and I don't have the time to try to do things the new *cypress way* rather than my way (visual free-form).

Secondly, the ability to write components.  I could eventually switch to Modus Toolbox using Verilog component creation.  That would probably take a few months or more to become proficient, but I could do it.  Unfortunately, there appears to be no way to to do that with Modus Toolbox.  Maybe instructional videos would help?  I have to admit I did my searches over 6 months ago, but the last time I checked a few weeks ago, nothing popped out at me.

Also, your new pin editor is not as intuitively flexible, but maybe that is because I can't create new modules or new schematics.

The hardware item issue is an issue I fully understand, but still am bothered by.  In my job, I create high temperature operational electronic designs.  The PSOC5LP will work to a temperature of 350F external temperature for quite some time, especially if clocked around 24mhz.  Your Current source and ADC are accurate enough even at those temperatures to allow for simple additive adjustments based on Die temperature.  Power down, power up at 350F seems to be dependent upon fabrication run.  Needless to say, we *never* return chips for warranty.

Given our unique usage, and the small size of the industry, we use an IR oven to melt the solder paste we use to put components on our small circuit boards that operate at 350F.  Our boards are less than 0.6" in width.  The PSOC6 looks like a device we would love to evaluate, but you do not have a gull wing part for it in production yet.

Also, the maker community can hand solder QFN or gull wing parts, and use IR ovens, but your BGA form factor in the small part is not something that appears to be IR oven friendly.  Have you or your engineers had experience with small runs?

Finally, I have experience with lots of software and hardware.  Could you contact me? I have a suggestion that could be great for Cypress and the user community.

 

Thanks for listening!

Moderator
Moderator

Hey Wade! Thanks for the feedback. FWIW, I miss the Creator schematic editor too. I am not a hardware guy, and it actually enabled me to understand low-level wiring a bit. That's saying something. I think this is tied to your pin comment, too. A table-driven list of potential inputs, and another of potential outputs in the device configurator is not nearly as intuitive as "drag a wire from A to B." All the same flexibility is there, it's just harder to figure out "which pin is A and which is B."

It is my hope that over time some of that ease-of-use returns. I'll forward these comments into the design team, and be in touch.

Cheers, and thanks again.

Jim

0 Likes
About the Author
Been there, done that. Mostly. For software tools and developer support.