What steps will reproduce the problem?
1. Create a simple program (test.c):
#include <stdio.h>
void main()
{
while (1) printf("Hello World\n");
}
2. Compile and load to a propeller thus:
propeller-elf-gcc -O2 -mfcache -mlmm -o test.o -c test.c
propeller-elf-gcc -mlmm -fno-exceptions -fno-rtti -o test.elf test.o -s
propeller-load -b <yourboard> test.elf -r -t
This should work fine; you will see loads of "Hello World" lines.
3. Now, change propeller-load.cfg's "baudrate" for your board to 57600. Or,
use the following loader command:
propeller-load -b <yourboard> -Dbaudrate=57600 test.elf -r -t
What is the expected output? What do you see instead?
I would expect that I would see lots of "Hello World" lines again. Instead I
see a lot of garbage.
What version of the product are you using? On what operating system?
propgcc-0.2.2
Please provide any additional information below.
Apologies, but the full Discussion is a bit wordy...
*** Summary:
My goal is to be able to use serial communications with a reduced baud rate. I
cannot do this in what appears as the most straight-forward way, but I can do
this by a series of work-arounds. IMHO, either propgcc should either fix the
situation to work in the most straight-forward way, or we should document and
thus formalize the work-arounds.
*** What I thought should work:
It is clear that the propeller-load program dynamically patches the clkfreq and
clkmode from propeller-load.cfg into executable. The fact that
propeller-load.cfg contains the baud rate, rx/tx pins, and tv pin(s) implies
that the loader will dynamically patch these values into the executable.
Further evidence is this snippet taken from lib/cog/cogserial.c:
/* globals that the loader may change; these represent the default
* pins to use
*/
unsigned int _rxpin = 31;
unsigned int _txpin = 30;
unsigned int _baud = 115200;
So I thought the easiest thing to do would be to change the baudrate in
propeller-load.cfg. This obviously does not do the correct thing. I
double-checked the propeller-loader source code, and found that
loader/src/loader.c does patch the serial_helper loader with the tx/rx/baud/tv,
but that's about it - nothing (particularly not BuildInternalImage()) patches
the final executable with rx/tx/baud.
Thus, it appears that the loader functionality to patch baud/pins is either
unplanned or still TBD.
*** What I did to make it work:
I included the following line at the start of my main() routine:
freopen("SSER:57600,31,30", "w", stdout);
I loaded the propeller with this command:
propeller-load -b <yourboard> test.elf -r -t57600
Notice that I did not include the -Dbaudrate=57600, because that just slows
down the load.
*** Explicit Requests For Fixes
Your response is most likely to be "Yep, that's the way it works, your
work-around is the right thing and we're not planning on fixing any code to
patch the baud/rx/tx in the final executable". Therefore, please add the
following information to http://code.google.com/p/propgcc/wiki/PropGccLoader:
** Start Quote **
Note: The loader uploads a small helper program into your Propeller to help it
perform the final loading. The loader patches the clkfreq and clkmode into
both this helper program and also your final program. However, the baudrate,
rxpin, txpin, and tvpin specify the paramaters that the loader and helper
programs use when transferring your program to the propeller, and also in
terminal mode after your program starts running. These values *are not*
patched into your executable for use during normal program execution. You
should keep the loader's baudrate at a high value (but one that is still
reasonable for your board configuration) so that your program loads as quickly
as possible.
However, you will need to take special measures if the loader's baudrate does
not match the program's baudrate (e.g. you set the loader's baudrate to a value
other than 115200, or if your program sets its baudrate to a value other than
115200). Please see the Propeller GCC Library (link to
http://propgcc.googlecode.com/hg/doc/Library.html) for information on how to
set the baud rate in your program. See the -t<baud> option below for
information on how to specify that terminal mode's baud rate matches your
program's baud rate.
** End Quote **
One reasonable place to add this is after "The -D variables are listed in the
help output" and the ensuing 10-item list.
If on the other hand, if your response is "Yep, we know that those variables
are not being patched into the executable, we just haven't gotten around to it
yet", then please still add a message explaining the serial helper and how/when
the baudrate/rxpin/txpin get patched into the binary. And it would be nice to
be able to specify two sets of parameters, one for loading and one for running.
*** Why am I messing around with baud anyway?
I need to work around two requirements:
- My application runs on an Spin Stamp in low power mode (battery operated).
Therefore, I run the Propeller in XTAL1 mode (no PLL), yielding a 10MHz clock.
- I want to use printf() for debugging, but I don't want to give up the extra
cog for the FDSerial driver.
With a 10MHz clock, SimpleSerial will not work above around 19200 baud.
Therefore I must change the baud rate.
*** Other Foolery
I've noticed that the propeller-loader will not work with baud rates below
38400 (at least in my Spin Stamp connected to my desktop). Furthermore, the
FDSerial and Simple Serial drivers will not work with baud rates below 9600.
My best guess is that this is a problem with the FTDI drivers not the
loader/library code. However, because it seems to fail with all revs of the
driver I could test, I'm not sure of this. I just thought that I'd mention
this in case someone else sees it and cares, but I'm unlikely to want to use
baud rates that low.
Original issue reported on code.google.com by tjstefan...@charter.net on 28 Jan 2012 at 10:55
Original issue reported on code.google.com by
tjstefan...@charter.neton 28 Jan 2012 at 10:55