Those "touch pad" inputs are notoriously unreliable. When we were creating the DC22 badge I lobbied against them. I wrote the original Spin library for the Parallax badge, but I still don't like those things -- nobody would ever use them in a commercial product (beyond the badges).
And 100 milliseconds is far too long before checking for discharge; in my tests I found that a pin would discharge itself (no finger) in 40 to 80 milliseconds. I would suggest you write a test program to see how long it takes to self discharge the pads, then use a qualification value that is something less than that. For precision measuring (one at a time), you can use a counter module (POS mode).
The program works, sort of, like I expected. This is for the Badge to test the touch pads, and the lights.
I expected the (P25) LED to stay on, but it flashes, and it is off, not sure why that is occurring. For the touch pads themselves, not sure how to include pins 25,26,and 27 in the 'T_pads PIN 15..17 INPUT' call out. Also I have to find out what pin the OSH is on, so that can be included.
When I touch P15 pad I expect both RGBs to light up at the same time, but they go on/off after one another. Well, now it seems I can get some LEDs and RGBs to flash when touch a few of the touch pads, using PropBasic. I guess I am making some headway.
Ray
' Base_badge.pbas
' Jan 27, 2016
'
' Test mode.
'
'
' Layout of Hackable Badge LEDs
'
' led led
' 5 |O| (P17)| O |(P27) |O| 0
' 4 |O| (P16)| L |(P26) |O| 1
' 3 |O| (P15)| E |(P25) |O| 2
' | D |
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
' charlieplexed LEDs configuration
' for the Parallax Hackable Badge
CPin0 PIN 6 OUTPUT
CPin1 PIN 7 OUTPUT
CPin2 PIN 8 OUTPUT
' charliepled RGB configuration for the Badge
CPrgb0 PIN 1 OUTPUT
CPrgb1 PIN 2 OUTPUT
CPrgb2 PIN 3 OUTPUT
' Pin assign for touch pads.
T_pads PIN 15..17 INPUT
T_pad15 PIN 15 INPUT
T_pad16 PIN 16 INPUT
T_pad17 PIN 17 INPUT
'T_pad25 PIN 25 INPUT
'T_pad26 PIN 26 INPUT
'T_pad27 PIN 27 INPUT
'T_pad0 PIN 0 INPUT ' OSH ???
''''''''''''''''''''
PROGRAM Start
''''''''''''''''''''
LOAD "/home/ray/propbasic/CPled_lib.pbas"
LOAD "/home/ray/propbasic/CPrgb_lib.pbas"
LOAD "/home/ray/propbasic/Tch_pads_lib.pbas"
' Start up code
Start:
' led,state = 0-on, 1-off
CPled 2,0 ' Turn on LED
' PAUSE 250
' loc,col,state loc="L"or"R",col=0-r,1-g,2-blue
' CPrgb "L",1,0 ' Left rgb,green,on
' PAUSE 3000
' CPrgb "L",1,1 ' " ,off
Main:
Chk_pads
IF T_pad17 <> 1 THEN
CPled 0,0
ELSE
CPled 0,1
ENDIF
Chk_pads
IF T_pad16 <> 1 THEN
CPrgb "L",1,0
PAUSE 250
CPrgb "R",1,0
ELSE
CPrgb "L",1,1
PAUSE 250
CPrgb "R",1,1
ENDIF
Chk_pads
IF T_pad15 <> 1 THEN
CPled 5,0
ELSE
CPled 5,1
ENDIF
GOTO Main
END
' SUBs FUNCs TASKS
'
I was able to add the rest of the touch pads, and keep an LED on all the time, just to show that the Badge is on. At the moment every pad has an associated function, which is limited to an LED or an RGB.
It would be kind of interesting to see how this program matches up to the Spin version, memory size, that is. Not sure if speed would have any bearing at this point.
Now I really really need some ideas as to how to approach coding the OLED. With that capability, made available, it would provide a way of finding out how efficient PropBasic would be in the process of creating menus and associated functionality. At this point I am open to any suggestions for ways of improving this program.
Ray
' Base_badge.pbas
' Jan 27, 2016
'
' Test mode.
'
'
' Layout of Hackable Badge LEDs
'
' led led
' 5 |O| (P17)| O |(P27) |O| 0
' 4 |O| (P16)| L |(P26) |O| 1
' 3 |O| (P15)| E |(P25) |O| 2
' | D |
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
' charlieplexed LEDs configuration
' for the Parallax Hackable Badge
CPin0 PIN 6 OUTPUT
CPin1 PIN 7 OUTPUT
CPin2 PIN 8 OUTPUT
' charliepled RGB configuration for the Badge
CPrgb0 PIN 1 OUTPUT
CPrgb1 PIN 2 OUTPUT
CPrgb2 PIN 3 OUTPUT
' Pin assign for touch pads.
T_pads1 PIN 15..17 INPUT
T_pads2 PIN 25..27 INPUT
T_pads3 PIN 5 INPUT
T_pad15 PIN 15 INPUT
T_pad16 PIN 16 INPUT
T_pad17 PIN 17 INPUT
T_pad25 PIN 25 INPUT
T_pad26 PIN 26 INPUT
T_pad27 PIN 27 INPUT
T_pad5 PIN 5 INPUT ' OSH
''''''''''''''''''''
PROGRAM Start
''''''''''''''''''''
LOAD "/home/ray/propbasic/CPled_lib.pbas"
LOAD "/home/ray/propbasic/CPrgb_lib.pbas"
LOAD "/home/ray/propbasic/Tch_pads_lib.pbas"
' Start up code
Start:
' led,state = 0-on, 1-off
CPled 2,0 ' Turn on LED 0
' PAUSE 250
' loc,col,state loc="L"or"R",col=0-r,1-g,2-blue
' CPrgb "L",1,0 ' Left rgb,green,on
' PAUSE 3000
' CPrgb "L",1,1 ' " ,off
Main:
DO
Chk_pads
IF T_pad17 <> 1 THEN ' P17
CPled 0,0
PAUSE 1000
CPled 0,1
ELSEIF T_pad16 <> 1 THEN ' P16
CPrgb "L",1,0
PAUSE 1000
CPrgb "L",1,1
ELSEIF T_pad15 <> 1 THEN ' P15
CPled 5,0
PAUSE 1000
CPled 5,1
ELSEIF T_pad27 <> 1 THEN
CPled 3,0 ' LED 3 on
PAUSE 1000
CPled 3,1 ' LED 3 off
ELSEIF T_pad26 <> 1 THEN
CPrgb "L",2,0
PAUSE 1000
CPrgb "L",2,1
ELSEIF T_pad25 <> 1 THEN
CPrgb "R",1,0
PAUSE 1000
CPrgb "L",1,1
ELSEIF T_pad5 <> 1 THEN ' OSH
CPrgb "R",0,0
PAUSE 1000
CPrgb "R",0,1
ELSE
CPled 2,0 ' Keeps LED 2 on, just let you the Badge is on.
ENDIF
LOOP
END
' SUBs FUNCs TASKS
'
Bean's docs are terse, but I've found no errors, and Jon McPhalen's PropBasic Syntax Guide provides additional info. Jon also wrote a number of his Spin Zone columns for Nuts & Volts on PropBasic, which provide not only tested examples but lots of detailed explanations. Now that I think of them, he has some examples of using inline assembler which I clearly need to re-read. The info is all out there somewhere.
I have had a few issues, but I've always found a work-around.
Ditto.
I use Viewport for PropBasic. The latest version of VP has issues so I use the previous version.
What is the version of Viewport you currently use for PropBasic?
Those "touch pad" inputs are notoriously unreliable. When we were creating the DC22 badge I lobbied against them. I wrote the original Spin library for the Parallax badge, but I still don't like those things -- nobody would ever use them in a commercial product (beyond the badges).
It's no surprise they are unreliable, as there are multiple, widely varying effects at play.
Besides the discharge effect, there can be significant mains related noise/pickup injection, which super imposes 50Hz or 60Hz on what is trying to be measured.
It may be more reliable to sense 'not pressed' as being a stable and short discharge, and everything else as 'probably pressed', and the time-frames for debounce need to consider the mains injection effects.
Bean's docs are terse, but I've found no errors, and Jon McPhalen's PropBasic Syntax Guide provides additional info. Jon also wrote a number of his Spin Zone columns for Nuts & Volts on PropBasic, which provide not only tested examples but lots of detailed explanations. Now that I think of them, he has some examples of using inline assembler which I clearly need to re-read. The info is all out there somewhere.
I have had a few issues, but I've always found a work-around.
Ditto.
I use Viewport for PropBasic. The latest version of VP has issues so I use the previous version.
What is the version of Viewport you currently use for PropBasic?
I'm using 4.8.9
You are using the one with issues. I don't remember what they are, right now but I know that "Max" has reported them to the OneRobot forum and the last time I checked, nobody had replied.
So, I guess I will start with the program below. Since the Spin driver uses spi, I guess I should use that also.
Their are a lot of blank spots in the code below, like, how do I use 'SHIFTIN/SHIFTOUT' to work with the pin call outs? In fact I am not sure about the example Spin data, what the heck does oled_dc, oled_cs, and oled_rst, have to do with SHIFTIN/SHIFTOUT? I need a lot of clarification as to how those two commands relate to spi.
I don't know if any of this can be of help and I hope it's kosher for me to take the liberty of posting someone else's code (it was posted to the forum in the first place) but at least there is some SPI code included.
Bean's docs are terse, but I've found no errors, and Jon McPhalen's PropBasic Syntax Guide provides additional info. Jon also wrote a number of his Spin Zone columns for Nuts & Volts on PropBasic, which provide not only tested examples but lots of detailed explanations. Now that I think of them, he has some examples of using inline assembler which I clearly need to re-read. The info is all out there somewhere.
I have had a few issues, but I've always found a work-around.
Ditto.
I use Viewport for PropBasic. The latest version of VP has issues so I use the previous version.
What is the version of Viewport you currently use for PropBasic?
I'm using 4.8.9
You are using the one with issues. I don't remember what they are, right now but I know that "Max" has reported them to the OneRobot forum and the last time I checked, nobody had replied.
Thanks Mickster for the .pbas code, it would have of been nice if the author would have included the brand name of the LCD device. If that program is of any indication to how long the driver for the OLED would be, then this looks like there is a long road ahead of me.
I went to the Badge site at the Parallax store, and the only information that I could find about the OLED display, is that it is a '128x64 OLED Display', not sure why Parallax is keeping the brand name under wraps.
What I am looking for is all the hex commands that are available for working with the display. I know that the Spin object that is being used, with the Badge, was written by a contributor that was written for a device that was being sold by Adafruit, back in 2012. I also noticed in the store that that display is not available, so no docs or any other information.
For the PropBasic program, I will have to use spi(SHIFTIN/SHIFTOUT), the hex commands would come in very handy, I would think. So, does anybody have any leads or any other necessary information?
Thanks Mickster for the .pbas code, it would have of been nice if the author would have included the brand name of the LCD device. If that program is of any indication to how long the driver for the OLED would be, then this looks like there is a long road ahead of me.
I went to the Badge site at the Parallax store, and the only information that I could find about the OLED display, is that it is a '128x64 OLED Display', not sure why Parallax is keeping the brand name under wraps.
What I am looking for is all the hex commands that are available for working with the display. I know that the Spin object that is being used, with the Badge, was written by a contributor that was written for a device that was being sold by Adafruit, back in 2012. I also noticed in the store that that display is not available, so no docs or any other information.
For the PropBasic program, I will have to use spi(SHIFTIN/SHIFTOUT), the hex commands would come in very handy, I would think. So, does anybody have any leads or any other necessary information?
"The 0.96” OLED screen features a high-contrast graphics display with 128x64 pixels. Pixels are white on a dark background. The screen has a built in SSD1306 display driver, which the Propeller controls directly by SPI protocol on pins P18 through P22."
Thanks Bob, I had a look at the datasheet, way over my head. I think I will leave that project to someone else, that is, making a PropBasic driver for the OLED.
I remember way back when somebody created a SIRCS driver for PropBasic, I looked in the OBEX, did not find one. I also did a search of the forum, nothing came up. Maybe one of you old PropBasic hands have a copy archived somewhere?
I am thinking that the SIRCS driver, after I butcher some code, I could turn the Badge into a remote controller for using with my ActivityBot, that has been sitting in a box, in a loose parts condition. That could be a doable experiment for PropBasic, I think. That way I could implement the touch pads, have some LEDs and RGBs light up, and possibly have the ActivityBot start to move.
Thinking about the Activity board, are there any PropBasic libraries of code for working with that board?
I don't know that anyone has written something specific in PropBasic for the Activity board, but a lot of Prop code can be run on any board by just changing pin assignments and such. Have a look at Jon's stuff. Also Andre Nieuwoudt recently posted some libraries of PropBasic code. I think it was a thread titled PropBasic Libraries? If you look in the Propeller 1 forum messages I think it was only a couple of weeks ago, maybe less.
[edit] Doh, too many "activity" things here. I don't know about the bot, but most Prop code should be adaptable to the Activity Board.
[edit again] It looks like Jon's SIRCS code was in PASM, with only a receiver in PropBasic.
IIRC Jon McPhalen wrote a SIRCS driver in PropBasic.
It was pretty simplistic but I think it worked. FWIW, I'm monitoring the happenings with PropBASIC and may dive in again -- as time permits -- as long as I don't have to jump through my own backside to compile and download a program.
[edit again] It looks like Jon's SIRCS code was in PASM, with only a receiver in PropBasic.
IMO, PropBASIC should not be used an excuse NOT to program in PASM. In fact, one can learn quite a bit by studying the output and then optimizing.
It would be good to have you dive in again. Maybe we can finally reach a critical mass of users that will justify the effort to make one of the mainstream IDEs support PB. And you're right about PASM, of course. One downside of PropBasic is that it makes it fairly easy to write cog code that's fast enough to do most of what the hardware can do, so it removes some of the motivation to learn PASM. For those of us who have never been assembler programmers, it's a significant hump to get over, but we certainly should.
.. One downside of PropBasic is that it makes it fairly easy to write cog code that's fast enough to do most of what the hardware can do, so it removes some of the motivation to learn PASM. For those of us who have never been assembler programmers, it's a significant hump to get over, but we certainly should.
Yes, but as Jon mentioned, you can learn a lot studying the output the Compiler produces.
Even if you write few lines of PASM, you should be able to read PASM reports from compilers.
I went to the Badge site at the Parallax store, and the only information that I could find about the OLED display, is that it is a '128x64 OLED Display', not sure why Parallax is keeping the brand name under wraps.
Thanks VonSzarvas, I looked at the information, and it is still way beyond my skill level. I decided I will let this thread take on a life of its own. If there is any interest, direct the thread to your own satisfaction.
As a different experiment, using PropBasic, I am going visit the usage of the QuickStart board, probably start another thread, when I get more details worked out on paper. Generally I am thinking QS board, Parallax serial ~$40 LCD, OW temp/humid module(s), RTC, to start. I do have some servos laying around, but there are no PropBasic drivers for that.
As soon as I get a feasibility outline worked out then I will start another thread.
Comments
Anyway, you don't need the "OUTPUT __param1" because the HIGH command sets the pin to an output anyway.
Maybe check all the touchpads at once and return a value of which one was pressed. Or a bitmap if you want to support multiple touches.
Bean
This seems to work to test all the pads in one subroutine.
And 100 milliseconds is far too long before checking for discharge; in my tests I found that a pin would discharge itself (no finger) in 40 to 80 milliseconds. I would suggest you write a test program to see how long it takes to self discharge the pads, then use a qualification value that is something less than that. For precision measuring (one at a time), you can use a counter module (POS mode).
I expected the (P25) LED to stay on, but it flashes, and it is off, not sure why that is occurring. For the touch pads themselves, not sure how to include pins 25,26,and 27 in the 'T_pads PIN 15..17 INPUT' call out. Also I have to find out what pin the OSH is on, so that can be included.
When I touch P15 pad I expect both RGBs to light up at the same time, but they go on/off after one another. Well, now it seems I can get some LEDs and RGBs to flash when touch a few of the touch pads, using PropBasic. I guess I am making some headway.
Ray
Oops. That was my fault. I just copied that sequence from the PASM driver.
Bob
It would be kind of interesting to see how this program matches up to the Spin version, memory size, that is. Not sure if speed would have any bearing at this point.
Now I really really need some ideas as to how to approach coding the OLED. With that capability, made available, it would provide a way of finding out how efficient PropBasic would be in the process of creating menus and associated functionality. At this point I am open to any suggestions for ways of improving this program.
Ray
What is the version of Viewport you currently use for PropBasic?
I'm using 4.8.9
It's no surprise they are unreliable, as there are multiple, widely varying effects at play.
Besides the discharge effect, there can be significant mains related noise/pickup injection, which super imposes 50Hz or 60Hz on what is trying to be measured.
It may be more reliable to sense 'not pressed' as being a stable and short discharge, and everything else as 'probably pressed', and the time-frames for debounce need to consider the mains injection effects.
My DropBox link to 4.8.2
http://onerobot.org/forums/topic/viewport-4-8-8/
Anyone know if Hanno has recovered from his accident?
Their are a lot of blank spots in the code below, like, how do I use 'SHIFTIN/SHIFTOUT' to work with the pin call outs? In fact I am not sure about the example Spin data, what the heck does oled_dc, oled_cs, and oled_rst, have to do with SHIFTIN/SHIFTOUT? I need a lot of clarification as to how those two commands relate to spi.
Ray
Thanks for the link, but I checked my local drive, and I have every release back to 4.0.0
I went to the Badge site at the Parallax store, and the only information that I could find about the OLED display, is that it is a '128x64 OLED Display', not sure why Parallax is keeping the brand name under wraps.
What I am looking for is all the hex commands that are available for working with the display. I know that the Spin object that is being used, with the Badge, was written by a contributor that was written for a device that was being sold by Adafruit, back in 2012. I also noticed in the store that that display is not available, so no docs or any other information.
For the PropBasic program, I will have to use spi(SHIFTIN/SHIFTOUT), the hex commands would come in very handy, I would think. So, does anybody have any leads or any other necessary information?
Ray
I believe he was using a "DOG" LCD
http://www.lcd-module.com/products/dog.html
"The 0.96” OLED screen features a high-contrast graphics display with 128x64 pixels. Pixels are white on a dark background. The screen has a built in SSD1306 display driver, which the Propeller controls directly by SPI protocol on pins P18 through P22."
From a quick Google search on the driver part number:
Datasheet: https://www.adafruit.com/datasheets/SSD1306.pdf
I remember way back when somebody created a SIRCS driver for PropBasic, I looked in the OBEX, did not find one. I also did a search of the forum, nothing came up. Maybe one of you old PropBasic hands have a copy archived somewhere?
I am thinking that the SIRCS driver, after I butcher some code, I could turn the Badge into a remote controller for using with my ActivityBot, that has been sitting in a box, in a loose parts condition. That could be a doable experiment for PropBasic, I think. That way I could implement the touch pads, have some LEDs and RGBs light up, and possibly have the ActivityBot start to move.
Thinking about the Activity board, are there any PropBasic libraries of code for working with that board?
Ray
https://www.parallax.com/downloads/propeller-spin-zone-articles-and-code
I don't know that anyone has written something specific in PropBasic for the Activity board, but a lot of Prop code can be run on any board by just changing pin assignments and such. Have a look at Jon's stuff. Also Andre Nieuwoudt recently posted some libraries of PropBasic code. I think it was a thread titled PropBasic Libraries? If you look in the Propeller 1 forum messages I think it was only a couple of weeks ago, maybe less.
[edit] Doh, too many "activity" things here. I don't know about the bot, but most Prop code should be adaptable to the Activity Board.
[edit again] It looks like Jon's SIRCS code was in PASM, with only a receiver in PropBasic.
It was pretty simplistic but I think it worked. FWIW, I'm monitoring the happenings with PropBASIC and may dive in again -- as time permits -- as long as I don't have to jump through my own backside to compile and download a program.
IMO, PropBASIC should not be used an excuse NOT to program in PASM. In fact, one can learn quite a bit by studying the output and then optimizing.
Yes, but as Jon mentioned, you can learn a lot studying the output the Compiler produces.
Even if you write few lines of PASM, you should be able to read PASM reports from compilers.
Ask and you shall receive!!
So unofficially, here's a link to some tutorials and datasheets that may help: http://www.buydisplay.com/default/128x64-oled-i2c-0-96-display-white-color-connector-fpc-ssd1306
As a different experiment, using PropBasic, I am going visit the usage of the QuickStart board, probably start another thread, when I get more details worked out on paper. Generally I am thinking QS board, Parallax serial ~$40 LCD, OW temp/humid module(s), RTC, to start. I do have some servos laying around, but there are no PropBasic drivers for that.
As soon as I get a feasibility outline worked out then I will start another thread.
Ray