One other thing that I had a lot of problems with was a particular 512Mb SD card. I had similar problems with this card with fsrw, and all those problems went away when Kye's SD card driver came along. I got used to this particular card working, and suddenly remembered I should go back and try my 1Gb sandisk cards.
So, one job might be to port over Kye's latest code (or maybe the latest fsrw) so it works with a wider variety of sd card brands.
Glad you got it working. Yes, I should check out Kye's latest code - I used a very early version, but I had to modify it to suit my needs. I'll see if I can adapt his latest version.
Hi Nick. Nothing as far as I know - are you having a problem with it? It works ok in all the cases I have tried.
Ross, I'm sorry!
I get the message that it is elided, but the cause is something different that I don't understand yet. It is code that compiled with ICC, so it should be right.
LCC gives you a message about code being "elided" if the compiler detects that the code actually does nothing - it simply eliminates it.
This worried me the first few times I saw it, but I have never found a case where it was wrong. For example, consider the following code:
void main () {
int i;
i; // this is a valid C statement - but it does nothing at all!
}
When you compile this, you get the message "expression with no effect elided"
Ross.
The funny thing is most engineers do not know what "elided" mean so they would contact us. I have considered changing it, but to what? Maybe "No code generated for expression with no side effect?"
Hmmm... that does sound pretty good. Maybe I will do that.
LCC gives you a message about code being "elided" if the compiler detects that the code actually does nothing - it simply eliminates it.
I know what elided is.
Fact is, that there is no dead code. Must have something to do with the compile sequence of code::blocks or that I forgot to move some files or something in that corner.
Again, forget about that matter until I come up with a more clever question.
First challenge - running bigger programs than hello world. What I'm attempting to show here is that not only can programs bigger than the propeller internal memory be run on the propeller, but (as far as I know), this allows Big C programs that simply cannot be done with Spin.
Case in point - KyeDOS is a brilliant little program that has a nice display, keyboard, sd card access, xmodem file transfer, but by the time you add all that overhead, there is little room left for your actual program.
I tried startrek because it is the biggest C program in the demo folder.
Catalina Compiler 2.6
Undefined or Redefined symbols:
pow undefined
fabs undefined
sqrt undefined
pow undefined
log10 undefined
Press any key to continue . . .
I compiled Othello and that works.
Next problem. Every time you recompile a program, you have to take out the sd card. So - is it possible to download and run a C program via the programming cable?
Well, I'm glad you asked.
Yes, it is possible. Run KyeDOS as the eeprom program in the propeller. Use the Xmodem file transfer function to send OTHELLO.BIN (this takes 20 seconds or so at 38k, but this speed could easily be increased). Then use KyeDOS to run CATALYST.BIN, and run Othello from Catalyst.
All this is a bit convoluted, but it does work, and the next step is to simplify things. Eg - KyeDOS could contain the Catalyst loader. OR, Catalyst could contain xmodem.
Further, KyeDOS has been set up so that you can 'type' commands via the serial port. So an IDE on a PC can send the commands to initiate the download. Catalyst could do the same thing.
So this is my little challenge to myself - set up an IDE with a C program in a window, and have a single 'compile/download/run' button.
So at some point I might need to hack into catalyst in some way.
Also, as an aside, this program is running on XMM on the dracblade. Are there any 'external ram' variants of catalina that run with SPI 8 pin SRAM chips? I had a crazy idea last night for a really minimalist board - propeller, sd card, vga, keyboard, TV, mouse, serial ram chip (maybe 128k), 12 free pins, and a huge area on the board laid out with the same tracks as a breadboard for prototyping.
When compiling startrek, add the -lm command line switch. This includes the maths library. This is done automatically if you use the build_all.bat command - open this file in a text editor and check the options it uses when compiling each program.
Ross.
P.S. There is currently no "SPI RAM" XMM driver for Catalina. I was going to develop one for the C3, but did not (at the time) have enough time to do so. Also, the performance of executing from SPI RAM would be very poor.
Ok, I think can add those sorts of extra switches with radio buttons.
Yes, if you say SPI is going to be too slow, that probably is right. A byte read from the dracblade is about 20 pasm instructions. Not sure how many for an SPI or the speed.
See attached. This is an IDE for Catalina. Default directory is the demo directory. Hit "compile" and it creates a batch file that combines "use catalina" and the catalina compilation with the switches for the dracblade and hi res VGA. It then automatically downloads using xmodem on KyeDOS.
Time to download Othello was about 25 seconds, which I think is a little faster than pulling out the sd card, copying it and putting it back in. Certainly more convenient anyway.
The IDE then 'types' the phrase "Spin Catalyst.bin"<CR> into KyeDOS, which runs Catalyst. Then you have to manually type the name of the program in Catalyst to run it.
I wonder if catalyst can be modified slightly so it accepts input from either the keyboard, or the serial port (like KyeDOS does).
Also attached is the serial port driver from KyeDOS. This is the best one for the dracblade, as it has two ports and runs in one cog (the original was 4 ports, and Pullmoll changed it to two but increased the buffer size).
Hmm - what other goodies could we add? How about the vt100 driver code from KyeDOS and the CPM project. Why VT100? Well, you can print to it like a normal terminal, but you can also send escape sequences to move the cursor around, and also other escape sequences to change the text and background color.
Addit: another question. Is there a way of finding out how much program space is free? eg, we have a 512k sram chip. If the program "new.c" is 89kb, some of that goes into hub (cog code etc), but roughly how much space is left? I could maybe get the filesize and my IDE could subtract 512k minus program size minus a constant, and give a rough idea how much space is left?
Impressive - I'll really have to look into KyeDos. I wrote Catalyst mainly as a way of simplifying the loading of Catalina programs. Maybe I should have just published a self-contained loader program and encouraged others to incoorporate it into their projects.
But in a way this is what Payload is already - its designed to be able to download not only ordinary binaries, but also XMM programs - and it doesn't need anything (xmodem or otherwise) to be running on the other end.
As for program size/memory space - yes, this is something I will be adding to Catalyst/Catalina sometime soon. Being able to find out at both compile time and load time exactly how much space is required by a program would be very useful. Trouble is that it's not quite as simple as just looking at the file size - you have to do a bit of digging around within the files, and also understand the various Catalina memory layouts.
Another thing - you don't need to run Catalyst just to run a Catalina program. Any normal Catalina (LMM) program binary can be loaded using any normal Parallax load process - you only need Catalyst for loading XMM programs from the SD Card. If you are happy to load them serially you don't need anything other than Payload (but beware - loading a 512kb program serially can take a long time!).
I've attached KyeDOS. Let's pull it to bits and see what happens!
Given we have an sd card, I would suspect that downloading things all the time will not be fun, especially big programs. I'd use this in the way that I'd write a C program on an IDE, download it to an SD card, then run it from the SD card.
For an 'autorun', maybe this can be an additional command? Maybe copy what we have in CP/M - there is an autoexec.sub and on startup, if no keyboard input is received for a while, the program goes and runs whatever is in autoexec. There are many possibilities with commands you could add to an autoexec, eg 'wait'
I've been deep inside the catalyst_xmm_sd_loader, which I've discovered is the core of the catalyst program.
Can you explain Payload a bit more? Does it download to hub/xmm, or does it download to the sd card, or does it download to both?
I'm just thinking of protocols. I understand xmodem, so I am happy writing xmodem in vb.net at one end, and Spin at the other end. But other protocols would be worth looking at, especially as they may be faster. If I know the protocol, I can write code in vb.net at the IDE end.
I'd like to get the compile/download/run for a large 200k xmm program truly down to one keypress. I see two ways to do this:
1) Modify Catalyst so it can handle a serial download to an sd card.
2) Modify KyeDOS so it can handle the loading of 200k programs.
There are advantages and disadvantages to each:
1) Catalyst can't do fat32 and can't handle some sd cards. This is a disadvantage compared to KyeDOS
2) KyeDOS does not have the bootloader code (I need to try to understand this more, as it is written in pasm and appears to load the first 31k into hub, then the rest into external memory)
3) Catalyst can't handle inputs from multiple sources like KyeDOS
repeat
if key.gotkey <>0 ' scan both the local keyboard and the com port
result:=key.getkey
if sio.rxavail(0)
result :=sio.rx(0)
until result <>0 ' until something comes in either port
I am not sure which is going to be the best, as each involves a rewrite of code.
So I've attached KyeDOS - maybe we can brainstorm hybridising some code?
So the quickest program is to combine the best of KyeDOS and Catalyst into one program.
But there is a 'quick and dirty' solution, that involves adding something like that code fragment as an #ifdef to Catalyst. The #ifdef would be #ifdef dracblade, and the code would accept bytes from both the serial port and keyboard. Then the IDE would be able to 'type' commands into catalyst as if they were being inputted from the keyboard.
Where this is heading is something very exciting - Big Programs on the propeller, in a standard language, with a very simple IDE that does not need any knowledge of command lines, (nor the complexity of what I went through yesterday). In other words, you can get your 'hello world' working quickly, but then seamlessly move up to 500kilobyte programs, with many thousands of code lines, without having to worry about running out of memory.
I think I might have discovered a way to completely automate the compile/download process. In the catalyst help I found this
build_all DRACBLADE <-- to use local VGA and keyboard
or
build_all DRACBLADE PC VT100 <-- to use PC terminal emulator
So I tried compiling with the second option, but I am getting garbage characters on the display. Now, this is a problem I've seen before many times with the CP/M emulation, and the solution has been to drop the baud rate from 115k to 38k (I think it is due to my longer serial cable)
However, I've not had any luck recompiling catalyst with a new baud rate. I found this line in the file Catalina_Common_Input.spin in the directory c:\program files\catalina\target\input
' DracBlade Loader and InterProp Comms definitions:
'
SIO_BAUD = 115200 ' Baud rate to use for all interprop comms and serial loading
However, changing this value did not seem to help. Is this the correct source file? I see in the compiler it uses a file "cataline_common" not "catalina_common_input"
Any help would be most appreciated as I think this might be the final part of a 'one keypress IDE'.
You won't get much sense out of me tonight - it's my 50th birthday tonight, and we've just opened a bottle of '99 Grange Hermitage.
But a couple of quick points:
Yes, the XMM SD card loader is the key to Catalyst - the rest is just frills.
When loading an XMM program, the Payload program actually downloads two programs - it first downloads a program that knows how to accept a serial download and put it into XMM RAM. Then it downloads the actual application program. The first downloaded program puts the first 32kb in hub RAM, and the rest into XMM RAM. Then it restarts the Prop. The application it loaded into the first 31kb is also a 2-phase program. The part that got loaded into Hub RAM does the driver initialization, then it loads the kernel and starts executing the C part (which is the part that got loaded into XMM RAM).
The protocol payload uses for the first download is the normal Parallax protocol (which is why it can load on any Propeller). The next download is done uses a more sophisticated error correcting/retransmission protocol (because I found that when downloading 512kb, the error rate was significant on some noisy prop platforms - and a single bit error can ruin the whole download).
By the way - I think Catalyst can do FAT32. IT's based on Kye's FATEngine, which (from memory) does FAT16 or FAT32. If I update to Kye's latest FATEngine, it should solve the "can't do some SD cards" problem. However, while Catalina can theoretically do FAT12, FAT16 or FAT32 (although I now disable FAT12 to save space) - it will only work on SD cards with an MBR - maybe this is what you are seeing? Try reformatting the problematic SD cards to have an MBR.
The baud rate you are fiddling with is (as the comment implies) the loader baud rate. The baud rate you need to change to affect the PC HMI option are the ones in:
Just for future reference, Catalina_Common_Input.spin is the un-preprocessed version of Catalina_Common.spin. The file Catalina_Common.spin is overwritten on each compile after including the appropriate compile time options, so changing this file does nothing - as the comment at the top of the file says!:
'-------------------------------------------------------------------------------
' !!! IMPORTANT NOTE !!!
' ======================
' If the name of this file does not end in "_Input.spin", then this
' is not the original file - it is a processed version that will get
' overwritten by the next compile. Do not change this file - instead,
' locate the original version (normally in the 'input' subdirectory of
' the Catalina target directory) and modify that version of this file.
'-------------------------------------------------------------------------------
We had some nice wines last night at my wife's 40th. 'Tis the season for parties!
If you are already using some of Kye's code it should be easier to update. Indeed, even the code I'm using is not the latest as I think he speeded up a reload of hub memory from an sd card.
Ok, I'm off to check out the baud rate in those three files you suggested.
A complete compile/download/save to sd card/run of a Big C program with just one keypress in an IDE.
This is going to make development of C programs much quicker. Can I confess now that the IDE is written in visual basic?
Anyway, Othello.c takes 40 seconds. Of that, I know we can speed up several things. The baud rate can possibly go back up from 38k to 115k. Also, loading catalyst off the sd card is taking 8 seconds, and I think Kye can do this a lot quicker. And catalyst and kyedos could be combined into one program.
Downloads are always going to be longer than Spin programs because, well, the programs are bigger than spin programs.
Your description also explores another important feature of Catalina - no wasted hub memory from loading up cogs. The two pass loader means that all the hub is free for other things, and the thing that excites me most is using it for video ram. Theoretically, Catalina ought to be able to run the most detailed video the propeller is capable of, right? Because you could devote up to 31k to video ram.
There are some minor bugs with the IDE - it often (but not always) fails with the first download, but works fine the next time. Anyway, this is the source - the Catalina tab is the one on the right, and the code is at the bottom as it was the last bit added. It is written in vb.net 2008.
I'd like to now start getting catalina to do things that are not possible in spin (not at least without having access to the innards of the spin interpreter).
Assume I have a program running with a text VGA driver. The XMM C code is being interpreted in a cog, and other cogs are doing their thing with keyboard, serial etc. Data is going via rendevous points in high hub ram.
Let's say I want to start my program in text VGA and after the user answers a few questions, I want to switch to graphics mode. I want to do this from within the C code.
Is this possible?
Already it is possible to run catalyst/payload so can we run it again? The video driver code might be written in spin or C - it probably does not matter. It exists as a binary file on the sd card. So, to my thinking, steps are:
1) move that binary file into low hub ram
2) do a jump to the beginning
3) the program runs and loads into the appropriate cog(s)
4) the program ends
meanwhile, and in parallel, xmm C is running from external memory, and is testing when the above program has loaded and is running.
My thinking is that if we can do this once, we can do it many times. Load and reload cogs on the fly. The only catch I see is that if one happened to be running a vga driver that used virtually all the hub ram, then the display would blank when you did this. But you could reload the video driver again afterwards. You could even cache the video hub ram into high external ram if you wanted to, then load it back into hub ram afterwards.
Also, I'm not sure it matters if the binary you load was created in C or spin. If spin, it might be a simple program that has spin and pasm, and loads to a defined cog. The program communicates with C via rendevous points. So maybe that is the only bit of code one might need to change. It might be a way of making much of the obex available to a C program?
meanwhile, and in parallel, xmm C is running from external memory, and is testing when the above program has loaded and is running.
This is all possible - but it might be difficult A Catalina program executing from XMM is still using a stack in Hub RAM - but presumably you would want to be able to reload as much Hub RAM as possible.
One way is to arrange for your stack to be small (at least during this load process), and located up high in Hub RAM - so that you could reload most of the Hub RAM. Catalina pulls various tricks similar to this during the various load processes it currently uses - but even so it can only typically load 31kb (it needs 512 bytes as a sector buffer, and it uses another 512 bytes for various other things it needs to keep track of while loading - such as the list of sectors it needs to load).
Possibly you could come up a cog storage mechanism that essentially "swaps out" an executing XMM process to cog RAM, then swaps it back in again when Hub RAM has been reloaded. This would be a bit similar to the trick Catalyst currently employs to allow an arbitrary SPIN or C program to accept command line parameters - essentially it saves the entire command line (up to 1200 chars) in a cog while the Propeller is being "restarted" to load and run the new program.
I'm just warning you that this stuff can get really complicated :smhair:
Good points there. To keep it simple, why not keep these bits of cog code as small as possible? Maybe they only need to be about 2k (for the pasm) and a bit of glue spin at the beginning? So a 4k program or something like that?
To test this, the very first thing might be to get C to wipe the first 4k of hub ram and prove everything still keeps working. Is there a C routine that allows writing to hub ram?
The party went well, thanks - I don't feel a day over 50!
(and the wine was spectacular!!!)
There is a C function to clear memory (memset) but the results may not be what you would expect, since the memory this function will clear - even when passed a pointer value of zero - could be in hub RAM or XMM RAM depending on the memory model used to compile the C program - instead, I'd do this using an LMM PASM routine, callable from C. There are examples on how to call PASM functions in Catalina\demos\spinc).
Plugins are cog programs intended to be accessed from C via the registry (by using the various functions defined in catalina_plugin.h).
Examples of the use of these functions are littered throughout the library sources - especially in Catalina\source\lib\catalina. For example, the code to implement the t_char function (which sends a request to the HMI plugin to output a character) is as follows:
I've just finished (re) reading the catalina manual. Maybe much of what I'd like is already done. This is Good News!
1) I don't much care for the green screen for VGA. But I see you can change the color from C. So if so, that is just a couple of lines of code at the beginning of a C program?
2) The SD card driver uses Kye's code already, so upgrading it to the latest version that can handle unusual sd card brands should not be so hard?
3) The big one. Would it be possible to turn pullmoll's 2 serial port driver code (which is a derivative of Tim Moore's code) into a plugin?
I know these are a bit of an ask, but are any of these possible?
Addit: I'm pondering a new dracblade design with a mouse port, and some more input/output pins, possibly configured as a standard parallel port. I think there are obex drivers (Kye's for instance) that combine keyboard and mouse in a cog. I think with some generic I/O and a mouse/sd card/vga/serial ports and 512k of memory, this could be quite a useful hardware/software platform that you can start coding C on without worrying about the nuts and bolts).
a) Yes, the screen colours can be configured in a couple of lines of C . Or you can change the default colors in the driver itself.
b) Catalyst uses Kye's file system, and I will update it to the latest version when I get time. Catalina uses a completely different file system (written in C) called DOSFS - if you find DOSFS is missing any functionality you need then I can add it.
c) Yes, I will add pullmoll's serial driver (or perhaps some other serial driver) as a plugin when I finish the current work on the libTiny C library.
I'm thinking of putting together a step by step guide to getting catalina working - eg I now have two versions of catalyst - one is for local keyboard and one is for control via the serial port. Now that these are compiled, rather than say to a new user 'here is how to compile these programs', it may be simpler to say 'here is a zip of files, just unzip them and put them on the sd card'.
Thinking through an install of catalina on the dracblade with the vb.net IDE, on a new system, the most complicated and time consuming part might actually be the download and install of vb.net!
Is it possible to compile a tiny program on the dracblade? For quick and simple testing?
eg the switches for the dracblade are
catalina -lcx -x5 -M 128k -D DRACBLADE -D HIRES_VGA
I read in the manual that x5 is for the xmm, so I tried changing that to x0, but it gave an error "compiled image exceeds 32k". I suspect something else needs to be changed as well.
Many thanks in advance.
addit - I added a software reset for the one button compile, so it toggles the DTR line and reboots into kyedos.
Also I got the screen to change color with a C function! Life is good.
Hi Ross,
i was a bit busy the last days and didn´t move on much. I just tried some more examples and had a closer look at the functions and the return values etc..
Conserning the gamepad driver is still have some problems. I know it´s a quite simple device but I still don´t get how to access some registers.
The Gamepad has the Latch Line, Data und CLK
So i have to set those to output i guess and read the first incoming bits from the Latch Line:
Following Spin code should do this
dira[LATCH]~~
dira[CLK]~~
dira[DATA]~~
outa[LATCH]~~
//Afterwards store the bits in some othere register like ina and set set LATCH to low again
outa[LATCH]~
//read bits and have a look what key was pressed
and repeat this
Well i think that should do the job right?
But how can I port this code to C? f.e. dira[LATCH]~~ oder dira[DATA]~~
LATCH, DATA, CLK and so has to be defined somewhere in SPIN. But how do i know the adress of it from outside?
And if I got so far, how much bits do i have to read to know what or if a key was pressed? I guess i can press every button once and read the bit sequence for each and store the somewhere to get the different buttons.
I hope you can give me a nice example so I can understand it. I think if i how to acces all registers once the rest should´t be that hard any more.
You need to look at the Catalina documentation - the Catalina Reference Manual describes (on page 28) the various functions to access the special registers. Also, you could look in Catalina\include\catalina_cog.h
The Catalina functions do not map directly to PASM instructions - they generally try to do in one function call what would take several instructions in PASM. They often take a mask parameter to specify which bits to affect, then another value to indicate what to set those bits to. They also return values. For example, the function to set DIRA is defined as:
So to set bits 0 and 1 as inputs, and bits 2 & 3 as outputs without affecting any other bits you would say something like:
_dira(0xF, 0xC);
These functions return the previous value of DIRA (if you want it). So to just fetch the current setting of DIRA without affecting anything, just specify a mask of 0. For exmaple:
current_dira = _dira(0, 0)
Similarly, there are functions to manipulate OUTA - for example, the function to affect OUTA is defined as:
unsigned _outa(unsigned mask, unsigned output);
So to set OUTA bit 2 as OFF and 3 as ON, while not affecting other bits you would say something like:
_outa(0xC, 0x8)
And of course, there are also functions to fetch INA - this does not need any parameters, it just returns the whole of INA:
current_ina = _ina()
Ross.
P.S. Depending on your version of catalina_cog.h, you might see references to get_dira() and get_dirb() - you should ignore these and use the _dira() and _dirb() functions instead.
Is it possible to compile a tiny program on the dracblade? For quick and simple testing?
eg the switches for the dracblade are
catalina -lcx -x5 -M 128k -D DRACBLADE -D HIRES_VGA
I read in the manual that x5 is for the xmm, so I tried changing that to x0, but it gave an error "compiled image exceeds 32k". I suspect something else needs to be changed as well.
Many thanks in advance.
addit - I added a software reset for the one button compile, so it toggles the DTR line and reboots into kyedos.
Also I got the screen to change color with a C function! Life is good.
Hi Dr_Acula,
Your problem is the -lcx option - this includes the extended library with full SD card file system support. Generally, this results (at least in the current version) with executables larger than 32k that will only run in extended memory. But if you don't need the SD card file system, use -lc or -lci instead (-lci includes the integer libbrary which omits floating point, -lc is the standard C library that includes floating point). For example:
i.e. you don't need either the -x or the -M options to just compile as LMM. One more thing though - the HIRES_VGA option can also use so much hub RAM that a program may not fit in 32k!
I already took a look at the documentation and I know how to acces the special register itself. Probably there is still some kind of missunderstanding from my side but the problem is not to access the special registers itself but rather what address to load into the register (depending on what is needed)
My understanding of embedded programming is not as good so it´s a bit hard for me to put a clear question but i will try to with an example:
To access the DebugLed I also had to know the adress of itself.
The adress is 0x00000001;
so i set _dira(0x00000001, mask)
and set it to output _outa(0x00000001, mask)
while the mask specifies the bits i want to set.
So i knew that the DebugLed uses the adress 0x0000001 because it was written in the Manuel i got with my Propeller.
But where do i get the adress for other "registers" i need for the gamepad drivers, f.e. the DATA or CLK or LATCH. These are no special registers as i understood correctly and can be loaded into _dira(addressof(....), mask); but where do i know their adress?
I suspect there will always be a minimum number of files considered essential, and sd access is probably one of them. So I might see if I can speed up the download instead by increasing the baud rate.
I thought I would try to understand how a plugin works. This will be relevant for the zog people too, as the ability to create plugins from obex code could be a skill worth developing. Right now, I suspect you are the only person able to master this art!
I thought I would compare the serial plugin (one port) with the two port code from CP/M. Obviously there is a lot of redundant spin code in the CP/M one. Indeed, at the most basic level, I think all you really want to know is 1) is head = to tail and 2) send or receive a byte. All the .hex and .dec methods are not needed.
Neverthless, it does seem a rather daunting task. See attached for the two pieces of code - they are rather different.
Comments
I now have "Hello, World!" on the screen.
One other thing that I had a lot of problems with was a particular 512Mb SD card. I had similar problems with this card with fsrw, and all those problems went away when Kye's SD card driver came along. I got used to this particular card working, and suddenly remembered I should go back and try my 1Gb sandisk cards.
So, one job might be to port over Kye's latest code (or maybe the latest fsrw) so it works with a wider variety of sd card brands.
Thanks so much for your patience!
Glad you got it working. Yes, I should check out Kye's latest code - I used a very early version, but I had to modify it to suit my needs. I'll see if I can adapt his latest version.
Ross.
Ross, I'm sorry!
I get the message that it is elided, but the cause is something different that I don't understand yet. It is code that compiled with ICC, so it should be right.
There is nothing to be done for you.
Nick
LCC gives you a message about code being "elided" if the compiler detects that the code actually does nothing - it simply eliminates it.
This worried me the first few times I saw it, but I have never found a case where it was wrong. For example, consider the following code:
void main () { int i; i; // this is a valid C statement - but it does nothing at all! }When you compile this, you get the message "expression with no effect elided"Ross.
The funny thing is most engineers do not know what "elided" mean so they would contact us. I have considered changing it, but to what? Maybe "No code generated for expression with no side effect?"
Hmmm... that does sound pretty good. Maybe I will do that.
I know what elided is.
Fact is, that there is no dead code. Must have something to do with the compile sequence of code::blocks or that I forgot to move some files or something in that corner.
Again, forget about that matter until I come up with a more clever question.
Nick
First challenge - running bigger programs than hello world. What I'm attempting to show here is that not only can programs bigger than the propeller internal memory be run on the propeller, but (as far as I know), this allows Big C programs that simply cannot be done with Spin.
Case in point - KyeDOS is a brilliant little program that has a nice display, keyboard, sd card access, xmodem file transfer, but by the time you add all that overhead, there is little room left for your actual program.
I tried startrek because it is the biggest C program in the demo folder.
I compiled Othello and that works.
Next problem. Every time you recompile a program, you have to take out the sd card. So - is it possible to download and run a C program via the programming cable?
Well, I'm glad you asked.
Yes, it is possible. Run KyeDOS as the eeprom program in the propeller. Use the Xmodem file transfer function to send OTHELLO.BIN (this takes 20 seconds or so at 38k, but this speed could easily be increased). Then use KyeDOS to run CATALYST.BIN, and run Othello from Catalyst.
All this is a bit convoluted, but it does work, and the next step is to simplify things. Eg - KyeDOS could contain the Catalyst loader. OR, Catalyst could contain xmodem.
Further, KyeDOS has been set up so that you can 'type' commands via the serial port. So an IDE on a PC can send the commands to initiate the download. Catalyst could do the same thing.
So this is my little challenge to myself - set up an IDE with a C program in a window, and have a single 'compile/download/run' button.
So at some point I might need to hack into catalyst in some way.
Also, as an aside, this program is running on XMM on the dracblade. Are there any 'external ram' variants of catalina that run with SPI 8 pin SRAM chips? I had a crazy idea last night for a really minimalist board - propeller, sd card, vga, keyboard, TV, mouse, serial ram chip (maybe 128k), 12 free pins, and a huge area on the board laid out with the same tracks as a breadboard for prototyping.
Back to coding!
When compiling startrek, add the -lm command line switch. This includes the maths library. This is done automatically if you use the build_all.bat command - open this file in a text editor and check the options it uses when compiling each program.
Ross.
P.S. There is currently no "SPI RAM" XMM driver for Catalina. I was going to develop one for the C3, but did not (at the time) have enough time to do so. Also, the performance of executing from SPI RAM would be very poor.
Yes, if you say SPI is going to be too slow, that probably is right. A byte read from the dracblade is about 20 pasm instructions. Not sure how many for an SPI or the speed.
See attached. This is an IDE for Catalina. Default directory is the demo directory. Hit "compile" and it creates a batch file that combines "use catalina" and the catalina compilation with the switches for the dracblade and hi res VGA. It then automatically downloads using xmodem on KyeDOS.
Time to download Othello was about 25 seconds, which I think is a little faster than pulling out the sd card, copying it and putting it back in. Certainly more convenient anyway.
The IDE then 'types' the phrase "Spin Catalyst.bin"<CR> into KyeDOS, which runs Catalyst. Then you have to manually type the name of the program in Catalyst to run it.
I wonder if catalyst can be modified slightly so it accepts input from either the keyboard, or the serial port (like KyeDOS does).
Also attached is the serial port driver from KyeDOS. This is the best one for the dracblade, as it has two ports and runs in one cog (the original was 4 ports, and Pullmoll changed it to two but increased the buffer size).
Hmm - what other goodies could we add? How about the vt100 driver code from KyeDOS and the CPM project. Why VT100? Well, you can print to it like a normal terminal, but you can also send escape sequences to move the cursor around, and also other escape sequences to change the text and background color.
Addit: another question. Is there a way of finding out how much program space is free? eg, we have a 512k sram chip. If the program "new.c" is 89kb, some of that goes into hub (cog code etc), but roughly how much space is left? I could maybe get the filesize and my IDE could subtract 512k minus program size minus a constant, and give a rough idea how much space is left?
Impressive - I'll really have to look into KyeDos. I wrote Catalyst mainly as a way of simplifying the loading of Catalina programs. Maybe I should have just published a self-contained loader program and encouraged others to incoorporate it into their projects.
But in a way this is what Payload is already - its designed to be able to download not only ordinary binaries, but also XMM programs - and it doesn't need anything (xmodem or otherwise) to be running on the other end.
As for program size/memory space - yes, this is something I will be adding to Catalyst/Catalina sometime soon. Being able to find out at both compile time and load time exactly how much space is required by a program would be very useful. Trouble is that it's not quite as simple as just looking at the file size - you have to do a bit of digging around within the files, and also understand the various Catalina memory layouts.
Like everything else, all it takes is time!
Ross.
Another thing - you don't need to run Catalyst just to run a Catalina program. Any normal Catalina (LMM) program binary can be loaded using any normal Parallax load process - you only need Catalyst for loading XMM programs from the SD Card. If you are happy to load them serially you don't need anything other than Payload (but beware - loading a 512kb program serially can take a long time!).
Ross.
Given we have an sd card, I would suspect that downloading things all the time will not be fun, especially big programs. I'd use this in the way that I'd write a C program on an IDE, download it to an SD card, then run it from the SD card.
For an 'autorun', maybe this can be an additional command? Maybe copy what we have in CP/M - there is an autoexec.sub and on startup, if no keyboard input is received for a while, the program goes and runs whatever is in autoexec. There are many possibilities with commands you could add to an autoexec, eg 'wait'
I've been deep inside the catalyst_xmm_sd_loader, which I've discovered is the core of the catalyst program.
Can you explain Payload a bit more? Does it download to hub/xmm, or does it download to the sd card, or does it download to both?
I'm just thinking of protocols. I understand xmodem, so I am happy writing xmodem in vb.net at one end, and Spin at the other end. But other protocols would be worth looking at, especially as they may be faster. If I know the protocol, I can write code in vb.net at the IDE end.
I'd like to get the compile/download/run for a large 200k xmm program truly down to one keypress. I see two ways to do this:
1) Modify Catalyst so it can handle a serial download to an sd card.
2) Modify KyeDOS so it can handle the loading of 200k programs.
There are advantages and disadvantages to each:
1) Catalyst can't do fat32 and can't handle some sd cards. This is a disadvantage compared to KyeDOS
2) KyeDOS does not have the bootloader code (I need to try to understand this more, as it is written in pasm and appears to load the first 31k into hub, then the rest into external memory)
3) Catalyst can't handle inputs from multiple sources like KyeDOS
repeat if key.gotkey <>0 ' scan both the local keyboard and the com port result:=key.getkey if sio.rxavail(0) result :=sio.rx(0) until result <>0 ' until something comes in either portI am not sure which is going to be the best, as each involves a rewrite of code.
So I've attached KyeDOS - maybe we can brainstorm hybridising some code?
So the quickest program is to combine the best of KyeDOS and Catalyst into one program.
But there is a 'quick and dirty' solution, that involves adding something like that code fragment as an #ifdef to Catalyst. The #ifdef would be #ifdef dracblade, and the code would accept bytes from both the serial port and keyboard. Then the IDE would be able to 'type' commands into catalyst as if they were being inputted from the keyboard.
Where this is heading is something very exciting - Big Programs on the propeller, in a standard language, with a very simple IDE that does not need any knowledge of command lines, (nor the complexity of what I went through yesterday). In other words, you can get your 'hello world' working quickly, but then seamlessly move up to 500kilobyte programs, with many thousands of code lines, without having to worry about running out of memory.
Your thoughts would be most appreciated.
build_all DRACBLADE <-- to use local VGA and keyboard or build_all DRACBLADE PC VT100 <-- to use PC terminal emulatorSo I tried compiling with the second option, but I am getting garbage characters on the display. Now, this is a problem I've seen before many times with the CP/M emulation, and the solution has been to drop the baud rate from 115k to 38k (I think it is due to my longer serial cable)However, I've not had any luck recompiling catalyst with a new baud rate. I found this line in the file Catalina_Common_Input.spin in the directory c:\program files\catalina\target\input However, changing this value did not seem to help. Is this the correct source file? I see in the compiler it uses a file "cataline_common" not "catalina_common_input"
Any help would be most appreciated as I think this might be the final part of a 'one keypress IDE'.
You won't get much sense out of me tonight - it's my 50th birthday tonight, and we've just opened a bottle of '99 Grange Hermitage.
But a couple of quick points:
Yes, the XMM SD card loader is the key to Catalyst - the rest is just frills.
When loading an XMM program, the Payload program actually downloads two programs - it first downloads a program that knows how to accept a serial download and put it into XMM RAM. Then it downloads the actual application program. The first downloaded program puts the first 32kb in hub RAM, and the rest into XMM RAM. Then it restarts the Prop. The application it loaded into the first 31kb is also a 2-phase program. The part that got loaded into Hub RAM does the driver initialization, then it loads the kernel and starts executing the C part (which is the part that got loaded into XMM RAM).
The protocol payload uses for the first download is the normal Parallax protocol (which is why it can load on any Propeller). The next download is done uses a more sophisticated error correcting/retransmission protocol (because I found that when downloading 512kb, the error rate was significant on some noisy prop platforms - and a single bit error can ruin the whole download).
By the way - I think Catalyst can do FAT32. IT's based on Kye's FATEngine, which (from memory) does FAT16 or FAT32. If I update to Kye's latest FATEngine, it should solve the "can't do some SD cards" problem. However, while Catalina can theoretically do FAT12, FAT16 or FAT32 (although I now disable FAT12 to save space) - it will only work on SD cards with an MBR - maybe this is what you are seeing? Try reformatting the problematic SD cards to have an MBR.
The baud rate you are fiddling with is (as the comment implies) the loader baud rate. The baud rate you need to change to affect the PC HMI option are the ones in:
Just for future reference, Catalina_Common_Input.spin is the un-preprocessed version of Catalina_Common.spin. The file Catalina_Common.spin is overwritten on each compile after including the appropriate compile time options, so changing this file does nothing - as the comment at the top of the file says!:
Back to the Grange ...
Ross.
We had some nice wines last night at my wife's 40th. 'Tis the season for parties!
If you are already using some of Kye's code it should be easier to update. Indeed, even the code I'm using is not the latest as I think he speeded up a reload of hub memory from an sd card.
Ok, I'm off to check out the baud rate in those three files you suggested.
A complete compile/download/save to sd card/run of a Big C program with just one keypress in an IDE.
This is going to make development of C programs much quicker. Can I confess now that the IDE is written in visual basic?
Anyway, Othello.c takes 40 seconds. Of that, I know we can speed up several things. The baud rate can possibly go back up from 38k to 115k. Also, loading catalyst off the sd card is taking 8 seconds, and I think Kye can do this a lot quicker. And catalyst and kyedos could be combined into one program.
Downloads are always going to be longer than Spin programs because, well, the programs are bigger than spin programs.
Your description also explores another important feature of Catalina - no wasted hub memory from loading up cogs. The two pass loader means that all the hub is free for other things, and the thing that excites me most is using it for video ram. Theoretically, Catalina ought to be able to run the most detailed video the propeller is capable of, right? Because you could devote up to 31k to video ram.
There are some minor bugs with the IDE - it often (but not always) fails with the first download, but works fine the next time. Anyway, this is the source - the Catalina tab is the one on the right, and the code is at the bottom as it was the last bit added. It is written in vb.net 2008.
Really it is a good idea considering the complex plethora of options.
Assume I have a program running with a text VGA driver. The XMM C code is being interpreted in a cog, and other cogs are doing their thing with keyboard, serial etc. Data is going via rendevous points in high hub ram.
Let's say I want to start my program in text VGA and after the user answers a few questions, I want to switch to graphics mode. I want to do this from within the C code.
Is this possible?
Already it is possible to run catalyst/payload so can we run it again? The video driver code might be written in spin or C - it probably does not matter. It exists as a binary file on the sd card. So, to my thinking, steps are:
1) move that binary file into low hub ram
2) do a jump to the beginning
3) the program runs and loads into the appropriate cog(s)
4) the program ends
meanwhile, and in parallel, xmm C is running from external memory, and is testing when the above program has loaded and is running.
My thinking is that if we can do this once, we can do it many times. Load and reload cogs on the fly. The only catch I see is that if one happened to be running a vga driver that used virtually all the hub ram, then the display would blank when you did this. But you could reload the video driver again afterwards. You could even cache the video hub ram into high external ram if you wanted to, then load it back into hub ram afterwards.
Also, I'm not sure it matters if the binary you load was created in C or spin. If spin, it might be a simple program that has spin and pasm, and loads to a defined cog. The program communicates with C via rendevous points. So maybe that is the only bit of code one might need to change. It might be a way of making much of the obex available to a C program?
This is all possible - but it might be difficult A Catalina program executing from XMM is still using a stack in Hub RAM - but presumably you would want to be able to reload as much Hub RAM as possible.
One way is to arrange for your stack to be small (at least during this load process), and located up high in Hub RAM - so that you could reload most of the Hub RAM. Catalina pulls various tricks similar to this during the various load processes it currently uses - but even so it can only typically load 31kb (it needs 512 bytes as a sector buffer, and it uses another 512 bytes for various other things it needs to keep track of while loading - such as the list of sectors it needs to load).
Possibly you could come up a cog storage mechanism that essentially "swaps out" an executing XMM process to cog RAM, then swaps it back in again when Hub RAM has been reloaded. This would be a bit similar to the trick Catalyst currently employs to allow an arbitrary SPIN or C program to accept command line parameters - essentially it saves the entire command line (up to 1200 chars) in a cog while the Propeller is being "restarted" to load and run the new program.
I'm just warning you that this stuff can get really complicated :smhair:
Ross.
Good points there. To keep it simple, why not keep these bits of cog code as small as possible? Maybe they only need to be about 2k (for the pasm) and a bit of glue spin at the beginning? So a 4k program or something like that?
To test this, the very first thing might be to get C to wipe the first 4k of hub ram and prove everything still keeps working. Is there a C routine that allows writing to hub ram?
I think you call these 'plugins', right?
(and the wine was spectacular!!!)
There is a C function to clear memory (memset) but the results may not be what you would expect, since the memory this function will clear - even when passed a pointer value of zero - could be in hub RAM or XMM RAM depending on the memory model used to compile the C program - instead, I'd do this using an LMM PASM routine, callable from C. There are examples on how to call PASM functions in Catalina\demos\spinc).
Plugins are cog programs intended to be accessed from C via the registry (by using the various functions defined in catalina_plugin.h).
Examples of the use of these functions are littered throughout the library sources - especially in Catalina\source\lib\catalina. For example, the code to implement the t_char function (which sends a request to the HMI plugin to output a character) is as follows:
#include <catalina_hmi.h> int t_char (unsigned curs, unsigned ch) { return _short_plugin_request(HMI, 22, ((curs&1)<<23) + ch); }I've just finished (re) reading the catalina manual. Maybe much of what I'd like is already done. This is Good News!
1) I don't much care for the green screen for VGA. But I see you can change the color from C. So if so, that is just a couple of lines of code at the beginning of a C program?
2) The SD card driver uses Kye's code already, so upgrading it to the latest version that can handle unusual sd card brands should not be so hard?
3) The big one. Would it be possible to turn pullmoll's 2 serial port driver code (which is a derivative of Tim Moore's code) into a plugin?
I know these are a bit of an ask, but are any of these possible?
Addit: I'm pondering a new dracblade design with a mouse port, and some more input/output pins, possibly configured as a standard parallel port. I think there are obex drivers (Kye's for instance) that combine keyboard and mouse in a cog. I think with some generic I/O and a mouse/sd card/vga/serial ports and 512k of memory, this could be quite a useful hardware/software platform that you can start coding C on without worrying about the nuts and bolts).
a) Yes, the screen colours can be configured in a couple of lines of C . Or you can change the default colors in the driver itself.
b) Catalyst uses Kye's file system, and I will update it to the latest version when I get time. Catalina uses a completely different file system (written in C) called DOSFS - if you find DOSFS is missing any functionality you need then I can add it.
c) Yes, I will add pullmoll's serial driver (or perhaps some other serial driver) as a plugin when I finish the current work on the libTiny C library.
Ross.
I'm thinking of putting together a step by step guide to getting catalina working - eg I now have two versions of catalyst - one is for local keyboard and one is for control via the serial port. Now that these are compiled, rather than say to a new user 'here is how to compile these programs', it may be simpler to say 'here is a zip of files, just unzip them and put them on the sd card'.
Thinking through an install of catalina on the dracblade with the vb.net IDE, on a new system, the most complicated and time consuming part might actually be the download and install of vb.net!
Is it possible to compile a tiny program on the dracblade? For quick and simple testing?
eg the switches for the dracblade are
catalina -lcx -x5 -M 128k -D DRACBLADE -D HIRES_VGA
I read in the manual that x5 is for the xmm, so I tried changing that to x0, but it gave an error "compiled image exceeds 32k". I suspect something else needs to be changed as well.
Many thanks in advance.
addit - I added a software reset for the one button compile, so it toggles the DTR line and reboots into kyedos.
Also I got the screen to change color with a C function! Life is good.
i was a bit busy the last days and didn´t move on much. I just tried some more examples and had a closer look at the functions and the return values etc..
Conserning the gamepad driver is still have some problems. I know it´s a quite simple device but I still don´t get how to access some registers.
The Gamepad has the Latch Line, Data und CLK
So i have to set those to output i guess and read the first incoming bits from the Latch Line:
Following Spin code should do this
Well i think that should do the job right?
But how can I port this code to C? f.e. dira[LATCH]~~ oder dira[DATA]~~
LATCH, DATA, CLK and so has to be defined somewhere in SPIN. But how do i know the adress of it from outside?
And if I got so far, how much bits do i have to read to know what or if a key was pressed? I guess i can press every button once and read the bit sequence for each and store the somewhere to get the different buttons.
I hope you can give me a nice example so I can understand it. I think if i how to acces all registers once the rest should´t be that hard any more.
You need to look at the Catalina documentation - the Catalina Reference Manual describes (on page 28) the various functions to access the special registers. Also, you could look in Catalina\include\catalina_cog.h
The Catalina functions do not map directly to PASM instructions - they generally try to do in one function call what would take several instructions in PASM. They often take a mask parameter to specify which bits to affect, then another value to indicate what to set those bits to. They also return values. For example, the function to set DIRA is defined as:
So to set bits 0 and 1 as inputs, and bits 2 & 3 as outputs without affecting any other bits you would say something like:
These functions return the previous value of DIRA (if you want it). So to just fetch the current setting of DIRA without affecting anything, just specify a mask of 0. For exmaple:
Similarly, there are functions to manipulate OUTA - for example, the function to affect OUTA is defined as:
So to set OUTA bit 2 as OFF and 3 as ON, while not affecting other bits you would say something like:
And of course, there are also functions to fetch INA - this does not need any parameters, it just returns the whole of INA:
Ross.
P.S. Depending on your version of catalina_cog.h, you might see references to get_dira() and get_dirb() - you should ignore these and use the _dira() and _dirb() functions instead.
Hi Dr_Acula,
Your problem is the -lcx option - this includes the extended library with full SD card file system support. Generally, this results (at least in the current version) with executables larger than 32k that will only run in extended memory. But if you don't need the SD card file system, use -lc or -lci instead (-lci includes the integer libbrary which omits floating point, -lc is the standard C library that includes floating point). For example:
i.e. you don't need either the -x or the -M options to just compile as LMM. One more thing though - the HIRES_VGA option can also use so much hub RAM that a program may not fit in 32k!
Ross.
I already took a look at the documentation and I know how to acces the special register itself. Probably there is still some kind of missunderstanding from my side but the problem is not to access the special registers itself but rather what address to load into the register (depending on what is needed)
My understanding of embedded programming is not as good so it´s a bit hard for me to put a clear question but i will try to with an example:
To access the DebugLed I also had to know the adress of itself.
The adress is 0x00000001;
so i set _dira(0x00000001, mask)
and set it to output _outa(0x00000001, mask)
while the mask specifies the bits i want to set.
So i knew that the DebugLed uses the adress 0x0000001 because it was written in the Manuel i got with my Propeller.
But where do i get the adress for other "registers" i need for the gamepad drivers, f.e. the DATA or CLK or LATCH. These are no special registers as i understood correctly and can be loaded into _dira(addressof(....), mask); but where do i know their adress?
Thanks in advance
I suspect there will always be a minimum number of files considered essential, and sd access is probably one of them. So I might see if I can speed up the download instead by increasing the baud rate.
I thought I would try to understand how a plugin works. This will be relevant for the zog people too, as the ability to create plugins from obex code could be a skill worth developing. Right now, I suspect you are the only person able to master this art!
I thought I would compare the serial plugin (one port) with the two port code from CP/M. Obviously there is a lot of redundant spin code in the CP/M one. Indeed, at the most basic level, I think all you really want to know is 1) is head = to tail and 2) send or receive a byte. All the .hex and .dec methods are not needed.
Neverthless, it does seem a rather daunting task. See attached for the two pieces of code - they are rather different.