Simplyfying SXB yet making it more powerful – a discussion.

John Bond

Hi Guys

I’m becoming quite impressed with SXB2.0 as I use it more. I am also aware that there are features that give us users vastly more power to customise our code. Maybe by sharing our ideas, we can get even more out.
·
Imagine just enabling large chunks of SXB code with just a single keystroke...
What about having single simple commands for motors, RTclocks, buffered UARTs and LCDs...
Imagine writing the bulk of your code in minutes then being able to concentrate on the exciting new stuff...
·
Dream on, dream on!
·
Well, various of the more experienced SX geeks have been moving in this direction. Bean included some compiling directives in SXB2.0 and Peter Verkaik posted an interesting program to exploit these features. I am not sure that we have got our heads round the incredible power of some of the new features on SXB2.0.· Unfortunately, a lot of the stuff I’ve seen so far has been too complex for me to use. I want a simple programming template, a vast array of new commands and features and some automatic optimisation of the code. (Don’t tell me, I should be programming the Propeller!).
·
What about using the LOAD and INC commands with conditional compiling (like PVK did) but hide it under the hood and keep the template clean? What about borrowing the multi-file approach used in “C” to simplify the process?
·
I have attached an example of how I think the template and files·may look.
·
1.··········· The idea is to keep the MAIN program template as simple clean and uncluttered as possible. Re-useable and robust code is stored as a component and automatically loaded – only when needed (you don't need to copy and paste code each time you need common code)
2.··········· Each project has the main program, three Header files and a folder called "Components" that stores the files of reusable code
3. ·········· All application specific code (code used by the current project only) is placed in this “Main Program” template. Code that is often re-used in other different programs is added as a component (file). This template will LOAD the code when it is activated in “Software_Comp.sxb" file.
4.··········· Once you've built the hardware, comment out or delete the code that is not used in the "Software_Comp.sxb" file. This will automatically optimise the subroutines and reduce the program size. You then update the files "Device_XXX.sxb" and "IO_Setup.sxb" files to suite your current project.
5.··········· You only have to disable a component in the "Software_Comp.sxb" to remove the code. You don't have to remove any of the LOAD instructions from this or any other file.
6.··········· When adding a re-useable component, you need to add it to this template, create the suitable "Components\XXX_XXX.sxb" file and add it to some or all of the following. "Software_Comp.sxb "CONs&VARs.SXB", "Components\DeclareSubs.sxb "Components\Start-Up_LCD.sxb". Try where practical to write the re-useable code as a SUB, FUNC or TASK
·
Enables reusable software········· - "Software_Comp.sxb"
Device (MCU) directives··············- "Device_XXXX.sxb"
I/O assignment····························- "IO_Setup.sxb"
CONs & VARs for components·· ·- "CONs&VARs.SXB"
Declaring subs used··················· - "DeclareSubs.sxb"
Interrupt Code····························· - "Interrupts.sxb"··························· - see my comments below
Individual interrupt code············· - "Components\Interupt_XXXXX.sxb"
Startup code·································- "Components\Start-Up_XXXX.sxb"
SUBs, FUNCs AND TASKs·············- "Components\Subs_XXXXX.sxb"
DATA, WDATA AND CDATA········ - "Components\Data_XXXXX.sxb"
Explanatory text·························· - "Components\Text_XXXXX.sxb"
·
Known bugs - ·· If you have one disabled subroutine that calls another disabled subroutine, you get the UNKNOWN COMMAND ... error when you compile, even though both are disabled. for example, open the Software_Comp.sxb file and disable both Components\Subs_Delay.sxb and Components\Subs_LCD.sxb then compile the main program... OOPS

Sorry about the long post and kind regards from the dark continent
John Bond

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Peter Verkaik

Hi John,

You said...What about using the LOAD and INC commands with conditional compiling (like PVK did) but hide it under the hood and keep the template clean?

That has been tried. There is a thread ( http://forums.parallax.com/showthread.php?p=780467·)
in which I and others tried making libraries stand-alone (libraries include libraries they need)
but that really messed up the list view with duplicate library code as comments.
My approach ever since has been to use main compilation switches in the application file.
It does make the application file less readable (mainly because conditional compilation statements
have the same color as comments) but it does allow to include/exclude code by simply
enabling/disabling conditional compile switches from the application file (no need to alter
libraries) and it keeps the list view clean in that code appears only once (as code or as comment)
and in the order it is included in the application file.
I don't see how we can improve or hide more, unless SXB becomes a multi-pass compiler,
and I don't think that will ever happen.

regards peter

John Bond

Peter - Possibly the people posting in the string “load Instructions…” have misjudged the typical SXB user. I am sorry I didn’t see the thread but it doesn’t matter because the stuff listed there is totally unusable to me, a typical user.

If one is a professional MCU programmer, chances are you're not using Parallax SX chips, you are using one of the cheap main stream products. This SX is a VERY niche focussed product. We SX users are made up of hobbyists, people who do both hardware and software, inventors, geeks, robotics, puppeteers etc. Users don’t have the attention span to spend hours battling to learn a complex protocol. They want to DO IT and they want to DO IT NOW!!!

This means "KEEP IT SIMPLE"

SX users don’t understand the phrase “It’s been tried before by the experts and it doesn’t work”. We come back to a topics and try a different approach (which is what I did). Virtual peripherals is a good and powerful a feature, I say let’s keep exploring it.

SX users also seem expect more feature than are listed in the spec sheet. (and I like this attitude)

Kind regards
John Bond

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Zoot

John -- why aren't you using '{$USES and '{$IFUSED and '{$DEFINE ? That way the progammer only needs to comment out (or conversely, insert) the USES statements so that subroutines/code in loaded files are only compiled if they are used, without having to comment out load instructions and the like. Makes it much tidier and clearer and that way the author of the library (I like the term library, rather than components, btw -- IMHO) can determine what needs to be compiled under what USED circumstances without the enduser of the library necessarily knowing what's going on.

I realize Peter's code can be a bit dense on first glance, but you might want to check his code more closely for some nice tricks related to automatic compiling of necessary code.

Lastly, the ISR should go at the END of the entire program (last page of memory) -- in many circumstances where there is a decent sized subroutine jump table there will not be room for a decent sized ISR in the first page of code space.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

John Bond

Zoot and Peter,

I see the problem...

Take a slightly closer look at the code, unzip the files. Yes I'm using conditional compiling but I've cheated. The software components file for example has the following...

'##########################################################################
'

---

' RE-USABLE COMPONENTS - Note the incorrect use of· '{$USES XXXX}
'

---

'Comment out or delete those not used by the current project

'{$USES·Components\Subs_Delay.sxb}
'{$USES Components\Subs_LCD.sxb}
'{$USES Components\Subs_eeI2C.sxb}
'{$USES Components\Subs_5Buttons.sxb}
'{$USES Components\Subs_ClockTime.sxb} - There's an interrupt here as well!!!
'{$USES Subs_PWM2Motors.sxb}

'Possible additional components
'==============================
'Components\Subs_POT_A2D.sxb
'Components\Subs_PWM_D2A.sxb
'Components\Subs_LED7Seg.sxb
'Components\Subs_MATRIX_4x4Keypad.sxb
'Components\Subs_RotaryEnc.sxb
'Components\Subs_SonyIRRemote.sxb
'Components\Subs_Max1Wire.sxb
'Components\Subs_Servo.sxb

'

---

Note how the compiler just drops through those files (components) that are not called.·This trick·also makes the code more readable and we amateurs·can use it, Just·delete the components you don't need. There may just be some other useful tricks.

And ZOOT - thanks for that tip on ISRs I'm used to seeing my ISRs at the top so I keep them there. I just jump the SUBs declaration. (Yes we mavericks tend to do things differently.Maybe thats why disruptive·change comes from mavericks. We just don't understand that rules are to ba obeyed. Sorry...)

Kind regards

John


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Post Edited (John Bond) : 5/18/2009 1:54:44 PM GMT

Zoot

But the USES should be in the program itself. This way the programmer chooses/defines what will be used, and it's also clear to someone else reading the program what's being used and where, and without even having to open the library -- which should be a "black box".

A good library should never need to be edited by the user -- totally defeats the purpose -- you don't want multiple copies of a library w/each project where the only differences are what's been commented out. Plus say I want to use the same library in multiple projects on the same drive...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

John Bond

Sure, then move them back into the program, it doesn't make it much more complex. You can also move the Declaration, I/O and CONs/VARs back into the program if you like. It's just make the template more complex.

My strategy is that the code should be easy to use and to understand (none of the examples I have seen so far meet this MINIMUM standard). In addition the SYSTEM DISCIPLINE should be to make the code simple and reusable (the examples also perform poorly in this test). My mindset is a little different because you look in the main template for the program, the declaration file for the MCU and the component file for the virtual peripherals.

We should understant this because when dealing with hardware, we look at the schematic for the logic, the BOM for the components and the PCB layout for assembly. I prefer this approach to a top heavy and unreadable template but hey, the purpose of my post is to create discussion…

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Peter Verkaik

John,

Spreading I/O definitions, VAR & CON delcarations. SUB declarations etc. over multiple
files doesn't improve on simplicity imho. Having all those in 1 file gives you an overview
of what is available/used in your project.

Still, I am with you that some parts could be 'hidden' as they are mostly static in that
they are present but once set have no direct use for the application as such (like my
library VAR's etc).

Perhaps a foldable listing (like used in Visual Basic editor) could help. Parts of the
listing you don't want to see are then just folded in, other parts are folded out.

For example:
'{$+.namespace1}
'anything following the above statement is hidden from the listing you edit, not the file
'...
'...
'{$-.namespace2}
'anything following the above statement is displayed
'...
'...

It doesn't have to be named namespaces, simple '{$HIDE} and '{$VIEW} would also do.
I like the + and - approach as you can leave in the line and give it a useful name.
However, this would require an updated editor and as PJMonty once explained, Parallax
would have to pay for these alterations. Still, would be nice.

regards peter