Rayman, there is a convenient fix! Since there was an inch that didn't get used along the X, I just shifted the hole thing over and the usable graphics area wraps back around to the far right of the screen, allows access for graphics now at both extremes. This will ultimately need to be solved, even if going back to bit maps. The last thing is how to change the circle color only to red or green.
Todd, the NH4 has a different kind of backlight control (PWM) than the PSB from which the code examples were adapted.
Plus, the PWM control wire is not even connected when using a Prop Platform board (it's in the place between GND and P31).
So, you'll need to connect PWM to a Prop Pin and then add some code to run PWM on that pin...
I probably should add PWM to the driver, but I don't think I've done it yet...
I see that the Prop Platform boards are not available at the moment. Is there anything else off the shelf that has the same pin-out for easy connection to the NH4? I am looking for a short term quick solution with a Prop, access to 8 pins for i/o, plus the NH4, 5v in, no larger than the Prop platform(no more than .5" wider).
Maybe, but I am using the screen flipped 90 degrees, so I am not using any 'print' characters. But mask works perfect, and since I have to create a bitmap for every phrase, it is easy just to mute the text layer and export a blank bmp, convert to dat.
PUB WaitFingerUp
'Wait for finger to be up
repeat
w(1_000_000)
'i2c.GetCapTouch ' doesnt work well
if i2c.GetCapPoints==0
return
i2c.GetCapTouch 'this works great
Ray, I have found the above to work much better. In a method where there is a read at the top, and I want to trap the finger press at the bottom to avoid repeated detections of the same key, I was getting bad results. Maybe this is something to test for yourself. With the original version, I was getting what looking like missed key presses about 50% of the time. The new method allows sure fire presses very rapidly.
I have problem trying to use the PASM_i2c_driver on an EEPROM on pin 28. The minimali2cdriver works fine on the EEPROM while the NH4_LcdDriver is running. I am certain that at some point in the past I have seen the PASM version working, but on a new board version it will not work. I have tried using the PASM driver with and without the start and stops, the minimal i2c driver works with start and stops but I think I header Dave Hein say the PASM version does not require them. I suppose the option is to hack the new board and use different pins on the LCD but was hoping to find out if it were possible by some way to read and write the eeprom while the LCD driver is running also.
I think the NH4 I2C driver is SPIN only using the main cog... So, just doing a DIRA[28..29]:=0 anywhere should tristate the I2C pins and allow the PASM I2C driver to work...
Comments
GraphicsYOffset=0
Rayman, there is a convenient fix! Since there was an inch that didn't get used along the X, I just shifted the hole thing over and the usable graphics area wraps back around to the far right of the screen, allows access for graphics now at both extremes. This will ultimately need to be solved, even if going back to bit maps. The last thing is how to change the circle color only to red or green.
Plus, the PWM control wire is not even connected when using a Prop Platform board (it's in the place between GND and P31).
So, you'll need to connect PWM to a Prop Pin and then add some code to run PWM on that pin...
I probably should add PWM to the driver, but I don't think I've done it yet...
There are these new versions: http://mghdesigns.com/propeller/dna.html
If you can solder your own, the "smorgasboard" at GadgetGangster.com is a great value.
I think he may also still sell the original Propeller Platform.
BTW: You can always take the Propeller Platform ExpressPCB files and have 3 copies made of the PCB for ~$50 to $80.
I guess maybe a Quickstart version of NH4 would be a good idea...
Drawbitmap(@
Drawbitmap(@
Drawbitmap(@
Etc
Is there a way to toggle a bitmap on and off like a blinking led or text, without having to have other bitmaps flicker on the redraw?
1. Removing print($100) 'erase screen
2. Creating a blank bitmap mask the same size as the tiles to blank out(in a flashing example).
This leaves all original graphics in tact without redraws.
Should be possible to write a little function that does that...
Ray, I have found the above to work much better. In a method where there is a read at the top, and I want to trap the finger press at the bottom to avoid repeated detections of the same key, I was getting bad results. Maybe this is something to test for yourself. With the original version, I was getting what looking like missed key presses about 50% of the time. The new method allows sure fire presses very rapidly.