BASIL Networks BN'B

Part 17: IoT Core Platform Development;- Peripheral I/O Device Design
The IoT Embedded Core Platform -Peripheral Devices Real World Testing - Continued

"You cannot change your destination overnight, but you can change your direction overnight"   John Rohn (Sept 17, 1930  - Dec 5th, 2009)

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)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Feb 11, 2019)

Quick review to set the atmosphere for Part 17:
From the previous Internet of Things Part-1 through Part- 16 have brought us to this level of what we want in an IoT core Platform.  It has also brought us awareness of the needs for privacy, security and control of devices attached to the Internet and how easy it is to intercept various protocols and change data being transferred over the information highway.  From all the data breaches being published on a daily basis we see that the original design of the Internet still has a couple of shortcommings from conception.  One shortcomming is .... wait for it ....security!  We will be designing security into the IoT Platform from the start and not as an after thought to be added later.

Now that the basic idea and some of the different aspects of product development have been introduced, it is a good practice to document ideas and concepts as well as additions using the IPD system.  Using the RTM section to insure that as we develop each section there are guidelines and test cases to insure that all the pieces fit together.  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.

Technology has advanced at a rapid rate over the past 50 years that it becomes difficult to keep up with the technology, however what is interesting is that the level of  "common knowledge" has also increased from the use of the technological advancements.  This series is presenting some of the advancements that are now considered common knowledge in the society and to our series as we all do with common knowledge, without a second thought and us this common knowledge to explore other areas of interest and repeat the process.   Our intent is to make the peripherals interfacing common knowledge to be easily applied to any core processor and perform functions to experiment and collect data to advance science.

What we want to cover in Part 17:
In Part-16 we presented that  fact that we should address testing of the peripherals (Proof of Design) PoD with a prototype build to insure when we interconnect several of the peripherals the throughput required for the applications will be met.  This also put us in a position to change the development direction from the peripheral that we have to developing a test methodology that will be used for testing the remaining peripherals for the platform.  With that stated we will move forward with detailing the Interface Test Fixture (ITF), creating a schematic and PCB layout for the ITF, not all in this part though since it is a relatively large development.

Creating a new IPD project for the Interface Test Fixture to keep track of the development process. Good golly Miss Molly will the documentation ever end?  Maybe in the tinker toy lab, but not for a real product development!  Developing good engineering documentation habits comes with the territory, documentation is still in the picture and still important.

Setting up Requirements Traceability Matrix (RTM) for the test cases for the analog input.  Traceability during development covers all 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.

OK, we will not be able to cover all the following sections in a single presentation/part so we will break this down and present the ITF development in a few sequential parts for the series. Just a short change in direction, however a better validation to complete the objective.

Expanding on the ITF functional block diagram Figure 16.1 the following sections documentation will be created to incorporate into the Interactive Product Development System.  

• The CPLD, FPGA In Circuit Programming Model
• The Isolation Interface - Pros and Cons
• The BUS Interface and Control
• The BUS Expansion
• The Peripheral PoD Common Interface Architecture
• The ITF On-Board Memory Configuration
• The ITF Serial Interface Group  I2C, SPI
• The ITF Computer Interface Model
• The ITF to PoD Device Physical Interconnects
• SUMMARY

Lets Get Started:
The IPD Documentation - Developing Documentation Discipline
Remember changing direction overnight does not mean changing goals or the final destination, it is just a better way to insure you will reach them.  In my years of exposure to the design arena as a designer and mentor I have had the honor of experiencing innovative and passionate creators to realize that the thought process of creative passion is not a linear step function, 1, 2, 3 ...N, probably because humans are not robots, that follow a preprogrammed set of processes as some may think.  The innovation of the human mind subconsciously is always performing scenarios to find the best solution for the task at hand.

OK, when we were discussing this project the question came up, Why did you select to use two CPLDs in stead of just on FPGA?  These are the results of that discussion, to review what was stated earlier.  The first reason is we selected MAX line of CPLDs was purely out of the experience level over the years we have used them.  The second reason we selected Intel®/Altera® is the way Altera archives the older revisions of  software on their website, both by date, revision number and the chips supported.  Another factor that weighted it was the amount of resources required to use the latest release of the software of all CPLD/FPGA manufacturers.  

Inrtel/Altera new release with a 12GB local DRAM would not compile the AD-CHAN  MAX-II CPLD and ran out of memory for the timing diagrams.  All the older releases run on 8GB DRAM/4GB DRAM on the x32 systems easily while the latest release states up to 32GB DRAM or more.  

This would require the majority of small companies and entrepreneurs to purchase the latest and greatest motherboards that supports that amount of memory.  The majority of older desktop motherboards are limited to 16GB including the Graphics memory and many of the laptops are limited to 8GB that are only a couple of years old.  Another deciding point of using two CPLDs you double the number of I/O pins that should cover this ITF design easily and have some logic Elements to spare for feature expansion and design changes.

OK, a quick review of the documentation system we will be using, Yes again, Ok I'm sounding like management now, - so what does that all mean to this series?  This means that to assist this innovative development process that may change direction at times from one development task to another a tracking system should meet the following requirements.

1. Interactive - by second nature without thought
2. Flexibility - being able to record changes and additions in real time.  During development changes in one project can easily effect another project.
3. Multiple Project Tracking - This is where we are now - being able to start and track new projects that will eventually interact with the product development at hand, hence: the IoT Core Platform development project.
   So, lets give the ITF a Project name- Universal_Peripheral_ITF for lack of a better one.

Repetition is the mother of retention,  wait a minute!..., I think I read that somewhere before.

CPLD, FPGA In Circuit Programming Model:
Since we are using CPLDs only on this ITF design we will start at the In-System-Programming (ISP) configuration.  This looks like and generally is a simple connection to program a CPLD on an assembled product however, this becomes more complex when you have several products and test fixtures that you have to maintain and program.  What we have found through experience in the lab is over the years we ended up with over a dozen different ISP programming cables because we just made them up as we needed them and the PCB layout was different for each test fixture we built. Since we did not assign a fixed set of ISP pins each cable was unique and only worked for one design.  We have since then set a standard connector and pin assignment for all CPLD and FPGA designs as we will present.  

Each manufacturer has their own pin assignments for programming their chips with a JTAG or serial protocol that easily translates down to a simple interface connector.  For the JTAG protocol that handles the majority of chips we selected a standard micro six pin connector with a 0603 four resistor isolated SMT for the required pull-up/pull-down terminations.  There are a couple of manufactures that offer the mating connector in a ready made cable that may be plugged into the programming ITF to the UUT.  

Considering that the market is now thinning out through M&As this will make it easier to standardize on some interface configurations.  There are other programming modes designed into these devices as well which are used for more complex designs for testing boundaries and other elements within the FPGAs that are not covered in this part of the series since we will not be using any of them.  We will put on the table for discussion creating a new blog series to address FPGAs in the future.

The JTAG protocol In-System Programming consists of four signals with the two resource pins which are shown in Table 17.0 below.  The connector used in the lab is a 1.27 mm (50 mil) center dual row 2x3, 6 pin standard connector. The manufacture numbers are Amphenol 20021321, Samtec FLE-103-01-G-DV-K to name a couple.  Any connector type will work, however we picked the 1.27mm pitch for the size that seems to take up the least room and easily available from several sources and the cables are easily created even in the lab.

Table 17.0  CPLD  ISP Standard Pin Assignment for ITF Cable

Over the last few years, M&As have narrowed the major players in the Programmable Logic Device arena to Intel/Altera, Xilinx Inc., Cypress Semiconductor Corp., Lattice Semiconductor Corp.,  Microchip/Atmel for the higher visibility ones.  We will look at each of the programming configurations from these manufacturers programmers for the standard JTAG In-System-Programming protocol configurations and apply the individual connectors out to a standard interface translation cable.  All the above mentioned programmers have standard connectors that are available from several sources so the translation from the individual ISP programmers will not be an issue.   

We will place the standard connectors on the ITF main board and trace them out to specific programmer connector.  Since this is a "universal ITF" making it compatible to test other peripherals that incorporate different CPLD and FPGA devices from different manufacturers we will add the universal interface to address different types of JTAG programmable logic on the same UUT.  This will maintain a single ISP cable set for all the different manufactures and make designing these devices into the product more organized.  With the incorporation of the IPD system organizing and tracking all the different manufacturers becomes easier as we will experience.  Table 17.1 shows the pin assignments for each manufacturers JTAG programmer pin assignments allowing a single translator cable to program the CPLD/FPGA and how the PCB traces interconnects to the translation cable for each manufacture.

Table 17.1   Manufacture ISP Standard Pin Assignment for ITF Cable Pin Assignment

The next step is the isolation of the JTAG signal paths which are three inputs and one output from Table 17.0.  Generally the JTAG clock rate is dependent on the devices being programmed or tested., however, the clock has a range of 10MHz to 100MHz (100ns to 10ns per bit) and for most CPLD it is 10MHz nominal.  The digital isolation IC we selected is the Analog Devices ADUM241E1WBRWZ  which incorporates a transformer isolation methodology.  

We have a choice of using the UUT power through the ITF ISP connector or adding a separate isolated power supply for the UUT.  It is a good practice to use a separate isolated power supply for the UUT and use the UUT power for the isolated ISP through the ITF ISP connector.  The total power for the Isolation side of the ITF ISP is less than 40MA per connector and the ribbon cable short distance less than 24" should work fine.  We are able to get the SN74AHC125N  Tristate quad buffer in a real DIP package for a standard 14 Pin socket.  This allows for easy repair if the UUT fails.  Figure 17.0 shows the functional block diagram of the ISP section of the Interface Test Fixture.

Figure 17.1   Functional Block Diagram of the ISP section of the ITF

The control of the drivers should be isolated as well in order to insure a known off state for the UUT.  The discussion of remote CPLD code updates will be discussed during the security section since the CPLD programming functionality is already on-board it is just not connected to the UUT CPLD/FPGA.  

Some questions arise as to why we just use one ITF ISP connector for all the manufacturers and just interconnect the ISP connectors from each programmer?  Well, for us here at BASIL Networks our clients give us their preferred list of components including which programmable logic IC to use that they already stock, so as a policy we always look at ITF's as universal as to accommodate our clients.  The PCB layout for this section of the interface will take up a bit of PCB real estate, 8 connectors, 9 chips.  What we use here is a standard 4" x 7" PCB footprint for these interfaces that fits easily into a 4.5" x 8 x 1.5" enclosure either plastic or metal that gives a good size/function optimization for ITF devices.  We will cover this when we get tot he PCB Layout of the ITF.

The Isolation Interface Pros and Cons:

Manager:  We don't need isolation!
Engineer: Yes we do- period.
Manager - Convince me the we do.

OK, Why do we want or need and Isolated I/O interface on the Interface Test Fixture anyway?  Good question! and needs to be answered since we just went ahead incorporated isolation for the In-System-Programming Model above, so lets explain why.  The general consensus for custom test equipment development is to add isolation if possible to protect the ITF when the device under test fails or goes into self destruct mode at power-on.

Ok, so what about this case were it is all low voltage, 3.3Vdc and 5Vdc as well as low current?  Why not just go right into the CPLD interface?  Yes, we actually could go right into the ITFs CPLD, however if a failure happens that overdrives or shorts the UUT devices inputs / outputs that causes the ITF CPLD to fail then we have to replace the ITF CPLD.  You will only be able to replace SMT components a few of times before you have to replace the ITF.  

For the ISP programmers, the isolation chips are DIP socketed, yes, they still make DIP sockets that are throughhole and actual DIP packages to.  See, even some of the "old"/seasoned technology still has a place in the modern technology world.  So for the manufacturers ISP chip programmers it is recommended since we are also translating the signal paths to a common pin assignment for the JTAG programming interface.  Lets lisst the Pros and Cons for the case of isolation.

The Pros for Isolation -

• Test equipment protection from the UUT is the first consideration when setting up any test fixture.
• Noise and ground current elimination - There are times when the test equipment will add noise or other signal return paths that can fail or even pass the test process.  Isolation separates the UUT from any stray signals that may find it way to the UUT and compromise the test data being collected.
• For the Control lines it is always a good practice to isolate them.  The isolated control lines will balance out the delays with the data lines as well.

The Cons for Isolation -

• The first is data throughput speed.- Isolation generally incorporate delays which may compromise that actual throughput when the system UUT is attached to the actual application.
• The next con is balancing the control lines with the data lines to insure the simulation of the BUS will accurately emulate the CPU that controls the BUS  peripheral BUS.  This is one area that can cause software programmers a real headache if the BUS data and control lines are not synchronized properly.
• I/O voltage compliance - Insuring that the I/O of the UUT comply with the I/O of the ITF in order to insure data transfer integrity.  The selection of the I/O isolation chips are the key to proper I/O voltage translation.

Isolation Summary:
Ok, so are we going to design in Isolation? - the answer is yes.  Why?- well, for one this is a universal ITF and the IoT platform will be just one of the devices it is applied to.  One of the main reasons is this is an on-going educational series and we have the time to address many peripheral applications;  designing this for only one would be a short sighted design.  

So, we see from this ITF example of how a simple test fixture easily explodes into the universal ITF and adds more time and cost to the development schedule that was not anticipated at the beginning.  Another aspect is that since this is a separate project within the IPD system it would be easily updated as required for other applications and it will give us a real world experience through a some of the challenges faced during a development project.  

Moving forward to the actual design of the ITF we want to keep thigs as simple as required to address the tasks to be performed..  This is where risk management attempts to sway the technical group to change direction.  We will cover the isolation of the remaining section of the ITF as we address each of the sections.  There are many that think risk management is a PITA, however in reality if presented financially unbiased for the best quality of a product it is a great checks and balance mechanism. OK you may laugh, the author cannot see you or hear you, unless you put it in a comment.

BUS Interface Control:
The BUS control is an important part of the ITF for several reasons, one of which is that it will include some serial transfer protocols that we will also use for the peripherals for the IoT Platform.  Since we already have a 50 Mbps SPI interface on the A/D Channel design adding this to the control section is a cut and paste operation for the CPLD used in the ITF and we will look at higher speeds as well.

Figure 17.2 shows the Data I/O and Control portion of the ITF, initially we suggested a 32 bit BUS I/O, however since we decided to incorporate isolation the real estate of the PCB required increased which forced us to drop back to a 16 bit interface. The Isolation IC we selected comes in a few configurations that fit the remaining sections as well and is a four bit chip.  This yields 14 ICs for the isolation, three octal transceivers for the data and control for a 16 bit Data I/O and 8 Lines Control for the ITF.  

This brings up the question do we really need a 32 bit I/O bus?  From my experiments with 32 vs 64 bit Linux and windows, the speed differential is only a few percent faster and x64 bit does require more memory.  Since all virtual tasks in windows seem to follow under a 16 bit virtual environment when using Intel® processors a 16 bit environment seems to by in line.  We will perform some multi-processor, multi-task benchmarks for other processors after the series and if time is available, comments are welcome if anyone has already performed similar tasks.

Figure 17.2   Functional Block Diagram of the ITF Data I/O Section

The digital isolators are ADuM240E0BRWZ  four bits per chip and are SMT and may be put directly on the board since they are buffered by a bus transceiver chip as well.  The octal buffers use are industry standard SN74HC540N and available in real PDIP packages for use with sockets, several distributors stock these octal transceivers since they are commonly used in test equipment.  So as we see here adding isolation does add a few components to the ITF design.

The critical interface control of the ITF is the synchronization of the BUS and I/O strobe control lines.  Many of the embedded systems use software strobes that add delays that vary with the CPU clock speed used.  This is one of the reasons we will be looking at a hardware control interface for data I/O in order to use a variety of CPU's with various speeds.  Just the typical reasoning used to build a universal ITF with a hardware BUS interface structure.  

Risk Management -  The one issue that will always exists when test fixtures or test equipment enters the picture is that of risk management and the push to spend the least amount of money and resources on test instrumentation.  "Do not test now, redesign later"; over the years in product development we have experienced risk managements decision to forgo the test fixtures and go right to a manufacture build that ended up in costing the company an order of magnitude more than the actual products development costs due to having to redesign the product.  It is not uncommon even today with the new generation of risk management and the so-called "automatic test simulation and verification technology", all the more reason to proceed carefully.  One fact to keep in mind is that the test equipment may be used for other development or simply stay with the product manufacturing for the life of the product.  We have always found it less expensive and more reliable to build the test equipment for the product during development.

BUS Expansion:
The BUS Expansion is used for external devices for testing that are generally not part of the IoT Platform.  This would be another ITF device for special testing and data collection such as a special temperature cycle mechanism for testing over temperature while operating or a peripheral that requires external triggers to start the operation.  The Expansion BUS may also be used as a peripheral test status register.  It is an eight bit bi-directional bus that may be programmed at the bit by bit level.  Figure 17.3 below show the functional block diagram of the expansion section.

Figure 17.3   Functional Block Diagram of the ITF Expansion Section

Peripheral PoD Common Interface Architecture:
As we see the 16 bit Proof of Design interface has already lead us to a common interface bus architecture at least for the AD-CHAN peripheral.  However we are not limited to only one I/O architecture, this would depend on the peripheral we interface and if we use more than one CPU;  the CPU memory architecture incorporates a parallel architecture for instruction speed and memory management.  From our experience the trade off from a 32 to 16 bit I/O architecture is small and the 16 bit architecture is considered the "sweet spot" of peripherals for parallel I/O interfaces.

If we really need more speed then we can always turn to PCI-Express, however that does require FPGA support and in reality, it is just a parallel to serial to parallel type architecture that also has other inherent delays that are present in the PCI architecture.  The ideal is a direct parallel architecture which is a memory cycle pipeline transfer when using the I/O peripheral as a memory mapped I/O.  We will experience this when we move into testing the AD-CHAN peripherals on board memory which is similar.  The expansion part of the ITF emulates an extended memory address so we will be able to incorporate blocks of memory as a particular application may require. This opens the array of applications that the IoT Core Platform may address.

ITF On-Board Memory Configuration:
The ITF On-Board memory function is a nice function to have to test many data throughput conditions, however it is not an absolute requirement except for this series.  Since this is an educational series we will add it as a separate function on the ITF and synchronize it with the main Data I/O and Control Bus CPLD.  

High speed SRAM in the 10ns arena are easily available in the 1 Meg x16 bit single chip.  When you go to 2Meg or 4Meg x16 the price obviously increases but if you have the room on the board it may be better to just add the extra chips footprint to the PCB and add it as needed.  For testing A/D converters of 16 bits and under a 1 Megx16 is more than adequate and we will address this as we get to that section of the series.  Figure 17.4 below shows the CPLD and SRAM functional block diagram where the SRAM connects directly to the CPLD and does not require any buffers.   The memory IC we selected is IS61WV102416DBLL-10TLI 1Megx16 or the IS61WV204816BLL-10TLI  2Megx16 and are available from several distributors.

Figure 17.4   Functional Block Diagram of the ITF On Board Memory

ITF Serial Interface Group - I2C, SPI
The Serial I/O group consists of some basic I²C, SPI and QSPI interfaces that are not integrated into the ITF design mainly because they will be a separate USB interface in a separate fixture.  These interfaces are already integrated into the IBPD test system as part of the basic I/O modules.  We will cover those devices later in the series as we need them.

A brief overview of the use for each of these devices when developing the IoT Platform I/O are listed below. Data about these interfaces are saturated on the Internet and we are not going to add to the saturation experience.

• SPI - Serial Peripheral Interface - As we presented the A/D Converter incorporated a high speed serial interface that follows the SPI architecture
• I²C - Inter IC Bus - Many peripherals today especially some of the complex functions use I²C or SPI or similar serial interfaces for control and data transfer.
• QSPI - Quad SPI - This is used most with FLASH memory and uses four data lines to transfer data and control.

ITF Computer Interface Model:
Now that we covered all the IoT Peripheral side of the hardware the remaining part if the ITF is how do we connect it to the desktop or laptop computer to control and collect data?   The Interface that will control the ITF that we will incorporate into the standard IBPD system specifically for this series is a USB 2.0 COTS controller for simple testing and interfacing.  BASIL Networks will modify the core IBPD system to incorporate the drivers specifically for this series and will be offered free to download for this series after the ITF presentation is complete for those that are experimenting while following the series.  Schematics, PCB Fab drawings and CPLD code will also be available.

The interface selected is a simple USB to 16 bit standard computer interface architecture that is connected to the Memory Access Controller CPLD which may change as we create the schematic and assign pins to each of the CPLDs.  As each peripheral is developed the IPBD software scripts will be presented for downloading to complete the development process.

We have searched the Internet for a simple USB to Parallel bridge IC and found that the FTDI USB bridge device seems to be the industrial standard and includes software for Windows, Linux. This will allow an easy parallel port interface as shown in Figure 17.5 below.

Figure 17.5   Functional Block Diagram of the ITF to USB 2.0 Bridge

ITF to PoD Device Physical Interconnects:
OK, one last item for the ITF that we have to cover before diving into creating the schematics.  Since we are building Proof of Design (PoD) for several of the peripherals for the IoT Platform we should decide on a standard interconnect platform so we can just Plug'N'Play these peripherals without have to create separate cables for each of them.

This is an important area to consider since what we select may limit other type peripherals for being connected.   The suggestion here is to design in as much flexibility as reasonable to connect other peripheral PoD devices.  The ITF manual connections type is single wire Push&Connect terminals and a secondary connection using Flat ribbon cable connectors.  Ribbon cables are press fit connectors which are easily assembled in the lab and offer many advantages for connecting several peripherals on a single cable for testing.

The PTSA Series connector series is what we use here in the lab allows the use of prototype breadboards for smaller circuits and experimentation as well before jumping into a full PCB layout.  Our intent here is to present a universal ITF device that will be useful for several years of experimentation and development of peripherals that are not internal in the embedded processor ICs.

This brings us to the presentation of the ITF hardware functionality, the next part is to create the schematics and layout of the ITF and prepare the PCB's for fabrication.  So as a quick review Figure 16.1 is shown below that combines all the previous sections of the ITF.  It is easy to see how and why test instrumentation is a high profile area for discussion.  It sometimes entails more complexity than the product design since it has to test the critical parts of the design that will be exercised the most during an application.  The key area of test instrumentation is to insure that the flexibility is incorporated during development and that the rights to the ITF belong to and controlled by the designer and manufacture to insure some type of security for prevent counterfeiting of the design.

Figure 16.1  ITF Test Setup Block Diagram

SUMMARY:
It is obvious now that ITF will take a few parts to complete prior to moving forward with the I/O Peripheral development as was intended from the beginning.  Putting the process in writing gives us a better perspective of how a project easily takes of on tangents that are required to complete the development.  For the implementation of the ITF to the IPD Documentation system, the conceptual documents contain Part-16 and Part-17 to begin the process.

The never ending roll test equipment plays in project development is a critical part of the product development success.  To test and validate a project like the IoT Platform and its peripherals takes a deeper understanding of the core of the product than just the applications.  A example, the Smartphone is used by many that have no idea nor do they require that knowledge to design, develop and test the phone, however they are very well versed in using the device integrating it into their everyday life.

As we stated throughout this series, product development has many sections for a successful development and it is now easy to understand why test equipment is a high profile subject matter.  The cost of test equipment to test a product may easily exceed the cost of the actual product development in time and resources and should be evaluated carefully.  

Test equipment development is a project within itself and should be done in parallel with the product development to insure all the test performance issues are addressed accurately.  Test equipment physical interconnects main function is to allow the capability and access to test all functions of a product and of course accurately collect data for performance analysis.

A product development project does require parallel development of the IoT Platform and the ITF however, incorporating the IBPD system methodology we should only have to design the initial ITF interconnectivity once to cover all the remaining peripherals which makes the ITF a universal test device that enters the reuse category.  And.... not to mention that the Interactive Product Development (IPD) System allows us to maintain organization of all documentation at an independent project level to run several projects simultaneously.  No fancy names or complex software gymnastics, just a simple effective, efficient tool to assist the designer(s) through product development stages.

There are still a few more sections for the Analog Input peripheral that has to be completed which 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 peripheral devices that we would like to be configured as part of  the core CPU.  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.

Development is not a simple smooth road in a technology environment that is constantly changing and offering more flexibility and features introduced each year.  We have be able to address this rapidly and implement changes within a competitive time to market in order to obtain a market share.

As the series progresses the author, Sal Tuzzo will be available for discussion through the BASIL Networks Contact Form for those that want to apply this series to conduct their own experiments.  I will always be appreciative for the private comments sent through the contact form for suggestions and advice during the development of this series.  This is a growing opportunity for everyone entering into product development as well as a great review for us "well seasoned" in the field to just refresh our DRAM.

Part 18 Preliminary Outline" A/D Channel Hardware/Software Design and the ITF: -Continued

• Creating the Schematic for the ITF
• Creating the PCB Layout for the ITF
• PCB FAB drawings and ordering the ITF for this series.
• A link to download the IBPD System for this series.
• A review or the Successive Approximation algorithm used in A/D conversion
• Testing the A/D peripheral.
• Adding other features to the A/D Channel while finishing the PoD schematics for the ITF
• And more ....

Reference Links for Part 17:

ITF Selected Components

• Analog Devices ADUM241E1WBRWZ  3/1 configuration
• Analog Devices ADuM240E0BRWZ  4/0 Configuration
• Standard SN74AHC125N
• Memory 1024x16 10ns IS61WV102416DBLL-10TLI
• Memory 2048x16 10ns IS61WV204816BLL-10TLI
• PCB Termination Blocks PTSA Series

PGA281 Programmable gain Amplifier Datasheet
IS66WVE4M16EBLL 64Mbit (4M x16) Pseudo SRAM Datasheet
Alliance Memory AS1C8M16PL 128Mbit (8Meg x16) Pseudo SRAM

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)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Feb 11, 2019)

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-17 Peripheral I/O Design - Peripheral Devices- Real World Testing - (Mar 15, 2019)

For Website Link cut and paste this code:

Part 16: IoT Core Platform Development;- Peripheral I/O Device Design
The IoT Embedded Core Platform -Peripheral Devices Real World Testing - Continued

"Entrepreneurs are never satisfied. They want to do things better. They strive for perfection and use all the ingenuity to their command to achieve it." - J. W.  Mariot (Sept 17, 1900  - Aug 13, 1985)

For those that are interested in the stages of a design engineers life and mindset they are from birth to 10 years of age generally defined as "Stubborn ",  from 10-21 years of age generally defined as "Thick headed", from 21-40 years of age generally defined as "Strong Minded" and 40 years and older is defined as "Seasoned".  The Authors mindset is well seasoned.

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)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Dec 7, 2018)
Part 17 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Mar 15, 2019)

Quick review to set the atmosphere for Part 16:
From the previous Internet of Things Part-1 through Part- 15 have brought us to this level of what we want in an IoT core Platform.  It has also brought us awareness of the needs for privacy, security and control of devices attached to the Internet and how easy it is to intercept various protocols and change data being transferred over the information highway.  From all the data breaches being published on a daily basis we see that the original design of the Internet had and still has a couple of shortcommings.  One shortcomming is .... wait for it ....security!  We will be designing security into the IoT Platform from the start and not as an after thought to be added later.

Now that the basic idea and some of the different aspects of product development have been introduced, it is a good practice to document ideas and concepts as well as additions using the IPD system.  Using the RTM section to insure that as we develop each section there are guidelines and test cases to insure that all the pieces fit together.  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.

Technology has advanced at a rapid rate over the past 50 years that it becomes difficult to keep up with the technology, however what is interesting is the level of common knowledge has also increased by the use of the technological advancements.  This series is presenting some of the advancements that are no common knowledge to be applied as we all do with common knowledge, without a second thought to benefit from the application to explore other areas and repeat the process.   Our intent is to make the peripherals interfacing common knowledge to be easily applied to any core processor and perform functions to experiment and collect data to advance science.

What we want to cover in Part 16:
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.  Prior to the selection of the Core Processor some real world I/O is generally a requirement to all applications for real world communications.

A quick detour to present some of the new component developments since we started the series.  We will then get back into the analog input development and present some details of why we picked the Analog Input Peripheral as the first I/O development project.

More of the RTM for the Interactive Product Development System, OK,Yes-developing good engineering documentation habits comes with the territory, documentation is still in the picture and still important.  

Setting up Requirements Traceability Matrix (RTM) for the test cases for the analog input.  Traceability during development covers all 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.

We will answer questions sent in from our readers about the design.

• The Peripheral Assignments Set Detour
• The Analog Input Design - Continued
• The Analog Input PCB Layout
  • The Pros/Cons of Building/Not-Building a PoD Module
• Should We Just Go With The FPGA For The PoD Module?
• What Will The PoD Module Cost?
• Adding A Real World Interface On The PoD Module
• Interface Test Fixture (ITF) Pro's/Con's Summary
• BASIL Networks Interface Test Fixture (ITF) Approach
• The ITF PoD Device Interconnects
• 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.  It is a mind-set encouragement task 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 of processes.  The innovation of the human mind is always performing scenarios to find the best solution for the task at hand.

OK, so what does that all mean to this series?  This means that to assist this innovative development process a tracking system should meet the following requirements.

1. Interactive - by second nature without thought
2. Flexibility - being able to record changes and additions in real time.  During development changes in one project can easily effect another project.
3. Multiple  Project Tracking - being able to start and track new projects that will eventually interact with the product development at hand.

Repetition is the mother of retention

The Peripheral Assignments Set:
From when this series started till present day there have been several new Interface IC's introduced to the market that we should review with the expectation of reducing development time and of course adding new features that would leverage our market share, yes, we always keep in mind the "monetization" of our development.

• Faster 16 bit A/D converter and greater than 16 bit A/D converters
• Higher density Pseudo SRAM - dual stack vertically
• Multi-channel temperature sensor IC - 8 channels

We looked at the AD7124-8 temperature IC a while ago however they just released a update to the IC April; 2018.  This chip will allow 8 channels of temperature sensing with a typical sampling rate of 25 Samples Per Second per channel for a full 24 bit dynamic range.  The device is full integrated with  a 24 bit Sigma-Delta A/D converter along with a PGA all synchronized by the internal SCLK of 614.4KHz.  It is a one chip solution on a 32 pin LFCSP (Lead Frame Chip Scale Package) basically a flat-pack with pads on the bottom of the chip instead of pins on each side.   There is some support circuitry that is generally required, however for our application we would update the SPI input requirements to add a separate channel for this device.  The cost / performance makes this chip a good choice.  We will cover this when we get to that part of the peripheral design.

One of the questions that was submitted by a reader, Why not just use one of these chips for the Analog Input?  OK, the answer to put this to rest is that they are all low speed A/D converters and when you put a multiplexer in the front end you slow down the individual channel throughput by (A/D Samples/Second) ÷ (Number of Channels) along with no buffer.  Many of these chips are less than a megasample per second.  

The Analog Input Design Continued:
OK, so from the Part-15 we see that there is only one spare pin on the 100 pin CPLD and if we want the full 22 gain ranges available on the PGA we have to use the last spare pin on the CPLD.  So should we go to the next package up, the 144 pin?  Some history - when we designed this peripheral several years ago and released the design one pin extra was not an issue since we only had one of four gain ranges and that only took 2 pins as well as only having a one Meg x16 buffer so we had some pins to spare.  The new design incorporates new features which takes up more pins so to start do we want the full 22 gain ranges, the answer is yes, more gain ranges gives better windowed resolution of the input signal.  The cost differential for a 100 pin to a 144 pin is about 2x the cost increase, the FPGA is about 3 times the cost, however there is more flexibility as well with the FPGA than the CPLD.  This does not just end here, there are other avenues that we will address when we start to look at the other peripherals development and if there are spare pins on the FPGA for the several digital serial inputs to handle other types of sensor chips.

To show just how fast technology changes during a product development cycle, when we started this design the largest cost effective SRAM available was one Meg x16. Shortly after that the Pseudo SRAM was introduced as 2 Meg x16, shortly after about 12 months that size went to 4 Meg x16. The next generation and size was introduced in August 2018 by Alliance Memory, a 8 Meg x16 Pseudo SRAM.   Now the challenge comes with the way the addresses are setup to write/read the data, the first 16 bits are Address/Data multiplexed and the remaining addresses 16..21 are fixed.  There are other timing considerations to using a multiplexed address/data memory device for our A/D Channel design that we will cover later on in the series.

This means that it is not a true parallel asynchronous SRAM where address and data are separated.  So if  we want to add an additional 4 meg x16 with a single chip we have to redesign the CPLD to accommodate the access requirements or we can just add an additional 4 Meg x16 chip and it will only cost us one control line which at this time does not exist in the CPLD if we keep the 22 gain ranges.  The cost differential is relatively low enough as to go with two chips verses one, however there is a cost to assembling the boards since costs are directly proportional to the number of components that have to be mounted.  The FPGA or the 144pin CPLD is leveraging up to be selected.  Lets continue on.

The leverage with this design is that it has a older PoC and PoD that we pulled out of our design library for "reuse".  If this was not the case then the recommendation would be to build it separately as a single channel to evaluate and test the PoD (Proof of Design).  OK, entrepreneurs do not contradict themselves they just adjust the design to be better and since this is an educational series we will build the PoD.  It is always a good practice to build a PoD production intent or otherwise unless the circuit is so simple it would not be required, however when using CPLD's and FPGA's it is always a good practice to build a PoD engineering model to iron out component issues as well as manufacturing issues.  Performing a Schematic and Layout also gives a foundation of the actual size requirement for a single channel, the number of PCB layers that will be required, shielding of sensitive signals and impedance control traces etc. requirements.

• The Pros/Cons of Building/Not-Building a PoD Module:
  The pros outweigh the cons in an engineering point of view, and from a business management point of view it is about risk management whether to build a PoD or just go right into a production model and debug from there.  These two sides will always exist in any product development and have to be addressed together to obtain the best results.  OK, that means that management and engineering have to play nice in the same sand box.    Lets list the pros and cons both technical and managerial that follows.
  • Technical Side - Pros:
    Building a PoD prototype you get the opportunity to iron out design limitations along with testing different methodologies within the CPLD like different speed versions and test performances.  For the PSRAM component there are unique setup requirements for the device to get the optimum performance.  On the analog front-end, the A/D, buffer amp, PGA and support components, the layout for PGA analog signal paths are generally critical to noise when close to digital traces.  Depending how the analog front end is layed out one may make a daughter board to test different PGA devices for future development changes.  Since the design is from our library of re-used designs many of these parameters have been proven, however even if the design is copied a PoD is still a good choice technically.  Silicon changes with manufacturer revisions and the revised IC may yield different results. Documentation would be required, specifications, Requirements Traceability Documents, Test Cases etc. for either a Pre-Manufacturing test build or a PoD build.
  • Technical Side - Cons:
    The only con to building the PoD prototype is the time delay to manufacturing.  Building any PoD is time consuming due to the fact that test procedures have to be created, Requirements Traceability Matrix has to be created for the PoD and referenced when creating the manufacturer ready design.  It is not recommended to attempt a multi-chip layout to accommodate several different PGA amplifiers due to the interactive noise that the extra traces and pins may create.  It would safer to just create a daughter board with the least amount of pins to connect to the main analog input layout.
  • Managerial Side Pros- No PoD Build:
     The Pros for this risk is that the production level prototype works and ready to go and you saved money and time and are able to setup a production run.  There are designs along with talented individuals that have the experience to build production intent pre-release builds and if your company has this talent then it the risk is minimized. The documentation to build either a PoD or Production Intent build for traceability would be the same, the only saving would be in the PoD build time, testing is still required.  The build time for a PoD is usually a few weeks.
  • Managerial Side Cons- No PoD Build:
    The cons for this risk are several - first if it does not work then you are back in the PoD build arena.  Another con is if it does not work and you make changes the risk is performance characteristics from the previous change and another build has to be performed prior to production release.  The risks is building several production intent builds which puts you back into the PoD build arena.  Just to duplicate the above risk sentence - There are designs along with talented individuals that have the experience to build production intent pre-release builds and if your company has this talent then it the risk is minimized. I have worked on projects where management built over five production intent builds that the fix caused other issues.  Over the years BASIL Networks averaged two builds, the second being a production intent build from the initial PoD build.  OK, this was not always the case in the past and it took several years of practice to get to that level.

Should We Just Go With The FPGA For The PoD Module?
Using an FPGA and combining several of the peripherals in a single chip with out doubt gives a better cost breakdown per peripheral, however what we usually find is we get back into the same category that the embedded processor market is in by trying to add as many peripherals to the chip and then pin sharing.  Pin sharing also reduces access and throughput timing as we read from the data sheets of these devices.  Granted FPGA's with enough pins will be similar to a real PC BUS and allow full access in both DMA and Interrupt configurations to time slice the peripherals at the top speed of the BUS.  We are not ruling out the FPGA for the final pre-production run however, for the educational series we will go with the PoD build concept this time.  As we gain experience in building the platform we would then select the peripheral schema for the application and probably just jump into a FPGA and run.  Keep in mind that if this is a device that requires a strong security protocol then the manufacturing process mechanically has to be taken into perspective to insure physical tampering is blocked from getting the internals of the FPGA code.

What Will The PoD Module Cost?
The cost for the PoD build varies depending on the security to protect the design.  If this is a DoD classified design then the rules for building have to be approved by the DoD and a vetting process has to take place.  If this is a commercial not classified design then to protect the design to a relative level a local PCB fab house that you have done business with and established a trust relationship with fits the plan.  Below is a list of materials for the PoD build using the 100 pin CPLD that interfaces to a eight bit port for testing.  Here in the lab we use the IBPD (Interactive BUS Protocol Development) system since we have been putting it together for a while for this purpose.  It also gives us the flexibility to measure performance of the Analog input PoD.  OK, the price disclaimer! The estimated cost for the PoD is taken from the Internet from Octopart which in many cases lists several distributors, this in no way is an approval of any company or advertisement, it is for educational purposes only.  Every company has their own supply chain management mechanism in place and should price this accordingly.  The unit cost for a single PoD is under $100.00. not including the PCB.  We purchase 5 boards at a time from several Fast PCB fab houses in the USA for the commercial non-classified projects, that is about $150.00 door to door for a 4"x7" PCB 2 sided. and about $300.00 door to door 4-layer.  Any sizes below that would not be much less since the major portion of the pricing is labor and machine time.  This also allows space for additional experimentation added chips like the FPGA or Amplifiers.  The estimated material cost for the PoD single channel is under $150.00 with 4 PCBs to experiment with at a later time.  Our library for this design is a quad channel Analog input card with address and control expansion capability build in.

Adding A Real World Interface On PoD and Validation Modules:
The Schematic of the Analog Input Module has to be completed for the PoD by adding some type of interface to the real world to test it.   Well we are at the point to decide to use a standard desktop, laptop or embedded processor interface to test the peripherals we will be designing.  There are pros and cons in all designs and it is best to Keep It Simple and Save (KISS) method. Of course the last S has several words depending if the first attempt really failed and you want to make a point.   

Here is the authors point of view that has evolved over the years since each of these have been experimented with during the many development projects.  There is no "silver bullet" to guarantee the success of any development, even working from a working model.  When you transfer the design from a PoD to an actual production intent there are always issues to address.  The issue with any development is to be able to segment the different parts of the design and test them to get an empirical data of the devices input/output characteristics. This allows you to perform a system analysis on the performance as well as to interface to other devices and systems.  

• Desktop - Interface - Purchasing a PCI/PCIe DAQ Plug'N'Play card
  OK- We have a couple of desktop computers in the lab that we use for testing that contain third party DAQ cards.  They work fine and come with some general purpose software to access the boards features.  We used them for general purpose signal analysis, FFT and other analytical functions.  The boards are generally under $1500.00 and are available from many manufacturers.  OK for the actual application software to test the PoD peripheral is another issue, we cannot escape the fact that some sort of test software has to be coded to test the device.  Vendors supply general purpose application software and most supply a C library to write custom software for testing.  The boards we have came with a C library and source code examples however, this method still required some custom software for testing various projects under development in the lab.  Even if you purchase Data Acquisition packages and there are several on the market to choose from; chances are you still have to code some software that is unique to the Plug'N'Play card for your development project.  What we are now experiencing is that older PCI interfaces that were running on Windows 2000 and XP (Yes we go back that far) are no longer supported and a new board and software and PC as well would be required to upgrade.  This may not be that difficult for a small company with one PC however for larger companies that are caught in the middle this gets very expensive.

• Laptop - Purchasing a USB type general purpose DAQ interface from one of many vendors.
  OK- We have a Laptop DAQ that we used in the lab and when on the road for presentations to customers, however, traveling with these type of devices inside luggage is not advisable if you do not have to.  The application software is on a single CPU license and for the amount of time it is used, buying multiple licenses was not for a small company.  This is one of the main reasons we developed the IBPD system, the runtime license is perpetual and may be loaded on as many systems as desired "legally" and the software runtime designed to be stored on a cloud and accessed to run locally without going through an installation on the variety of Windows® OS's once installed on the server.  All data files collected may sent to the server or stored on the local laptop disk drive.  The IBPD system is not an analytical computational package it is a multi-function interface data collection system allowing a fast and repeatable test setup for collection test data.  Here in the Lab we have several analytical software packages to analyze data that is designed to do just that;  it is easier to develop confidence in a analytical package that is designed for mathematical analysis.

• Network,- Purchasing a Network DAQ interface from one of many vendors.
  OK- Now we enter the lab of today - the virtual network lab that all test equipment is connected to the network and accessed via a Desktop, Laptop, through the Internet.  We have a couple of network connected communication test devices here in the lab.  Granted the network access makes it much easier to communicate with the Data Acquisition, however you still have to have a hardware interface to test the PoD device.  The Network communications eliminates the direct Plug'N'Play Interface and the USB interface however, it does not eliminate the custom interface software to test the PoD or the separate interface hardware to connect the DAQ to the PoD device.

• Use an embedded processor selected for the IoT Platform - Quick Development Board from one of many vendors.
  OK- I know that many are looking to see just what processor we may use for this IoT Platform.  However before we spill the news lets just look at what would be required if we selected to go this route.  First all software for the peripheral has to be coded, this includes the test and application software since accessing the device with any embedded processor will be unique.  Testing in the future for multiple peripherals PoD will only function with the selected processor.  There is no guarantee that the high level code is transferable to any other manufactures platform   We have a few different Microchip, Atmel, SMSC rapid development boards in the lab along with the IDE (Integrated Develop Environment) systems that are supplied from the manufacturers to use there products.  The concern is that developing test as well as application software while developing hardware for the same embedded system becomes a risk for any upgrades or design changes that may interact with other parts of the system.  It is always a good practice to insure that peripherals perform separately prior to connecting them to a BUS architecture that is in development.

Interface Test Fixture Pro's/Con's Summary:
OK now that we see there is no easy way to address testing the PoD without some type of a custom interface.  Wireless was not mentioned as an approach mainly due to security, all test fixtures connected use a wired interface.  When we test wireless it is in a shielded area to maintain a fixed perimeter.   Ok, we easily see the pros and cons of the above approaches, however of all of them connecting to the main analysis desktop or laptop a wired network would be an advantage since we can collect data in the lab and do analysis in an office area or another area outside the lab.  USB devices have been banned in may secure areas and the IT department that maintains the controlled area PC's disable the interface in the OS to insure that they will not function if plugged in.   We are looking at a specific PCIe laptop ExpressCard interface card for Laptops specifically for the IBPD system.  The ExpressCard interface for a laptop allows much easier mobility for the next generation of the IBPD system.   Since the IBPD does include internal buffer memory the network interface would be the selected choice since all PC's today come with some type of internal network that may be hard wired.

OK, a bit of engineering marketing for BASIL Networks, PLLC - The IBPD system has a High Speed parallel I/O feature with a buffer, however it is only a couple of meg x16 bits at 10ns throughput.  So to address many of the peripheral requirements of the IoT Platform the IBPD system main controller will be undergoing a hardware update for this blog series.  The update will be a buffer from a single channel of 2 Meg x16 to a dual channel 16 bits each capable of 4 Meg x32 expandable to 64 meg x32 at 10ns throughput rate.  This will address the 32 bit processor series that we are also looking at for the IoT Platform.  The Engineering experience, it is easy to build one or two or even 10 of just about anything however, building 10,000 requires a stable design and project traceability and testing during development.

BASIL Networks Approach to Interface Test Fixtures:
Through the years of product development we have experienced many setbacks with special or custom interface test fixtures for the products we were contracted to develop.  The issue that stood out the most was the setup and repeatability of test when we were requested to make requested revisions to the design.  Prior to the changes we would setup the test to insure we were at a stable starting point prior to the revisions.  Well, this did create some issues since the test fixtures were as common as could possibly be and used for other projects.  The fixtures were also updated over time and when we set it up to repeat the testing of a previous product, well the results were different.  This directed us to question the definition of what our in house test system should incorporate to increase the quality of our product development, Reliability, Repeatability, Functionality and Time saving (R²FT) is what every test system should inherently be.  This brought us to the level of what it would take to develop a test system that allows a simple custom interface that may remains with the initial product development used for validation.  Using a fixed test interface fixture and keep it with the PoD products we were able to demonstrate the R²FT methodology.  To date we were able to develop inexpensive test interface fixtures connected to the IBPD system and maintain complete one step Plug'N'Play repeatability to the validated PoD and Production models.  We were able to keep the cost of the typical Interface Test Fixture (ITF) under $250 with standard connectors and maintain this with the product PoD and validation hardware.   We have found that non-standard connectors specified by some clients are very expensive, however, the cost of non-repeatable test results when having to setup a test with different hardware can easily exceed those costs.  This bring us to the Interactive Product Development (IPD) system that is part of the stable repeatability and P'N'P test setup, all development documentation and test documentation remain in a single accessible location.   OK, enough of the marketing sales pitch, lets put this together with real hardware designs.

What we came up with is an isolated digital interface that is capable of interfacing up to 64 bits data and 24 bits control capable of speeds up to 10ns capture and control through an FPGA and CPLD on board to any specified connectors since this board stays with the product development any connectors the customer desires may be implemented.  A functional block diagram of the test setup segments are shown below.

We will be designing several peripheral interfaces and it would be advantageous to have a general purpose test fixture to be able to just plug the peripheral in and test the design and performance throughput.  There will always be some sort of independent test fixture to test devices in development, this comes with the territory.  It is one of the areas that I have experienced in the 35 plus years designing products for manufacturers that is neglected "AND" ends up costing more time and money to fix issues that crop up during manufacturing.  Test fixture design is as important as the product you are designing and has to be addressed.  The difficulty is that it is better to address this during the development and with some innovation one can development a interface test fixture that will handle many different functions.  Hence: that is what our intent is here at this time.  It is one of the reasons we selected the Analog Input peripheral as the first peripheral to design.  From Figure 12.3 IoT Platform Interface Function Segment Mapping  that shows the different peripherals that we want to incorporate into the platform a Interface test fixture would be an advantage.   So, lets put together a functional block diagram with a little innovation that would make it easier to test these peripherals.  From the beginning we selected to use a parallel BUS architecture to communicate with the core CPU in order to get the maximum throughput from the processor as well as being able to incorporate DMA (Direct Memory Access) for the processors main core memory.

Figure 16.0  PoD  Interface Test Fixture  Block Diagram

The schematic for the ITF will include both an FPGA and/or a CPLD - The selection of the FPGA is with the Intel/Altera® Cyclone series and the CPLD is the MAX II, MAX10-FPGA series.  Any FPGA and CPLD series like Xilinx® etc. may be substituted if that is what the designer is more comfortable with.  The interface logic design is just aligning the right pins to functions within the FPGA and CPLD to meet the expectations of the PoD device.  For this series we selected the QFP (Quad Flat Pack) case outline mainly because it may be repaired in house manually. For pin assignment we have a 144 QFP (89 I/O pins ) the CPLD is similar for I/O Pins and the QFP's are standard packages.  The initial design used the Cyclone FPGA which is obsolete and was selected because it used a 240 pin QFP.  The devices available in a QFP seem to stop at 144 pins and limited to a smaller series.  Using BGA's requires an outside assembly house to assemble and repair if necessary so keeping this as an in house build for the entrepreneur and small company seems appropriate for an educational series. The FPGA is MAX 10 10M08SCE144A7G  with 101 I/O and will handle from 1.25V I/O to 3.3 V I/O to cover all the types of interface devices.  The FPGA is MAX 10 10M08SCE144A7G  with 101 I/O and will handle from 1.25V I/O to 3.3 V I/O to cover all the types of interface devices.  The programmable logic device market share has been changing with the Microchip acquiring Atmel and Intel acquiring Altera and Xilink and Lattice Semi holding it's own.  The CPLD's and FPGA's we used several years ago are no longer available and since the M&A's the inventory is also thinning out.  This means it would be a good practice to use some of the modern IC's for the test fixture.  We also looked at Quartus Prime Lite - the memory requirements will work for many if we use the MAX II or V series and would work with about 2 to 4 GB RAM.  If we go to the higher FPGA's we would need up to 32GB RAM, yes- 32GB RAM.  This puts many students and beginners outside the resources available at this time.  We even run older systems here that have a max of 16BG RAM allowed on the main board.  

The ITF  PoD Device Interconnects:
For those who were curious on why we picked the Analog Input peripheral to start, well it has the most interconnections and the most components external to the FPGA and/or  CPLD which ever we select as the final production device.   The original reuse Analog Input device was originally designed over 10 years ago incorporating a byte wide I/O BUS using a parallel 16 bit SAR A/D converter and 65535 x16 static RAM buffer.  So we modified this design a few years ago to accommodate the updated embedded processor market and added a much larger buffer.  With that stated this is a good time to discuss just what type of peripheral BUS architecture we want to have on the IoT Core Platform.  Yes, we did discuss this before and selected the 8 bit BUS architecture to get things moving along, however since this is a new development project we do have options to change as we develop, that is what development is all about- being able to adjust to the times.  Many embedded processors have a 32 bit core with a varying I/O BUS architecture, 8/16/32 to address many applications.

Since we separated the I/ O Peripherals from the core CPU and decided to make adding the peripherals P'N'P devices as required by the application hence, a micro version of a desktop where we just plug in a peripherals or connect them via a BUS connectors or cable or even wireless to the Core CPU.  Interconnecting the variety of peripherals now requires us to address the core CPU I/O BUS interconnect scheme and how we are to test the performance of any peripheral added.

The Interface Test Fixture (ITF) interconnectivity is a critical part of a successful product development and it is one that the industry always tries to risk manage out of the picture building test system due to the time and expense involved.  For all us seasoned designers we have learned not to lose any sleep over it however we do insure that accountability for the SNAFU of testing is assigned appropriately.

We have to decide on the type of connector to put on the ITF to accommodate peripherals.  Our intent is to be able to create any type of peripheral that may be connect to any embedded core CPU type.  The embedded market is changing and there are many types of embedded systems out there to choose from.  The market is also thinning out as we discussed to make room for the next generation.  The M&A transition always happens prior to the next generation of technology in order to filter out the players that are not interested in staying in the game.  So as designers we have to remain as flexible as possible to remain in the competition and avoid the headaches of redesigning a product due to obsolescence.  As we stated in the previous parts, peripherals are best kept separate for the embedded system in order to take advantage of the changing embedded CPU technologies.  The other advantage is that sensor and input devices by design have a longer life time cycle in the industry than CPU's of processors and address the embedded market arena naturally.

OK, to start the ITF interconnection design expectation is that it will handle 8/16/24/32 bit high speed data transfers, so we can leave the design as is or as an option increasing the peripheral I/O to a 16 bit BUS architecture for the core CPU instead of the eight bit byte architecture.  While we are at this level and the design is still just a paper design lets investigate the pros and cons of increasing the I/O BUS width from eight bits to 16 bits.  There are a few questions that arise immediately with this investigation of change.

• Why do we want to go through this exercise?
  Because it is always good to cover possibilities and options during the design process before any physical hardware is built.  Also when ever a re-use part is introduced to a project the review will bring up new questions.  The main reason is this is an educational design series and if I trimmed all the what if's out of the process it would not represent a real life process.

• Will we have to go to an FPGA or stay with a CPLD?
   That depends on how we want to integrate the I/O devices and how many others will fit in a single FPGA.  It is a Price/Performance decision.  Generally it is a good idea to keep the analog I/O peripherals separate from other peripherals since adding more channels would be more efficient and easier.  Even if we stay with the CPLD and move to the 144 pin the number of I/O pins will determine the device for the peripheral at the end game.   What we will see is that the determining factor for all FPGA's and CPLD's end up being a pin requirement to obtain the functionality of the device.  The number of  I/O pins for the 100 pin TQFP device is 76 and the number of I/O pins for the 144 pin TQFP device is 116.

• Will the 16 bit BUS architecture have a faster throughput rate?
  This is a good question - By default the 16 bit BUS requires one Read or write cycle to get two bytes; the byte BUS will require two reads or writes to produce the same results, therefore by default the 16 bit BUS throughput is faster by design.  The issue is the PCB layout and will the number of traces require more room therefore requiring a larger area PCB or more layers?  We will see this at the time of the layout process.

• How will this effect the software/firmware?
  The firmware would be simpler if we went to a 16 bit BUS architecture.  This would effect the initialization, data collection setup, memory data retrieval and control.   All in all a 16 bit BUS architecture would be faster for read/write access.

• What will be the cost differential?
  We will look at the cost differential when we actually design the new architecture.  We would be going to a 144 pin CPLD that also would allow us some room to even add a second channel A/D and Memory.

• What about a dual port memory for real time R/W of the buffer?
  At the time of the initial design and the redesign for re-use we did not consider a dual port memory since the main application did not require real time R/W while data is being collected.  However this is a possibility to consider in today's fast data transfer world.  However, the current 100 pin TQFP CPLD design is not capable of a dual port design due to pin limitations.  Moving to a 16 pin BUS architecture may accommodate this with the 144 pin TQFP.

So before we go off on a tangent lets just look at the throughput required to transfer the entire four Meg buffer into the CPU core memory for analysis or just transferring the data to the real world over the network  The typical assumption of a network data transfer is that the processor and memory runs an order of magnitude faster than the network traffic at least for the desktop and Laptop devices, Our IoT Platform core CPU expectations is that it will have at least a 200MHz clock rate and a 100MHz from side memory BUS.  The process is to just transfer the four meg x16 A/D Channel memory into a core CPU accessible memory in order to transfer it over the network, thus making the A/D channel ready to collect more analog input data.  

OK, collecting data a the maximum sample rate of one microsecond would take four seconds to fill the four Meg x16 buffer.  Here is where some internal understanding of the architecture of the selected embedded core processor is required.  All embedded processors are not created equal, all for silicon equal rights :).

The process of transferring I/O to core CPU accessible memory does have similar process steps which are 1. Read I/O port memory data,  2. Move I/O data to core CPU memory.  This requires at least two full data transfers and in some embedded systems three to four depending how the I/O architecture is characterised, so lets take the worst case four steps.  For a 200MHz core CPU the I/O instruction time would be about 40ns per instruction, therefore 40ns x 4 instructions = 160 ns per memory location resolves to 4,194,304 x 160 x10^-9 = 0.6711 seconds.  This time would at least double for an 8 bit BUS I/O architecture.

So that means that we may collect four meg x16 blocks of data every 0.7 seconds for a 16 bit I./O architecture or 1.4 seconds for an eight bit I/O architecture on average until we run out of local core memory.  Transferring four meg x16 bits of data in a stream protocol over the Ethernet will take at least .7 seconds to transfer each word to the Ethernet controller plus the time to transfer each word through the network and acknowledge the transfer.

So the question is will a maximum of .7 or 1.4 seconds for a block of 4 Meg x16 be sufficient for the majority of application? Or another way to ask, how many real world applications would that throughput fit or fail?  We have time to think about this and look up some IoT control applications.  Either way we should look at a 16/32 bit I/O ITF interconnect to characterize the performance at the full speed of the peripheral.

The Interface Test Fixture:
At this point we are able to understand how the development of  "test equipment" can get out of hand especially if the test system requires additional custom interface software and other special development.  This is one of the reasons that management looks at a risk management approach when it comes to test fixtures.  Over the years we have been on both ends of the track when developing test equipment especially when the validation requirements adds cost to the test fixture to prove the validation requirements approach and sometimes exceed the cost of developing the product being tested.  

OK, it is not all that bad says the optimist , it really is not that bad.  Technology advancements have made it possible to create test equipment with a new philosophy that we will present here which is what we use here is our solution to test fixtures we use during product development that is inexpensive enough to actually keep the ITF with the product development for the duration of the products life even after it enters production.  The expectations of the ITF for this series is to be capable of collecting validated data for analysis to insure the features and functions of the Unit Under Test (UUT) meets the design and marketing performance.  

Today's test interconnects are mainly data collections mechanisms for off-line data analysis, unless the analysis is capable of being performed within the ITF.  So, to eliminate the risk management equation, we are presenting a methodology that we have used here for many years which we have incorporated into a  test system that is programmable, inexpensive and flexible to interface any test fixture.  This is the Interactive BUS Protocol Development (IBPD) System that we presented earlier in the series for the entrepreneur and manufacturer can incorporate into their development strategy for a cost effective product development mechanism.

To give this series a better purpose we have decided to integrate a COTS USB interface with a special driver for the IBPD to be used for the Interface Test Fixture for all the peripherals being developed in this series.  The basic IBPD core is available for download at this time and the intent is to have the IBPD driver for the ITF ready for download by the next few parts of the series along with the FPGA and CPLD configuration files prior to the building of the PCB for the ITF.  OK, keep in mind that the ITF is a product development and we have a choice of making it part of this IoT Platform project or creating a separate project.  The choice for us would be to make the Interface Test Fixture a separate IPD project for reuse since it will end up as a universal test fixture for many other projects down the road.  

OK, another marketing plug; Running multiple projects with the Interactive Product Development (IPD) system keeps track of all the details of each project and allows us to interactively manage document changes in real time.  Wow - too many acronyms, well there are not that many new ones however, we will put a list together for this series in the summary for reference throughout the series.

Creating The ITF Hardware:
The ITF PCB at this time does not exist for this series, so for a sense of reality in the product development environment we will develop the ITF in line with the PoD Analog Input peripheral.  Designing a new product is challenging, designing in testability is even more challenging since the Interface Test Fixture becomes part of the product design responsibilities.  Who better to design the ITF than the individual that designed the product!  We have other test fixtures here in the lab so we would not be starting from scratch.  Figure 16.1 ITF Test Setup Block Diagram below shows our expectations and what we will be putting together for the IoT Peripherals ITF.

Focusing on the first peripheral development PoD interconnects selecting a connector set to interface the PoD is important since it has to meet the speed requirements of the peripheral in order to validate throughput expectations. For this design series we selected the old industrial standard IDC ribbon connector, they are inexpensive and readily available, we have used these type cables at speeds up to 10ns for short runs of shielded flat cable.  We will design the ITF interconnection connectors for a 8/16/32 bit I/O system and complete the pin assignment for the PoD PCB.  The 144 Pin TQFP FPGA and CPLD interconnects to the isolation block should be sufficient to handle just about any type of peripheral communications between peripherals and the IBPD System.  Since this is going to be used to test a variety of peripherals incorporating a buffer memory on the ITF would be a good to test full speed performance of the Unit Under Test (UUT).

Since we are addressing high speed performance with the ITF incorporating a high speed static RAM in the 8ns to 10ns speeds are suggested since they are readily available in four to 16 megabyte sizes and are COTS.  This does sound like an over-kill, however it is a one time cost and if you build one for engineering development and one for manufacturing the product transfer to production will be much smoother and increase the quality of manufacturing especially when a good reference is available to shorten production test times.  Our Analog PoD schematic will move towards completion when we get the ITF interconnects completed.

OK, it is easy during the development process to go on tangents and lose focus on the product. That is one of the reasons companies have an engineering department and a test equipment department, oh FYI - that does not guarantee success of the product and in larger companies engineering test fixtures take a back seat to manufacturing production test fixtures.  Our approach covers both the development and manufacturing which may be automated to start on demand as well as having separate test scripts for each manufacturing stage.

Figure 16.1  ITF Test Setup Block Diagram

SUMMARY:
Wow, here we were thinking we would just design the Analog Input peripheral and be done.  As we see test equipment plays a key roll in the performance testing and validation for the peripherals.  Test equipment development is a project in itself and should be done in parallel with the product development to insure all the test performance issues are covered.  This does entails parallel development of the ITF however, with the IBPD system methodology we should only have to design the initial ITF interconnectivity once to cover all the remaining peripherals.  Test equipment interconnects main function is to test all functions of the product and of course collect data for performance analysis.  

There are still a few more sections for the Analog Input peripheral that has to be completed which 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 peripheral devices are to be configured to the core CPU.  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.

We will without doubt come back here as we build and test this peripheral.  Development is not a simple smooth road in a technology environment that is constantly changing and offering more flexibility and features a few time a year.  We have be ale to address this rapidly and implement changes within a competitive time range to obtain a market share.

Keeping track of multiple projects methodically and allowing interaction to update in real time is a challenge the has been addressed in the lab over the years that evolved into an Interactive Product Development (IPD) System.  No fancy names or complex software gymnastics, just a simple effective, efficient tool to assist the designer(s) through product development stages.

All companies have some sort of management development system, however for those that realize that their system is not able to handle the growing demands, call us to talk about tailoring our IPD and IBPD system to meet your needs.  Each part of this development series demonstrates the advantages of interactive development tools as the IBPD and the IPD system as we implement these tools for each stage of the IoT Platform development stages. All functions neatly organized in the appropriate folders with a easy Click'N'Open access to organize and track the development process.  

As the series progresses Sal will be available through the BASIL Networks Contact Form for discussions for those that want to apply this series to conduct their own experiments.  I want to thank all the readers for their comments of encouragement and letting me know their appreciation for this publication.

Part 17+ Preliminary Outline" A/D Channel Hardware/Software Design and the ITF: -Continued

• A link to download the IBPD System for this series.
• Adding other features to the A/D Channel while finishing the PoD schematics for the ITF
• Creating the ITF schematic and PCB layout
• PCB FAB drawings and ordering the ITF for this series.
• Creating Device Driver Flow Charts for the A/D peripheral operation.
• And more ....

Reference Links for Part 16:

PGA281 Programmable gain Amplifier Datasheet
IS66WVE4M16EBLL 64Mbit (4M x16) Pseudo SRAM Datasheet
Alliance Memory AS1C8M16PL 128Mbit (8Meg x16) Pseudo SRAM

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)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Dec 7, 2018)
Part 17 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Mar 15, 2019)

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-16 Peripheral I/O Design - Analog Input Peripheral Design - (Oct 29, 2018)

For Website Link cut and paste this code:

• Main
• Archives
• Albums
• Links
• Admin

• Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-17
• Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-16

• BN'B Posts Q&A All Categories [4]
• General [0]
• Manufacturing [0]
• Product Design - Hardware - Theory & Practices [0]
• Product Design - IoT Hardware/Software [17]
• Product Design - Software - Theory & Practices [0]
• Security - Computer Forensic Science - Cracking/Hacking [0]
• Security - Network Cybersecurity, Policies & Human Behavior [0]
• Security - Product Development General [0]
• Security - Product Development Hardware/Software [0]
• Technology & Law - IP, Trade Secrets, Copyright, Patents [0]
• Technology Consulting, Contracts & NDA's [0]

• RSS 0.90
• RSS 1.0
• RSS 2.0
• XML