New Program Demonstrates Variable Patching

jazzed

This new package demonstrates defining pin numbers for TV, Keyboard, and SDcard with a .cfg file.

It uses the standard C stdio interface. This is just one way of doing the job.
There are other smaller ways. This is the most easily recognized for C programmers.

The demo will run in LMM and other memory modes.

The key item is pin definitions - but first ....


To use this demo with SimpleIDE-v0-6-11:

1. Download and unzip the attachment to your workspace
2. Copy the c3tvkb.cfg file to the propeller-load folder
3. Connect your C3 - TV+Keyboard+SDcard
4. Start SimpleIDE
5. Open the tvkbfile.side project
6. Click the green Run tool button F10
7. Wait for the TV to start up.
8. Play with the Keyboard.

Now, this program uses a TV and Keyboard driver for a console.

First it will print the string "TV Keybd File Demo ...."

Then, the program opens, writes, and closes a file.
Then it reads the file and prints the contents.
(I was amused seeing the quote in Bean's sig once).

Finally it starts the Keyboard echo demo prompted by "Press any key ..."

So, what happened and why is it important?

The program has some built-in things:

1. The propeller-load reads from the .cfg file and sets variables in the program at load time.
2. The TV and Keyboard pin variables are defined globally in the program with a specific syntax.
3. The filesystem will start on first file access using the pins in the .cfg file. This saves memory.
4. Any board .cfg file that has the TV, Keyboard, and SD card pins defined can be used.

Rules for using board.cfg variables:

1. Each variable must be global.
2. Each variable should be declared as: int _cfg_varname = -1;
3. For config varnames such as "sdspi-do:" the variable will be: int _cfg_sdspi_do = -1;
4. The loader will patch the variable with the value from the board.cfg
5. Variables not patched will remain -1.

Why is this important?

• It lets you share programs without recompiling them.
• You do not need to use -D BOARD and #ifdef BOARD ... #elif BOARDB ... #else ... #endif everywhere.
• All you need to do is load the program with propeller-load and a board.cfg file.
• There are other advantages yet to be seen.

Any questions?

Thanks,
--Steve

mindrobots

Ok, this is seriously cool!

You're gonna make me get up and look for my keyboard at this rate!!

jazzed

Here is a simple version of the config variable field patching.
The output below shows which variable fields get patched from the .cfg file.

PropellerGCC Config Variable Field Demo

_cfg_clkfreq        80000000	0x04c4b400
_cfg_clkmode             111	0x0000006f
_cfg_baudrate         115200	0x0001c200
_cfg_rxpin                31	0x0000001f
_cfg_txpin                30	0x0000001e
_cfg_cache_driver         -1	0xffffffff
_cfg_cache_size         8192	0x00002000
_cfg_cache_param1          0	0x00000000
_cfg_cache_param2          0	0x00000000
_cfg_sd_driver            -1	0xffffffff
_cfg_sdspi_do              0	0x00000000
_cfg_sdspi_clk             1	0x00000001
_cfg_sdspi_di              2	0x00000002
_cfg_sdspi_cs              3	0x00000003
_cfg_sdspi_clr            -1	0xffffffff
_cfg_sdspi_inc            -1	0xffffffff
_cfg_sdspi_addr           -1	0xffffffff
_cfg_sdspi_select         -1	0xffffffff
_cfg_sdspi_mask           -1	0xffffffff
_cfg_tvpin                12	0x0000000c
_cfg_vgapin               16	0x00000010
_cfg_kbclk_pin            27	0x0000001b
_cfg_kbdat_pin            26	0x0000001a
_cfg_mouseclk_pin         25	0x00000019
_cfg_mousedat_pin         24	0x00000018
_cfg_scl_pin              28	0x0000001c
_cfg_sda_pin              29	0x0000001d

These names are not set in stone.

Instructions are same as before.
Copy the variables.cfg file to the propeller-load folder and start SimpleIDE.

jazzed

Many of the config names in my previous post are the standard to use with Propeller-GCC.
The ones that are not standardized yet are keyboard, mouse, and scl/sda.

Thanks.
--Steve

mindrobots

Steve,

Starting from your first post:

C3 and SimpleIDE-v0-6-11

followed instructions 1-8 and noticed the keyboard didn't work.

Checked over things and noticed the loader complained about not having patch values for the keyboard. Checked the .cfg file for C3 and sure enough, no entries for keyboard. Since there was a 0-6-12 version, I through I'd try that in case this was a between releases feature.

Same results.

Edited c3.cfg and added these two lines:

kbclk-pin: 27 # added to make demo run
kbdat-pin: 26 # added to make demo run

(Note: the difference between the _cf_xxxx_yyyyy (underscored) labels used in c and the xxxx-yyyyy (hyphenated) labels used in the .cfg file is confusing and annoying. If it could be changed to be consistent, that would be nice. As it is, it's workable and can be documented as a required difference.)

Once I did this, the demo worked as advertised. Just like Abe said!

Test #2
I took a demoboard and added a GG microSD module (hopefully, I'll get product placement points!) to the breadboard.
P0 -> CS
P1 -> Di
P2 -> Clk
P3 -> Do

I added these lines to the released demoboard.cfg file:

kbclk-pin: 27 # added to make demo run
kbdat-pin: 26 # added to make demo run
sd-driver: sd_driver.dat
sdspi-do: 3
sdspi-clk: 2
sdspi-di: 1
sdspi-cs: 0

hooked the demoboard up in place of the C3 and loaded the program. It totally worked without any code changes.

This is very VERY NIFTY!!!

I haven't played with the configvar.zip files from post #3 yet. Would these (variables.cfg) take precedence over the board.cfg values or would the board.cfg values take precedence? Or am I misunderstanding the use of this file?

The use of the *driverlist and isn't intuitive to the beginning c programmer.

On reading the code, it would appear that stdio is all linked to the simpleserial as normal but somehow, stdin is linked to the keyboard driver and stdout (and stderr?) is linked to the TV driver - when does this magic take place. It does seem like magic at this point.

Seeing this magic and the potential with the loader variables, another idea pops up - since this program is just using standard character IO, would it be possible to patch in either the TV, VGA or serial output driver at loader time? This would allow the same program to run on any of the three typical output devices without recompiling or changing code, just change the .cfg variable for stdio.

This is such a good demo for the many good techniques and features it shows: .cfg variables, redirecting stdio (once that voodoo is understood), writing interfaces between propgcc and .spin drivers and running multiple Cogs (even though it isn't visible, it happens!)

I'll play with the variables.cfg more and start writing some tutorial around it. I also have a Quickstart I can build up with TV and SD to put another set of variables into play.

BRAVO!!!!

mindrobots

This is very powerful magic!!

This feature allows you to add custom cfg variables to a .cfg file and as long as you match your names, you can have the loader substitute values.

For example with the C3, the LED you can blink is on pin 15.

In my .c program, I add:

int _cfg_status_led = -1;

to my program as a global variable (outside of any function definitions so the loader can find it)
and to my c3.cfg file, I add:

    status-led: 15

inside my program I can toggle _cfg_status_led to my heart's content.

If I want to run the same blinky program on a QuickStart, I can add:

    status-led: 16

to the quickstart.cfg file and it will work with pin 16 as my target LED.

GOOD STUFF!!

I understand the requirements for changing the stdio devices and what is needed now - a couple hours of painful reading of C code later, things clicked!! My redirection of stdio through the .cfg values seems doable now but not something that should be expected to be a standard feature and would introduce a lot of bloat to non-XMM programs. I sure learned a lot poking through the code, though!!

jazzed

mindrobots wrote: »

This is very powerful magic!!

Can I quote you on that?


The LED example is good exercise. Glad you got it. David Betz added config variable patching to make hardware configurations easier. Thanks David.

mindrobots wrote: »

I understand the requirements for changing the stdio devices and what is needed now - a couple hours of painful reading of C code later, things clicked!! My redirection of stdio through the .cfg values seems doable now but not something that should be expected to be a standard feature and would introduce a lot of bloat to non-XMM programs. I sure learned a lot poking through the code, though!!

I have library documents that will help understanding the stdio devices and many other things, but the package is not complete yet. It should be ready next week.

Thanks,
--Steve