Surely you don't have so many com ports on your machine?!
I seem to remember there was an upper limit on the com port numbers PropellerIDE could deal with. Is there a way to get that down to a more sensible number?
I guess when you have more than 21 Parallax products attached to you machine, you get 22.
Seriously, you know when a new FTDI is scanned, it assigned another COM port, but you already knew that.
I have had so many boards on this machine, it's time to clean the COM ports because many are out in the field.
Seriously, you know when a new FTDI is scanned, it assigned another COM port, but you already knew that.
No, I don't know that.
When I plug in a USB serial device it can be a bit of a lottery as to which port name it gets. Although normally if there is only one such adapter it always comes up the same.
Then, with not much effort I can configure my machine to dedicate a particular port name to a particular USB/Serial adapter's USB vendor and product id.
But then I do all that on Debian not a legacy operating system:)
For some reason Windows will keep COM ports on the device list even though they aren't currently in use. I assume it so that they can be reused for the same device, and the driver doesn't need to be reloaded for that device, but I really don't know the actual reason why it does this. This causes the COM port number to increase over time. The COM ports have to be manually freed up in order that they can be reused.
I did try freeing up all the COM ports, and the board was then assigned COM5. However, this didn't fix the problem on my system.
I've just built the latest Propeller IDE code in Brett's GitHub against Qt5.4 on Windows 8. I can confirm that the loader works as expected- I was able to upload a FullDuplexSerial test successfully and see the output. I can't upload the .exe file here ( for no doubt good reasons! ) but if anyone wants to give it a try ( no warrantee etc ) then let me know!
If there's a newer, better loader that can be packed into Propeller IDE for the time being then I'll propose this to Brett, but it would definitely be an interim solution pending a "one true loader" solution.
Edit: Looks like the GPIO stuff is in PropGCC, interesting, I might have to grab that and have a play with it. Putting open-source projects in Google Code is a beautiful way to get them ignored or overlooked
Just to be clear, p1load.exe runs fine from a command-prompt window. It just appears that p1load.exe is not being executed correctly from PropellerIDE on my Windows machine.
I would be happy to try a new PropellerIDE based off of the latest code. You can attach exe files by putting them in a zip file.
I looked at the source to p1load and there really isn't much to it. I had forgotten that it doesn't even know how to load .elf files, just Spin binaries. I see no reason to try to preserve it. If you have a better solution, please go ahead and use it. There is really very little value in p1load. The only positive thing I'll say about it is that, like p2load, it uses a translation of Chip's Pascal loader code so it it should be fairly reliable as long as you get the serial driver interface right.
Are we talking about loader/src/PLoadLib.c from propgcc ?
I have a few positive things to say about it:
1) It's small and simple.
2) It does one thing. The only thing it needs to do. Not understanding elf files and other such junk is a bonus.
3) It's easily portable to almost any thing that can run C. For example we have used it from MIPS based WIFI routers running OpenWRT where there is prescious little space for any more code in the file system. Potentially it could be used in those new 2 dollar WIFI adapters that are now everywhere.
Well, alright only three poitive things.
I have always thought that:
a) That loader should be in it's own github repository rather than burried in prop-gcc.
b) It should build into a command line program and into libraries.
c) Any other more sophisticated loader, ie, one that loads elf files etc, would be it's own separtate project and make use of the ploadlib.
d) Perhaps the os dependent parts should be abstracted out and open/close/read/write etc functions could be injected by the user, functions passed in as parameters.
Are we talking about loader/src/PLoadLib.c from propgcc ?
I have a few positive things to say about it:
1) It's small and simple.
2) It does one thing. The only thing it needs to do. Not understanding elf files and other such junk is a bonus.
3) It's easily portable to almost any thing that can run C. For example we have used it from MIPS based WIFI routers running OpenWRT where there is prescious little space for any more code in the file system. Potentially it could be used in those new 2 dollar WIFI adapters that are now everywhere.
Well, alright only three poitive things.
I have always thought that:
a) That loader should be in it's own github repository rather than burried in prop-gcc.
b) It should build into a command line program and into libraries.
c) Any other more sophisticated loader, ie, one that loads elf files etc, would be it's own separtate project and make use of the ploadlib.
d) Perhaps the os dependent parts should be abstracted out and open/close/read/write etc functions could be injected by the user, functions passed in as parameters.
PLoadLib is not used by p1load. I translated Chip's Pascal code directly. PLoadLib was written by Steve Densen and I'm not sure what reference, if any, he used. I'll extract the loader part of p1load and make it into a library and push the whole p1load project to github. Then we can decide which parts of it we want to use going forward if any.
You mean PLoadLib is not used in prop-gcc at all ?!
You mean I have been starting from the wrong code as reference ?
I just took a look in the prop-gcc repo and I see loader/src/propeller-load.c which uses loader.c which uses PLoadLib.c
I see no p1load anywhere. What is it? Where is it?
Would the real Propeller loader please stand up !
No, that's not true. PLoadLib is used by propeller-load. It is not used by p1load or p2load. They use Chip's code translated to C. Interestingly, the P2 loader uses a different bit order than the P1 loader. Not sure why Chip changed it.
FYI, I wrote p2load to use with the FPGA version of P2 that requires a two-stage loader. I used the low-level loader code from p2load to make p1load that knows how to load Spin binaries when Steve wanted to try using Chip's code to see if it was more reliable than PLoadLib. I can't remember whether he decided that it was or not.
I'm still lost here. In the prop-gcc sources I see a loader/ and a p2load/. Nowhere do I see a thing called p1load.
What and where is p1load ? What uses p1load?
p1load is not currently checked in anywhere. I will push it to github once I factor out the loader code into a library. I don't know what uses p1load although it sounds like PropellerIDE might. Or does it use propeller-load? I'm actually just as confused as you are.
Ah, I see. Confusion reigns. Never mind, that's normal at this end.
Now I have a quandary. Do I continue with my JS loader modeled on PLoadLib or scrap that and start again with a new one modeled on p1load ?
Or does it makes any difference anyway, that JS is not looking anything like the C code anyway. In JS everything has to be turned inside out because everything has to be asynchronous, no waiting on the serial port for example.
Ah, I see. Confusion reigns. Never mind, that's normal at this end.
Now I have a quandary. Do I continue with my JS loader modeled on PLoadLib or scrap that and start again with a new one modeled on p1load ?
Or does it makes any difference anyway, that JS is not looking anything like the C code anyway. In JS everything has to be turned inside out because everything has to be asynchronous, no waiting on the serial port for example.
Decisions decisions...
I suggest that you ask Jeff Martin for his new Propeller loader protocol document and write your own loader based on that. :-)
What? You mean write code according to some specification? That must be some new methodology, certainly never heard it in these parts before.
As we know, documentation is always erroneous and prone to misinterpretation. I'd rather start from the original Pascal code from the master himself. Or perhaps sniff the bytes on the serial line.
What? You mean write code according to some specification? That must be some new methodology, certainly never heard it in these parts before.
As we know, documentation is always erroneous and prone to misinterpretation. I'd rather start from the original Pascal code from the master himself. Or perhaps sniff the bytes on the serial line.
Where is that Pascal version anyway?
The Pascal code is part of PNut.exe. I think Chip sent me a copy of the source quite a while ago when I first started working on porting propgcc to the old P2. Not sure where it is now but I'm sure he'll send it to you. Or you can just look at the code in p1load. I'll attach it to this message. The code taken from PNut is clearly marked in the source file.
I think I now remember why that is. To build propeller-load requires that you have propgcc installed. Someone complained about that and that is why I made p1load for Steve.
I think I now remember why that is. To build propeller-load requires that you have propgcc installed. Someone complained about that and that is why I made p1load for Steve.
Actually, along those same lines, someone mentioned earlier that PropellerIDE used an orphaned version of p1load. I think I can safely say that it uses the *official* version of p1load since I wrote p1load to go with PropellerIDE when propeller-load was rejected. Could someone post the p1load sources that are used to build PropellerIDE so I can make sure I have all of the latest changes?
Actually, along those same lines, someone mentioned earlier that PropellerIDE used an orphaned version of p1load. I think I can safely say that it uses the *official* version of p1load since I wrote p1load to go with PropellerIDE when propeller-load was rejected. Could someone post the p1load sources that are used to build PropellerIDE so I can make sure I have all of the latest changes?
Could someone post the p1load sources that are used to build PropellerIDE so I can make sure I have all of the latest changes?
If you click on the link in the first post of this thread there is a link for the source code at the bottom of the webpage. The source for p1load is included in the zip file that the webpage references. I'm guessing this is the same source code that dgately posted, but I didn't check to see if it matched.
Thanks! Looks like there are only minor differences between the version of p1load.c in the zip file you posted and the one I have, some code that is commented out and a debugging printf that seems like it should probably be commented out in a production version of the code. I guess I'll stick with my own copy of that file for now. I'll extract the loader functionality into a library and push the results to github. When it's done, I'll post a message to the forum.
Here is a start to my Propeller loader library. There is clearly some polishing that needs to be done but this code works and the code in ploader.c is independent of any particular serial port interface. You just have to supply callback functions for resetting the Propeller, sending a buffer of bytes and receiving a buffer of bytes. I've attached a zip file containing a modified version of p1load that uses this library instead of the code that used to be built into p1load.c. I've only included the osint_linux.c serial interface code but I think this should work with the osint_mingw.c code that is included in the p1load that is part of PropellerIDE. I'll verify that tomorrow. Just thought I'd post this as a sanity check. :-)
Here is the header file that describes the loader API:
#ifndef __PLOADER_H__
#define __PLOADER_H__
#ifdef __cplusplus
extern "C"
{
#endif
/* serial port interface - filled in by the user prior to calling PL_Init */
typedef struct {
void (*reset)(void *data);
int (*tx)(void *data, uint8_t* buf, int n);
int (*rx_timeout)(void *data, uint8_t* buf, int n, int timeout);
} PL_serial;
/* loader state structure - filled in by the loader functions */
typedef struct {
PL_serial *serial;
void *serialData;
uint8_t txbuf[1024];
int txcnt;
uint8_t rxbuf[1024];
int rxnext;
int rxcnt;
uint8_t lfsr;
} PL_state;
/* PL_Init - Initializes the loader state structure. */
void PL_Init(PL_state *state, PL_serial *serial, void *data);
/* PL_HardwareFound - Sends the handshake sequence and returns non-zero if a Propeller
chip is found on the serial interface and also sets the version parameter to the
chip version.
*/
int PL_HardwareFound(PL_state *state, int *pVersion);
/* PL_LoadSpinBinary - Loads a Spin binary image. Must be called immediatel following a
successful call to PL_HardwareFound.
*/
int PL_LoadSpinBinary(PL_state *state, int loadType, uint8_t *image, int size);
#ifdef __cplusplus
}
#endif
#endif
Yes, but I would need to download all of propgcc to get it.. and in any case I wanted something with very little complexity and extremely self-contained, and modifyable the way I wanted it. Finally, writing such tools is something I like, if I couldn't do any programming I wouldn't have worked with microcontrollers in the first place.
Sadly you missed the fact that the PloadLib.c in prop-gcc is, despite it's name, by itself itself a stand alone very simple propeller loader. Only requires the osint... serial port support interface modules and the header files. Only a couple of files to copy and paste from https://code.google.com/p/propgcc/source/browse/?name=default#hg%2Floader
Never mind, writing a loader is a nice exercise and it's not such a big job.
I do wish prop-gcc would move to github. git and github are certainly much faster.
Comments
I guess when you have more than 21 Parallax products attached to you machine, you get 22.
Seriously, you know when a new FTDI is scanned, it assigned another COM port, but you already knew that.
I have had so many boards on this machine, it's time to clean the COM ports because many are out in the field.
EDIT: Phil beat me to it again!
When I plug in a USB serial device it can be a bit of a lottery as to which port name it gets. Although normally if there is only one such adapter it always comes up the same.
Then, with not much effort I can configure my machine to dedicate a particular port name to a particular USB/Serial adapter's USB vendor and product id.
But then I do all that on Debian not a legacy operating system:)
Why do you guys torture yourselves so ?
I did try freeing up all the COM ports, and the board was then assigned COM5. However, this didn't fix the problem on my system.
If there's a newer, better loader that can be packed into Propeller IDE for the time being then I'll propose this to Brett, but it would definitely be an interim solution pending a "one true loader" solution.
Edit: Looks like the GPIO stuff is in PropGCC, interesting, I might have to grab that and have a play with it. Putting open-source projects in Google Code is a beautiful way to get them ignored or overlooked
I would be happy to try a new PropellerIDE based off of the latest code. You can attach exe files by putting them in a zip file.
Joke, you have me spitting my coffee everywhere.
The idea of moving prop-gcc to github has come up many times and there always seems to be a reason not to.
Now that the is the paralaxinc repositories on github there is no excuse for prop-gcc not to be up there.
Putting open-source projects in Google Code is a beautiful way to get them ignored or overlooked
I can't seem to upload files here at all- just get an "Upload Failed". Tried .7z and .zip.
I've stuck it on a random file host I found on Google though... ( dodgy much? ) : http://s000.tinyupload.com/index.php?file_id=86263200634510495130
Nooo...
Are we talking about loader/src/PLoadLib.c from propgcc ?
I have a few positive things to say about it:
1) It's small and simple.
2) It does one thing. The only thing it needs to do. Not understanding elf files and other such junk is a bonus.
3) It's easily portable to almost any thing that can run C. For example we have used it from MIPS based WIFI routers running OpenWRT where there is prescious little space for any more code in the file system. Potentially it could be used in those new 2 dollar WIFI adapters that are now everywhere.
Well, alright only three poitive things.
I have always thought that:
a) That loader should be in it's own github repository rather than burried in prop-gcc.
b) It should build into a command line program and into libraries.
c) Any other more sophisticated loader, ie, one that loads elf files etc, would be it's own separtate project and make use of the ploadlib.
d) Perhaps the os dependent parts should be abstracted out and open/close/read/write etc functions could be injected by the user, functions passed in as parameters.
ploadlib is the reference for my JavaScript loader for node.js and Chrome apps. https://github.com/ZiCog/propeller-loader.js
You mean I have been starting from the wrong code as reference ?
I just took a look in the prop-gcc repo and I see loader/src/propeller-load.c which uses loader.c which uses PLoadLib.c
I see no p1load anywhere. What is it? Where is it?
Would the real Propeller loader please stand up !
FYI, I wrote p2load to use with the FPGA version of P2 that requires a two-stage loader. I used the low-level loader code from p2load to make p1load that knows how to load Spin binaries when Steve wanted to try using Chip's code to see if it was more reliable than PLoadLib. I can't remember whether he decided that it was or not.
I'm still lost here. In the prop-gcc sources I see a loader/ and a p2load/. Nowhere do I see a thing called p1load.
What and where is p1load ? What uses p1load?
Now I have a quandary. Do I continue with my JS loader modeled on PLoadLib or scrap that and start again with a new one modeled on p1load ?
Or does it makes any difference anyway, that JS is not looking anything like the C code anyway. In JS everything has to be turned inside out because everything has to be asynchronous, no waiting on the serial port for example.
Decisions decisions...
No doubt about as to where and which at least..
-Tor
What? You mean write code according to some specification? That must be some new methodology, certainly never heard it in these parts before.
As we know, documentation is always erroneous and prone to misinterpretation. I'd rather start from the original Pascal code from the master himself. Or perhaps sniff the bytes on the serial line.
Where is that Pascal version anyway?
p1load.c
https://code.google.com/p/propgcc/
It is the loader used by SimpleIDE. I imagine it is probably also the loader used by PropellerIDE. If not, I don't understand why.
Actually, PropellerIDE appears to use p1load...
dgately
p1load.zip
dgately
Here is the header file that describes the loader API:
#ifndef __PLOADER_H__ #define __PLOADER_H__ #ifdef __cplusplus extern "C" { #endif /* serial port interface - filled in by the user prior to calling PL_Init */ typedef struct { void (*reset)(void *data); int (*tx)(void *data, uint8_t* buf, int n); int (*rx_timeout)(void *data, uint8_t* buf, int n, int timeout); } PL_serial; /* loader state structure - filled in by the loader functions */ typedef struct { PL_serial *serial; void *serialData; uint8_t txbuf[1024]; int txcnt; uint8_t rxbuf[1024]; int rxnext; int rxcnt; uint8_t lfsr; } PL_state; /* PL_Init - Initializes the loader state structure. */ void PL_Init(PL_state *state, PL_serial *serial, void *data); /* PL_HardwareFound - Sends the handshake sequence and returns non-zero if a Propeller chip is found on the serial interface and also sets the version parameter to the chip version. */ int PL_HardwareFound(PL_state *state, int *pVersion); /* PL_LoadSpinBinary - Loads a Spin binary image. Must be called immediatel following a successful call to PL_HardwareFound. */ int PL_LoadSpinBinary(PL_state *state, int loadType, uint8_t *image, int size); #ifdef __cplusplus } #endif #endifp1load.zip
Here is a link to the github repository for p1load: https://github.com/dbetz/p1load
Sadly you missed the fact that the PloadLib.c in prop-gcc is, despite it's name, by itself itself a stand alone very simple propeller loader. Only requires the osint... serial port support interface modules and the header files. Only a couple of files to copy and paste from https://code.google.com/p/propgcc/source/browse/?name=default#hg%2Floader
Never mind, writing a loader is a nice exercise and it's not such a big job.
I do wish prop-gcc would move to github. git and github are certainly much faster.