Eldon WA0UWH posted yesterday on lessons learned about the Parallax Propeller programming language Spin. I too have been having fun and games trying to create a user interface for my multimode multiband beacon using the LCD module. Whilst some of my problems have been due to my failure to spot my own stupid mistakes, a couple were caused by the tools themselves.
A considerable amount of time was wasted recovering a working program after a change I made seemed to have messed it up. Eventually I discovered by accident that the program fails to run correctly on the Propeller board unless the main Spin source file is the foremost one in the Propeller Tool editor. I had begun splitting my code into separate objects with their own source files and because I had been editing or referring to one of these files I had tried running the code with one of these files in the foreground instead of the main one.
I wasted a couple of hours trying to backtrack what I had done and ended up installing one of those programs that archives each version of a file whenever you save it so that you can roll back to a previous state. The best program I have found for this is AJC Active Backup which comes with a diff tool that shows the differences between two files but unfortunately I have lost the licence key since the last time I installed it so as I was feeling tight-fisted I had to use something less good.
The other problem that caused a lot of lost time was an apparent error in the LCD UI Spin object. Specifically, the cursor method that is supposed to let you change the cursor to a flashing underscore or block just seems to clear the LCD and then crash. I had been hoping to use the cursor to show what bit of information the user was editing but I can't get it to work.
I'm not sure exactly where I am going with the beacon project. Jeff KO7M has developed a WSPR encoder that generates the required code when you input your call, power and locator. However there is not much point in using it unless I provide an interface that allows you to input this information as text. If I choose to support Opera then the bit code will have to be programmed in as no-one other than Opera's programmer knows the algorithm used to encode the callsign. As my beacon is unlikely to be used by anyone other than G4ILO in IO84 at however much dBm it produces I may as well hard code all beacon texts.
The other thing I'm not sure about is how to add the PA. The LCD UI module is now plugged into all the headers on the Gadget Gangster board and I don't want to attach wires to the board itself. I could solder headers to the two rows of holes adjacent to the existing headers on the Gangster board and then plug a board to the bottom of it. That would be the probably be the neatest solution - unless anyone has a better idea?
1 comment:
Julian,
I too have been foiled by compiling an Object without the Main. To help avoid that all of my Object now have as the first method; "PUB Demo", where Demo is a stand alone demo of the Object. Demo can report that it is just a DEMO. Other PUB methods would be used for normal use.
I am starting to adhere to the following conventions, with slight variation depending on the Object:
PUB Demo
PUB Start (passes control values, which then/also calls Init)
PUB Init
PUB Progress (reports progress of backgrounded tasks, 99 to 0, where 0 == complete)
PUB Kill
PUB Restart
PUB
PUB and PRI
I agree, the TOOL has poor file control functionality, I augment it with the OS - which is a bit of a pain.
I use the OS directory structure to provide Revision Control. My directory structure are: /REVnn/. Before a major revision I clone the /REVnn/ to the next revision number (i.e., /REV07/ becomes /REV08/). It is not sophisticated but it has saved my efforts.
For OPERA file input, I plan use Text from a an SD card, where the text is prepared on a PC.
I am planning a LCD GUI for all other Beacon Controls.
Note, I am still learning the Prop, but I think conventions are the key.
Eldon
Post a Comment