Timer16 and ScaledTimer16 classes updated
Peter Verkaik
Posts: 3,956
Hi,
I have updated my Timer16 and ScaledTimer16 classes because of a strange error I detected.
The original Timer16 class extended the Timer class (which extends the Virtual Peripheral class).
In a recent project I had so many Uarts that I had to stop and start these only when required.
It appeared I could only start 5 vp's and now I finally found out why.
In the attached images you see some static fields.
The sysTimer is the first VP and installs in vpBank 0x80 as it should.
The ledTimer is the 2nd VP but since it is an extended Timer its vpBank is NOT_INSTALLED (-1)
which is also correct.
When you look at the stamp.core.Timer fields you will see that its vpBank is set to 0xB0
which is INCORRECT, because the sysTimer object is never stopped and so it should be 0x80.
Also notice the fields are ScaledTimer16 fields.
Finally the fields stamp.core.VirtualPeripheral[noparse][[/noparse]3]
These are the same as for stamp.core.Timer
Conclusion, apparently the ScaledTimer16 class, although an extended Timer object, somehow
installs itself in a different rambank then the first Timer object.
I noticed this never before because I never had to stop and start VP's so frequently.
In the updated classes the Timer16 class no longer extends the Timer class.
Instead I have defined a static protected Timer object, that is used to have access
to the Timer methods tickLo() and tickHi().
With these updated classes I found that stamp.core.Timer field vpBank remained at 0x80 as it should.
The updated classes Timer16.java and ScaledTimer16.java are here:
http://tech.groups.yahoo.com/group/JavelinCode/files/Javelin%20Stamp%20IDE/lib/stamp/core/
regards peter
I have updated my Timer16 and ScaledTimer16 classes because of a strange error I detected.
The original Timer16 class extended the Timer class (which extends the Virtual Peripheral class).
In a recent project I had so many Uarts that I had to stop and start these only when required.
It appeared I could only start 5 vp's and now I finally found out why.
In the attached images you see some static fields.
The sysTimer is the first VP and installs in vpBank 0x80 as it should.
The ledTimer is the 2nd VP but since it is an extended Timer its vpBank is NOT_INSTALLED (-1)
which is also correct.
When you look at the stamp.core.Timer fields you will see that its vpBank is set to 0xB0
which is INCORRECT, because the sysTimer object is never stopped and so it should be 0x80.
Also notice the fields are ScaledTimer16 fields.
Finally the fields stamp.core.VirtualPeripheral[noparse][[/noparse]3]
These are the same as for stamp.core.Timer
Conclusion, apparently the ScaledTimer16 class, although an extended Timer object, somehow
installs itself in a different rambank then the first Timer object.
I noticed this never before because I never had to stop and start VP's so frequently.
In the updated classes the Timer16 class no longer extends the Timer class.
Instead I have defined a static protected Timer object, that is used to have access
to the Timer methods tickLo() and tickHi().
With these updated classes I found that stamp.core.Timer field vpBank remained at 0x80 as it should.
The updated classes Timer16.java and ScaledTimer16.java are here:
http://tech.groups.yahoo.com/group/JavelinCode/files/Javelin%20Stamp%20IDE/lib/stamp/core/
regards peter
