I guess I've never thoroughly read the ANSI C specification but I've used C for more years than I can count and there are certainly features of every C runtime environment I've ever used that are not in the ANSI C specification but should probably be supported in a practical implementation. One of these is simple line editing so when you read from the console you get to use backspace to edit your input text. I guess you could argue that this is overkill for an embedded system but the very fact that we're trying to make the Propeller run C in the first place is stretching what it was designed for so why not provide the expected C environment. If you just implement backspace in every driver the higher level "read from STDIN" code can use that to implement simple line editing by doing "backspace space backspace" for every backspace character the user types. That's good enough for most purposes. I will be happy to volunteer to help with this.
I used t_getpos and t_setpos to implement a simple line editor so xbasic is now sort-of functioning on the Dracblade compiled with Catalina. There are still some problems though. Error handing doesn't seem to be working which makes me wonder about whether setjmp and longjmp are working correctly. Also, even though "save" and "load" are implemented, they hang on the Dracblade under Catalina even with an SD card inserted in the Dracblade. I'm not sure if there is some "mount" operation that I have to do before doing fopen/fprintf/fclose.
I've attached a zip file containing the sources for this new version of xbasic. This zip file also contains a compiled binary in bin/xbasic.binary as well as syntax.txt that gives a summary of the syntax accepted by the xbasic compiler. I certainly haven't tested all of the statement types. In fact, the only thing I've really tested so far are the statements that are in test.bas which is the test program I've been using as a quick sanity check.
Hmmm.... I just added support for CLKFREQ, CNT, INA, OUTA, and DIRA and ran the timing loop that Humanoido used to time Bean's Embedded Basic and it seems that xbasic is more than 50 times slower. :-(
I'm sort of surprised it is so much slower because it compiles to bytecodes and just interprets the bytecodes at runtime. You'd think that would be faster than parsing the program at runtime like I believe Embedded Basic does. Part of the difference is probably that xbasic is running out of external memory and I think Embedded Basic fits entirely in hub memory. Anyway, the xbasic performance is disappointing under Catalina and its performance under ZOG is even slower.
If you are using Catalina function calls such as _ina() and _outa() (or your program consists of a lot of other small function calls, as many C programs do), then you should also use the Catalina Optimizer. I have seen execution speed double in some cases - this is because the optimizer 'inlines' such very small function calls very effectively.
Also, I presume you are timing performance on the the DRACBLADE? That platform has particularly slow XMM RAM (this is not a criticism of the design - it is simply a consequence of the limited number of pins Dr_Acula had to implement the XMM interface). But it does mean your program speed will be faster on another platform - and also will improve dramatically once you can start using the new caching XMM driver.
It's possible that a combination of these could improve your program execution speed by 4 or 5 times.
On another subject, Implementing backspace in the dozen or so HMI plugins is not too difficult (they all have basically the same structure) - the main problem is simply finding the space to do so. I have already had to dump a couple of functions from some of the HMI plugins (t_integer, t_hex) and re-implement them in C. I may have to dump a few more (e.g. t_int, t_unsigned).
Ross.
P.S. I'll try your new version of xbasic out tonight. I can't think of any reason that the file access or setjmp/longjmp shouldn't work.
I just tried xbasic compiled for ZOG on the Dracblade and it looks like the Catalina version is twice as fast at executing the compiled bytecodes but is significantly faster at compiling from basic source to bytecodes.
I just tried xbasic compiled for ZOG on the Dracblade and it looks like the Catalina version is twice as fast at executing the compiled bytecodes but significantly slower at compiling from basic source to bytecodes.
How odd! What does "significantly" mean? Is it twice as slow? More?
Must be some specific operation that Catalina is doing particularly slowly. I'd like to find out what it is and fix it. Shame we don't have a profiler for the Prop!
How odd! What does "significantly" mean? Is it twice as slow? More?
Must be some specific operation that Catalina is doing particularly slowly. I'd like to find out what it is and fix it. Shame we don't have a profiler for the Prop!
Ross.
No, sorry. I meant that the ZOG version of the compiler was significantly slower than the Catalina version.
Maybe I'd better make an xbasic thread the next time but I thought I'd post one more message here with the xbasic sources so RossH can try it and let me know what I'm doing wrong that is causing my error handling and SD card file I/O to fail. This version is cleaned up a bit from the last version and also replaces the inappropriate printf function with a more normal looking PRINT statement. So, the following program should work:
10 for x=1 to 10
20 print x, x*x
30 next x
I have lots more to do including adding dynamic strings and objects but this version works and has at least a little ability to interface with the Propeller. I have implemented CNT, INA, OUTA, DIRA, and CLKFREQ variables so you should be able to flash an LED. :-)
Maybe I'd better make an xbasic thread the next time but I thought I'd post one more message here with the xbasic sources so RossH can try it and let me know what I'm doing wrong that is causing my error handling and SD card file I/O to fail.
Hi David,
I think I have sorted out your problem. There are two issues:
1. Your make file is mixing up compile flags and link flags. This meant the correct flags were only set on the compilation of xbasic.c, and not on the other files. This results in different object files using different memory models, which gave rise to some very odd behaviour. I think this explains many of the problems (e.g. LARGE XMM mode not working, debugger not working, setjmp/longjmp not working). Change your makefile to the following:
Note that these lines specify the -x5 (LARGE XMM) memory model - if you use this memory model you will be able to run larger much BASIC programs.
2. Also, have you downloaded the latest update to Catalina (i.e. Catalina_2.9_C3_target_update_3.zip)? I think this may be the reason your SD Card is not working - there was a bug in the original 2.9 release that meant the SD Card plugin was not being loaded when the program was compiled with the -lcix option - so the program just freezes waiting for the SD card driver to respond. Just download this file from sourceforge and unzip it in your target directory.
As far as I can tell, everything now seems to work correctly.
Ross.
P.S. There is no problem with the DRACBLADE platform support - all the strange problems I saw are explained by the above issues.
Thanks for the advice on CFLAGS and LDFLAGS. I have to say that it seems odd to me to use -D flags in the linker command line. -D usually defines preprocessor macros that are only used when compiling code not linking it. I think that may have been where I was confused.
I was running the official 2.9 release not the C3 update. I figured that was experimental. I guess I wasn't aware that it also fixed a bug in the official 2.9 release. I'll make both of those changes and try this again on my Dracblade board. It's good to know that everything should be working fine. It will be interesting to see how Catalina with the large XMM memory model compares with ZOG. The previous test wasn't really fair since the Catalina small XMM memory model puts all data in hub memory which is of course much faster.
I tried changing the makefile CFLAGS and LDFLAGS and building with the C3 update to Catalina and now the SD card save and load functions are working. However, error handling is still failing. This may be my own bug though.
I tried changing the makefile CFLAGS and LDFLAGS and building with the C3 update to Catalina and now the SD card save and load functions are working. However, error handling is still failing. This may be my own bug though.
Hi David,
Once I finish the C3 Flash loader I'll have a look at the error handling if you're still having problems. Could still be a Catalina issue in there somewhere.
Thanks Ross! It's interesting that SD card I/O is working under Catalina on the Dracblade but not error handling but SD card I/O is failing under ZOG on the C3 but error handling is working and the same code is running on both! :-)
I have Flash support for the C3 working now - Catalyst and all the other loaders (such as the payload serial loaders) can now use SPI RAM and SPI Flash in much the same way as they use ordinary XMM RAM.
There is a new memory model (-x3) and a couple of new compile-time flags which allow the read-only segments to be separated from the read-write segments - the idea being that the former can in SPI Flash and the latter can go in SPI RAM. The same model will work on both the C3 and the Morpheus platform.
The reason it is taking so long is that I had to do some re-organization of Catalina's use of upper Hub RAM - which means I have to re-test everything else on all other platforms before I can do a release. It also means the changes are too extensive for a patch release, so I will have to do a full Catalina 3.0 release.
I have a question about 3.0 and the use of SPI flash. Will it be possible to load code into SPI flash and the Catalina VM into EEPROM to make a system that will boot directly into the application already in flash on reset without requiring an SD card or serial connection for payload?
I have a question about 3.0 and the use of SPI flash. Will it be possible to load code into SPI flash and the Catalina VM into EEPROM to make a system that will boot directly into the application already in flash on reset without requiring an SD card or serial connection for payload?
Hi David,
Yes, the -x3 (aka FLASH) memory model puts all code segments into SPI Flash, plus the initialized parts of the data segments. The Catalina target is not stored in the FLASH, but can be programmed into EEPROM separately. If the loader in the target detects a -x3 binary in the SPI FLASH it copies the data segments into SPI RAM before loading and starting the kernel. So Catalina programs can be made to auto-execute on Prop reset without either a serial connection or an SD card.
There is another interesting benefit to this scheme - because Catalina implements a Hardware Abstraction Layer, the program (as stored in the FLASH) is not dependent on the target at all - this means the same program loaded in FLASH can be executed with different device drivers loaded - e.g. you could have a target loaded into EEPROM that detects whether a VGA display is connected and figures out whether to load a VGA or a TV driver.
I think Andre' has posted code somewhere for detecting that a VGA display is plugged in - so if I get time I'll include an example target that does this in the release.
Here is a sneak peak at a fully functional Catalina 3.0 for the C3!
The attached archive contains "Super Star Trek" compiled for the C3 using Catalina.
The program executes from the C3's SPI FLASH, using the SPI RAM for global data and heap space, and Hub RAM for the stack and local variables. It uses the TV display and keyboard on the C3. It also uses the SD card - but an SD card is only required if you want to load and save games, or use the on-line help. To use the on-line help, you must load the enclosed sst.doc file into the root directory of an SD card and insert it before playing the game.
The game has to use the TV display instead of the VGA display because the caching SPI XMM driver takes an extra cog, and hence the game cannot use the normal 80 column VGA display - this means the game is not especially pretty (it was intended to be played on an 80 column terminal, not a 40 column TV display) - but it is quite functional. In any case, it is primarily intended as a simple demonstration of the forthcoming capabilities of Catalina on the C3.
You can load the program into the C3 using any version of the Catalina payload loader (not included). To load it, unzip all the files in this archive to a local directory somewhere on your PC, and then connect the PC to the C3.
Then execute the following command:
payload -t 1000 xmm sst
The xmm parameter refers to a new XMM loader (included) that knows how to program the SPI FLASH, and the -t 1000 raises the payload comms timeout (in this case to 5 seconds - i.e. 5 retries of 1000ms each). This is necessary because the load process must erase the SPI FLASH, and this can take several seconds. The default payload timeout is short enough that the program thinks the C3 has failed to respond when it gets to that part of the load process.
The program is large (over 400kb) and can take a minute or two to load into the C3. The comms LEDs will stop flashing for a few seconds during the load process - don't panic, this is normal during the FLASH erase.
Catalina 3.0 is still in testing, but I hope to have a release ready soon!
Enjoy!
Ross.
P.S. This version will not auto-boot on reset - it needs to be reloaded each time. To auto-boot requires a new Flash_Boot program to be loaded into EEPROM - this program will be available in the full release of Catalina 3.0.
Well done! I guess there would have been a lot of coding behind the scenes. I am particularly impressed with the thousand fold increase in the download speed *grin*
The program is large (over 400mb) and can take a minute or two to load into the C3
Well done! I guess there would have been a lot of coding behind the scenes. I am particularly impressed with the thousand fold increase in the download speed *grin*
I tried changing the makefile CFLAGS and LDFLAGS and building with the C3 update to Catalina and now the SD card save and load functions are working. However, error handling is still failing. This may be my own bug though.
Hi David,
Just wanted to let you know I found a problem with Catalina's implementation of setjmp & longjmp that would have affected some XMM platforms. This may explain why your error handling code is not working.
I'll include the fix in release 3.0.
Ross.
P.S. I just tried it on the DRACBLADE, and the error handling now seems to work correctly.
Just wanted to let you know I found a problem with Catalina's implementation of setjmp & longjmp that would have affected some XMM platforms. This may explain why your error handling code is not working.
I'll include the fix in release 3.0.
Ross.
P.S. I just tried it on the DRACBLADE, and the error handling now seems to work correctly.
That's great news! I'm looking forward to trying Catalina 3.0!
Now we can get back to more serious issues - like how to make C the language of choice for the Propeller II
Ross.
This has got me thinking, why not on the prop 1 as well?
A general question might be to ask what barriers there might be to using C. I can think of two (and I'm slowly working towards trying to solve them but someone left at work last week so I'm doing two jobs and *severely* withdrawing from lack of propeller time)
Two things I can think of are:
a) an IDE that looks similar to the proptool and
b) cog objects that can be dropped in with the ease of the propeller spin library
I think both of these are entirely achievable. I have a) working in vb.net though I'm a bit stuck porting it over to a platform that can run on linux and apple. It is the little things, like the differences in directory structures / vs \ vs : but I think they are all solvable.
b) will just take time, but I'd like to think that a critical mass of users might be all it takes.
Perhaps I need to build a cloning device so I can clone myself...
I'm taking a look again at self contained cog objects. Pass variables, return variables.
I have this code working:
PUB Main
coginit(1,@cogstart,0) ' cog 1, cogstart, dummy value
DAT
org 0
cogstart wrbyte testvalue, testaddress ' test value A
jmp #cogstart
testaddress long 500 ' hub location
testvalue long 65 ' ascii A
fit 496
PASM End
*/
void mycogject(int cognumber, unsigned long parameters) // this name copied from the .spin name in the pasm section - names must match eg void mycogject matches mycogject.spin. Also first code after this must be the .h array file. Put your code after the };
{
/**
* @file mycogject_array.h
* Created with spin.binary PASM to C Array Converter.
* Copyright (c) 2011, John Doe
*/
unsigned long mycogject_array[] =
{
0xa0bc09f0, 0x003c0803, 0x5c7c0000, 0x000001f4,
0x00000041
};
unsigned long par_cogject[] = { 100, 2, 3 }; // data to pass to cog - ignore if not used
_coginit((int)par_cogject>>2, (int)mycogject_array>>2, cognumber); // array name built from spin file name
}
and it prints "A" = 65
Now I would like to pass a parameter via Par. I think this does the code from C
unsigned long par_cogject[] = { 100, 2, 3 }; // data to pass to cog - ignore if not used
but I can't seem to get the data back out again within the pasm code. Is the syntax correct here for 'par'? It always returns 40, regardless of what I change in the par_cogject array
PUB Main
coginit(1,@cogstart,0) ' cog 1, cogstart, dummy value
DAT
org 0
cogstart mov testvalue,par
wrbyte testvalue, testaddress ' test value A
jmp #cogstart
testaddress long 500 ' hub location
testvalue long 65 ' ascii A
fit 496
PASM End
*/
void mycogject(int cognumber, unsigned long parameters) // this name copied from the .spin name in the pasm section - names must match eg void mycogject matches mycogject.spin. Also first code after this must be the .h array file. Put your code after the };
{
/**
* @file mycogject_array.h
* Created with spin.binary PASM to C Array Converter.
* Copyright (c) 2011, John Doe
*/
unsigned long mycogject_array[] =
{
0xa0bc09f0, 0x003c0803, 0x5c7c0000, 0x000001f4,
0x00000041
};
unsigned long par_cogject[] = { 100, 2, 3 }; // data to pass to cog - ignore if not used
_coginit((int)par_cogject>>2, (int)mycogject_array>>2, cognumber); // array name built from spin file name
}
Hmm - just thought of something - I'm passing longs but writing bytes. However, it should ? be ok, it is the LSB that should get passed?
You need to transfer par into testaddress not testvalue.
PUB Main
coginit(1,@cogstart,0) ' cog 1, cogstart, dummy value
DAT
org 0
cogstart mov [COLOR="red"]testaddress[/COLOR],par
wrbyte testvalue, testaddress ' test value A
jmp #cogstart
testvalue long 65 ' ascii A
testaddress res 1 ' hub location
fit
Just to answer Dr_A's question - yes, passing longs but writing bytes will work since the values are all less than 256 - the Prop is a "little endian" architecture which means a byte read from or written to a long address refers to the "littlest" byte of the long.
Prop is a "little endian" architecture which means a byte read from or written to a long address refers to the "littlest" byte of the long.
little endian = first byte at "little end" of address i.e. byte 0 of a word or long, etc....
big endian = first byte at "big end" of address i.e. byte 1 of a word, byte 3 of a long, etc...
Comments
Thanks,
David
I've attached a zip file containing the sources for this new version of xbasic. This zip file also contains a compiled binary in bin/xbasic.binary as well as syntax.txt that gives a summary of the syntax accepted by the xbasic compiler. I certainly haven't tested all of the statement types. In fact, the only thing I've really tested so far are the statements that are in test.bas which is the test program I've been using as a quick sanity check.
I'm sort of surprised it is so much slower because it compiles to bytecodes and just interprets the bytecodes at runtime. You'd think that would be faster than parsing the program at runtime like I believe Embedded Basic does. Part of the difference is probably that xbasic is running out of external memory and I think Embedded Basic fits entirely in hub memory. Anyway, the xbasic performance is disappointing under Catalina and its performance under ZOG is even slower.
If you are using Catalina function calls such as _ina() and _outa() (or your program consists of a lot of other small function calls, as many C programs do), then you should also use the Catalina Optimizer. I have seen execution speed double in some cases - this is because the optimizer 'inlines' such very small function calls very effectively.
Also, I presume you are timing performance on the the DRACBLADE? That platform has particularly slow XMM RAM (this is not a criticism of the design - it is simply a consequence of the limited number of pins Dr_Acula had to implement the XMM interface). But it does mean your program speed will be faster on another platform - and also will improve dramatically once you can start using the new caching XMM driver.
It's possible that a combination of these could improve your program execution speed by 4 or 5 times.
On another subject, Implementing backspace in the dozen or so HMI plugins is not too difficult (they all have basically the same structure) - the main problem is simply finding the space to do so. I have already had to dump a couple of functions from some of the HMI plugins (t_integer, t_hex) and re-implement them in C. I may have to dump a few more (e.g. t_int, t_unsigned).
Ross.
P.S. I'll try your new version of xbasic out tonight. I can't think of any reason that the file access or setjmp/longjmp shouldn't work.
How odd! What does "significantly" mean? Is it twice as slow? More?
Must be some specific operation that Catalina is doing particularly slowly. I'd like to find out what it is and fix it. Shame we don't have a profiler for the Prop!
Ross.
No, sorry. I meant that the ZOG version of the compiler was significantly slower than the Catalina version.
Here is a summary of the xbasic syntax:
Hi David,
I think I have sorted out your problem. There are two issues:
1. Your make file is mixing up compile flags and link flags. This meant the correct flags were only set on the compilation of xbasic.c, and not on the other files. This results in different object files using different memory models, which gave rise to some very odd behaviour. I think this explains many of the problems (e.g. LARGE XMM mode not working, debugger not working, setjmp/longjmp not working). Change your makefile to the following:
Note that these lines specify the -x5 (LARGE XMM) memory model - if you use this memory model you will be able to run larger much BASIC programs.
2. Also, have you downloaded the latest update to Catalina (i.e. Catalina_2.9_C3_target_update_3.zip)? I think this may be the reason your SD Card is not working - there was a bug in the original 2.9 release that meant the SD Card plugin was not being loaded when the program was compiled with the -lcix option - so the program just freezes waiting for the SD card driver to respond. Just download this file from sourceforge and unzip it in your target directory.
As far as I can tell, everything now seems to work correctly.
Ross.
P.S. There is no problem with the DRACBLADE platform support - all the strange problems I saw are explained by the above issues.
Thanks for the advice on CFLAGS and LDFLAGS. I have to say that it seems odd to me to use -D flags in the linker command line. -D usually defines preprocessor macros that are only used when compiling code not linking it. I think that may have been where I was confused.
I was running the official 2.9 release not the C3 update. I figured that was experimental. I guess I wasn't aware that it also fixed a bug in the official 2.9 release. I'll make both of those changes and try this again on my Dracblade board. It's good to know that everything should be working fine. It will be interesting to see how Catalina with the large XMM memory model compares with ZOG. The previous test wasn't really fair since the Catalina small XMM memory model puts all data in hub memory which is of course much faster.
Thanks,
David
Hi David,
Once I finish the C3 Flash loader I'll have a look at the error handling if you're still having problems. Could still be a Catalina issue in there somewhere.
Ross.
I have Flash support for the C3 working now - Catalyst and all the other loaders (such as the payload serial loaders) can now use SPI RAM and SPI Flash in much the same way as they use ordinary XMM RAM.
There is a new memory model (-x3) and a couple of new compile-time flags which allow the read-only segments to be separated from the read-write segments - the idea being that the former can in SPI Flash and the latter can go in SPI RAM. The same model will work on both the C3 and the Morpheus platform.
The reason it is taking so long is that I had to do some re-organization of Catalina's use of upper Hub RAM - which means I have to re-test everything else on all other platforms before I can do a release. It also means the changes are too extensive for a patch release, so I will have to do a full Catalina 3.0 release.
Ross.
Hi David,
Yes, the -x3 (aka FLASH) memory model puts all code segments into SPI Flash, plus the initialized parts of the data segments. The Catalina target is not stored in the FLASH, but can be programmed into EEPROM separately. If the loader in the target detects a -x3 binary in the SPI FLASH it copies the data segments into SPI RAM before loading and starting the kernel. So Catalina programs can be made to auto-execute on Prop reset without either a serial connection or an SD card.
There is another interesting benefit to this scheme - because Catalina implements a Hardware Abstraction Layer, the program (as stored in the FLASH) is not dependent on the target at all - this means the same program loaded in FLASH can be executed with different device drivers loaded - e.g. you could have a target loaded into EEPROM that detects whether a VGA display is connected and figures out whether to load a VGA or a TV driver.
I think Andre' has posted code somewhere for detecting that a VGA display is plugged in - so if I get time I'll include an example target that does this in the release.
Ross.
Yes, I always underestimate the time needed to test - and every time I add a new platform it doubles the testing time required! :depressed:
Here is a sneak peak at a fully functional Catalina 3.0 for the C3!
The attached archive contains "Super Star Trek" compiled for the C3 using Catalina.
The program executes from the C3's SPI FLASH, using the SPI RAM for global data and heap space, and Hub RAM for the stack and local variables. It uses the TV display and keyboard on the C3. It also uses the SD card - but an SD card is only required if you want to load and save games, or use the on-line help. To use the on-line help, you must load the enclosed sst.doc file into the root directory of an SD card and insert it before playing the game.
The game has to use the TV display instead of the VGA display because the caching SPI XMM driver takes an extra cog, and hence the game cannot use the normal 80 column VGA display - this means the game is not especially pretty (it was intended to be played on an 80 column terminal, not a 40 column TV display) - but it is quite functional. In any case, it is primarily intended as a simple demonstration of the forthcoming capabilities of Catalina on the C3.
You can load the program into the C3 using any version of the Catalina payload loader (not included). To load it, unzip all the files in this archive to a local directory somewhere on your PC, and then connect the PC to the C3.
Then execute the following command:
The xmm parameter refers to a new XMM loader (included) that knows how to program the SPI FLASH, and the -t 1000 raises the payload comms timeout (in this case to 5 seconds - i.e. 5 retries of 1000ms each). This is necessary because the load process must erase the SPI FLASH, and this can take several seconds. The default payload timeout is short enough that the program thinks the C3 has failed to respond when it gets to that part of the load process.
The program is large (over 400kb) and can take a minute or two to load into the C3. The comms LEDs will stop flashing for a few seconds during the load process - don't panic, this is normal during the FLASH erase.
Catalina 3.0 is still in testing, but I hope to have a release ready soon!
Enjoy!
Ross.
P.S. This version will not auto-boot on reset - it needs to be reloaded each time. To auto-boot requires a new Flash_Boot program to be loaded into EEPROM - this program will be available in the full release of Catalina 3.0.
Oops! Kb, not Mb!
Hi David,
Just wanted to let you know I found a problem with Catalina's implementation of setjmp & longjmp that would have affected some XMM platforms. This may explain why your error handling code is not working.
I'll include the fix in release 3.0.
Ross.
P.S. I just tried it on the DRACBLADE, and the error handling now seems to work correctly.
That's great news! I'm looking forward to trying Catalina 3.0!
This has got me thinking, why not on the prop 1 as well?
A general question might be to ask what barriers there might be to using C. I can think of two (and I'm slowly working towards trying to solve them but someone left at work last week so I'm doing two jobs and *severely* withdrawing from lack of propeller time)
Two things I can think of are:
a) an IDE that looks similar to the proptool and
b) cog objects that can be dropped in with the ease of the propeller spin library
I think both of these are entirely achievable. I have a) working in vb.net though I'm a bit stuck porting it over to a platform that can run on linux and apple. It is the little things, like the differences in directory structures / vs \ vs : but I think they are all solvable.
b) will just take time, but I'd like to think that a critical mass of users might be all it takes.
Perhaps I need to build a cloning device so I can clone myself...
Nooooo! I can barely keep up with just one of you!
Ross.
I'm taking a look again at self contained cog objects. Pass variables, return variables.
I have this code working:
PUB Main coginit(1,@cogstart,0) ' cog 1, cogstart, dummy value DAT org 0 cogstart wrbyte testvalue, testaddress ' test value A jmp #cogstart testaddress long 500 ' hub location testvalue long 65 ' ascii A fit 496 PASM End */ void mycogject(int cognumber, unsigned long parameters) // this name copied from the .spin name in the pasm section - names must match eg void mycogject matches mycogject.spin. Also first code after this must be the .h array file. Put your code after the }; { /** * @file mycogject_array.h * Created with spin.binary PASM to C Array Converter. * Copyright (c) 2011, John Doe */ unsigned long mycogject_array[] = { 0xa0bc09f0, 0x003c0803, 0x5c7c0000, 0x000001f4, 0x00000041 }; unsigned long par_cogject[] = { 100, 2, 3 }; // data to pass to cog - ignore if not used _coginit((int)par_cogject>>2, (int)mycogject_array>>2, cognumber); // array name built from spin file name }and it prints "A" = 65
Now I would like to pass a parameter via Par. I think this does the code from C
unsigned long par_cogject[] = { 100, 2, 3 }; // data to pass to cog - ignore if not usedbut I can't seem to get the data back out again within the pasm code. Is the syntax correct here for 'par'? It always returns 40, regardless of what I change in the par_cogject array
PUB Main coginit(1,@cogstart,0) ' cog 1, cogstart, dummy value DAT org 0 cogstart mov testvalue,par wrbyte testvalue, testaddress ' test value A jmp #cogstart testaddress long 500 ' hub location testvalue long 65 ' ascii A fit 496 PASM End */ void mycogject(int cognumber, unsigned long parameters) // this name copied from the .spin name in the pasm section - names must match eg void mycogject matches mycogject.spin. Also first code after this must be the .h array file. Put your code after the }; { /** * @file mycogject_array.h * Created with spin.binary PASM to C Array Converter. * Copyright (c) 2011, John Doe */ unsigned long mycogject_array[] = { 0xa0bc09f0, 0x003c0803, 0x5c7c0000, 0x000001f4, 0x00000041 }; unsigned long par_cogject[] = { 100, 2, 3 }; // data to pass to cog - ignore if not used _coginit((int)par_cogject>>2, (int)mycogject_array>>2, cognumber); // array name built from spin file name }Hmm - just thought of something - I'm passing longs but writing bytes. However, it should ? be ok, it is the LSB that should get passed?
PUB Main coginit(1,@cogstart,0) ' cog 1, cogstart, dummy value DAT org 0 cogstart mov [COLOR="red"]testaddress[/COLOR],par wrbyte testvalue, testaddress ' test value A jmp #cogstart testvalue long 65 ' ascii A testaddress res 1 ' hub location fitJust to answer Dr_A's question - yes, passing longs but writing bytes will work since the values are all less than 256 - the Prop is a "little endian" architecture which means a byte read from or written to a long address refers to the "littlest" byte of the long.
Ross.
big endian = first byte at "big end" of address i.e. byte 1 of a word, byte 3 of a long, etc...