What's new in version 6

• Overview
• Declarations

• Function Hierarchies
• I/O Exposed
• Signed Numbers

The primary difference is in the hierarchy of the objects. 

In the versions up to 5.0, the objects existed as flat data.  That is to say that all the properties that an object used were encapsulated within one layer and that all the properties were simple values.

For example, the object oDCMotor included properties for controlling a DC Motor and properties for controlling the H-Bridge needed to drive the motor. Having all the components for controlling a motor encapsulated in a single object proved to be an advantage over non Object Oriented languages.  However, it still required the programmer to understand how the H-Bridge controlled the motor.  In addition to the components of the H-Bridge, the PWM components which are also needed to control a motor were present as well. Yet again, the programmer was required to understand how the PWM controlled the motor. The result was a list of properties that controlled all the components needed to drive a DC Motor. See the list to the right.

}Value <-(PWM property)  }Brake  }Direction  }InvertOutB <-(HBridge property)  }InvertOutD <-(HBridge property)  }IOLineB  }IOLineD  }IOLineP  }Mode <-(HBridge property)  }Operate  }Period <-(PWM property)  }PreScale <-(PWM property)  }Unsigned

In version 6.0, the objects have been reorganized into functional hierarchies.

Compare the version 5 oDCMotor property list to the one in the new version 6 compiler:

The second thing to notice is that all of the properties are objects.  (Objects that you can use in your own programs.)

The third thing to notice is that the properties that controlled the H-Bridge and the PWM are no longer on the list.  Instead there is an object called H-Bridge in the list.  It is an H-Bridge object. Like the oDCMotor object, it has its own set of properties.  The properties that controlled the H-Bridge are now in its property list.

Notice that there are more properties listed here for the new H-Bridge object than were listed for the H-Bridge functions in the version 5 oDCMotor.  With all of the H-Bridge functions encapsulated in an object, the H-Bridge is now a complete object that can be used in your program.  Also notice that all of the properties are in terms that directly relate to the H-Bridge itself.

Within the H-Bridge Object, notice that there is an object called PWM.  Yet again, the PWM functions have been encapsulated into a self contained and complete object that you can use in your programs.

The hierarchical arrangement provides a simplified approach to the top level object while providing greater control of the minute details.  For example.  When an oDCMotor is created, it automatically initialized all the properties of the H-Bridge Object for you.  The H-Bridge automatically initializes all the properties of the PWM Object as well.  All that is absolutely necessary to get the motor to operate is to interact with the top-level properties.

As for the other properties that are no longer on the top-level, each property associated with a particular function will reside within that function, therefore eliminating the confusion of what properties control what functions.  For example, if you wanted to change the Prescale property of the PWM that is being used by the H-Bridge that is being used by the oDCMotor Object, you simple drill down to it.

Motor.HBridge.PWM.PreScale = NewValue

In such a statement, you are literally specifying which sub function of which function you are referring to which increases the readability of your program.

In version 6.0, the I/O functions used to control specific hardware devices have been exposed.

As an example, the Hamamatsu UVTron Flame Detector is a popular choice in hobby robotics.  In the ooPIC environment, this object can be used with ease.  You simply declare that you want to use it and it works.  There is no need to know anything else.  While this is all good and well, the I/O function used to read this sensor might be useful in other applications as well.  Therefore, in version 6, its I/O function is exposed.

Like the oDCMotor object, which uses an HBridge to do the I/O, the Hamamatsu UVTron Flame Detector's I/O has now been encapsulated into its own object and can now be found in the property list of the UVTron object.

Here we see that the UVTron uses a low-speed timer to read it.  An oCycleTimeL Object named "Timer" to be specific.  A closer inspection of the oCycleTimeL object's help page tells us that it is capable of calculating the approximate frequency of a square wave.  In addition, it points us to other objects that also use this timer.

	Object	Description	A1	A2	B1	B2	C1
	oSpeedOMeter	Reads a Speedometer.			x	x	x
	oUVTronHM	Reads a Hamamatsu UVTron Flame detector.			x	x	x

As listed, the oSpeedOMeter Object uses the oCycleTimeL Object.

Do you see a similarity to the UVTron?

Like the UVTron, all of the hardware specific objects now have their I/O functions exposed. 

For a second example, the oJoystick Object uses the oOrbitSwitch4 Object to do the actual I/O required to read the joystick.  A closer inspection of the oOrbitSwitch4's help page tells us that it reads a group of 4 switch inputs arranged in a circular fashion and calculates a value based on which side of the circle the switches are closed.  It also shows us some objects that use this function.

	Object	Description	A1	A2	B1	B2	C1
	oBumper4	Reads a 4-contact bumper.			x	x	x
	oCompassDN	Reads a Dinsmore 1490 Compass.			x	x	x
	oJoyStick	Reads an Atari style joystick			x	x	x

Notice a similarity of four switches arranged in a circle in these three objects?

It should be noted that there are several "new" objects which have been introduced in version 6. Yet these objects are not technically new.  They are just new encapsulations of I/O functions that were always there, providing the I/O for the hardware objects.  The Object List now includes all of these "new" I/O function objects.   

In the ooPIC Version 6.0 Compiler and in combination with Firmware Version C, signed number support has been enhanced to include signed variables.  Signed numbers are also reflected in a more robust C language implementation.  For instance, the syntax "Signed Byte a;" is now legal.