QuickStart board tests
Rsadeika
Posts: 3,837
I just got in my QuickStart board, I ran my LED test program, which worked as expected. I also hooked up the uSD reader, which also worked as expected, so far so good.
Since this new board is supposed to have a 64KB EEPROM, are there any programs for checking out the EEPROM. I thought I remember someone mentioning that you can use XMM on the upper half of the EEPROM, I could be mistaken in what I remember.
For the tech guys, on the header, there is a Vin connection, can I hook my Li-ion Power Pack/Charger to this connection, without frying anything? The tech information for the regulator states that it can handle up 12VDC @1AMP, is this correct? Is their any easy way of picking a 5V supply on the QSboard, maybe off of the header?
Ray
Since this new board is supposed to have a 64KB EEPROM, are there any programs for checking out the EEPROM. I thought I remember someone mentioning that you can use XMM on the upper half of the EEPROM, I could be mistaken in what I remember.
For the tech guys, on the header, there is a Vin connection, can I hook my Li-ion Power Pack/Charger to this connection, without frying anything? The tech information for the regulator states that it can handle up 12VDC @1AMP, is this correct? Is their any easy way of picking a 5V supply on the QSboard, maybe off of the header?
Ray
Comments
I put a QuickStart on a BOEBOT chassis, and use the USB for programming. I never have battery and USB connected at the same time just for caution [edit: there is a protection diode on the Vin circuit that should protect the USB from higher battery voltages]. The BOEBOT battery pack is only 6V. The little SMD regulators can usually take 15VDC or higher.
You can put your own XMMC program in the EEPROM and run it by using the following propeller-load:
propeller-load -b quickstart -r -t yourprogram.elf
If you want to make your program run after reboot (i.e. persist in the EEPROM), then:
propeller-load -b quickstart -e -r -t yourprogram.elf (this might hang)
propeller-load -b quickstart -r -t yourprogram.elf
Note that the first propeller-load might not run your program and instead hang; this will be fixed when the next version of propeller-load comes out because it has a "eeprom-first" fix for this, but you'll have to add "eeprom-first: TRUE" to your quickstart.cfg or else use "-b eeprom". However, you need to follow it with another propeller-load "-r" but without the "-e".
An interesting fact: The -e flag tells propeller-load to install the XMM kernel and boot loader into the EEPROM. However, whenever you propeller-load your XMMC program to the QuickStart board (even just to run it), propeller-load automatically writes the non-kernel code to the EEPROM (after the first 5K or so). So, after you run the propeller-load command with the "-e", you never need to do it again (unless you whack the first 5K or so of your EEPROM).
This also means you must be aware of this caution: When you upload an LMM program to an EEPROM system with the -r flag, you do not disturb the EEPROM. However, whenever you upload an XMMC program with the -r flag, you always disturb the EEPROM.
One more caution: XMM (as opposed to XMMC) programs will not work on the QuickStart.
Propeller Version 1 on COM7
Writing 4556 bytes to Propeller RAM.
Verifying ...
1496 bytes sent
932 bytes sent
1720 bytes sent
Download OK!
The second program was filetest.c, the uSD program. The program compiled and ran in XMMC mode, but when I typed in 'ls' the program came back with an 'IO' error. The program did show "Card Detected", but it seems like the file system did not get mounted. Info for XMMC mode:
Propeller Version 1 on COM7
Writing 4556 bytes to Propeller RAM.
Verifying ...
1496 bytes sent
27784 bytes sent
1724 bytes sent
Download OK!
In XMM mode the program got compiled and loaded, but crashed on the "Card Detect" portion. Info for XMM mode:
Same as above.
Do I conclude from this that in XMM, and XMMC modes, I can have 64KB(32KB on chip, and 32KB EEPROM) of memory to program with? Also, what does this mean? :
Writing 4556 bytes to Propeller RAM.
Verifying ...
1496 bytes sent
27784 bytes sent
1724 bytes sent
Ray
XMMC mode must be used with EEPROM and other devices like Flash and SDcard.
XMMC means XMM code only. Normal XMM mode uses external memory for code and data.
Fortunately, we do not allow any writes to EEPROM in XMM mode.
@denominator thanks for mentioning eeprom-first.
I'm adding them to EEPROM based configs for ascp, hydra, quickstart, protoboard in the next package.
--Steve
Ray,
As Steve mentioned, XMM mode (as opposed to XMMC) does not work unless you have an external RAM memory of some sort. The fact this worked for you at all is a fluke - a larger program that actually uses data will most likely hang or fail unpredictably. (I have suggested to the developers that we somehow detect this and warn you that it will not work.)
What kind of media are you using? SDHC media will not work properly, you currently must use a SD card.
No, your board has a 64K EEPROM, so you have about 83K to work with in XMMC mode in your setup: you have 64K - 5K (i.e. about 59K) for your code, and 32K - 8K (i.e. about 24K) for data. The missing 5K for code represents the kernel and cache memory driver; the missing 8K for code represents the code cache.
As mentioned above, the QuickStart card does not support XMM unless you connect SRAM to it and write a driver for that RAM (non-trivial).
What version of PropGCC are you using? Both the 0.2.2 and 0.2.3 versions spit this out when you load the prop:
This format tells you exactly what is going on.
- Ted
When I run filetest.c in LMM mode, the program works just fine, no problem with the uSD card. When I run the program in XMMC, then I have the problem with the uSD card, I think the dfs_mount() subroutine is not working correctly in XMMC mode, if that is possible.
As I mentioned in post#4, I am using the latest SimpleIDE, not sure what version of PropGCC gets loaded up, but I would guess that it is the latest.
Ray
Your version of filetest.c contains code that looks like this __PROPELLER_LMM__ is defined only when you compile in the LMM mode. This code will not be enabled in the XMMC mode. I suggest that you delete the conditional compile directives so that this portion of the code will look like. That should make it work in any mode.
Ray
// // file = QS_padscan.c // propgcc conversion of JonnyMac's SPIN version of Quickstart Button Demo // simple propgcc tutorial demo // // copyright 2011 by Rick Post // terms of use below // #include <propeller.h> int scan_pads(long int delay) { OUTA |= 0x000000ff; // "charge" the pads - force them HIGH DIRA |= 0x000000ff; // set them as output DIRA &= 0xffffff00; // release touch pads back to input waitcnt(delay+CNT); // delay for a "touch" // a touched pad goes to LOW // so if you invert the input bits you can mask them out // and return the "touched" pads as HIGHS return ((~INA) & 0x000000ff); // return the touched pads } int main(void) { int pads = 0; DIRA |= 0x00ff0000; // set LEDs for output and pads for input DIRA &= 0xffffff00; while (1) { pads = scan_pads(CLKFREQ / 100); // scan the pads passing delay to wait for user touch pads = pads << 16; // shift the pad pins (0..7) to the LED pins (16..23) OUTA &= 0xff00ffff; // clear out the scanned pads from last time OUTA |= pads; // set the most recent scanned pads } return(0); } /* +-------------------------------------------------------------------- TERMS OF USE: MIT License +-------------------------------------------------------------------- Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. +-------------------------------------------------------------------- */I'll have to try it when I get home later today. I thought it working as intended and expected when I shared it with the world. Sometimes the touch pads on the QuickStart are fickle but 4 not working and one stuck doesn't seem right.
I just did that, and I do not get an "IO error", I just get a blank line. The same thing happens with "ll", a blank line.
Ray
I just loaded the code you pasted into your thread and ran it on a Quickstart board. It ran fine and lit the LEDs above any keypad that was touched. The Quickstart pads are sensitive - some on my board think they are touched when I touch the edge of the board.If you go back and look through the early Quickstart threads, you will see a number of people getting different button responses from their Quickstarts. They are environmentally sensitive.
My code is rather simple, it just reads the pads (scans the 8 bits for any "presses") as 8 bits. The main code takes this 8 bit value and shifts it to the left 16 bits to line it up with the LEDs and uses that shifted value as the mask for the OUTA. For a while, my 7 button was very sensitive so it was lighting along with others. There's nothing in the code that would light a specific LED or cause 1/2 the buttons to work. All buttons are scanned (0xFF) and used for output to the LEDs so if L19 is always lit, P3 must be always indicating pressed.
Yes, the program runs just as expected, in LMM mode.
I just solved the mystery. I had my uSD card reader plugged into p0 - p4, when I removed the Vcc, and Vss from the card reader, it solved part of the problem. I had to remove all of the wires from the header, in order for the qs_pad.c to work correctly.
Since the uSD card reader behaves the best, when it is using p0 - p4, or so I have read, will the connection of the LEDs, and the pads become a hidden problem for those pins, when other things get attached there? You would think that their would be away to get around this problem, if it is a problem.
Ray
In the program below, I noticed that the "printf("%d %d %d\n",h,m,s);" the data values, in the terminal, get spaced about nine characters apart. How do I minimize that spacing? I also noticed that in the main() while loop, when I request the time to get printed, I just keep getting zeroes displayed, I am not sure what is causing that. Any help will be appreciated.
Ray
/* * datalog.c */ #include <stdio.h> #include <propeller.h> #include <unistd.h> #include <pthread.h> volatile int h,m,s; volatile h = 0; volatile m = 0; volatile s = 0; void *TimeClock(void *argv) { pthread_set_affinity_thiscog_np(); while(1) { if (s > 59) { m = m + 1; s = 0; } if (m > 59) { h = h + 1; m = 0; } if (h > 11) { h = 0; m = 0; s = 0; } sleep(1); s = s + 1; } } int main(int argc, char* argv[]) { int buffer; pthread_t thr; pthread_create(&thr, NULL, TimeClock, NULL); sleep(1); printf("This is the DATALOG program.\n"); sleep(4); printf("HOUR:MINUTE:SECOND\n"); printf("%d %d %d\n",h,m,s); while(1) { fflush(stdout); buffer = getc(stdin); if (buffer == '1') { printf("%d %d %d\n",h,m,s); } } return 0; }[php]
printf("%02d:%02d:%02d\n",h,m,s);
[/php]
[ugh. forum software eats %'s]
This gives printf details: http://www.manpagez.com/man/3/printf/
As for the functionality of your program ... this looks like it may be a pthread bug.
Move pthread_create to just after the first sleep(1) and it works fine in one case.
Eric or anyone have ideas ?
Added:
You shouldn't do this:
volatile int h,m,s;
volatile h = 0;
volatile m = 0;
volatile s = 0;
Do this instead:
volatile int h = 0;
volatile int m = 0;
volatile int s = 0;
The following program works in both LMM and XMMC mode. Here are the fixes:
* getc() doesn't yield the processor to other threads. So instead:
- Use FullDuplexSerial instead of SimpleSerial; FullDuplexSerial is thread-safe
- Unfortunately, feof(stdin) is the "standard" way of determining that there's a character ready for input. This doesn't work in PropGCC (this could be considered a bug in the library), so instead call the underlying FDSerial driver directly. Note that this is non-standard, but works.
* TimeClock was subject to drift because sleep(1) will return some undetermined amount of time after one second (e.g. if other threads don't yield often enough); so it was re-coded to make sure it accurately processes seconds.
* The sleep() function appears busted in XMM (appears to be a bug in the library), so provided an alternative.
* Used %02d in printf()
/* * datalog.c */ #include <stdio.h> #include <propeller.h> #include <unistd.h> #include <pthread.h> #include <driver.h> extern _Driver _FullDuplexSerialDriver; _Driver *_driverlist[] = { &_FullDuplexSerialDriver, NULL }; volatile int h,m,s; void *TimeClock(void *argv) { pthread_set_affinity_thiscog_np(); printf("Hi from TimeClock\n"); unsigned long now = CNT; long diff; while(1) { pthread_yield(); diff = (long)(CNT - now); if (diff < CLKFREQ) continue; now += CLKFREQ; s = s + 1; if (s > 59) { m = m + 1; s = 0; } if (m > 59) { h = h + 1; m = 0; } if (h > 11) { h = 0; m = 0; s = 0; } } } extern int _FdSerial_rxcheck(void* data); #ifdef __PROPELLER_XMMC__ unsigned int sleep(unsigned int n) { unsigned long now = CNT; long diff; while(n) { pthread_yield(); diff = (long)(CNT - now); if (diff < CLKFREQ) continue; now += CLKFREQ; n--; } pthread_yield(); return 0; } #endif int main(int argc, char* argv[]) { int buffer; pthread_t thr; printf("Hi from main\n"); pthread_create(&thr, NULL, TimeClock, NULL); printf("Starting main thread\n"); sleep(1); printf("This is the DATALOG program.\n"); sleep(4); printf("HH:MM:SS\n"); printf("%02d:%02d:%02d\n",h,m,s); while(1) { pthread_yield(); if (_FdSerial_rxcheck((void*)stdin->drvarg[0]) == '1') printf("%02d:%02d:%02d\n",h,m,s); } return 0; }volatile int h, m, s;
h = m = s = 0;
Actually, no initializers are necessary. By definition, any non-local (i.e. file-static or global) variables are initialized to 0.
I also had to add a sleep(1) in the TimeClock() function, without it, the messages in the main() would not display.
In the main(), I was trying to get "printf("\n>") to work, but it seems that it is appearing in all the wrong places. Also, the pthread_create(), I expected the "Hi from TimeClock" to appear first before the "Hi from main" message. It seems that the start of the pthread is lagging quite a bit, at least that is my perception.
I ran this in LMM, and XMMC modes, and the program appears to be the same in both instances.
Since denominator mentioned that their was possibly a problem in XMM mode, I am assuming that he is testing this code on a C3? Since I am getting some different results, could their be a possibility that this code is running differently on a QuickStart, or are their some differences between running the code in SIDE, and the command line?
Ray
/* * datalog1.c */ #include <stdio.h> #include <propeller.h> #include <unistd.h> #include <pthread.h> #include <driver.h> extern _Driver _FullDuplexSerialDriver; _Driver *_driverlist[] = { &_FullDuplexSerialDriver, NULL }; volatile int h,m,s; void *TimeClock(void *argv) { pthread_set_affinity_thiscog_np(); sleep(1); printf("Hi from TimeClock\n"); unsigned long now = CNT; long diff; while(1) { pthread_yield(); diff = (long)(CNT - now); if (diff < CLKFREQ) continue; now += CLKFREQ; s = s + 1; if (s > 59) { m = m + 1; s = 0; } if (m > 59) { h = h + 1; m = 0; } if (h > 11) { h = 0; m = 0; s = 0; } } } extern int _FdSerial_rxcheck(void* data); #ifdef __PROPELLER_XMMC__ unsigned int sleep(unsigned int n) { unsigned long now = CNT; long diff; while(n) { pthread_yield(); diff = (long)(CNT - now); if (diff < CLKFREQ) continue; now += CLKFREQ; n--; } pthread_yield(); return 0; } #endif int main(int argc, char* argv[]) { int buffer; pthread_t thr; sleep(1); pthread_create(&thr, NULL, TimeClock, NULL); printf("Hi from main\n"); printf("Starting main thread\n"); printf("This is the DATALOG program.\n"); printf("HH:MM:SS\n"); printf("%02d:%02d:%02d\n",h,m,s); printf("> \n"); while(1) { pthread_yield(); if (_FdSerial_rxcheck((void*)stdin->drvarg[0]) == '1') { printf("%02d:%02d:%02d\n",h,m,s); printf("\n>"); } } return 0; }00:00:00
>
and not:
>00:00:00
The good thing is that it seems like the clock is working correctly.
Ray
Next I would like to add a 'Set Time' command, it will be '2', but I am not sure how I would capture '00:00:00' with the time, in military mode, and update those values in the TimeClock() pthread. Using the existing example, I can capture the '2' but how do I deal with the rest. At some point I guess it would be nice to add a 'day of the week' item, but that sounds like it might be very code hungry.
I also want to implement a random event, like an LED flashing at random intervals, in a pthread. Does C have a random number generator? After I get this working, then I will add the uSD card program, and have the program capture and log the event on an uSD card, maybe for a twenty four hour time frame, as a start.
Also will probably need a '3 - Start log', and '4 - Stop log' choice, while testing in terminal mode. If all this works, then I will probably figure out how to use a pad(s) to start/stop the data log process while it is running off of some batteries.
Ray
/* * datalog1.c */ #include <stdio.h> #include <propeller.h> #include <unistd.h> #include <pthread.h> #include <driver.h> extern _Driver _FullDuplexSerialDriver; _Driver *_driverlist[] = { &_FullDuplexSerialDriver, NULL }; volatile int h,m,s; void *TimeClock(void *argv) { pthread_set_affinity_thiscog_np(); /* sleep(1); printf("Hi from TimeClock\n"); */ unsigned long now = CNT; long diff; while(1) { pthread_yield(); diff = (long)(CNT - now); if (diff < CLKFREQ) continue; now += CLKFREQ; s = s + 1; if (s > 59) { m = m + 1; s = 0; } if (m > 59) { h = h + 1; m = 0; } if (h > 11) { h = 0; m = 0; s = 0; } } } extern int _FdSerial_rxcheck(void* data); #ifdef __PROPELLER_XMMC__ unsigned int sleep(unsigned int n) { unsigned long now = CNT; long diff; while(n) { pthread_yield(); diff = (long)(CNT - now); if (diff < CLKFREQ) continue; now += CLKFREQ; n--; } pthread_yield(); return 0; } #endif void menu(void) { printf("0 - menu\n"); printf("1 - Time\n"); } int main(int argc, char* argv[]) { int buffer; pthread_t thr; sleep(1); pthread_create(&thr, NULL, TimeClock, NULL); printf("Hi from main\n"); printf("Starting main thread\n"); printf("This is the DATALOG program.\n"); menu(); printf("HH:MM:SS\n"); printf("%02d:%02d:%02d\n",h,m,s); printf(">"); fflush(stdout); while(1) { pthread_yield(); if (_FdSerial_rxcheck((void*)stdin->drvarg[0]) == '0') { printf("\n"); fflush(stdout); menu(); printf(">"); fflush(stdout); } else if (_FdSerial_rxcheck((void*)stdin->drvarg[0]) == '1') { printf("%02d:%02d:%02d\n",h,m,s); printf(">"); fflush(stdout); } } return 0; }XMM mode is invalid for boards without RAM.
XMMC is the only valid external memory mode valid for QuickStart as is.
Generally you should be using standard printf with pthreads programs.
IMHO, a data logger application should not be using pthreads.
Such a program should be using Propeller's native multi-processing abilities with cognew.
There is a COG based RTC in the library. I'm working on an example for you.
Of course, trying to use pthreads for this has exposed certain weaknesses.
While the weaknesses are not good, knowing that we have them is for bug fixes.
Thanks for your continuing efforts and patience.
--Steve
If I were using Spin, then of course I would have a simulated RTC running in its own cog, the external event running in its own cog, and the uSD running in its own cog. But I am working with PropGCC, and trying to figure out how PropGCC should be used to the best advantage.
In my case, testing software with some real projects works best for me, I am not sure about everybody else, they may have different ideas about how to test things.
In conclusion, this should be lots of fun, and maybe a little excitement when a test project comes together, and it works.
Ray
Ray,
Sorry for the confusion. The bugs I mentioned are in XMMC mode; presumably they are in XMM mode as well. I was using a Protoboard in EEPROM mode to mimic what you're seeing on your QuickStart.
- Ted
Steve,
A quick note about the library's RTC: Last time I looked, using the RTC and the associated time libraries took between 8K an 9K. This is OK for XMM/XMMC programs, but in LMM it's just another space killer. And you either have to use a separate cog to keep the RTC updated, or make sure you poll it regularly.
When faced with this situation in a C program, I've always used a separate cog whose whole job was to waitcnt for a second's worth of cycles, then increment a counter.
Another scheme I played with is using the cog's counters: Set one counter in a duty cycle mode to produce 1000 ticks/second, and the set the other counter as an edge detector on the first counter's output. That way the second counter holds a clock containing the number of millisecnds. Two notes: (a) this burns both your counters and an output pin (b) you could have the first counter tick of once per second instead of 1000 times/second, but because the typical clock rate of 80,000,000 does not divide evenly into 2^32, it would cause the clock to be off by 1%.
- Ted