Re: PropCS - a small project
Everything is now working... mostly. I am not sure what is happening, but sometimes the SD card (cheap Kingston 2GB) gets locked, hung, or something? I have to remove it and put it back in to clear it and get things working again.Originally Posted by jazzed
Not a problem unless I have my board in a case.
Re: PropCS - a small project
I just got my GG PPUSB board up and running, I noticed the same thing, as you describe, was happening to me. The uSD card that I used was working perfectly on the C3 board. I am starting to suspect that maybe it is the card reader on the GG board that is the problem. I am using a Microcenter uSD card, that is on the cheap side.Everything is now working... mostly. I am not sure what is happening, but sometimes the SD card (cheap Kingston 2GB) gets locked, hung, or something? I have to remove it and put it back in to clear it and get things working again.
Ray
Re: PropCS - a small project
I changed back the revision I made to the 'cat' command, as Ted explained it, now I know what it is supposed to do. I added the explanation to the ManCat() file.
For my ManMisc() file I need a good explanation for how the redirection works. I tried 'echo This is >> test1.txt', it created a test1.txt file and inserted 'This is', but so did the use of just '>', what is the difference? Now I am wondering if you use something like test1.txt << echo this is', would you get the same results?
Also I noticed there is a 'pwd' command, not sure what this is. If it is a way of producing a password, interesting, but how would that work?
Ray
Re: PropCS - a small project
pwd = print working directory
> says direct the output into the file, deleting the old file if it exists
>> says direct the output into the file, appending to any previous file that may exist.
So:
>echo foo > bar
>cat bar
foo
>echo foo > bar
>cat bar
foo
>echo foo >> bar
>cat bar
foo
foo
>echo foo > bar
>cat bar
foo
>
Re: PropCS - a small project
Ray.
filetest.c was developed to test out the file driver in PropGCC. I used the "software tool" approach, where I wrote simple functions that could be combined together to do some basic testing. The software tools along with the basic redirection operators provide a flexible and compact program that could fit in 32K in the LMM mode. I like what you've done with PropCS. It's looking good. As Steve suggested, you might want to name your *.h files to *.c to conform with normal C practice. Of course, it works fine the way you have it also. BTW, there is no << redirection operator. There is only <, > and >>.
If you have access to a Linux machine or a Windows machine with Cygwin you might try out the commands to see how they work there. If you don't have access to either one you could download Spinix and try it our on a Prop. I've added quite a few Linux-like features to it.
Dave
Re: PropCS - a small project
Below is another version of PropCS, which has a problem that I can not figure out. I am trying to add a PPUSB in the mount() function, using SimpleIDE, when I compile I get an error: redefinition of 'params'. This 'params' seems to appear in the other board definitions, but only becomes a problem when I add the PPUSB code.
I also tried to move the printf.c code into PropCS_uni.c, having the notion that if I use an '#ifdef __PROPELLER_LMM__' for control , I would not have to remember to have printf.c added to compile when using LMM mode. The problem here is, that when I compile, it comes up with a not enough memory error. The question I have is, why does it not come up with a memory error when it is compiled with the PropCS_Uni.c and printf.c?
Ray
Re: PropCS - a small project
Ray,
This error occurred because you have two blocks that say #ifdef PPUSB: one at line 395, and one at line 476. And, you also have a #define C3_CARD at line 455. Therefore, you are triply-defining params!
The solution is to change "#ifdef PPUSB //PARALLEL_SPI" on line 476 back to "#ifdef PARALLEL_SPI", remove the #define at line 455 (or comment it out), and fix the #ifdef PPUSB block at line 395 to be appropriate for the board you're working with.
You most likely get the "not enough memory" error because your #ifdef isn't correct, the C compiler isn't seeing your code, and therefore is linking in the standard printf(), which is much bigger than the code in printf.c.
Try this... put the following code at line 20 of your PropCS_Uni.c:
If you compile, all is well. Then, change #ifdef __PROPELLER_LMM__ in some subtle way, for example, change LMM to MMM, or delete one of the underscore characters. You'll get the memory error.Code:#ifdef __PROPELLER_LMM__ #include "printf.c" #endif
The reason is "#ifdef" says "if defined". Nothing makes sure the symbol is in the symbol table - if it's not defined, that block of code is just ignored.
When debugging #ifdef problems, it is often useful to look at the preprocessor's output. If you include --save-temps (note the two dashes at the start) in your command line, you should see a PropCS_Uni.i file in your project directory. You can then look to see what the preprocessor did, and can fix any problems you find.
- Ted
Re: PropCS - a small project
I just tried the 'Send file to target SD card:' , which compiled, and made an autorun.pex file which I specified to be put on the SD card. When I hit the reset button, nothing happened, I was expecting a program to start and run. I tried the 'Burn' option which in fact worked, when I did a reset, it started up a program. So, I am not sure if I missed a step when I did 'Send file to target SD card:', or what?
Now that I have this relatively large program that I can start off of an SD card, what do I have to do to be able to have it run on a personal terminal screen? I think the last time I tried using pins 31,30 for accessing a personal terminal screen, it was running into problems. Has this been taken care of, or there never was a problem to begin with?
The other thing that I am thinking about is running small programs that would be located on the SD card, which I would call from within a program. For instance, in my PropCS program I would have a command 'GetIt', the actual command code would be on the SD card, and would be accessed from within PropCS? Am I expecting to much?
Ray
Re: PropCS - a small project
Ray,
You didn't make a mistake. In order to run your program from the SD card, you need a program called the SD Cache Loader. When you send to SD card, the loader sends a program into Propeller RAM via the Propeller's built-in boot loader. That program is called the Serial Helper. The loader and the Serial Helper then communicate; the loader sends up your program for placement on the SD card, and the Serial Helper does the actual writing. Then, the loader resets the Propeller and sends yet a new program up in the Propeller RAM (again via the Propeller's built-in boot loader) - this program is called the SD Cache Loader. The loader then tells that program to run.
The SD Cache Loader looks at the SD card, finds AUTORUN.PEX, caches the sector map for the entire program, loads the XMMC kernel and the SD Cache Driver, and then hands over control to the kernel. At this point, your program is running, but nothing was written to the EEPROM!
When you select "Burn", the loader in its last step, send the SD Cache Loader to the Propeller, sends it to both RAM and EEPROM. That way when you reset the Propeller, the SD Cache Loader lives again and can refind your AUTORUN.PEX and re-run it.
Interestingly, if you take the SD card out at this point, insert it into a PC, change AUTORUN.PEX to a different program, reinsert it into your Prop board and reset it, then the new program would run. For the same reason, if you use Simple IDE to "Send file to target SD card" with a new program, then hit reset, your new program will run. This is because the magic SD Cache Loader is already in your Propeller's EEPROM.
- Ted
Last edited by denominator; 04-14-2012 at 07:21 PM. Reason: typos.
Re: PropCS - a small project
Ray,
I'm not sure what you mean when you refer to "accessing a personal terminal screen".
As far as loading programs using PropGCC, AFAIK, nobody has done this. However, it sounds like you are re-creating Dave Hein's Spinix (http://forums.parallax.com/showthread.php?123795-spinix) in C. His Spin code would be a great guide for this task, but beware the memory usage for Spin and PropGCC differ, so there are probably a few landmines you'll want to navigate around.
- Ted
Re: PropCS - a small project
Actually, I have not looked at Dave Hine's Spinix program, I want to keep an open mind about how I will be coding my small project. I am not sure about what you mean about "memory usage" differences.
I'm not sure what you mean when you refer to "accessing a personal terminal screen".
As far as loading programs using PropGCC, AFAIK, nobody has done this. However, it sounds like you are re-creating Dave Hein's Spinix (http://forums.parallax.com/showthread.php?123795-spinix) in C. His Spin code would be a great guide for this task, but beware the memory usage for Spin and PropGCC differ, so there are probably a few landmines you'll want to navigate around.
- Ted
In the early days of PropGCC usage, I had a heck of a time trying to use pins 31,30 to communicate with a terminal program that is not the PropGCC terminal/SimpleIDE terminal. What I am thinking is, I have the C3 start up with PropCS, and on my computer I start a terminal program which is connected to the C3 with whatever port is available. In other words, communicating with the C3 without the use of SimpleIDE.
When the PropCS is running in stand alone, it would be nice to be able to start up programs that are on the SD card, just to see if something like that can be done. I personally do not think that it can be done, but I thought I would present the idea. That way you could keep the PropCS code as small as possible, and still have the capability to expand the 'commands' list.
The other idea that I had was trying to implement the UNIX '&' (background task?), so that means using pthreads, that is why I want to keep the PropCS code as small as possible. I am also staying away from thinking in terms of PropCS as a kernel, or an OS, just thinking that PropCS is some tight code that can run some specific commands.
Ray
Re: PropCS - a small project
Ray,
Re: the terminal. I'm assuming that you're using the same USB connection to your computer that SimpleIDE uses, so pins 31,30 are appropriate. I don't know for sure what your trouble was or the tool(s) you used, but I use propeller-load to talk to my boards and it works fine. I think a potential troublemaker is if subsequent serial terminal programs flash the DTR and cause the Prop to reset - so if your serial terminal program does this you have to burn to EEPROM. Besides "propeller-load -t" you could also try the Parallax Serial Terminal.
Re: stand alone. You should at least check out what Spinix does - it does almost exactly what you want to do, albeit with Spin. I think it may be possible if you're crafty enough. The memory differences I was referring to: C in XMM/XMMC mode has a cache from 0x6000 - 0x7FFF, the stack starts a few bytes below 0x6000, and the heap starts at the top of the data area in RAM (above any hub code and hub data). You have to load the program somewhere in that region safely and manipulate the linking of the subprogram to know about the higher address and also manipulate the kernel for the subprogram to play in that area. Spin has a different set of difficulties, so Spinix is a guide, not the solution.
Also see this thread: http://forums.parallax.com/showthrea...s-from-Hub-RAM
- Ted
Re: PropCS - a small project
As for the terminal program that I was referring to in an earlier post, I created it using Visual C#. What it is doing is, when I start the program, while I have PropCS running, it does a reset/reboot of the C3 board. I looked at all of the settings for SerialPort in the terminal program, and the only thing that I found that could help is an 'enable DTR - true/false, I have this set to false, but I did have it set to true , and the problem still occurs. Other than that, I did not see anything else that would change the way the terminal program works. I was thinking of maybe trying Visual C, but I do not think that I would be able to figure out what to do with SerialPort settings to make the program work correctly.
Since I have been working with SimpleIDE, and PropCS, I have found that the easiest way to use the IDE is to create a specific project. In this case I have a project name, PropCS_C3F-SDXMMC which has only that particular board selection in the mount() function, and all of the IDE settings needed to compile the program correctly. This way I have minimized the size of the mount() funtion, even when you are using the SD for larger program space you still have to try to keep the main code as small as possible, and it has the correct settings each time I start up the IDE.
Ray
Re: PropCS - a small project
SimpleIDE terminal toggles DTR when it closes the port. If you need another terminal program to run after programming I recommend using BURN or RUN buttons and not RUN Console.
This is good advice. I've had a little trouble by not following it.
Perception: sensory input filtered by past experience.
Re: PropCS - a small project
Ray,
I agree with you and Steve that it is easy to get confused by having too much stuff going on in the mount() routine. All those different setups are there to show you the options you have, and simplifying them to the board you're using will definitely make it easier for you to see what's going on.
However, I want to assure you that unless you define multiple board symbols, you are not using up any additional program space. The #ifdef foo .... #endif is a preprocessor directive. This means that if the controlling symbol (foo or whatever) is not defined, then the preprocessor will completely omit the enclosed code before passing the code to the compiler. Thus, because the compiler doesn't see the code, compiler does not generate any extra code - it's like the enclosed code never existed at all, other than taking up lines in the source file.
- Ted
Re: PropCS - a small project
What is the accuracy of the software RTC? Yesterday afternoon I decided to let the clock run for about 18 hours, making sure it would run past midnight. This morning, when I checked the RTC clock, which was running within PropCS, it was more than an hour and three minutes off. The real time was 6:30:00, but the RTC time was 7:33:00. I had the daylight savings set on, so I am not sure as to why it is showing an hour difference? Assuming the the hour difference can be fixed, I am not so sure that a three minute discrepancy on an 18 hour run could be of any practical use. So, where are those boards with an hardware RTC, I am not a board manufacturer, so the answer has to be with somebody else.
Ray
Re: PropCS - a small project
A crystal oscillator should be accurate to at least 100 PPM, which is 0.01 percent. After 18 hours you should have an error of less than 7 seconds. A 1 hour error is about 6% and a 3 minute error would be about 0.3 percent, which is still well above the expected error. If the error is really 6% you will see it lose 1 second every 18 seconds, or 10 seconds in 180 seconds. Check the time for a couple of minutes and see if you lose a few seconds druing that time.
If there is some weird daylight savings thing going on, then the error is only 0.3 percent, which may be due to how your oscillator is set up, in addition to how daylight savings is handled. Or maybe the RTC code isn't handling the rollover at midnight correctly. Try setting the time to 23:59:50, and see what happens after the midnight rollover.
Re: PropCS - a small project
I was just thinking about the Daylight Savings setting, does that mean that the software will automatically: Spring forward/Fall back? Tomorrow I will have to find the exact date for the Spring forward/Fall back, and see what happens.
Ray
Re: PropCS - a small project
The time library should change time based on this rule: DST goes from the 2nd Sunday in March to the first Sunday in November.
Perception: sensory input filtered by past experience.
Re: PropCS - a small project
This evening I will be doing another, possibly ~18 hour test. I will be setting up the date for March 10 2012 in non DST time, this will see what kind of accuracy I get, and if it really does the DST switch.
Since I am trying to get my board to work in stand alone, I am running into another problem. When I put my board in stand alone, meaning that the USB is unplugged, and running on the power plug. When I plug the USB back in, and start up a terminal program, it is always doing a reset, re-booting PropCS. I have tried this with SimpleIDE, Parallax Serial, and my own terminal program, they all re-boot PropCS when the USB is plugged back in. Now, I am not sure what I have to do to overcome this, let alone understand what is really happening, an explanation would be appreciated.
Since I have four different boards available I am now thinking about making one of the boards, maybe the QSboard, a development setup. Maybe somebody has a different idea as to what a development setup would look like?
Ray
Posting Permissions
Bookmarks