Blog Main BN'B

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-15

saltuzzo | 07 December, 2018 12:22

Part 15: IoT Core Platform Development;- Peripheral I/O Device Design
The IoT Embedded Core Platform -Analog Input Peripheral Device Design - Continued

"There is no end to education. It is not that you read a book, pass an examination, and finish with education. The whole life, from the moment you are born to the moment you die, is a process of learning". - Jiddu Krishnamurti (May 12, 1895 - Feb 17, 1986)

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016)
Part 2 IPv4, IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016)
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums(Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems-Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Peripherals -Documentation Management Processes (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices -Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)

Quick review to set the atmosphere for Part 15:
From the previous Internet of Things Part-1 through Part- 14:

We will be presenting documentation throughout the design process to keep it interesting. At first we dove right in to the actual design and created several pieces of documentation during the process. This part will give some more insight on the actual documentation process setup for product development and how to create Project Requirements Documents in a simple step by step process. This is the right time to introduce the Project Management (PM) and Project Requirements Documentation process for traceability using a Database Management System and the IPD System.

The basic features incorporated into the IPD system are:

Compartmentalization - for different categories of documents of development stages, Business, Technical, Financial etc.
Organization - Project level single Top-Level-Directory structure separates projects.
Traceability - Bidirectional trace capabilities of the development processes, test cases and validation.
Security - Incorporates Compartmentalization security practices for controlled access of project directories and files.
Backup/Restore - Archive processes to insure all the required files and directories are included archived from the Top-Level-Directory.

Additions were made to the Opening IPD System MAIN MENU as shown below.- Part 13 was also updated to reflect these changes. As we see there have been a few additions and we will present the additions that are effected in this part of the series.

Figure 15.0 IPD Interactive Product Development System Top Menu Update

What we want to cover in Part 15:
It is time we addressed the technical side of the RTM (Requirements Traceability Matrix documentation since we will be setting up test cases. There is no magic to Project Management practices as we will see by the end of this series. We will present some documentation requirements for a few more parts at the introduction in order to become familiar with the IPD Systems flexibility. This is still a development project series and our intent is to remain at the technical level while highlighting/outlining the documentation requirements of product development.

Traceability during development covers al aspects from Business, Legal as well as Technical and is essential when validating each stage of the project. We will keep this more at a technical project development, PoD (Proof of Design) level for a while until we get to a point where the business side is required. At this time the IoT Core Platform is a universal platform that may be applied to many infrastructure critical applications as well as commercial simple applications giving it a wide range of applications.

We will answer questions sent in for our readers about the design in general and why certain parameters and parts were chosen.

Review Developing Documentation Discipline and the IPD System
The Interactive Product Development (IPD) Systems Directory Structure
Traceability Required Documents
RTM - (Requirements Traceability Matrix) Databases
Question & Answers -Analog Input Design
SUMMARY

Lets Get Started:
The IPD Documentation - Developing Documentation Discipline
It is always beneficial to review the documentation process being used to keep the our development processes organized and to review the areas that have not been completed, not that we have to complete them in any order per ser, it is to initialize a mind set for the section currently being developed. The mind of the passionate creator is not a linear step function, 1, 2, 3 ...N, probably because humans are not robots, that follow a preprogrammed set process. The mind fills in parts of the process sometime a few steps ahead and changes a few steps back as the development progresses. What is required is flexibility to perform tuning the development in real time.

Organization and Project Management (PM) are important parts of any development project period. However it is only a part of the project that keeps it on a direct path to completion. The intent/goal is to have a PM application program that allows the entrepreneur to focus their passion for product design while "intuitively" keeping track of all the different aspects of product design. As we will see as the development moves forward the organizational and security of the IPD system incorporates a simple interactive step for each stage of the development which allows the creator to focus on the technical details of the design, make changes along the way while maintaining an organizational methodology for the documentation of the project.

IPD System Directory Structure Architecture:

Naming Conventions:
When the average reader looks at the diagrams of the directory structure there is always the thought of why so many directories? Answer: - Quick review. There are several reasons, which we will highlight with a few now and address more in depth as the series moves forward which will be self explanatory as we enter different developmental stages. The engineering practice answer is "a good naming convention is a must for all application packages and mandatory for any project or product development". Naming conventions allow instant memory recall (the human type) on what is in the file and provides simple filename organization for search and retrieve applications. As shown Figure 14.0 IPD Directory Structure our naming convention for the IPD system directories are IPD_Top-Level-Project-Name, hence: IPD_IoT-PLATFORM for this series project. SS_xxx for the various SaveSet sub-directories identifying various related development categories, hence: SS_IPD for the core IPD sub-directory, then one more level sub-directories IPD_xxx for the specific category types of designs and documentation, hence: IPD_CPLD for the CPLD design sub-directory, IPD_FPGA for the FPGA sub-directory and so on for each category of development.

File names for the actual files within the design sub-directories are users defined since this main objective in the IPD naming convention is to organize the development process by directory level and leave the individual filename of the user that will have a better relationship to the users project, this allows easy navigation to though the IPD system by project. One of the important features of writing software is the naming convention used, we will address programming naming conventions when we get into the software part of the series. As we see product design is easily broken down into several categories and subcategory types which entails multiple disciplines to be successful. The intent/goal of the IPD system is to allow the focus on design and development while intuitively documenting the process for traceability. As we stated many times during this series that product development of any type requires a unique combination of documentation along with an intuitive mind-set for a successful product.

It would be interesting to hear from my readers how many have experienced difficulties of "Now Where Did I Put That File?" The Internet encourages the download of PDF and other files to read at will. So, speaking for myself only, I download the file and put it on our internal public drive to share. You would be amazed how fast the drive gets filled with random files that have to be opened to figure out the contents. When I was starting out I filled up hard drives real fast, over the years organization developed and today the structure I am presenting here is used to relate files to projects. The experienced gained over the years as an entrepreneur developer will now be implemented in the new IPD System with the goal to help entrepreneur's and small businesses compete in product development and time to market.

Traceability Required Documents:
Today's product development requirements have changed over time from a couple of business and technical documents to many documents that have to deal with various rules and regulations in both consumer and industrial market arenas. To name a few requirements documents, legal, business, and several technical documents to cover computer hardware, software and validation documentation to register compliancy. There are special documents on security breach compliancy as well to adhere to the many regulations that the industry is plagued with. Organizing these documents and being able to track the document requirements through the development process requires vigilant monitoring to insure all the requirements have been met and validated. For our project the documents that we will be creating over this series are listed below. The IPD System allows the registering of these documents with a unique Document Trace ID for tracking throughout the development process. Figure 15.1 IPD System Required Documents Dialog allows the user to assign a unique Document ID for tracking each of the required documents for the project through the RTM (Requirements Traceability Matrix) relational database network as shown in Figure 15.2 IPD System Traceability Matrix Database Dialog below.

BRD - Business Required Document
PRD - Product Required Document - Many applications and this will vary to accommodate
HRD - Hardware Required Document - Form Fit Functions
SRS - Software Required Specifications Document - unique to the Application
TRD - Technical Required Document - Full Technical Specifications
VRD - Validation Required Documents - Compliance docs for all components and test results.
LRS - Legal Required Specifications Document - to be compliant with all the new regulations

Figure 15.1 IPD System Required Documents Dialog

RTM (Requirements Traceability Matrix) Database:
Organized development documentation is only one issue being able to trace the development process bi-directional throughout the development cycle to correct any errors or make specification changes that arise during the process is totally an different issue. There are so many snippets on the Internet about Requirements Traceability Matrix methodologies along with many do's and do not, one could make a career out of it, Oh!! wait, there is a career and certification on it already. Figure 15.1 is the IPD Systems RTM documents dialog for traceability.

Top level Project Management where the entire project or program is managed at the 50,000 foot level, hence the main management level of all projects, however for both large and small companies the breakdown of the product development process is the same, the main difference between large and small company sizes is the amount of human resource availability. The IPD System allows the entrepreneur and the small company to develop projects and organize the different aspects of projects development intuitively. For the entrepreneur, the mind-set is always active and many ideas flow for projects to design, manufacturer etc., the IPD System allow the entrepreneur to organize multiple projects and add top them at will when the ideas flow and maintain the organizational requirements to clearly see the state of development of each project intuitively.

When the small company decides to outsource some of the development, the IPD system handles each outsource as a project base allowing control and security protecting the Intellectual Property of the full program. The out sourced project when completed becomes a reuse module for the larger project and is introduce through the reuse section of the IPD System with all of its documentation intact for a true reuse module (If there really is such a thing as complete reuse!) either way it just becomes a component for the larger project.

Security is also designed in at the ground level. Initially this was performed in a manual process, this was relatively easy since we just filed the documents in a physically secure location of course in a Top-Level_Directory identifying the project. Automating the process using relational databases creates a new security issue which we have designed in for the ground floor on the IPD system. Security access is controlled an assigned by several security access level ID's for the Server itself, the different project databases, Programs, Projects, Categories, Sub-Categories and Filenames. This is controlled by the Access Level Management section and is accessed by assigned program managers for the project. This is for each project base development and is the bottom level of security access. Top Level security access is controlled through a secure server by the Security Officer who assigns responsible manger for each project at the project level. We will address this more as we get closer to the end of the project series and introduce both IoT Platform security protocols and IPD System protocols. As stated our intent/goal is to present a solid product development platform that is intuitive and second nature for the control and organization for product development.

OK, I do realize that we just jumped right into designing without using the Required Documents except for the IoT Conceptual Document back in part 12 or any of the RTM databases for the design, however it was intentional. The intention was due to the facts that we were making changes to the IPD Systems as we are developing the IoT Platform in order to insure we cover all the bases of development. What better way than to interact with all the required rules and regulations during the design process for present day technology development to insure a true intuitive organizational methodology.

It is easier to understand when you have a device being developed to reference then doing all the paperwork first, and it is important that the development shows the flexibility of the intuitive process that the entrepreneur can update at any time to comply with the required documents. Since we are only at the first peripheral design stage we will enter this RTM case for that section and publish the result for each DED (Deliverable Expectation Document) created and put in the Requirements sections.

Figure 15.2 IPD Traceability Matrix Database (RTM) Dialog

OK, Now that we understand the number of documents that are the top level of product development - we will create these as we proceed with the design and update them as the need exists to track the details of the development. For entrepreneurs the top level idea is always the most exciting, it is the detailing to bring it to fruition that tends to slip on the documentation, so it is a good idea to have an intuitive system that will keep track as the ideas and details come into play during development, hence the IPD system. We will be adding information to the top two dialogs, treating them as a living document system. Lets get on with the design and address the questions that have been asked.

Questions & Answers - Analog Input Design:

Question:
What was the criteria for selecting 16 bits?
Answer:
Basically the selection is one of 35 years of designing data acquisitions and process control systems. To shorten the answer and validate the suggestion look at the website page About->History to start. A 16 bit 1 MHz Successive Approximation converter covers many of the general purpose applications for an analog input peripheral and falls in the balance of bit to performance ratio for the majority of analog input resolution. This also give the opportunity to add different type of analog front end signal conditioning to allow windowing to increase the dynamic capture range which is part of the next question.

Question:
Why the 11 range gain setting and not the typical 1,10,100,1000 range like many other DAQ systems?
Answer:
There are actually 22 ranges on the PGA281 which allows a wide range of inputs to accommodate various type of transducers and sensor devices to get the maximum dynamic range from the sensor. The 22 voltage ranges are calculated from the max input range of the A/D which is bi-polar of +/-1.25000 volts DC. Applying the ranges the table below shows the full scale A/D range for each gain range. Table 15.0 below shows the full scale input range to the amplifiers gain range.

PGA 281 Gain Range (G4=0)	FS A/D = ±1.250Vdc/Gain Range 0	Resolution 0 = (FS Range / 2¹⁶)-1)	PGA 281 Gain Range (G4=1)	FS A/D = ±1.250Vdc/Gain Range 1	Resolution 1 = (FS Range / 2¹⁶)-1)
0.125	±10.00 Vdc	152.592 x10^-6	0.172	±7.2674 Vdc	110.8951 x10^-6
0.250	±5.000Vdc	76. 2962x10^-6	0.344	±3.6337Vdc	55. 4475 x10^-6
0.500	±2.500 Vdc	38.1481 x10^-6	0.688	±1.8168 Vdc	27.7230 x10^-6
1.000	±1.250 Vdc	19.0741 x10^-6	1.375	±0.9090 Vdc	13.8706 x10^-6
2.000	±0.625 Vdc	9.53703 x10^-6	2.75	±0.4545 Vdc	6.93533 x10^-6
4.000	±0.3125 Vdc	4.76852 x10^-6	5.5	±0.2272 Vdc	3.46690 x10^-6
8.000	±0.15625 Vdc	2.38426 x10^-6	11	±0.1136 Vdc	1.73345 x10^-6
16.00	±0.078125 Vdc	1.19212 x10^-6	22	±0.056818 Vdc	0.67000 x10^-6
32.00	±0.0390625 Vdc	0.59606 x10^-6	44	±0.028409 Vdc	0.43350 x10^-6
64.00	±0.0195312 Vdc	298.032 x10^-9	88	±0.014204 Vdc	216.742 x10^-9
128.0	±0.0097656 Vdc	149.016 x10^-9	176	±0.0071022 Vdc	108.374 x10^-9

Table 15.0 Analog Full Scale Input Range to Gain Ranges

OK, why so many ranges? When you look at the gain ranges 1, 10, 100, 1000 and usually follow the +/- 10.00 volts, 1.00 volt, 0.100 volt and 1.000 x10^-3 volts full scale. The few ranges limits the resolution of the sensor because of the large jump in ranges. Hence: for a 2 volt sensor the Gain of 1 must be used and that limits the full range of the analog input effective resolution to (2.0vdc ÷ 152.588 x10^-6) = 13,107 bit counts out of 65535 bit counts effectively a 13 bit A/D. By adding more gain ranges you get a closer match to the analog sensor point yielding a more accurate representation of the signal being measured. The PGA281 has 22 different gain ranges (G0-G4) to handle many different sensor ranges.

The other reason we selected the PGA281 is for the full differential input capability up to ±15.0 Vdc as well as the large full scale common mode rejection ration. This allows the use of additional signal conditioning to apply an offset to one side of the analog input. This is easily used for monitoring noise on say a 5 volt line. By adding a 5 volt signal to on side of the input you get to monitor the noise from a relative 0 volt input and use the gain to get full scale noise on a DC level. We will be adding this capability to the analog input as the series moves forward. The A/D converter that is used only has a 2.5Vdc full scale Range or ±1.25 Volts Bi-Polar which is what out ranges are based on.

Question:
What is the purpose of putting an A/D 2Megx16 buffer memory?
Answer:
There are many useful purposes for the A/D buffer memory, the main reason is to free up the CPU for difficult periodic conversions. Today's CPU's handle many tasks and collecting data with a timed periodic conversion rate becomes challenging. Setting up a DMA memory area varies from hardware to hardware and is generally limited in size and the memory refresh rate. A buffer allows data to be collected at a precision periodic rate using a controlled timer counter that is in the CPLD design. An external trigger to start the data collection is generally part of the memory buffer features. A typical application is to collect data at a 1Meg Sample Rate for two seconds and perform an analysis on the captured data frame.

Question:
Why just a single A/D channel? Why not just put a multiplexor for many channels ?
Answer:
The next session is to add other analog input features. We have scheduled a multiplexor and a Analog Output control for applying a voltage offset to the analog input to capture smaller signals that ride on a DC voltage within the analog input range. Generally 8 channels differential and 16 channel single ended are the typical expectations of the industry. We will also be adding programmable channel sequencing - Start Channel to Final Channel with various gain levels for each channel.

Question:
Why start with a CPLD and not use an FPGA from the start?
Answer:
This question arise on a regular basis. The answer is it depends on the application. Our initial intent for the Analog Input was to make it a Plug-N-Play module to be added to the application as required. Designing that initially with a CPLD does not prevent us from making it part of an FPGA if the application calls for it. The CPLD just makes it easier to make it a module and validate the PoD.

SUMMARY:
There are still a few more sections for the Analog Input peripheral that has to be completed that we will cover in the next part of the series. What we have been able to accomplish to date is a solid ground floor understanding of how the IoT devices are configured. The selection of the Analog Input device is a good start to understand how peripherals are configured and controlled regardless of the type of BUS interface used to communicate with the host CPU.

Each part of this development series shows a little more the advantages of an IPD system as we incorporate each stage of the IoT Platform development into the IPD system to organize and track the development stages. All functions neatly organized in the appropriate folder with a easy Click'N'Open to continue the development process.

Thank you everyone for the encouragement and kind communications directly on this blog series. I am available for consultation on this series or any other projects that you would like consultation or help with. As the series progresses the author will be available for discussion for those that want to follow this series in detail and conduct their own experiments. Contact me directly through the BASIL Networks Contact Form. I will create a sub category for this series on unique questions and answers as not to be embedded by multiple post comments and hard to review.

Part 16 Preliminary Outline" A/D Channel Hardware/Software Design: -Continued

Adding other features to the A/D Channel
Creating Device Driver Flow Charts for the A/D peripheral operation.

Reference Links for Part 15:

PGA281 Programmable gain Amplifier Datasheet

Intel®/Altera® Quartus Download 9.1 sp2 from Archives

Intel®/Altera® Quartus Lite 18.x Download

Requirements Traceability Matrix (RTM)
Project Management
Mezzanine Board

The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method. Thank You - expand your horizon- Sal Tuzzo

Network Sorcery: http://www.networksorcery.com
The Internet Engineering task Force: IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Memory Segmentation
The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016)
Part 2 IPv4, IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016)
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application Continued-The Ethernet Protocol(s) (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application Continued-The CRC-32 and Checksums (Nov 27, 2017)
Part 8 IoT Core Platform& Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations (Jan 12, 2018)
Part 9 IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (May 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices -Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)

Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-15 Peripheral I/O Design - Analog Input Peripheral Design - (Dec 7, 2018)

For Website Link cut and paste this code:

<a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=20&blogId=1" target="_blank">BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-15 Peripheral I/O Development:-Analog Input Perpheral Device Design (Dec 7,  2018)</a>

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-14

saltuzzo | 29 October, 2018 15:25

Part 14: IoT Core Platform Development;- Peripheral I/O Device Design
The IoT Embedded Core Platform -Analog Input Peripheral Device Design - Continued

"As we get more technically driven, the importance of people becomes more than it's ever been before. You have to utilize who you are in your work. Nobody else can do that: nobody else can pull from your background, from your parents, your upbringing, your whole life experience." - David Carson (1955 - Age 63)

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016)
Part 2 IPv4, IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016)
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums(Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems-Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Peripherals -Documentation Management Processes (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices -Peripheral Design From the Beginning (Oct 7, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)

Quick review to set the atmosphere for Part 14:
From the previous Internet of Things Part-1 through Part- 13:

(Worth Repeating) - Since the beginning of this series in September 2016 there have been many hacked IoT devices using COTS embedded hardware and software creating high visibility to security and privacy. The current database of breaches encouraged us to present a more detailed hardware and software presentation to assist designers and educate new comers of the new challenges with security and privacy. Due to the complexities of processors today we will continue to follow our technical presentation methodology, Overview - Basic - Detailed (OBD). We will be addressing the many sections of the Core IoT Platform separately to keep the presentations at a reasonable length. The full details will be presented during the actual hardware, firmware and software design stages.
The internals of the embedded processor IC's peripherals assignments.
Documentation categories, requirements, review & creation.
The Conceptual presentation of our Core IoT Platform Documentation
Brief Introduction to the Interactive Product Development System
Common Functions of Peripherals and data memory buffers
Introductions to the world of FPGA and CPLD development systems
Analog Input Peripheral Preliminary Design Requirements
Analog Input Functional Block Diagram
A/D Data Transfer Timing Diagrams
Control CPLD Schematic Diagram For the A/D Converter

What we want to cover in Part 14:

In this part of the series we want to cover more on the process steps that were performed to develop the CPLD and interconnections to the surrounding A/D converter and Programmable Gain Amplifier for the Analog input peripheral.

Review Developing Documentation Discipline and the IPD System
The Interactive Product Development (IPD) Systems Directory Structure
The CPLD Section of the Interactive Product Development System
The CPLD Register Assignments
The CPLD Pin Assignments and Memory Chips
The CPLD and Component Schematic Capture Symbols
A/D Analog Input Schematic Design
Simple Flow Diagram to Test Timing

SUMMARY

Lets Get Started:
The IPD Documentation - Developing Documentation Discipline
It is always beneficial to review the documentation process being used to keep the our development processes organized and to review the areas that have not been completed, not that we have to complete them in any order per ser, it is to initialize a mind set for the section currently being developed. The mind of the passionate creator is not a linear step function, 1, 2, 3 ...N process it fills in many pieces as the development progresses.

Organization and Project Management (PM) are important parts of any development project period. However it is only a part of the project that keeps it on a direct path to completion. The intent is to have a PM application that allows the entrepreneur can focus their passion for product design while intuitively keeping track of all the different aspects of product design. As we will see as the development moves forward the organizational and security of the IPD system is a simple interactive step for each stage of the development which allows the creator to focus on the technical details of the design.

IPD System Directory Structure:
As we stated many times during this series that product development of any type requires a unique combination of documentation and mind-set for a successful product.

Back in part 11 Figure 11.0 IPD Relational Databases we presented the number of different databases that may be used for a full product development process, in part 12 Figure 12.5 IPD System Directory Structure we presented the preliminary directory structure for compartmentalization of the different document types during development.. Remember as stated before all of this development process was initially done manually for many years and has a proven track record for product development.

So now that we are into the actual development incorporating the IPD system lets present the updated directory structure that the IPD system incorporates to show how the system organizes the development. Figure 14.0 shows the new directory structure of the IPD system we will be using for this development. The directory structure follows the same philosophy as the Interactive BUS Protocol Development (IBPD) system of compartmentalization allowing document organization and security. It is easy to create a directory structure that is organized, creating all the interaction with relational databases and interactive dialogs is what makes the IPD a useful tool in development. This directory structure may also be maintained manually and is a good starting point with minimal effort to encourage product development discipline.

Figure 14.0 Interactive Product Development (IPD) System Directory Structure

OK, why so many directories for product development? There are several reasons, which we will highlight a few now and address more in depth as the series moves forward as we enter each of the stages.

Compartmentalization - of different documents and development stages, Business, Technical, Financial etc.
Organization - Project level single top directory structure separates projects.
Security - Incorporates Compartmentalization security practices for controlled access of project directories and files.
Backup/Restore and Archive processes to insure all the required files and directories are included.

Many companies separate development into sections by design. there are financial, management, procurement, modular parts of a design, marketing and the list goes on. The next issue is security which we just touched lightly on in part 12 and 13. However, today security is an important function to maintain trade secrets and market share. The IPD system controls access security for each project at the directory and files levels by user login and user pass phrase. The IPD has several levels of integrated security and uses AES256 along with other propriety obfuscating algorithms; we will address this again later in the series when we get into the security aspects of the platform.

CPLD Interactive Dialog of the IPD System:
OK, lets look at the CPLD design and move forward. The CPLD/FPGA Integrated Development Environment (IDE's)! Due to the competition in the CPLD/FPGA industry these IDE's all have very competitive features like command line opening of a project which allow the direct interaction with the IPD system. Figure 14.1 IPD System CPLD Dialog, interactive CPLD dialog for the project allows easier program management and organization by a simple Click&Open function.

Many of the programmable logic IDE's if not all are project based, meaning they setup a separate directory for each device being developed. However, what we have found is that many of them are not backwards compatible. If you use a new version then the files are no longer compatible with the release that it was developed on. This is also one of the several reasons we have several releases of the IDE's on our in-house servers. For a single designer only backward compatibility is generally not an issue however, when there are several designers involved with a project this becomes a software compatibility issue and some type of control on application development software is required. The IPD system CPLD interactive dialog allows application development software control of the different CPLD's for a project.

At BASIL Networks we have several releases of our schematic capture and layout software due to non-compatibility upgrading issues and the time required to re-layout an older product that will not extend its life cycle, changes are not on the roadmap for them. All companies from the single entrepreneur to the largest of corporations have these same issues to deal with. For a larger corporation this can easily become a nightmare resource and financial burden on the company. We were forced to make the decision that all new designs will be with the latest IDE's and we will face the same upgrading issues in a few years when updates are not compatible again. For programmable logic IDE's there may be a slight header alteration for the HDL or RTL to make the source code transferable, which is a very small issue as compared to other IDE's.

Figure 14.1 Interactive Product Development (IPD) System CPLD Development Dialog

The Quartus IDE from Intel/Altera which we are using in this project opens on a command line using a single file linking the device project and uses the file extension *.qpf. From the file highlighted in the list it is ADC_CHAN.qpf. The Application Program field at the top section of the dialog shows the application program icon and location as "C:\altera\91sp2\quartus\bin\quartus.exe" that will open the ADC_CHAN.qpf CPLD design. Every line item in the list has its own database record and the CPLD design database used with the dialog as with the remaining design dialogs allow 256 unique designs giving the user the ability to have designs using different IDE's from different manufactures organized in a clean directory structure for the project with a Click&Open feature insuring repeatability and saving time.

From the directory layout we see that the CPLD directory is N:\IPD_IoT-PLATFORM\SS_CAD\IPD_CPLD. The N:\ drive is BASIL Networks In-House off-line cloud server that is being used for this project. The directory IPD_IoT-PLATFORM is the actual top level project directory we initialized in part 13 for the IoT platform project. The SS_CAD\CPLD (SS_CAD means Save Sets for CAD type functions) and CPLD is the design subdirectory directory where all CPLD designs are stored. From there we created the subdirectory ADC_CHAN to put the CPLD design in for the Analog Input. The sub-directory ADC_CHAN is in a separate field from the directory tree in order to easily see the current design selected. This can be created several ways either from the IDE or manually. Project and design information are also important for program management and the interactive dialog shows information about the CPLD chip, the designer, creation date and time on project. The project security allows full project encryption as well as directory and file encryption along with access control for the project controlled by the top level Project Manager. The designer also fills in the abstract of the design to view what the design entails and is used mostly for browsing. The machine ID and Login ID will change depending on the machine being used to view or modify the design and will be saved in the database last accessed fields for the top level manager to view. The users may also use private AES256 pass phrases for each file which would be required to open the file. If you loose the key or pass phrase, there is no Manager key to open any of the files.

CPLD Register Assignments:
The next part of the ADC_CHAN CPLD design is the Register Assignments. This is required to test the CPLD logic and timing for the 50MHz SPI interface in Figure 13.4B and Figure 13.4C along with the full CPLD register set Figure 13.5A and Figure 13.B.

We have used Microsoft® Xcel, LibreOffice® Calc, OpenOffice® Calc spreadsheet type application programs over the years for the register and pin assignment functions. Table 14.0 A/D CPLD Command Control & Data Register Assignments below identifies the assignments for programming the A/D Analog Input CPLD.

A little note about the internal 8192 bit FLASH on the CPLD chip; this is programmable at this time so we will be able to test different security features we plan on as an add-in later in the series. Once this is completed we will use a separate file to load the flash during In-Circuit-Programming of the CPLD. This creates a fixed security feature that will only be capable of reading through a special entry sequence created by the designer and integrated into the software for the specific IoT Platform allowing each platform to be unique. This will separate the physical hardware and insure that it is the right hardware being accessed. There are several spare functions in this CPLD design since it was a re-use from other more complex designs. We will return to these spare functions as we proceed to design other peripherals and maybe even combine them into a single CPLD or FPGA.

Table 14.0 A/D CPLD Command, Control & Data Register Assignments

CPLD Pin Assignments:
OK, why do we want to assign pins first to the CPLD? For the seasoned professional this will be a bit boring, however for our readers new to designing with CPLD's this excerpt added to the introduction to CPLD will give a bit more detail to the design experience. The pin assignments along with the logic functions of the application determines how the pins are connected internally. If the design is complex then timing issues will occur and the device may not perform as expected. Figure 14.2 CPLD Typical Interconnection Matrix Array shows how a typical CPLD or Gate Array single layer is configured, some CPLD's and FPGA's have several of these layers vertically and interconnections vertically as well as same layer interconnects and they all have their propagation delay characteristics.

The Logic Elements consists of a complex array of logic functions that are programmable, each manufacturer has their own way of defining these logic block and are easily looked up on the Internet. The I/O Blocks are the blocks for each pin allowing pull up/pull down Open Drain, Tri-State etc. pin functions while the logic elements perform the desired logic functions and eventually connected to I/O Pins.

Figure 14.2 CPLD Typical Interconnection Matrix Array

Each of these LE's consist of identical blocks of logic functions like AND,OR, MUX, REGISTER functions that are connected to several layers of a cross hatch matrices where each cross on the matrix is a connection point. There are propagation delays when going from one interconnection to another as well as inter-layer connections where these delays can easily add up to several nanoseconds which can cause missing register loads and data transfers. For our IoT Platform A/D Analog Input design we have a 50 MHz SPI controller, a 20ns clock width per bit and the data has to be stable for 10ns and then clocked into the register. Considering the typical clock rise/fall times are under 2ns that only gives us a 6 ns window to capture the data. So when we look at the timing in those terms we see why we may have to select the faster CPLD. The Intel/Altera MAXII series have a few different speed configurations, the average is 350MHz clock rates for the global clock input pins. The global pins are special pins on the matrix that propagate directly through the matrix so the minimum number of interconnects are required to use the signals. Our design does use one of those pins for the 200MHz clock signal that is used throughout the IoT Platform as a reference clock. For further education on these devices, there are several free on-line video class room tutorials from beginners to seasoned engineers that you may take at your own pace. Purchasing a inexpensive development kit for these is probably a good idea. BASIL Networks, PLLC does not sell end user products, nor do we sponsor any manufacturers. Distributors like Digikey® and Mouser® and others have evaluation kits for a good majority of chip manufacturers.

Ok lets tackle the CPLD Pin Assignment now which is required prior to "creating the schematic capture symbol" for the controller section of the Analog Input peripheral. From Figure 13.3 Analog Input Peripheral Block Diagram the part number of the Cellular-RAM or Pseudo SRAM memory chip is IS66WVE2M16EBLL-70BLI for the 2Meg x16 bit when the design was initially created a few years ago. Today ISSI ( Integrated Silicon Solutions, inc.) manufactures the 4Meg x16 bit (64Mbit ) in the same BGA(48) package and is in production, the part number is IS66WVE4M16TBLL-70BLI. We will look at both of these parts for the CPLD pin assignment.

The pin assignment objective is to have the shortest distance traces between the pins of each component attached to the CPLD. This is done to minimize the traces on the PCB Layout and keep the trace impedance characteristics the same or as close as possible for each trace. We will cover PCB Layout trace characteristics when we get to the layout part of the peripheral.

During this series we will be introducing the basics for the beginners and a quick refresher for the seasoned engineer. I will be available to answer questions via the contact sheet on this site. I will post the questions and answers with a link to a separate category for this series in order not to get the questions and answers buried in the blogs comments since we do get a fair amount or comments.

The Block diagram Figure 13.3 the grouping of the pins by function has been defined already so we will start there. The largest number of pins are assigned to the memory chip. The memory is a 48-ball TFBGA (Thin Profile Fine-Pitch Ball Grid Array) the dimensions of 6mm x 8mm and a pitch of 0.75mm. There are a few rules for BGA packages that should be followed for good engineering practices. There are many tutorials and papers on PCB layout of BGA packages which we will cover when we get into the layout section of the peripheral, for now we will just look at the traces as simple lines. There is logic in why this exercise is practiced prior to the actual layout, simply put, it is easier to do a preliminary pin assignment than try to assign 70 pins to the CPLD during layout. Another reason is to minimize the number of PCB layers. PCB Layers are in multiple of two, which doubles the process requirements during fabrication, hence increasing the cost of the PCB by almost double depending on the actual PCB yields and company producing the PCB. Another reason as stated prior is the trace width and spacing between traces which effect the cost and yield directly. The memory chip 48-ball TFBGA has a pitch of 0.75 mm (29.52 mils) and a ball width of 0.30 mm (11.81 mils) which running a 0.2 mm (8 mil) trace with 8 Mil spacing will produce a high yield PCB. Also a 0.38mm (15mil) through hole with a 0.635mm (25 mil) pad allows both sides of the board to be utilized easily. The TFQP 100 Pin CPLD has a pitch of 0.5mm and is 16mm square and the fact the all the pins are on the four edges of the chip makes it easier to layout.

Figure 14.3A shows the free hand traces for the pin assigning of the CPLD, Figure 14.3B shows the grouping of trace routes for the memory TFBGA out to one side of the chip to connect to the CPLD pins. The yellow pins are the address pins and the light blue pins are the data pins, The Red pins are the +3.3Vdc power pins and the gray are ground pins. Since this is a re-use design we have already optimized the layout, however the exercise is well worth practicing for future designs. PCB layout is an artist type process of spatial dimensioning, some of the best PCB layout engineers are center brain individuals that have artistic talents to be able to visualize unique logic patterns which both right and left hemispheres of the brain are uniquely connected.

Figure 14.3A A/D CPLD & Memory Preliminary Block Freehand Trace Route

You do not have to hand trace this entirely, just a preliminary to see if there are enough pins on each side of the CPLD to connect. As stated some of the traces will be reassigned to appropriate pin numbers during the layout process. Every designer has their own way of creating a PCB layout, however the most common areas are those that may be susceptible to crosstalk and other transients, those traces are usually shielded from other traces. the rest remains the decision of the designer and the area constraints of the PCB. For the beginner, do not get discouraged, even some of the seasoned designers take a few tries before they get a working layout. For the seasoned, well, for myself, I generally get a good nights sleep and a fresh pot of morning coffee. Some of the IDE layout packages have what they call "Auto-Routing" I personally avoid auto routing since it pure logic and will place via's and longer traces depending on the trace list sequence. Human interaction and manual layout works best for me however, as stated every designer has their own way of designing just like artists their signature characteristics sow in their work.

PICTURE_CPLD_PinsGrouping
Figure 14.3B A/D CPLD & Memory Preliminary Block Trace Route Layout

In the process of the PCB layout for this re-use we tried several layouts to get the optimum for this design. Although this design may be layered out on a simple two sided PCB it was designed on a four layer PCB with other analog designs for a specific application. The four layer PCB choice was to include a ground plane and a separate power plane, giving the analog traces some shielding.

The actual Pin assignments for the CPLD is shown in Figure 14.4A CPLD Pin Assignments By Number and Figure 14.4B CPLD Pin Assignments By Name. BASIL Networks design methodology is to show both Number and Name assignments in spreadsheet form for easier PCB and Schematic capture symbol generation as we will see when we get into the next sections of the process.

The Pin Assignment by name insures that we have all the proper power and programming pins assigned properly. What we have done here is to create a set of spreadsheets with the critical pin assignments for each of the CPLD manufactures series and started from there. The Quartus Pin Assignment function in the IDE for the CPLD shown in Figure 14.3 will generally block the user from connecting to reserved pins on the component. Pin assignments for the entire Intel/Altera CPLD MaxII line

Figure 14.4A A/D CPLD Pin Assignments by Number

Figure 14.4B A/D CPLD Pin Assignments by Name

We have found it is much easier to create a schematic symbol when the pins are listed by name and it follows the signal flow of the block diagram in Figure 13.3. We finished assigning the pins for the remaining connections of which we did make changes during the layout process however they were only a few number changes that are expected during a CPLD and component layout process. Schematic symbols and PCB footprints were created for the remaining components as well. This design incorporated the 2Meg x16 PSRAM and the CPLD only had one spare pin.

CAD Symbols
Now that we have the CPLD initial pin assignments grouped we are able to create a schematic capture library symbol for the components. There are only four IC's to this design, the CPLD, the Memory chip IS66WVE2M16EBLL, the A/D Converter AD7890 and the Programmable Gain Amplifier PGA281. Figure 14.5A shows the pin assignment layout of the CPLD and since this is a custom layout care should be taken for the placement of the signals to make it easier to read the schematic capture drawings. Figure 14.5B are the remaining CAD Symbols for this design, the A/D Converter 7890, PGA-281 and the Memory IC respectively. The CPLD Pin assignments are preliminary and you should expect to change these in real time during the PCB trace layout process. During our layout process we did change several pins to reduce the number of via's in the layout. Many critical timing designs also require controlled impedance traces in order to align the signal transmissions which would require reassignment of pins. Yes, PCB's have inherent trace delays and are directly proportional to frequency (1/Time), so that gives us two propagation delays, one inside the CPLD and one on the PCB traces. When creating a schematic capture symbol a starting point would be to layout the CPLD pin assignments that follow the block diagram, although there are many approaches to arrive at the best results. This design selected to use the MAX-II -T100 series 100 pin TQFP CPLD which is a 3.3 volt device for the internal power and up to 5v for the I/O pins. There are several places you can download free footprints and schematic capture templates for many of the components, the two that are most prevalent are Octopart and SnapEDA. It is always a good practice to create your own within the CAD IDE you are using.

The actual interconnect to the IoT Core Platform has been left out at this time on purpose since we have not designed the remaining peripherals and the interconnect to the peripherals will be analyzed at that time. To date we selected a CPU parallel interface architecture to connect the peripherals so it becomes a mechanical interconnect issue for now.

When creating schematic capture component symbols we find that as the number of pins increase so the page size of the schematic increases. Some of our designs incorporated a 208 pin CPLD and that required a C size drawing by default. For many years BASIL Networks standardized on a B (11"x17") size format, however as time moves on we changed that to a C" size (17"x22"). If you shrink these drawings to fit the printer page and they are reduced to the level that the pin assignments are not readable and the saving paper size purpose has been defeated. Pick a CAD package that you are comfortable with to follow the series, they are all competitive and the end result will be the same. It is the individual designer that determines the end result not the CAD package.

Figure 14.5A A/D CPLD Schematic Capture Symbol

Picture_ADC_Component_Symbols
Figure 14.5B A/D AD7890 MSOP-10 Package , PGA-281 TSSOP16
PSRAM Memory Ball-48 TFBGA Schematic Capture Symbol

A/D Analog Input Schematic:
To encourage documentation discipline we will add the ADC-CHAN Schematic Capture to the IPD system. This allows a Click&Open design function, organizes the directories and saves time in looking for the design. Figure 14.6 shows the PCB Schematic capture dialog for the ADC-CHAN peripheral. The separation of development tasks allows the designer to track time spent for each part of the design and for the project manager to organize and present the design resources used for the project.

Figure 14.6 Interactive Product Development (IPD) System PCB Schematic Dialog

For this series we are using Cadence OrCAD for the schematic capture to create the PCB Schematic design. Most of the small companies have a single users license for each PC and probable only one or two. Many CAD packages offer two forms of license, single user for loading on a single desktop and they are generally perpetual type licenses. The other license type is a network license with a specific number of run time licenses allowed from an in-house network server. Here are the issues that we have observed with network licenses along with the associated license control managers; they are a pain in a place where the sun does not shine. Server maintenance generally changes thing with licenses and interferes with server ID's where license managers have to be reloaded and validated. Some use disk serial numbers, some use encrypted keys created from the servers internal setup and the technique goes on. We encourage single user licenses mainly if the server fails or has to be changed you do not loose all the licenses and development is delayed for only one system. For us here at BASIL Networks, since we collaborate with other seasoned designers across the country that all have their own private labs as we do, it is best to purchase a single user license to run on a desktop. Creating a gold disk or full recovery image backup is a lot easier to recover and pick up where you left off, however if you have to replace the motherboard you will probably have to validate the license again.

For the actual design files we keep them on the in-house private cloud server that is not connected to the Internet. For this series we allotted a drive on the in-house server and labeled it B:\ for those that want to follow along. Servers running RAID is fine since replacing a bad disk may be done without turning off the server in many cases.

OK, the next step is creating the schematic, so here it is for the AC CHAN peripheral without the IT Core Platform interconnect just the off page connections since we will be adding to this as we perform the designs for the remaining peripheral controllers. We have not decided if this design would fit in a single larger package and allow us to add the remaining peripherals for the Core Platform. We will decide that as we continue on with the series. There are many times during a design that all the components seem to just fit into place and a single controller has the most advantages. Figure 14.7 shows the first pass of the schematic for the AC CHAN peripheral.

Figure 14.7 AC CHAN Schematic Capture Design

A/D Software Setup Flow Diagram
All this fun stuff designing now leads us to see if it still functions the way we expect. In order to do that we have to test the core functions of the COLD and in order to do that we have to simulate the programming and use the timing analysis tool that is part of the Quarts DE. We will put together a small flow diagram to test the AC CHAN COLD timing and functionality before proceeding. The setup timing test will only increment the memory address once and end the data collections in order to test the timing of the data transfer in the COLD. All the status signals are shown in the timing diagram Figure 13.6 A/D COLD Conversion To Memory Timing Diagram. To perform the test we simulate a program controlled Start Scan function.

PICTURE_ADC_CHAN_FLOWTEST
Figure 14.8 AC CHAN COLD Setup Timing Test Flow Diagram

SUMMARY:
There are many approaches to interconnect the a block of peripherals to a BUS architecture, we are at the beginning of the peripheral and it would be advantageous to wait until we have a few of the peripherals designed to see how they would interact with different BUS architectures before making that decision..

Thank you everyone for the encouragement and kind posts on this blog series. Our intent is to help educate the beginner and present a good review for design professionals of high quality design practices for developing product lines in today's multi-disciplined technical environment. With the advancement of technology many of the simple functions like data collection has become common knowledge. If we look at the various peripherals as different types of data input sensors just as the human body has sensors like touch,(pressure / temperature), smell , visual, audio and taste for those that would put something they are unsure of on their tongue. These human sensors are all fed into the central cortex and distributed to various parts of the brain, bio-chemical (not silicon) central processing platform to configure some sort of reality as to how the sensors react. The IoT Core Platform is no more than a controlled group of sensors or a data input platform to allow the data to be transferred and processed by a higher level of computational power. At the end of this the IoT Core Platform becomes as a single multi-functional component that may be applied to many unique control functions. However to get to that level we still have to adhere to the engineering task of developing the various parts of the platform which has many parts or projects to connect together.

The A/D Peripheral being just one small part of our platform, which emphasizes the necessity of an organized product development protocol. As we begin to answer the question "why an IPD system?" We see that incorporating a IPD system we can reduce the design time as well as have a unique way to organize the development multiple projects and combine them into one project at any time. All functions neatly organized in the appropriate folder with a easy Click'N'Open to continue the development process.

As the series progresses the author will be available for discussion for those that want to follow this series in detail and conduct their own experiments. Contact me directly through the BASIL Networks Contact Form. I will create a sub category for this series on unique questions and answers as not to be hidden by multiple post comments and difficult to recall.

Part 15 Preliminary Outline" A/D Channel Hardware/Software Design: -Continued

Creating Device Driver Flow Charts for the A/D peripheral operation.
Adding other features to the A/D Channel

Reference Links for Part 14:

Intel®/Altera® Quartus Download 9.1 sp2 from Archives

Intel®/Altera® Quartus Lite 18.x Download

Requirements Traceability Matrix (RTM)
Project Management
Mezzanine Board

Network Sorcery: http://www.networksorcery.com
The Internet Engineering task Force: IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Memory Segmentation
The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016)
Part 2 IPv4, IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016)
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application Continued-The Ethernet Protocol(s) (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application Continued-The CRC-32 and Checksums (Nov 27, 2017)
Part 8 IoT Core Platform& Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations (Jan 12, 2018)
Part 9 IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (May 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices -Peripheral Design From the Beginning (Oct 7, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)

Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-14 Peripheral I/O Design - Analog Input Peripheral Design - (Oct 29, 2018)

For Website Link: cut and paste this code:

<a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=19&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-14 Peripheral I/O Development:-Analog Input Perpheral Device Design (Oct 29, 2018)</a>

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through

BASIL Networks BN'B

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-15

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-14

Menu

Search

Calendar

Recently...

Categories

Syndicate