Tested on GadgetGangster Propeller Platform USB and Propeller Platform (with PropPlug).
steve@steve-laptop:~/spin$ uname -srv
Linux 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:17:33 UTC 2010
steve@steve-laptop:/usr/local/lib/catalina/bin$ ./payload ~/spin/helloworld.bin
Using Propeller (version 1) on port /dev/ttyUSB0 for upload
steve@steve-laptop:/usr/local/lib/catalina/bin$ nanocom /dev/ttyUSB0 -b 57600 -n
NANOCOM : Hit ESC for menu. ESC & Enter to quit.
Hello World
Hello World
Hello World
steve@steve-laptop:~/spin$ bstl.linux helloworld.bin
Brads SpinTool Loader v0.05 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 09:34:58 on 2009/07/03
Found a USB Serial Device
Propeller Version 1 Found!
steve@steve-laptop:~/spin$ nanocom /dev/ttyUSB0 -b 57600 -n
NANOCOM : Hit ESC for menu. ESC & Enter to quit.
Hello World
Hello World
**********Menu***********
1. Display Current Line Status
2. Set Bit Rate
3. Set Data Bits
4. Set Parity
5. Set Stop Bits
6. Set Flow Control
7. Set Echo Settings
8. Exit
9. Leave Menu
Enter. Exit
*************************
Hello World
steve@steve-laptop:~/spin$ uname -srv
Linux 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:17:33 UTC 2010
steve@steve-laptop:~/spin$
It does help indeed. I don't have nanocom for Ubuntu -- and apt-get install nanocom doesn't get it, so I'm not sure how to get that specific terminal. I downloaded microcom and did:
microcom -p/dev/ttyUSB0 -s57600
and then, while it is running, I did
bstl jazzedHelloWorld.binary
Normally this wouldn't work, because the serial terminal captures returning bytes that BSTL needs during the load cycle, and bstl would change the baudrate too -- but for some reason microcom lets me get away with it most of the time (it has slow response).
After that, about once a second -- a message prints on the serial terminal with the correct number of characters; but with totally wrong values (garbage). So, that suggests the baud rate is wrong (no surprise). That happens up and until I reset the GG: So that proves that BSTL *does* load your binary on my system, although something is still wrong with the serial settings. It also means that the serial terminal in BST is resetting the serial line when it starts up, (yucky bug) and that is what is causing the gadget gangster to reset.
microcom also causes the messages to stop printing when I exit it, and restart microcom to change the baud rate, (or simply starting it after the load is complete) verifying that there is a serial line reset problem. I might be able to fix this by keeping the serial port opened with a 'c' program that doesn't read data from the serial line, but the simplest fix is probably just to get nanocom which obviously works on your system -- and complain to the author of BST about the serial terminal reset of the GG.
Where did you get an Ubuntu version of nanocom? It's not the same as the one on source-forge, becuase that one acts differently.
Let's just say it's special and sometimes I'm a messy programmer - here's the source.
My machine is i686, and an i686 executable is in the nanocom directory.
I've added some special features like -n to append LF/CR on LF output.
Another feature is -x "string" which will cause the program to terminate if string is printed.
Also, get the menu by pressing ESC. Quit is ESC then ENTER.
The microcom program works fine for me. Please verify your crystal is 5MHz.
Let's just say it's special and sometimes I'm a messy programmer - here's the source.
My machine is i686, and an i686 executable is in the nanocom directory.
I've added some special features like -n to append LF/CR on LF output.
Another feature is -x "string" which will cause the program to terminate if string is printed.
Also, get the menu by pressing ESC. Quit is ESC then ENTER.
Thank you. Before I got your version -- I modified the source forge nanocom, and am able to get "Hello world" now using it. YAY!
I was correct, BSTL was downloading the file right and the garbage I was getting was the hello world.
The microcom program works fine for me. Please verify your crystal is 5MHz.
Yes, it is, it's an as-shipped GadgetGangester with no modifications except a soldered wire to take USB 5V power to the 5V input (That is not the problem. external power makes no difference).
I'll try yours in a minute -- but I won't be surprised if it doesn't work. Our systems are a little different -- though both are Ubuntu:
uname -srv
Linux 2.6.35-23-generic #40-Ubuntu SMP Wed Nov 17 22:14:33 UTC 2010
What's going on in my system is that when the USB serial port is opened or closed, a program (don't know which one, or if the kernel driver) is resetting the RS232 wire that goes to the propeller reset pin.
So long as I don't allow the port to close and re-open, eg: like do bstl and then launch nanocom -- then the chip does not reset; This is great except that BSTL will *change* the baudrate to 115200 which is why I get garbage characters;
So, I just modified nanocom to stop receiving characters when I select the menu "CTRL-T" (which frees the receive line problem up so that BSTL works right *every* time) and then, when I exit the nanocom menu, I have it restore the baudrate.
When I do that, I get "Hello World" as expected once a second; so that definitely is the problem on my system -- what is causing mine to be different than yours -- I don't know.
I'll compile your program and see if it works with your version on my system -- don't be surprised if it doesn't. Being as mine is a 64 bit system, it is possible that my serial driver behaves a little bit differently than yours -- I'll let you know in a little while. I do know that payload still doesn't work on my system; and I need to recompile that -m32 from original source just to make extra sure I didn't mess it up trying to fix it.
If i have for example:
i put a rect. on the screen.
now i put a nother rect on the screen and let it move arround changing the coordinates.
If the second rect hits the first one i want it to stop.
So the question is .. is there an easy way? or do i need to work with the coordinates and lenghts itself..?
What's going on in my system is that when the USB serial port is opened or closed, a program (don't know which one, or if the kernel driver) is resetting the RS232 wire that goes to the propeller reset pin.
So, I just modified nanocom to stop receiving characters when I select the menu "CTRL-T" (which frees the receive line problem up so that BSTL works right *every* time) and then, when I exit the nanocom menu, I have it restore the baudrate.
When I do that, I get "Hello World" as expected once a second; so that definitely is the problem on my system -- what is causing mine to be different than yours -- I don't know.
I'll compile your program and see if it works with your version on my system -- don't be surprised if it doesn't. Being as mine is a 64 bit system, it is possible that my serial driver behaves a little bit differently than yours -- I'll let you know in a little while. I do know that payload still doesn't work on my system; and I need to recompile that -m32 from original source just to make extra sure I didn't mess it up trying to fix it.
I think there must be another problem with payload, since it detects the Prop but doesn't appear to get a response to the "load" command (which follows pretty much immediately). My current thinking is that it might be the timing of detecting the response from the Propeller - this is about the only timeout that is not configurable in payload - it is fixed at 250ms by the following code in the prop_upload function:
count = 5; // 250 ms
while (count-- > 0) {
SendByte(port, 0xf9); // wait for the response
mdelay(50);
if (ByteReady(port)) break;
}
You might try tweaking that (e.g. set count to 10, or larger) to see if that helps.
If it's not that, then it must be a deeper problem with the ByteReady function. You might also log whether the select call within that function (in rs232.c) is unexpectedly returning an error.
Ok, I still haven't gotten to payload -- that's next; but at least I know the condition on Ubunto10.10 that is resetting the Gadget Gangster; this may be a kernel issue, or it may be a 64 bit compile of the kernel issue; I am not sure yet which -- but it is one or the other, so this might affect more than just Ubuntu users.
The kernel driver for the USB serial is resetting the DTR line whenever two events occur together -- a program "Opens" the serial port, followed by a writing of the terminal settings.
Jazzed's version of nanocom unfortunately causes the Gadget Gangster to reset as well as every other terminal program I have tried on this test Ubuntu 10.10, 64 bit system.
A second cause of reset is whenever the USB driver becomes totally closed -- that is no program has /dev/ttyUSB0 open at all. If I run bstl and it finished before the terminal program is started, the GG will be reset. (Very frustrating...)
So, for GG to work with the ubuntu10.10, 64bit system -- I must have a program which opens the serial port, and then can suspend use of it (no reads/writes).
I have a special compile of nanocom to do this task, I execute:
nanocomMod64 /dev/ttyUSB0 -b 57600 -p n -d 8 -s 1 -f n -e n
and then, once running, I press Control-T to put it in menu mode; The modification I made causes nanocom NOT to read the serial port while the menu is up. This allows file loaders to operate on the serial port without interference from nanocom; so in a different terminal I can execute:
bstl HelloWorldJazzed.binary
That one uploads Jazzed re-named test program to the GG. I can then switch back to the already running nanocomMod64 serial terminal program, exit the menu mode, and all data in the buffer will be printed, followed by "Hello world" at the correct baud rate. (Expect garbage at the top because of BSTL changing the baud rate to 115200, the baud will be corrected the moment the menu is exited.)
The nanocom program is fully functional, I didn't add Jazzed's modifications to it; but I can add that later once payload is fixed.
Alternately, once nanocom is running and in menu mode -- and BSTL finished load a program like simple.binary (115200 baud) -- I can use programs which do not change the baud rate like "cat /dev/ttyUSB0"
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
pst : "FullDuplexSerial"
PUB main
pst.Start( 31,30,0,115200 ) ' Rx=31, Tx=30
' ... more code follows... get simple.spin from the attached file.
Note: The correct RS232 (FullDuplexSerial) polarity for gadget gangster is NON-inverting (number 0).
What I can't do: I can't start a new serial terminal that changes the baud rate without it resetting the GG, and I can't get payload to work yet.
Here's my slightly modified version of nanocom: both 32 and 64 bit binaries included; others who need to get a 64 bit Ubuntu system running can use that and BSTL until we get payload fixed.
Ross, perhaps if you're interested -- load a propeller platform using BSTL on your 32 bit Ubuntu system, you could then verify if it is all/any Ubuntu compile of the kernel, the particular kernel (Linux 2.6.35-23 generic), or just the 64 bit compile of that kernel which has the serial driver issues I have. Now, I'll work on and get payload working...
Just a data point, but bst / bstc / bstl are all tested on 64 bit and 32 bit x86 machines. i386 Ubuntu and x86-64 Debian.
Bst takes great care not to touch the dtr line between the download and opening the serial terminal.
Try running bst, open the serial terminal and configure it to the correct baud setting, then (with the serial terminal still open) switch back to the bst window and load the prop. The serial terminal will auto-disconnect, load the prop, reconnect and change the baud rate without touching the DTR line.
This may or may not help, but we had some issues with the CP/M emulation and the timing of the DTR reset line. It depends on whether it changes on the positive edge or the negative edge. The solution was to change from a BC547 to a BC557 reset transistor, and to swap a few resistors around.
One, remote but real possibility, is that a program leaves DTR in one state, high or low, and then another program changes that state. Depending on the polarity of the reset components, that change in state may or may not reset the propeller. So you could get different behaviour and it may not manifest itself with the program you think it does, but rather when the next program is loaded. It could even be the program after that one. Eg say it resets on the negative edge. Program A leaves DTR low. Program B changes it to high. Program C changes it low. For a negative edge reset it will reset when program C runs, but for a positive edge it will reset when program B runs.
It can get even more complex with timing pulses that possibly are too short to cause a reset.
I honestly believe what Andrew is seeing is a Linux device driver problem specific to the CPU architecture.
The reason I'm unsure of that myself is I test bstl on x86-64.
The Mac is a pig as using the POSIX interface there is _no_ way of telling it to leave DTR alone between port opens and closes, but Linux and Win32 (surprisingly) are far better behaved. What he really needs is a CRO.
@RossH, you really want to poll for completion for quite a bit longer than 5 cycles. It's easy to miss and if you are too slow in polling the chip will time out. I had a lot of timing issues on the Mac with the kernel missing a userspace timer schedule and the load timing out. I poll pretty much as fast as I can and do it for 100 cycles waiting for a reply.
You get more timing issues when the ambient temperature is high also as the clock in the prop slows down. I ended up adding a couple of thousand load/run cycles with a hair dryer pointed at the chip to my regression tests. It poked a number of holes in the timing.
Just a data point, but bst / bstc / bstl are all tested on 64 bit and 32 bit x86 machines. i386 Ubuntu and x86-64 Debian.
Bst takes great care not to touch the dtr line between the download and opening the serial terminal.
I believe you. Notice that Jazzed can run nanocom after loading the program and his system doesn't reset the gadget gangster.
When I use *his* program, my gadget gangster is reset. Being as they are manufactured identically, they ought to behave identically -- but they don't. The settings I use with my alternate version of nanocom ought not reset the DTR either -- you can try it on your system to see if you can BSTL upload a program and then run nanocom with my settings. If it does reset a propeller platform (any/not necessarily GG) that would be useful information too -- it would say that nanocom is less careful than BST.
BTW: are you the/an author of BST? if so, awesome work!
Try running bst, open the serial terminal and configure it to the correct baud setting, then (with the serial terminal still open) switch back to the bst window and load the prop. The serial terminal will auto-disconnect, load the prop, reconnect and change the baud rate without touching the DTR line.
BST doesn't appear to have a way to load a binary from the GUI without compiling it first so I will have to use a spin program; I will have to admit, you could be right -- possibly -- for I didn't have a tested spin program until after using Jazzed binary to eliminate other possibilities. I'll give it another try as you say with the spin program I attached in the previous post.
Ross, I did a careful compare with the original -- and rewrote the endian code (simpler) and possibly corrected a mistake in my patch in the datalength send parameter -- the results are the same, but I did learn something by fiddling with the time-out. When there is a 250ms time out, I get "No response", but when the time-out is longer I get an error code of 0xFF (-1) and not a reply byte of 0xFE. So, that eliminates the possibility of a *missed* response byte -- and strongly suggests that not all bits are getting to the propeller during the load sequence.
I think maybe it is waiting for more data, and then eventually times out. I think the propeller can load at lower baud rates, so I am going to slow mine down and see if that helps ... any other thoughts?
EDIT: I tried the BST terminal with it connected during an upload, and with it disconnected during an upload with simple.binary of the last package. It resets the GG as all command line terminals do; So, it is clear that the BST terminal closes and re-opens the connection; if it just left the connection open -- but suspended reading, this wouldn't happen.
Slowing down payload's transmit rate, either the original program or my modified version with or without -m32 has no noticeable effect. This is a stumper of a problem. I wonder what is BSTL doing differently that has the magic effect of working....
Ross, I did a careful compare with the original -- and rewrote the endian code (simpler) and possibly corrected a mistake in my patch in the datalength send parameter -- the results are the same, but I did learn something by fiddling with the time-out. When there is a 250ms time out, I get "No response", but when the time-out is longer I get an error code of 0xFF (-1) and not a reply byte of 0xFE. So, that eliminates the possibility of a *missed* response byte -- and strongly suggests that not all bits are getting to the propeller during the load sequence.
I think maybe it is waiting for more data, and then eventually times out. I think the propeller can load at lower baud rates, so I am going to slow mine down and see if that helps ... any other thoughts?
I've not had tme for much work on this yet, but I supect it to be a timing problem. I'll have a play with the oscillocope on the weekend. One possible clue is that I've also found a problem when using a "real" RS232 port under Linux (as compared to a USB serial port). The symptoms are the same. This may be related, or it may be not. The funny thinga about this one is that it used to work - so either I've broken something, or something in the Linux kernel has changed.
The funny thinga about this one is that it used to work - so either I've broken something, or something in the Linux kernel has changed.
You know what? I have a kernel version that does mis-behave. I thought maybe it was some software causing the problem. I only boot 2.6.32-24-generic these days.
BST doesn't appear to have a way to load a binary from the GUI without compiling it first so I will have to use a spin program; I will have to admit, you could be right -- possibly -- for I didn't have a tested spin program until after using Jazzed binary to eliminate other possibilities. I'll give it another try as you say with the spin program I attached in the previous post.
Actually, it does but it's pretty well hidden.
Goto File->Open and change the filter to *.binary/*.eeprom.
Otherwise, change the filter at the bottom of the directory boxes to "All Files (spin, pbas, sprj, binary, eeprom)"
When you open a .binary or .eeprom file it will give you a a box to let you load it into the prop.
<Edit> Any chance of sending me your .config from the kernel and giving me a uname -a? I'd like to try and reproduce this locally. brad <at> proptools.org
Actually, it does but it's pretty well hidden.
Goto File->Open and change the filter to *.binary/*.eeprom.
Otherwise, change the filter at the bottom of the directory boxes to "All Files (spin, pbas, sprj, binary, eeprom)"
When you open a .binary or .eeprom file it will give you a a box to let you load it into the prop.
<Edit> Any chance of sending me your .config from the kernel and giving me a uname -a? I'd like to try and reproduce this locally. brad <at> proptools.org
Ahhh ... I didn't think of trying that.
As a note; it's just ubuntu 10.10 generic kernel, not recompiled or anything.
uname -a
Linux Rocky 2.6.35-23-generic #40-Ubuntu SMP Wed Nov 17 22:14:33 UTC 2010 x86_64 GNU/Linux
How do you want me to get the configuration, as kernel sources aren't on this system (it isn't mine, but I have an account), I have the /boot file:
Its running on a genuine intel core duo2 E8500 at the moment. And just for extra annoyances, I found that the optimiser in GCC is malfunctioning/or my processor is optimising illegally -- I have to use -O0 to guarantee that some of the code I compile (-32 or not is irrelevant) actually works.
Eg: Doing an assembly of a 32 bit little endian word by summing (((u32)(*buffer++))<< n*8), will produce wrong results if the optimiser is on. So, it wouldn't surprise me if the kernel was somehow miscompiled -- I've been googling and there appears to be some Athalon/Intel problems ... though usually its the Athalon that malfunctions...
Does any one have a disassembly of how the Propeller boot loader code actually reads the data in? I've re-written the detector and driver to use common bit packing and bit reading algorithms with higher density capability, and easier debugging, and yet I can't get a response out of the propeller once the program is loaded now (negative or positive).
This is the algorithm as far as I understand it:
1st) send 250 bits of LFSR to propeller 1 bit at a time. Then send %01=$F9 (or %11=$FD) as a place holder to get a response bit. GetResponse 250 times and compare it against the LFSR; (This works perfectly. YAY.)
2nd) GetResponse 8 more times for the version number. (That works too. YAY).
3rd) Send the number $00000001 lsbit first; To trigger a Load HUBRam;
--all numbers from here on out are 32bit numbers, sent 1 to 4 bits at a time from the LSBit to the MSBit.
--all data in the .binary file is little endian, so read lsBYTE, then midBYTE, then midhighBYTE, then highBYTE, then start over.
4th) Send a 32 bit number, lsbit first, representing the number of 32bit words to be uploaded.
5th) Send that number of 32 bit words to the propeller; Grouping is irrelevant -- 8 bits to 32bits with variable packing is accepted.
6th) Read a response bit to see if the checksum came out correctly.
Now, step 6 is continually failing; My scope shows that the propeller simply isn't sending *anything* back -- ever -- once the load process begins. So, I tried a modified approach -- I found a small 48 byte program, and loaded it, followed by sending %01 or %11 forever, and watching for a response -- which never comes.
I need a little more information about timeouts (nominal) and the load algorithm to understand why I am never getting a response.
Does anyone have a disassembly of the data load program that is inside the propeller so I can get a better Idea of how the timeouts work?
I've been googling and there appears to be some Athalon/Intel problems ... though usually its the Athalon that malfunctions...
Unfortunate that. My X86_64 tests are on Athlons.
Your understanding of the algorithm appears to be correct. The only thing I can think of is maybe there is an error in the way you are packing the bits for the download.
The other thing I can suggest is that you add an extra idle bit at the end of each long to let the Propeller catch up and do it's wrlong properly. It's not normally an issue at 115200 baud unless the prop is *really* hot, but the way Parallax packs their bits guarantees that this problem does not occur.
For some reason I got the impression you were running another architecture. Oh well.
Probably because I thought I was running an AMD processor until my brother gave me a box with that processor in it, and said he had upgraded the system.... I probably wrote something which led you astray :shrug:
At least I now have the propeller source code and can understand where the likely failure points are in the loading of it.
Hopefully, tonight I will have it loading with my modified version of payload.
I will need to compute some time-out tolerances:
The propeller is a (H?)cmos process of some kind, so the internal RC oscillator can vary in frequency by a factor of up to 2.5:1 over temperature, depending on how it is made & whether or not temperature compensation was done: from posts from BradC, I think it isn't compensated. In the loader it mentions two frequencies in the timing loop: 400ns @ 20MHz and 1us @ 8MHz. Does anyone know if those are the "limits" of the operating frequency during loading, or are they just examples? eg: would 8 to 20Mhz be the "worst" case operating frequencies of a propeller during a load cycle?
Attached is a slightly tweaked version of payload.c that works on all the Linux platforms I've tried, including Ubuntu 10.10.
The problem in Ubuntu was (as I suspected) a timing problem. I've not gotten completely to the bottom of it yet, but the following command seems to work quite reliably:
nice -n -20 payload -t 500 -r 500 <program>
The nice -n -20 command raises the priority of payload and improves the reliability of timing on the serial comms, and the -t and -r arguments to payload increase two of the payload timeouts to 500ms each.
The nice command seems to only be absolutely necessary on Ubuntu, although it does no harm on other platforms, and does seem to improve the reliability on all platforms when a 'real' RS232 port is being used (as opposed to a USB serial port).
Note that I have only been able to try this out on 32 bit platforms - I'd appreciate it if someone could recompile it as a 64 bit binary and try it. If it proves reliable on all platforms, I may change the default timeouts so that the -t and -r arguments are not required.
I got my 64 bit version of payload working (attached).
The code is simplified in places to make error detection and debugging easier for me; Use what you like from my code; It also has a slightly different method of response gathering to reduce risk of mis-timer issues on some platforms (like OS-X), but it needs to be tested to see if it is worth keeping or is more irritating than helpful.
It works on my system 64bit, with either 32bit or 64bit mode binaries.
There are quirks, see the comments at the program start, but it works without setting Nice at 115200 baud without problems for all binaries I have to load. I will upload a cleaned up version tomorrow for comments/and unused code for future issues -- (or change the present upload of payloadMod.zip) if possible; though this link has usable code as is for little endian processors like the intel.
It is enhanced both in error checking and in upload speed; it finds the propeller much faster now.
I think, Ross, the timing issues you mentioned may be affecting my version as well -- but for some reason it only affects it when running at a "slower" baud rate than the maximum.
Again, I think this is just a bug in the 64 bit ubuntu distribution...
I'll try yours on my system in a few minutes and let you know how it works, as well.
Oh, BTW, Ross, on your version of Ubuntu -- do you have the reset problem caused by the communication software starting up -- eg: like mine, or is that problem just on my system?
--Andrew.
EDIT:
Ross: no good on a 64 bit native compile even w/ -O0, but it is partially good in 32 bit compatibility mode.
For 64 bit, I get:
andrew3@Rocky:~/src/propeller/Nsource/source/catalina$ sudo nice -n -20 ./payload -t 500 -r 500 simple.binary
Using Propeller (version 1) on port /dev/ttyUSB0 for upload
Error loading program
And, on a 32 bit compile w/ -m32 -O0 works at full speed, 115200; However, trying a slower baudrate from 19200 to 57600, does *NOT* work.
andrew3@Rocky:~/src/propeller/Nsource/source/catalina$ sudo nice -n -20 ./payload -t 500 -r 500 -b 19200 simple.binary
Using Propeller (version 1) on port /dev/ttyUSB0 for upload
Error: No response received
andrew3@Rocky:~/src/propeller/Nsource/source/catalina$ sudo nice -n -20 ./payload -t 500 -r 500 -b 57600 simple.binary
Using Propeller (version 1) on port /dev/ttyUSB0 for upload
Error: No response received
In addition, it requires sudo to run nice for higher priority scheduling; I was allowed to do it for the test, but that isn't something that will be allowed on a prodution Linux box.
I got my 64 bit version of payload working (attached).
The code is simplified in places to make error detection and debugging easier for me; Use what you like from my code; It also has a slightly different method of response gathering to reduce risk of mis-timer issues on some platforms (like OS-X), but it needs to be tested to see if it is worth keeping or is more irritating than helpful.
Oh, BTW, Ross, on your version of Ubuntu -- do you have the reset problem caused by the communication software starting up -- eg: like mine, or is that problem just on my system?
No, I don't see anything unusual with my Ubuntu system. But I run it under a virtualbox emulation, which may be different to a real system.
I run with 2.6.34 and have no problems. If I go to 2.6.35, I get DTR resets on any terminal program startup. There are some source changes in ftdi_src.c in the two kernels with flow control during ftdi_open, but I'm not sure if they account for the problem. I'll stick with what works for the time being.
I got my 64 bit version of payload working (attached).
The code is simplified in places to make error detection and debugging easier for me; Use what you like from my code; It also has a slightly different method of response gathering to reduce risk of mis-timer issues on some platforms (like OS-X), but it needs to be tested to see if it is worth keeping or is more irritating than helpful.
Hi Andrew.
I tried your version of payload on my Ubuntu 10.10 system, and without the nice command it exhibits the same problems as my original (i.e. it is very unreliable, successfully loading a program about one time in 10, or even less often). When I use the nice command, both your version and my version become quite reliable, but yours is substantially slower to load programs (about 50% slower).
There is obviously more going on here than we currently understand. Unfortunately I have not been able to get Ubuntu to run natively at all on my machine (but strangely enough it runs quite well under VirtualBox). I may have to wait until I can get access to a 64 bit machine to go any further.
Ross.
P.S.Toggling DTR on opening nanocom is something I see on all my versions of Linux - Ubuntu 10.10 is no different to Fedora 12 or Debian 5 - and they all use different kernel versions.
P.S.Toggling DTR on opening nanocom is something I see on all my versions of Linux - Ubuntu 10.10 is no different to Fedora 12 or Debian 5 - and they all use different kernel versions.
Do you see this with BST serial terminal? I only have a problem with BST as of 2.6.35.
Yes, it is slower in that version during loading -- but it is faster during finding of the propeller. I don't have any reliability issues on my machine running it -- so the virtual box is adding a layer of trouble to yours. As far as the clean version I was going to load up today ... It's not happening that fast...!
I have been trying to clean up the code with faster buffered versions; but I am having difficulty. I can do the LFSR portion of the code many different ways, and completely reliably at any speed; However, the upload portion of the code does not behave as expected -- even when reduced to 2 bits at a time fixed upload words. (I need a sanity check to verify that the encoding is correct).
I am trying to upload a 48 byte program who's bytes are well defined:
Given that I correctly load the command and the program length words, I ought to be able to get a response back from the propeller regardless of whether or not the program uploads right : eg: I ought to be able to get a negative response, at least. But for some reason, I am unable to get any response at all, even using very conservative timed words (2 bits/byte transmission).
Eg: to send the command word and the length word, I am sending the hexadecimal byte sequence:
Followed by 12 more lines; then I start polling by sending either 0x68 or 0xF9's -- but I never get a response.
Am I encoding that wrong somehow? The above examples do represent the number 1 and 12 respectively, don't they?
Oh, BTW. The rs232.h file defines SetDTR and ClearDTR as returning "int", but neither of these functions have a return value.
I expect that is a compatibility issue with windows, but what is the return value supposed to represent in windows?
I am just adding a return 0 to get rid of the warning messages, but it would be nice to know what the value is supposed to
represent so I can correct that problem right.
Also, re SetDRT and ClrDTR - on Windows, these functions return nonzero on success, or zero on error. I should probably make the Linux versions do the same.
Your encoding doesn't look right to me. Put a couple of printfs in 'writeLong' as follows to see how an actual file is encoded for transmission:
Yes, That's three bits/byte encoding in your original writeLong; I modified mine to go to 2 bits/byte and to save in a buffer rather than directly output to RS232 -- as in:
The encoding wasn't the problem. The buffer being sent was.... sheesh, global variables.... (wild goose chase).
I changed my rs232.c code for the SetDTR to return !!ioctl( ... ) which I think will have the same effect as the windows return value you mentioned. Thanks for the note.
Here is a significantly cleaned up version; there still are issues, like the baudrate if not an exact value leaves the terminal in a messed up state -- some baudrates don't work (19.2K,38.4K) and it isn't windows frendly, yet, but on my system it is stable -- loads lightning fast now (will work at up to 230400 baud) -- but the speed enhancement is probably system dependent....
I'd be curious as to how it performs in a virtual box, now that it is properly buffered.
@Jazzed, thanks for all the help on the kernel issues; I wish I could just down-grade my kernel, but no such luxury.
Is there a way of removing the old modified payload (zipfile) from a few posts back, and replacing it with this new one? If not, hopefully I got the right package selected -- a 43K one with rs232.c also included. I just don't want to leave confusing pieces of information around if I don't have to.
Let me know what your results are with this version, and perhaps I can polish out any irritations people have -- I'm glad that it at least works well now for me. Thanks for all the help and patience in getting me to this point.
A couple of quick questions; I need to understand the registry a bit better. The code for the registry "C" interface appears to be written in assembly, and there are multiple copies which makes it difficult to track down exactly what is going on.
eg: for example, why is _status_of_plugin(int cog_id) returning void in "catalina_plugin.h" ?
I want to run "test_registry.c" in the demos library, for example, to work this out myself -- I compiled it and loaded it successfully, but the serial line output doesn't produce any output;
Given that Gadget Gangster, as deliviered, has no screen, etc. my only choice is serial line for right now. What do I do to get the HMI driver to redirect to the serial port for both input and for output? eg: so I can use scanf() and t_printf() or printf(), etc.
Is there a particular platform that I should compile for, or do I need to set a new one up -- and how are the baudrates determined?
Comments
Hope this helps.
It does help indeed. I don't have nanocom for Ubuntu -- and apt-get install nanocom doesn't get it, so I'm not sure how to get that specific terminal. I downloaded microcom and did:
microcom -p/dev/ttyUSB0 -s57600
and then, while it is running, I did
bstl jazzedHelloWorld.binary
Normally this wouldn't work, because the serial terminal captures returning bytes that BSTL needs during the load cycle, and bstl would change the baudrate too -- but for some reason microcom lets me get away with it most of the time (it has slow response).
After that, about once a second -- a message prints on the serial terminal with the correct number of characters; but with totally wrong values (garbage). So, that suggests the baud rate is wrong (no surprise). That happens up and until I reset the GG: So that proves that BSTL *does* load your binary on my system, although something is still wrong with the serial settings. It also means that the serial terminal in BST is resetting the serial line when it starts up, (yucky bug) and that is what is causing the gadget gangster to reset.
microcom also causes the messages to stop printing when I exit it, and restart microcom to change the baud rate, (or simply starting it after the load is complete) verifying that there is a serial line reset problem. I might be able to fix this by keeping the serial port opened with a 'c' program that doesn't read data from the serial line, but the simplest fix is probably just to get nanocom which obviously works on your system -- and complain to the author of BST about the serial terminal reset of the GG.
Where did you get an Ubuntu version of nanocom? It's not the same as the one on source-forge, becuase that one acts differently.
Let's just say it's special and sometimes I'm a messy programmer - here's the source.
My machine is i686, and an i686 executable is in the nanocom directory.
I've added some special features like -n to append LF/CR on LF output.
Another feature is -x "string" which will cause the program to terminate if string is printed.
Also, get the menu by pressing ESC. Quit is ESC then ENTER.
The microcom program works fine for me. Please verify your crystal is 5MHz.
Thank you. Before I got your version -- I modified the source forge nanocom, and am able to get "Hello world" now using it. YAY!
I was correct, BSTL was downloading the file right and the garbage I was getting was the hello world.
Yes, it is, it's an as-shipped GadgetGangester with no modifications except a soldered wire to take USB 5V power to the 5V input (That is not the problem. external power makes no difference).
I'll try yours in a minute -- but I won't be surprised if it doesn't work. Our systems are a little different -- though both are Ubuntu:
What's going on in my system is that when the USB serial port is opened or closed, a program (don't know which one, or if the kernel driver) is resetting the RS232 wire that goes to the propeller reset pin.
So long as I don't allow the port to close and re-open, eg: like do bstl and then launch nanocom -- then the chip does not reset; This is great except that BSTL will *change* the baudrate to 115200 which is why I get garbage characters;
So, I just modified nanocom to stop receiving characters when I select the menu "CTRL-T" (which frees the receive line problem up so that BSTL works right *every* time) and then, when I exit the nanocom menu, I have it restore the baudrate.
When I do that, I get "Hello World" as expected once a second; so that definitely is the problem on my system -- what is causing mine to be different than yours -- I don't know.
I'll compile your program and see if it works with your version on my system -- don't be surprised if it doesn't. Being as mine is a 64 bit system, it is possible that my serial driver behaves a little bit differently than yours -- I'll let you know in a little while. I do know that payload still doesn't work on my system; and I need to recompile that -m32 from original source just to make extra sure I didn't mess it up trying to fix it.
Hi wuut,
A bit of googling comes up with this:http://stackoverflow.com/questions/115426/algorithm-to-detect-intersection-of-two-rectangles
Ross.
I think there must be another problem with payload, since it detects the Prop but doesn't appear to get a response to the "load" command (which follows pretty much immediately). My current thinking is that it might be the timing of detecting the response from the Propeller - this is about the only timeout that is not configurable in payload - it is fixed at 250ms by the following code in the prop_upload function:
count = 5; // 250 ms while (count-- > 0) { SendByte(port, 0xf9); // wait for the response mdelay(50); if (ByteReady(port)) break; }You might try tweaking that (e.g. set count to 10, or larger) to see if that helps.If it's not that, then it must be a deeper problem with the ByteReady function. You might also log whether the select call within that function (in rs232.c) is unexpectedly returning an error.
Ross.
The kernel driver for the USB serial is resetting the DTR line whenever two events occur together -- a program "Opens" the serial port, followed by a writing of the terminal settings.
Jazzed's version of nanocom unfortunately causes the Gadget Gangster to reset as well as every other terminal program I have tried on this test Ubuntu 10.10, 64 bit system.
A second cause of reset is whenever the USB driver becomes totally closed -- that is no program has /dev/ttyUSB0 open at all. If I run bstl and it finished before the terminal program is started, the GG will be reset. (Very frustrating...)
So, for GG to work with the ubuntu10.10, 64bit system -- I must have a program which opens the serial port, and then can suspend use of it (no reads/writes).
I have a special compile of nanocom to do this task, I execute:
nanocomMod64 /dev/ttyUSB0 -b 57600 -p n -d 8 -s 1 -f n -e n
and then, once running, I press Control-T to put it in menu mode; The modification I made causes nanocom NOT to read the serial port while the menu is up. This allows file loaders to operate on the serial port without interference from nanocom; so in a different terminal I can execute:
bstl HelloWorldJazzed.binary
That one uploads Jazzed re-named test program to the GG. I can then switch back to the already running nanocomMod64 serial terminal program, exit the menu mode, and all data in the buffer will be printed, followed by "Hello world" at the correct baud rate. (Expect garbage at the top because of BSTL changing the baud rate to 115200, the baud will be corrected the moment the menu is exited.)
The nanocom program is fully functional, I didn't add Jazzed's modifications to it; but I can add that later once payload is fixed.
Alternately, once nanocom is running and in menu mode -- and BSTL finished load a program like simple.binary (115200 baud) -- I can use programs which do not change the baud rate like "cat /dev/ttyUSB0"
Note: The correct RS232 (FullDuplexSerial) polarity for gadget gangster is NON-inverting (number 0).
What I can't do: I can't start a new serial terminal that changes the baud rate without it resetting the GG, and I can't get payload to work yet.
Here's my slightly modified version of nanocom: both 32 and 64 bit binaries included; others who need to get a 64 bit Ubuntu system running can use that and BSTL until we get payload fixed.
Ross, perhaps if you're interested -- load a propeller platform using BSTL on your 32 bit Ubuntu system, you could then verify if it is all/any Ubuntu compile of the kernel, the particular kernel (Linux 2.6.35-23 generic), or just the 64 bit compile of that kernel which has the serial driver issues I have. Now, I'll work on and get payload working...
Bst takes great care not to touch the dtr line between the download and opening the serial terminal.
Try running bst, open the serial terminal and configure it to the correct baud setting, then (with the serial terminal still open) switch back to the bst window and load the prop. The serial terminal will auto-disconnect, load the prop, reconnect and change the baud rate without touching the DTR line.
One, remote but real possibility, is that a program leaves DTR in one state, high or low, and then another program changes that state. Depending on the polarity of the reset components, that change in state may or may not reset the propeller. So you could get different behaviour and it may not manifest itself with the program you think it does, but rather when the next program is loaded. It could even be the program after that one. Eg say it resets on the negative edge. Program A leaves DTR low. Program B changes it to high. Program C changes it low. For a negative edge reset it will reset when program C runs, but for a positive edge it will reset when program B runs.
It can get even more complex with timing pulses that possibly are too short to cause a reset.
Can you measure DTR in some way?
The reason I'm unsure of that myself is I test bstl on x86-64.
The Mac is a pig as using the POSIX interface there is _no_ way of telling it to leave DTR alone between port opens and closes, but Linux and Win32 (surprisingly) are far better behaved. What he really needs is a CRO.
@RossH, you really want to poll for completion for quite a bit longer than 5 cycles. It's easy to miss and if you are too slow in polling the chip will time out. I had a lot of timing issues on the Mac with the kernel missing a userspace timer schedule and the load timing out. I poll pretty much as fast as I can and do it for 100 cycles waiting for a reply.
You get more timing issues when the ambient temperature is high also as the clock in the prop slows down. I ended up adding a couple of thousand load/run cycles with a hair dryer pointed at the chip to my regression tests. It poked a number of holes in the timing.
I believe you. Notice that Jazzed can run nanocom after loading the program and his system doesn't reset the gadget gangster.
When I use *his* program, my gadget gangster is reset. Being as they are manufactured identically, they ought to behave identically -- but they don't. The settings I use with my alternate version of nanocom ought not reset the DTR either -- you can try it on your system to see if you can BSTL upload a program and then run nanocom with my settings. If it does reset a propeller platform (any/not necessarily GG) that would be useful information too -- it would say that nanocom is less careful than BST.
BTW: are you the/an author of BST? if so, awesome work!
BST doesn't appear to have a way to load a binary from the GUI without compiling it first so I will have to use a spin program; I will have to admit, you could be right -- possibly -- for I didn't have a tested spin program until after using Jazzed binary to eliminate other possibilities. I'll give it another try as you say with the spin program I attached in the previous post.
Ross, I did a careful compare with the original -- and rewrote the endian code (simpler) and possibly corrected a mistake in my patch in the datalength send parameter -- the results are the same, but I did learn something by fiddling with the time-out. When there is a 250ms time out, I get "No response", but when the time-out is longer I get an error code of 0xFF (-1) and not a reply byte of 0xFE. So, that eliminates the possibility of a *missed* response byte -- and strongly suggests that not all bits are getting to the propeller during the load sequence.
I think maybe it is waiting for more data, and then eventually times out. I think the propeller can load at lower baud rates, so I am going to slow mine down and see if that helps ... any other thoughts?
EDIT: I tried the BST terminal with it connected during an upload, and with it disconnected during an upload with simple.binary of the last package. It resets the GG as all command line terminals do; So, it is clear that the BST terminal closes and re-opens the connection; if it just left the connection open -- but suspended reading, this wouldn't happen.
Slowing down payload's transmit rate, either the original program or my modified version with or without -m32 has no noticeable effect. This is a stumper of a problem. I wonder what is BSTL doing differently that has the magic effect of working....
--Andrew
I've not had tme for much work on this yet, but I supect it to be a timing problem. I'll have a play with the oscillocope on the weekend. One possible clue is that I've also found a problem when using a "real" RS232 port under Linux (as compared to a USB serial port). The symptoms are the same. This may be related, or it may be not. The funny thinga about this one is that it used to work - so either I've broken something, or something in the Linux kernel has changed.
Ross.
Actually, it does but it's pretty well hidden.
Goto File->Open and change the filter to *.binary/*.eeprom.
Otherwise, change the filter at the bottom of the directory boxes to "All Files (spin, pbas, sprj, binary, eeprom)"
When you open a .binary or .eeprom file it will give you a a box to let you load it into the prop.
<Edit> Any chance of sending me your .config from the kernel and giving me a uname -a? I'd like to try and reproduce this locally. brad <at> proptools.org
Ahhh ... I didn't think of trying that.
As a note; it's just ubuntu 10.10 generic kernel, not recompiled or anything.
uname -a
Linux Rocky 2.6.35-23-generic #40-Ubuntu SMP Wed Nov 17 22:14:33 UTC 2010 x86_64 GNU/Linux
How do you want me to get the configuration, as kernel sources aren't on this system (it isn't mine, but I have an account), I have the /boot file:
Its running on a genuine intel core duo2 E8500 at the moment. And just for extra annoyances, I found that the optimiser in GCC is malfunctioning/or my processor is optimising illegally -- I have to use -O0 to guarantee that some of the code I compile (-32 or not is irrelevant) actually works.
Eg: Doing an assembly of a 32 bit little endian word by summing (((u32)(*buffer++))<< n*8), will produce wrong results if the optimiser is on. So, it wouldn't surprise me if the kernel was somehow miscompiled -- I've been googling and there appears to be some Athalon/Intel problems ... though usually its the Athalon that malfunctions...
Does any one have a disassembly of how the Propeller boot loader code actually reads the data in? I've re-written the detector and driver to use common bit packing and bit reading algorithms with higher density capability, and easier debugging, and yet I can't get a response out of the propeller once the program is loaded now (negative or positive).
This is the algorithm as far as I understand it:
1st) send 250 bits of LFSR to propeller 1 bit at a time. Then send %01=$F9 (or %11=$FD) as a place holder to get a response bit. GetResponse 250 times and compare it against the LFSR; (This works perfectly. YAY.)
2nd) GetResponse 8 more times for the version number. (That works too. YAY).
3rd) Send the number $00000001 lsbit first; To trigger a Load HUBRam;
--all numbers from here on out are 32bit numbers, sent 1 to 4 bits at a time from the LSBit to the MSBit.
--all data in the .binary file is little endian, so read lsBYTE, then midBYTE, then midhighBYTE, then highBYTE, then start over.
4th) Send a 32 bit number, lsbit first, representing the number of 32bit words to be uploaded.
5th) Send that number of 32 bit words to the propeller; Grouping is irrelevant -- 8 bits to 32bits with variable packing is accepted.
6th) Read a response bit to see if the checksum came out correctly.
Now, step 6 is continually failing; My scope shows that the propeller simply isn't sending *anything* back -- ever -- once the load process begins. So, I tried a modified approach -- I found a small 48 byte program, and loaded it, followed by sending %01 or %11 forever, and watching for a response -- which never comes.
I need a little more information about timeouts (nominal) and the load algorithm to understand why I am never getting a response.
Does anyone have a disassembly of the data load program that is inside the propeller so I can get a better Idea of how the timeouts work?
--Andrew.
http://forums.parallax.com/showthread.php?101483-Propeller-ROM-source-code-HERE&p=711064#post711064
Unfortunate that. My X86_64 tests are on Athlons.
Your understanding of the algorithm appears to be correct. The only thing I can think of is maybe there is an error in the way you are packing the bits for the download.
The other thing I can suggest is that you add an extra idle bit at the end of each long to let the Propeller catch up and do it's wrlong properly. It's not normally an issue at 115200 baud unless the prop is *really* hot, but the way Parallax packs their bits guarantees that this problem does not occur.
Probably because I thought I was running an AMD processor until my brother gave me a box with that processor in it, and said he had upgraded the system.... I probably wrote something which led you astray :shrug:
At least I now have the propeller source code and can understand where the likely failure points are in the loading of it.
Hopefully, tonight I will have it loading with my modified version of payload.
I will need to compute some time-out tolerances:
The propeller is a (H?)cmos process of some kind, so the internal RC oscillator can vary in frequency by a factor of up to 2.5:1 over temperature, depending on how it is made & whether or not temperature compensation was done: from posts from BradC, I think it isn't compensated. In the loader it mentions two frequencies in the timing loop: 400ns @ 20MHz and 1us @ 8MHz. Does anyone know if those are the "limits" of the operating frequency during loading, or are they just examples? eg: would 8 to 20Mhz be the "worst" case operating frequencies of a propeller during a load cycle?
--Andrew.
Attached is a slightly tweaked version of payload.c that works on all the Linux platforms I've tried, including Ubuntu 10.10.
The problem in Ubuntu was (as I suspected) a timing problem. I've not gotten completely to the bottom of it yet, but the following command seems to work quite reliably:
The nice -n -20 command raises the priority of payload and improves the reliability of timing on the serial comms, and the -t and -r arguments to payload increase two of the payload timeouts to 500ms each.
The nice command seems to only be absolutely necessary on Ubuntu, although it does no harm on other platforms, and does seem to improve the reliability on all platforms when a 'real' RS232 port is being used (as opposed to a USB serial port).
Note that I have only been able to try this out on 32 bit platforms - I'd appreciate it if someone could recompile it as a 64 bit binary and try it. If it proves reliable on all platforms, I may change the default timeouts so that the -t and -r arguments are not required.
Thanks,
Ross.
I got my 64 bit version of payload working (attached).
The code is simplified in places to make error detection and debugging easier for me; Use what you like from my code; It also has a slightly different method of response gathering to reduce risk of mis-timer issues on some platforms (like OS-X), but it needs to be tested to see if it is worth keeping or is more irritating than helpful.
It works on my system 64bit, with either 32bit or 64bit mode binaries.
There are quirks, see the comments at the program start, but it works without setting Nice at 115200 baud without problems for all binaries I have to load. I will upload a cleaned up version tomorrow for comments/and unused code for future issues -- (or change the present upload of payloadMod.zip) if possible; though this link has usable code as is for little endian processors like the intel.
It is enhanced both in error checking and in upload speed; it finds the propeller much faster now.
I think, Ross, the timing issues you mentioned may be affecting my version as well -- but for some reason it only affects it when running at a "slower" baud rate than the maximum.
Again, I think this is just a bug in the 64 bit ubuntu distribution...
I'll try yours on my system in a few minutes and let you know how it works, as well.
Oh, BTW, Ross, on your version of Ubuntu -- do you have the reset problem caused by the communication software starting up -- eg: like mine, or is that problem just on my system?
--Andrew.
EDIT:
Ross: no good on a 64 bit native compile even w/ -O0, but it is partially good in 32 bit compatibility mode.
For 64 bit, I get: And, on a 32 bit compile w/ -m32 -O0 works at full speed, 115200; However, trying a slower baudrate from 19200 to 57600, does *NOT* work.
In addition, it requires sudo to run nice for higher priority scheduling; I was allowed to do it for the test, but that isn't something that will be allowed on a prodution Linux box.
--Andrew.
I'll have a look at your changes tomorrow.
No, I don't see anything unusual with my Ubuntu system. But I run it under a virtualbox emulation, which may be different to a real system.
Hi Andrew.
I tried your version of payload on my Ubuntu 10.10 system, and without the nice command it exhibits the same problems as my original (i.e. it is very unreliable, successfully loading a program about one time in 10, or even less often). When I use the nice command, both your version and my version become quite reliable, but yours is substantially slower to load programs (about 50% slower).
There is obviously more going on here than we currently understand. Unfortunately I have not been able to get Ubuntu to run natively at all on my machine (but strangely enough it runs quite well under VirtualBox). I may have to wait until I can get access to a 64 bit machine to go any further.
Ross.
P.S.Toggling DTR on opening nanocom is something I see on all my versions of Linux - Ubuntu 10.10 is no different to Fedora 12 or Debian 5 - and they all use different kernel versions.
Yes, it is slower in that version during loading -- but it is faster during finding of the propeller. I don't have any reliability issues on my machine running it -- so the virtual box is adding a layer of trouble to yours. As far as the clean version I was going to load up today ... It's not happening that fast...!
I have been trying to clean up the code with faster buffered versions; but I am having difficulty. I can do the LFSR portion of the code many different ways, and completely reliably at any speed; However, the upload portion of the code does not behave as expected -- even when reduced to 2 bits at a time fixed upload words. (I need a sanity check to verify that the encoding is correct).
I am trying to upload a 48 byte program who's bytes are well defined:
Given that I correctly load the command and the program length words, I ought to be able to get a response back from the propeller regardless of whether or not the program uploads right : eg: I ought to be able to get a negative response, at least. But for some reason, I am unable to get any response at all, even using very conservative timed words (2 bits/byte transmission).
Eg: to send the command word and the length word, I am sending the hexadecimal byte sequence:
E7 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 # The number 0x00000001 ?
E6 F7 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 E6 # The number 0x0000000C ?
Followed by 12 more lines; then I start polling by sending either 0x68 or 0xF9's -- but I never get a response.
Am I encoding that wrong somehow? The above examples do represent the number 1 and 12 respectively, don't they?
Oh, BTW. The rs232.h file defines SetDTR and ClearDTR as returning "int", but neither of these functions have a return value.
I expect that is a compatibility issue with windows, but what is the return value supposed to represent in windows?
I am just adding a return 0 to get rid of the warning messages, but it would be nice to know what the value is supposed to
represent so I can correct that problem right.
--Andrew
Yes, I see it with bst as well.
@Andrew,
Your encoding doesn't look right to me. Put a couple of printfs in 'writeLong' as follows to see how an actual file is encoded for transmission:
// assumes buffer large enough, returns bytes copied (to transmit) static void writeLong(int port, u32 value) { int i; u8 tmp; printf("%8lx:",value); for (i=0; i<10; i++) { tmp = 0x92 | (value & 0x01) | ((value & 2) << 2) | ((value & 4) << 4); SendByte(port, tmp); printf("%2x ",tmp); value >>=3; } tmp = 0xf2 | (value & 0x01) | ((value & 2) << 2); SendByte(port, tmp); printf("%2x\n",tmp); }Also, re SetDRT and ClrDTR - on Windows, these functions return nonzero on success, or zero on error. I should probably make the Linux versions do the same.Yes, That's three bits/byte encoding in your original writeLong; I modified mine to go to 2 bits/byte and to save in a buffer rather than directly output to RS232 -- as in:
for (bits=0; bits<32; bits+=2 ) { txByte=0xE6 | (data32 & 0x01) | (data32 & 0x02)<<3; **buffer=txByte; ++(*buffer); ++pack; data32 >>=2; }EDIT: (TRUNCATED)The encoding wasn't the problem. The buffer being sent was.... sheesh, global variables.... (wild goose chase).
I changed my rs232.c code for the SetDTR to return !!ioctl( ... ) which I think will have the same effect as the windows return value you mentioned. Thanks for the note.
Here is a significantly cleaned up version; there still are issues, like the baudrate if not an exact value leaves the terminal in a messed up state -- some baudrates don't work (19.2K,38.4K) and it isn't windows frendly, yet, but on my system it is stable -- loads lightning fast now (will work at up to 230400 baud) -- but the speed enhancement is probably system dependent....
I'd be curious as to how it performs in a virtual box, now that it is properly buffered.
@Jazzed, thanks for all the help on the kernel issues; I wish I could just down-grade my kernel, but no such luxury.
Is there a way of removing the old modified payload (zipfile) from a few posts back, and replacing it with this new one? If not, hopefully I got the right package selected -- a 43K one with rs232.c also included. I just don't want to leave confusing pieces of information around if I don't have to.
Let me know what your results are with this version, and perhaps I can polish out any irritations people have -- I'm glad that it at least works well now for me. Thanks for all the help and patience in getting me to this point.
--Andrew.
A couple of quick questions; I need to understand the registry a bit better. The code for the registry "C" interface appears to be written in assembly, and there are multiple copies which makes it difficult to track down exactly what is going on.
eg: for example, why is _status_of_plugin(int cog_id) returning void in "catalina_plugin.h" ?
I want to run "test_registry.c" in the demos library, for example, to work this out myself -- I compiled it and loaded it successfully, but the serial line output doesn't produce any output;
Given that Gadget Gangster, as deliviered, has no screen, etc. my only choice is serial line for right now. What do I do to get the HMI driver to redirect to the serial port for both input and for output? eg: so I can use scanf() and t_printf() or printf(), etc.
Is there a particular platform that I should compile for, or do I need to set a new one up -- and how are the baudrates determined?
Thanks,
--Andrew.