There was a great series of questions sent to us earlier today from a frequent reader and commenter using the “Submit a Question” widget just to the right of here. So good, in fact, that I wanted to address it here in a unique blog. Here goes…
(In response to a job posting the reader saw on a third party site) “If there are a 100-1000 [company name] sort of crucibles of creativity out there, and they start with MCUs (as C++ expertise IS available), how do they get to the S1/2/3? Later when they get the betas done and they need to have something that last a few days so they look at the power draw of the MCU?
The first question is addressed:
The transition from an MCU to the ArcticLink 3 S1/S2/S3 starts and ends with our Integrated Development Environment (IDE) tool.
The language for programming within the IDE is very, very similar to C. While not exactly the same, its close enough that every C engineer that’s worked with the tool (internal and external) has been able to begin programming within a manner of minutes. The IDE allows the customer/engineer to take their existing code, port it into the QuickLogic format, and run tests and simulations. Once all development, testing, and simulations are complete, the code is transferred to a QuickLogic server, where it is compiled into a programming code for the ArcticLink 3 S1 (and in the future, S2 / S3) device. The code doesn’t remain on our servers, allowing 100% IP security for the customer. The code can then be programmed directly to the AL3 S1 device on the hardware board supplied as part of the IDE tool, and tested in a real world scenario hooked directly to the inertial (and other) sensors the customer has chosen.
And the second…
It’s often the case that we see customers starting to address power consumption once they’ve actually gotten to prototypes. As the reader correctly stated, there is a lot of C++ expertise, and many customers do proof of concept on MCUs. However, once they get to the point of actually creating their initial PCBs and numbers are crunched, all of a sudden power numbers start to show themselves.
It’s not quite in the last days of design that a customer will find this – no matter good our IDE is, making the transition from an MCU to AL3 S1 requires an cycle of algorithm porting, testing and simulation, as well as a hardware revision to accommodate the different footprint of the AL3 S1 vs. MCU. While this process isn’t a massive undertaking, it will require some time perform. Not to sound like a broken record, but the IDE will shorten this time as compared to other solutions.