PropBasic and QuickStart board
Rsadeika
Posts: 3,837
in Propeller 1
Below is a base program for usage with the QuickStart (QS) board. Basically it is, or will be a menu driven program, meaning touch a pad, from a menu selection list, on the LCD display, and it starts a specific function.
The below program, touching of the pad just fires up an associated LED. I guess that is the best starting point for the base program. Now I have to acquire the necessary peripherals. Probably would be nice to get an appropriate LCD, something that could display the eight pad selections, and only use a couple of pins. My count of the available usable pins is seven, maybe use P27 and P28 as the I2C bus. I consider P0-7 and P16-23, as permanently assigned pins.
Just as a reminder I am using Linux and Geany+PropBasic+BSTC setup, somewhat cumbersome, but it gets the job done. Once openspin can deal with "@@@" functionality, then I will replace BSTC with openspin. But hopefully Propeller IDE, by then, will have PropBasic integrated, and working with "@@@".
Ray
The below program, touching of the pad just fires up an associated LED. I guess that is the best starting point for the base program. Now I have to acquire the necessary peripherals. Probably would be nice to get an appropriate LCD, something that could display the eight pad selections, and only use a couple of pins. My count of the available usable pins is seven, maybe use P27 and P28 as the I2C bus. I consider P0-7 and P16-23, as permanently assigned pins.
Just as a reminder I am using Linux and Geany+PropBasic+BSTC setup, somewhat cumbersome, but it gets the job done. Once openspin can deal with "@@@" functionality, then I will replace BSTC with openspin. But hopefully Propeller IDE, by then, will have PropBasic integrated, and working with "@@@".
Ray
' QS_base.pbas ' Feb 3,2016 ' ' Start of a base system using the touch pads. '''''''''''''''''''' DEVICE P8X32A, XTAL1, PLL16X FREQ 80_000_000 ' Pin assign for touch pads. ' Multiple assignment is for usage with the existing lib. T_pads1 PIN 0..7 INPUT T_pads2 PIN 0..7 INPUT T_pads3 PIN 0..7 INPUT T_pad0 PIN 0 INPUT T_pad1 PIN 1 INPUT T_pad2 PIN 2 INPUT T_pad3 PIN 3 INPUT T_pad4 PIN 4 INPUT T_pad5 PIN 5 INPUT T_pad6 PIN 6 INPUT T_pad7 PIN 7 INPUT '''''''''''''''''''' PROGRAM Start '''''''''''''''''''' LOAD "/home/ray/propbasic/Tch_pads_lib.pbas" ' This sets up a forever loop for touch pad usage. ' The action is around the touch pads, which will ' be driving specific functions. In this case it ' is working an LED. Start: DO Chk_pads IF T_pad0 <> 1 THEN HIGH 16 PAUSE 1000 LOW 16 ELSEIF T_pad1 <> 1 THEN HIGH 17 PAUSE 1000 LOW 17 ELSEIF T_pad2 <> 1 THEN HIGH 18 PAUSE 1000 LOW 18 ELSEIF T_pad3 <> 1 THEN HIGH 19 PAUSE 1000 LOW 19 ELSEIF T_pad4 <> 1 THEN HIGH 20 PAUSE 1000 LOW 20 ELSEIF T_pad5 <> 1 THEN HIGH 21 PAUSE 1000 LOW 21 ELSEIF T_pad6 <> 1 THEN HIGH 22 PAUSE 1000 LOW 22 ELSEIF T_pad7 <> 1 THEN HIGH 23 PAUSE 1000 LOW 23 ENDIF LOOP END '''''''''''''''''''' ' SUBs FUNCs TASKS '
Comments
So far the program compiles, but I do not get any activity on the touch pads. I guess I need an explanation from one of the experts. My logic seems to be valid, but I am definitely missing something.
Ray
First, the .spin file produced by PropBasic, it looks like it has added three 'SUB Chk_pads', not sure why that would be occurring or does it even have a final result on the .spin file.
Second, in the .spin file that Propeller IDE works with, I do not see any functional code for the TASK and I do not see any functional code for the 'SUB Chk_pads'. Now, I do not even try to pretend that I know anything about PASM, but that does look suspicious to me. It could be that the code is in there, but I just do not recognize it. Should I be suspect about using the PropBasic COGSTART a TASK? Or what do I have to really do to get my program to work in a TASK?
Ray
Propeller IDE:
'' *** COMPILED WITH PropBasic VERSION 00.01.42 Aug 25, 2013 *** '' QS_base.pbas '' Feb 3,2016 '' '' Start of a base system using the touch pads. ''''''''''''''''''''' CON 'DEVICE P8X32A, XTAL1, PLL16X _ClkMode = XTAL1 + PLL16X _XInFreq = 5000000 'FREQ 80_000_000 '' Pin assign for touch pads. '' Multiple assignment is for usage with the existing lib. ' T_pads1 PIN 0..7 INPUT 'T_pads1 PIN 0..7 INPUT ' T_pads2 PIN 0..7 INPUT 'T_pads2 PIN 0..7 INPUT ' T_pads3 PIN 0..7 INPUT 'T_pads3 PIN 0..7 INPUT ' T_pad0 PIN 0 INPUT 'T_pad0 PIN 0 INPUT ' T_pad1 PIN 1 INPUT 'T_pad1 PIN 1 INPUT ' T_pad2 PIN 2 INPUT 'T_pad2 PIN 2 INPUT ' T_pad3 PIN 3 INPUT 'T_pad3 PIN 3 INPUT ' T_pad4 PIN 4 INPUT 'T_pad4 PIN 4 INPUT ' T_pad5 PIN 5 INPUT 'T_pad5 PIN 5 INPUT ' T_pad6 PIN 6 INPUT 'T_pad6 PIN 6 INPUT ' T_pad7 PIN 7 INPUT 'T_pad7 PIN 7 INPUT OBJ T_pads: "T_pads.spin" 'T_pads TASK ''''''''''''''''''''' PUB __Program | __VarsPtr 'PROGRAM Start __VarsPtr := 0 T_pads_COG:=T_pads.Init(@__DataStart, 0) CogInit(0, @__Init, __VarsPtr) DAT org 0 __Init __RAM mov dira,__InitDirA mov outa,__InitOutA jmp #Start ''''''''''''''''''''' ''LOAD "/home/ray/propbasic/Tch_pads_lib.pbas" '' This sets up a forever loop for touch pad usage. '' The action is around the touch pads, which will '' be driving specific functions. In this case it '' is working an LED. Start 'Start: mov __temp1,T_pads_COG 'COGSTART T_pads add __temp1,#8 coginit __temp1 __DO_1 'DO jmp #__DO_1 'LOOP __LOOP_1 mov __temp1,#0 'END waitpne __temp1,__temp1 ''''''''''''''''''''' '' SUBs FUNCs TASKS '' '********************************************************************** __InitDirA LONG %00000000_00000000_00000000_00000000 __InitOutA LONG %00000000_00000000_00000000_00000000 T_pad0 LONG 1 << 0 T_pad1 LONG 1 << 1 T_pad2 LONG 1 << 2 T_pad3 LONG 1 << 3 T_pad4 LONG 1 << 4 T_pad5 LONG 1 << 5 T_pad6 LONG 1 << 6 T_pad7 LONG 1 << 7 T_pads3 T_pads1 T_pads2 LONG 255 << 0 _FREQ LONG 80000000 ____STRING_adr LONG 0 __clkfreq_adr LONG 0 T_pads_COG LONG 0-0 __remainder __temp1 RES 1 __temp2 RES 1 __temp3 RES 1 __temp4 RES 1 __temp5 RES 1 __param1 RES 1 __param2 RES 1 __param3 RES 1 __param4 RES 1 __paramcnt RES 1 FIT 492 CON LSBFIRST = 0 MSBFIRST = 1 MSBPRE = 0 LSBPRE = 1 MSBPOST = 2 LSBPOST = 3 ' TASK T_pads 'TASK T_pads DAT __DATASTARTPropBasic:Bean
Ray
Bean
As I mentioned earlier, I have a Linux system that I have Geany+PropBasic+BSTC, and Propeller IDE setup. Now the finger can be pointed at Propeller IDE and/or BSTC, why aren't they including T_pads.spin when I do a run?
I have QS_base.spin and T_pads.spin in the same directory(folder) as BSTC, so why doesn't BSTC come back with an error telling me that it could not find T_pads.spin, same goes for Propeller IDE, no errors are posted. I am almost tempted to go to the other thread and start pushing for PE-BASIC. Get rid of this crazy scenario.
This also means that I should set up in a Windows environment, hopefully I would get ahead of this crazy scenario, unless of course the same thing occurs with that setup. I can see now why only the very committed users are actually using PropBasic in a BST IDE setup. And here I was trying to move away from Windows.
More to come, I am not done yet.
Ray
So, I run my test1.pbas with PropBasic, so far so good. Run test1.spin with BSTC : '0 - Unable to locate top file 0'. Since BSTC is not cooperating, I will not be able to do any LMM stuff.
Propeller IDE seems to like test1.spin, it runs and lights up P16 on the QuickStart board. But if I test out any LMM stuff, it will complain and throw up errors. Now I will try my QS_base.pbas file and see what happens.
Yes, I am now really considering lobbying for PE-BASIC, maybe if PE-BASIC had a scripting option, and you were not totally locked into the interpreter...
Ray
Others appreciate your patience, if that helps
Why not take ViewPort for a "spin". It's all I use. I copied my link from your other thread so it should be good. If not, you can find the original over there.
https://www.dropbox.com/s/2sonsg7n9yzj0oc/viewport482.zip?dl=0
Sorry folks, but I just hit a brick wall with PropBasic. After installing a setup on my Windows 7 box, and running the QS_base.spin with Propeller IDE, which compiles with no errors, but there is no activity on the QuickStart board. So, the same thing is occurring with a Windows setup. I double checked to make sure that the spin file had 'OBJ T_pads : "T_pads.spin"', yes , it was there. For some reason Propeller IDE is not including it in the QS_base.spin program, when compiled, but the worst part, it is not throwing up an error.
What I might try is the hard core option, do everything from the command line, and batch files, no no no, I have to go and lie down for a while before...
Ray
Not sure how you can blame PropellerIDE... BTW: I was able to build your code with PropellerIDE (as well as SimpleIDE. Both use OpenSpin and compiled the resultant .spin files without issue as there is no '@@@' within the PropBasic output in this case). I don't see the problem as PropellerIDE not including/compiling the T_pads.spin source. It actually does! As a test, I added some code to a second version of T_pads.spin to increase its size and changed the the OBJ line in the main source to point to that version. On compile, the size of the binary changes with any additions or deletions that I make to T_pads.spin file, so yes its binary is included within the overall program binary... You just need to debug why your loop is not executing.
dgately
' Tch_pads_lib.pbas Chk_Pads SUB 0 '''''''''''''''''''''''''' '... SUB Chk_pads 'OUTPUT __param1 ' Set pin to output HIGH T_pads1 HIGH T_pads2 HIGH T_pads3 ' Charge pin INPUT T_pads1 INPUT T_pads2 INPUT T_pads3 ' Switch pin capacitance PAUSE 30 ' Wait the delay time HIGH 22 ' blink one of the QuickStart's LEDS to test that this code gets executed PAUSE 200 LOW 22 ENDSUBAnd, the Quickstart's LED on P22 blinks each time when Chk_pads gets called from the main program. It seems that the code is getting executed.
dgately
I had created a SUB called Chk_pads, which when added in the beginning of the T_pads TASK, it compiles without any errors and when run on the QS board, the touch of the pads does not respond. When you take the code out of the SUB and add it to start of the DO...LOOP, like the program below, then the touch pads become active.
I also added an LMM to the PROGRAM Start command just to see if there were any side affects from that. The program seems to run fine when used with BSTC, but it will not work with Propeller IDE.
Now I am wondering if I can move LED on/off that is associated with a touch pad out of the TASK and try do that within the Start:. I am guessing that I cannot because of this global verses local code and variable stuff. That means that when you do a TASK you may have to have some sort of special setup to have communication between the COGSTARTed TASK and the main code, just guessing here. Have to do some more fooling around.
Ray
My experience, when using PropGCC, having a lot of code overhead built in, I expected the programs to be memory hungry. The reason I am testing PropBasic is to see if similar programs that I have done in PropGCC, can be much smaller, in memory usage, with the same functionality, when using PropBasic.
I guess a quick example, the SD driver, in PropGCC I believe the code size is ~11KB, in Spin the size ~9KB, in PropBasic ???, plus, if there was one, would it be, what 100x faster.
Which brings up the point of "5x", actually what does that really mean, in real terms? If that is such limiting factor, maybe the Propeller should be running in the FREQ 100_000_000 mode, that would negate that "5x" handicap :-). And I am sure that that would be a very visible attribute.
Now, back to the subject at hand, if I were to pursue using PropBasic, which has not been determined just yet, I would be pushing Bean to come up with a CMM equivalent.
I guess everybody must be thinking, what the heck kind of program is he thinking about. Actually if you take an ActivityBot and create a program that uses the servos, SD, Ping, Compass, IR, ADC, maybe throw in an XBee, just for starters. I suppose for PropBasic, it would be a breeze.
Now I am really thinking that maybe PropBasic is not the right choice, only because that most of the drivers do not exist, and than, after all is said and done, the program would still would not be able to run because it ran out of memory space. But it would really be fast, if it did fit in the memory available.
Ray
PropGCC is somewhat forced to use a limited-register model.
How much that helps, will depend on the program.
Any language forced into interpreted mode will be slower, so the real question for speed is, what can be packed into a COG in native PASM ?
-Mike
The LMM core that runs in the COG will runs code 4x slower, but IT needs to loop and then it loses the HUB window. So it ends up being about 5x slower for code with no jumps. Jumps are really slow because two HUB reads are required (one to read the instruction, then one to read the address that follows it).
As I've said, most of my programs use LMM for the main code because it is usually larger. Then native mode for all the TASKs because they are usually small and sometimes need to run fast (video output for example).
This works really well for me, and if you look at the PE-BASIC source code (PE-BASIC is written in PropBASIC) you will see that you can write quite a large program in LMM.
CMM ??? Is that the 8-bit token thing ??? If so, I don't see implementing that in PropBASIC.
Bean
What I would like to do is have the T_pads running all the time, which I have done so far, by putting into a COGed TASK, but how do get it to do some meaningful work, from within the main code. Like I mentioned, maybe moving the LED on/off association to the main area would be a good start.
I still do not know for sure the concept of using the HUB space as the device between a COG and main program for the this bit of code. Any help would be appreciated.
Ray
Well any way, I guess I got the one touch pad to behave, so now I can move the other ones to the main. After I am done with that then I will have the touch pads active, waiting for a touch, and I can build from there. Open for code improvement.
Are there any drivers for a servo, a high speed one, just like they use for the ActivityBot? Does anybody know how to go about creating the driver? I think the next experiment should be, attach a servo to the QuickStart board, and then use the T_pads to control the servo. This would be a good real example of touch pads and servo control, if that is possible with PropBASIC of course.
Ray
Ray
I have two QuickStart Rev A boards and a Human Interface Board (HIB), that I use to test the program. First, when I run the below program in LMM mode, some of the pads are not responsive, especially pads P4,P5,P6,and P7. When I remove the LMM mode then they seem to be more responsive.
Now when I add the HIB, the LED associated with pad P2, starts to blink, that is not part of the code. So, I guess I am wondering why the program acts differently when it is using LMM and a COGSTARTed TASK. The second part is, why is it working in a strange way when the HIB is added.
Ray
If Temp2 > 9 Then Temp2 = Temp2 + 6
High Temp2.......
A quick assessment, when you have an LMM program trying to work with a COGSTARTed TASK, timing takes a beating? I thought that when I made both an LMM, then it would be better, but it was even worse. So, I guess you have to be very careful how you intend to use an LMM program with a COGSTARTed TASK. But, I probably do not know what I speak of.
Ray