JANOS History October 28, 2017

In 2011 it became apparent that we needed to redesign the JNIOR. This was not because its features and functions were lacking in any serious way. It was more due to the fact that product performance was limited and starting to fall behind that expected by the market. We also could tell that certain devices we used were approaching some kind of End of Life. Specifically the Dallas/Maxim-IC DS400 processor.

We needed to develop hardware around a new processor. While that was certainly doable from a hardware perspective, it meant that none of the existing JNIOR operating system code and its applications would be usable. Regardless of processor selection we would be faced with a new real-time operating system (RTOS) and have to develop a new approach to applications. This would mean as well that the user would see a totally different user interface and would have to learn new procedures for the JNIOR.

Would the result actually be a JNIOR? Certainly we would not be creating a drop-in product revision. This was not going to be an acceptable approach. The main point in the specification of the next series of JNIOR demanded that it remain consistent and familiar to the customer base. If this was not the case then we would never be able to stop producing the Series 3 and move to the Series 4 in any seamless fashion.

So in order to develop a revised series of the JNIOR without disrupting product use we had to both redesign the hardware and the firmware. We needed an RTOS were we would have complete control over the user interface and product capabilities. Given that existing operating system offerings were bloated with generic code, burdened with licensing issues, and expensive the decision was made to write our own.

Series 4 Product Specification

So the first step in any engineering project is to write the Specification document, right? It shouldn’t be any different here. But we never did create a specification document for this. Actually in this case there was no need. The Series 3 JNIOR in and by itself was our design specification.

The intent of the effort was to create a 100% drop-in revision to the Series 3 that utilized a new processor. That meant that it couldn’t look different form a Series 3. All of the external hardware connections had to remain consistent. The external expansion modules needed to continue to be usable. And, it still needed to execute the existing application programs. Basically, once the Series 3 were no longer in production we needed to be able to ship a customer a replacement JNIOR that didn’t involve re-engineering the application and modifying the installation.

That said, the intent also was for the new version of JNIOR to demonstrate “improved performance”. This mostly referred to processing speed. The Series 3 JNIORs were taking upwards of a minute just to boot and load applications. We had to improve on that. But by just how much? It was left unstated.

There were also (naturally) software issues with the existing Series 3 line. Many were rooted in 3rd party code for which we had no access and no ability to rectify. Some of those bugs we indeed started to consider as features. It would make no sense to replicate any of those. The revised JNIOR would be able to address those issues even if it meant some slight change in user interface or procedure. This was to be minimized however.

We had to consider licensing and copyrights. We could not directly convert the Dallas/Maxim-IC TINI operating system for our own use. We absolutely needed to develop our own new and improved code to avoid any legalities or added licensing expense.

Further we wanted to insure that we would not encounter any deficiency or issue caused by 3rd party code. These tended to be costly in our experience as a solution generally was not forthcoming and we would spend a large effort in creating our own work-around. So the new operating system would not utilize 3rd party code if possible. We were to have 100% control of, and knowledge of, the source code. This allowing us to guarantee bug fixes in an unprecedented short turnaround.

Finally, the door had to remain open for the introduction of new functionality that would improve the value of the product.

So, I believe that this conveys the (previously unwritten) set of specifications behind the creation of the Series 4 JNIOR and the JANOS operating system. Now that the product revision is reaching its own maturity I’ll let you create the report card.

Processor Selection
(Fall 2011)

With our goals set we obviously first and foremost had to select a new processor to sit at the core of the new JNIOR series. This would be a good topic for the Hardware section as there were a number of considerations involved. We decided to try the Renesas RX600 line and specifically the 144-pin version of the RX62N.

We obtained an RX evaluation kit, installed the Renesas IDE and wrote some simple “Hello World” type programs. I then jumped into the assembly code and looked carefully at the register handling in C subroutine calls, the complexity of startup code, and the handling of interrupts. It also mattered how the program stack was handled. And there needed to be some atomic instructions (for mutex implementation). I could experiment with these things with the evaluation kit. It also mattered how code was optimized. Was code compact and yet still execute efficiently?

The micro-controller’s complement of I/O pins and their flexibility were of interest. There had to be a good set of peripherals available. Enough to handle at least 3 serial streams. There needed to be flexibility in an external memory bus. Much had to be considered.

Once the decision was made new schematics were created and a board laid out for the first Model 410. The first prototype was hand assembled and made to execute a simple “Hello World” program through the RS-232 (COM ) port. That was (to the best of my recollection) December of 2011.

By | On October 28, 2017 11:34 am | No Comments | Categorized in: