Perhaps I am misunderstanding something here, but if the end result of your download is that the program ends up on the SD card, then just use Catalyst to load it.
Yes, the Catalyst SD card driver is slower than the KyeDos one - but the Catalyst one can also load XMM, whereas (AFAIK) KyeDos cannot. In any case, even for programs megabytes in size, we're talking load times of only a few seconds - just how fast do you need it to be?
In any case, even for programs megabytes in size, we're talking load times of only a few seconds - just how fast do you need it to be?
Can you expand on that a bit more?
I'm getting download times of 20 seconds or more. This fits with my calculations - 115kilobits/sec (baud) = apprx 11kilobytes a second and for a 200k program this is around 20 seconds and these programs are only going to grow if we want to do fun things like a GUI. I think USB 1.0 is either 1.5 Mbit/s or 12Mbit/s. I think USB 2.0 is 480Mbit/s.
Even at the slowest USB 1.0 speed it ought to be more than 10x faster?
I'm getting download times of 20 seconds or more. This fits with my calculations - 115kilobits/sec (baud) = apprx 11kilobytes a second and for a 200k program this is around 20 seconds and these programs are only going to grow if we want to do fun things like a GUI. I think USB 1.0 is either 1.5 Mbit/s or 12Mbit/s. I think USB 2.0 is 480Mbit/s.
Even at the slowest USB 1.0 speed it ought to be more than 10x faster?
Sorry, I meant that to load them from SD card should take only seconds at most. I'm confused about exactly what you are trying to do. If the program is on the SD card, why do you want to download it serially? Just download it via USB to the SD card, then use Catalyst to load it.
Ah, sorry, I didn't explain that very well. I'm thinking of the development stage, where you are constantly downloading new versions of the program, maybe changing just one line at a time. So the aim is to get the new program into the propeller as quick as possible.
So the question is - if I have a program on an SD card, and if I am not connected to a PC any more, is it possible to run some sort of loader program from the propeller in order to run an XMM program on an SD card?
So the question is - if I have a program on an SD card, and if I am not connected to a PC any more, is it possible to run some sort of loader program from the propeller in order to run an XMM program on an SD card?
Why not just download Catalyst, compiled to auto-execute the program? But you don't really need to download anything. Just program Catalyst into EEPROM and reset the Propeller.
Yes, that would work. What about if I have ten programs, all with different names. How would I go about running one in particular?
I guess that depends on how you intend to specify the file on your end. You could recompile Catalyst each time, but why would you want to? Typically, you would be reloading the same program each time.
I see an interesting comment of yours on the GCC thread regarding codeblocks. That thread is going off in lots of interesting directions and there was another comment about splitting the task into and IDE and command line threads.
In a way this is very similar to what we already have. You have the catalina command line. I have written an IDE that pulls together this command line compiler, all your downloaders, plus the homespun compiler, plus a Basic to C converter, plus a tab for pasm development, plus file transfer to SD card, plus TinyC compiler for quick testing.
There is nothing particular clever about what I have done, but it does make for a very convenient development platform, especially when so many things are now "one click" exercises.
So I am very intrigued by what you are looking at with codeblocks. I've not looked at how plugins work, but in general terms, what I have found with the vb.net IDE is that you need to store some parameters somewhere (eg the location of the default directories, the default serial port, your favorite memory model), you need to be able to save/load/edit those parameters, then when you hit the 'compile' button, you need to take some of those parameters, convert them to a batch file, then run the batch file.
Is this the sort of thing you can do with a codeblocks plugin?
I see an interesting comment of yours on the GCC thread regarding codeblocks.
...
I've not looked at how plugins work, but in general terms, what I have found with the vb.net IDE is that you need to store some parameters somewhere (eg the location of the default directories, the default serial port, your favorite memory model), you need to be able to save/load/edit those parameters, then when you hit the 'compile' button, you need to take some of those parameters, convert them to a batch file, then run the batch file.
Is this the sort of thing you can do with a codeblocks plugin?
Hi Dr_A,
That kind of thing, yes - but Code::Blocks is specifically designed to "wrap" C/C++ type command line compilers like GCC - so it already knows what kinds of things you will probably need to configure, and integrates them all properly into the framework. It's very good at that, and its also far cleaner, simpler and faster to use than many other IDEs - but C/C++ is really all Code::Blocks was ever intended for.
Code::Blocks does not even pretend to be language neutral - fairly extensive knowledge about how typical C/C++ compilers work is "built in" - which is why it is so easy to integrate a new one. But this means you probably coudn't (for instance) easily use it as a development environment for Ada or Java, or any other language that does not "work" the same way as a typical C/C++ compiler does (i.e. in terms of typical utilities, or the way libraries are managed and built etc). It also probably wouldn't cope well with an indentation-sensitive language like SPIN - you'd have to rewrite too much of it.
So I don't think Code::Blocks is a competitor to either the type of multi-language IDE you are working on, or the type of IDE they are currently discussing over on the GCC/Eclipse thread. They seem to think their IDE will need to support all the other languages that GCC itself can support (such as Java, Objective-C and even Fortran) - even though it is very unlikely anyone will ever run those on the Proeller. Personally, I have my doubts about the utility of C++ for professional usage - but I accept that it is desirable for hobby use (mainly because of the Arduino), and I'm prepared to wait and see how it pans out if they get GCC working well enough.
Of course Code::Blocks has all the usual syntax and context sensitive editing features that you would expect - but they're heavily C/C++ oriented. It has various "core" plugins, and also supports third-party ones designed to do useful things for C/C++ programs (for example, to reformat your C code to a new format).
My first attempt at Code::Blocks integration required no coding at all - I just reconfigured the standard compiler "plugin" to add Catalina as a selectable option - you still had to specify the various command line options in obscure ways and places. This is my second attempt, and is a slightly "deeper" integration - it adds Catalina as a compiler "built into" the standard compiler plugin on equal terms with all the others (GCC, ICC, PCC etc) - so (for instance) all the various Catalina command line options are now correctly managed and properly organized as multiple choice option sets in the standard compiler options dialogs (so you don't need to remember them anymore!).
Also, the installation process (when I get it working properly!) will be almost a single step - and will be single step if I can get my plugin modifications included back into the mainstream Code::Blocks releases.
I was going to write another plugin to incorporate the payload loader and blackbox debugger (and I may still!) but so far it has turned out to be so simple to integrate them as "tools" that you can select from the menu that I probably won't bother. Of course, deeper integration is possible, but would take much longer - and who has the time?
There are a lot of things code::blocks can do. Indeed, I am starting to wonder if it can do all the important things my vb.net IDE can do.
First, you can add your own custom help. That is nifty because then if people get lost, you can have help specific to catalina.
If we want to compile and download with a few keypresses, I wonder if the 'tools' can do that? I think there are macros in there, so does that mean you can add ${project_filename) and this will add the name of the file into the catalina command line?
Those 4 launch options in tools are just exactly what my IDE does - with the default being "launch in a new window and wait for a keypress'. I have a second option that launches and runs catalina and doesn't wait for a keypress - I use that when I am confident there are no bugs and I don't need to look at the catalina messages coming back. Well - that could be another 'tool' menu.
A huge amount of my IDE is the text formatting, but of course code::blocks has that already done. You can even customise the colors of the text etc. And code::blocks has one thing my IDE does not - the ability to shrink and expand blocks of code. That is becoming very important in huge 200k programs like the IDE, because some blocks of code you work on a lot, and others you just want to shrink down and forget about because you know they work.
I wonder if it is possible to do the following in code::blocks using macros and predefined settings?
You can see there are some things that could be added quite easily eg the current filename. What I'm not sure is adding things like "Memsize" which is a variable that I tend to change fairly often as it is quicker to make it smaller for faster downloads. And "portnumber" which is the serial port which is also a user setting that might change from time to time.
Would it break the "purist" model to put these somehow into the C program and the compiler strips them out? Or do they go in a "user settings" file which I think code::blocks can do.
There is one other 'tool' I use often, and that is to compile with catalina but not download, and to leave the window open so any error messages are visible. Because the catalina compiler is so quick, I tend to do these check compiles every few minutes, so that there are never more than one or two errors to fix at any one time. I tend to do "compile plus download" less often.
I'd be fascinated to see what you have working so far.
If we want to compile and download with a few keypresses, I wonder if the 'tools' can do that? I think there are macros in there, so does that mean you can add ${project_filename) and this will add the name of the file into the catalina command line?
You can always compile with just a mouse click. I have decided not to mess about with the standard set of compile commands and buttons (yet!) - instead I use the "tools" to download whatever you have just compiled, and/or run the debugger. As you have read, this can be done with completely trivial configuration.
I may eventually add my own "compile" commands (e.g. "Compile and download to RAM", "Compile and download to EEPROM" or "Compile and Debug" - but apart from looking slightly more integrated, it really doesn't add much to the current functionality, which is that you first press the "build" button, then select the appropriate tool (e.g. "Download and Debug") from the tool menu. But I'll see how much time I get.
A huge amount of my IDE is the text formatting, but of course code::blocks has that already done. You can even customise the colors of the text etc. And code::blocks has one thing my IDE does not - the ability to shrink and expand blocks of code. That is becoming very important in huge 200k programs like the IDE, because some blocks of code you work on a lot, and others you just want to shrink down and forget about because you know they work.
I wonder if it is possible to do the following in code::blocks using macros and predefined settings?
Yes, I'm sure it would - but it may require a plugin (something like the source reformatting plugin).
You can see there are some things that could be added quite easily eg the current filename. What I'm not sure is adding things like "Memsize" which is a variable that I tend to change fairly often as it is quicker to make it smaller for faster downloads. And "portnumber" which is the serial port which is also a user setting that might change from time to time.
Setting the memsize does not make a difference to the size of the resulting file unless you also specify -e to output .eeprom formats. The memsize option is mainly intended as a check used to make sure your program is not growing too large to fit in your fixed size eeprom. If you are using .binary format, just set it to the size of your XMM RAM and then forget about it - the file size will always be the smallest possible.
Also, the payload loader doesn't require you to specify a port - it will find it automatically. And I've now modified the blackcat debugger to do that as well. Now the only reason you would ever want to specify a specific port is because it can make downloading slightly faster (i.e. if the programs don't have to locate the right port each time). But this only takes a few seconds, so I hardly ever bother any more.
Would it break the "purist" model to put these somehow into the C program and the compiler strips them out? Or do they go in a "user settings" file which I think code::blocks can do.
No, but with an automated IDE and build tool, you would tend to keep things like this in separate files (like a resource file).
There is one other 'tool' I use often, and that is to compile with catalina but not download, and to leave the window open so any error messages are visible. Because the catalina compiler is so quick, I tend to do these check compiles every few minutes, so that there are never more than one or two errors to fix at any one time. I tend to do "compile plus download" less often.
Like most IDEs, this kind of functionality is "built in" to Code::Blocks.
This sounds great. Ok, maybe we don't need so many settings. Looking at what I have -
1) VGA and graphics settings - these are now somewhat obsolete with cogjects, as I just paste in all the cogjects as arrays at the beginning of a program and then load them from the C code as needed.
2) Memsize - well if you say that is always the smallest, then maybe just set it at 512k. Or 32Mb?
3) Download speed. I think 115200 is the default for everything now so that never needs to change.
4) The port. If payload finds this automatically, that makes things much simpler.
Well, those were all the settings I have, so if we don't need settings, then it ought to make it even easier to customise code::blocks.
Having used an IDE now for a number of months, I think I can start to say which are the commonly used 'tools' menus:
1) Compile and leave the catalina window open - for debugging
2) Compile and download LMM
3) Compile and download XMM
4) Compile with TinyC, or another compiler, and run on the PC to check out individual functions.
Like you say, this largely what code::blocks was designed for.
I've got five gadget gangster designs being made at the moment and the aim is to start off with a standard GG motherboard, run a LMM program, and when you run out of memory, get a memory expansion board (which might only cost $10 or so) and piggyback that on top. Then just go on with compiling with the XMM tool.
I'm looking forward to seeing what you have working!
Addit - there is a thread running at the moment where sphinx has been mentioned. sphinx can compile spin on the propeller - if the c programs can compile the c part, and sphinx can do the spin and pasm part, is it possible to self host a c compiler on the prop??
I recently had a need to do a clean install of Fedora Core 14 (64 bit), and then re-install Catalina. Since the Linux binary distribution of Catalina is for 32 bit Linux, I decided to recompile it from source. This made me realize that the instructions included with Catalina itself are a little "thin" (to say the least!) so I thought I'd better document the process. I will include this in the next release.
The version of Catalina I installed was 3.0.2. The instructions would be very similar for other versions, and also for other Linux distributions - whether 32 bit or 64 bit.
The instructions assume you have downloaded the following files from the Catalina SourceForge site (I stored them in a directory called /Shared)
Catalina_3.0_Linux.tgz
Catalina_3.0.2_patch.zip
Substitute the actual directory where you stored them (as required) when executing the following steps.
Step 0: Become root
It is easiets to perform the Catalina installation when logged in as root:
su root
Step 1: Install the necessary utilities
Building and running Catalina requires some Linux utilities:
Note that you probably already have some of these installed.
Step 2: Set up the catalina base directory and install the sources
The default location for Catalina under Linux is /usr/local/lib/catalina
mkdir /usr/local/lib/catalina
cd /usr/local/lib/catalina
tar xvfp /Shared/Catalina_3.0_Linux.tgz
unzip /Shared/Catalina_3.0.2_patch.zip
Note that unzipping the patch will overwrite some of the files in the catalina directory - this is normal. Step 3: Set up the environment and Linux permissions
Ensure the appropriate linux permissions are set:
cd /usr/local/lib/catalina
source ./use_catalina
cd bin
chmod a+x ./Set_Linux_Permissions
Set_Linux_Permissions
The script Set_Linux_Permissions sets most permissions, but on some Linux platforms you may also need to add permissions to allow users to use the include, lib and large_lib directories. You can do this as follows if you get errors on compiling when logged in as a user other than root:
Also, if you want to be able to build some of the Catalina utilities (such as Catalyst) as a user other than root, you will also need write and execute permission to to the relevant directories:
cd /usr/local/lib/catalina/source/catalina
./build_all
cd /usr/local/lib/catalina/source/lcc
./build_all
cd /usr/local/lib/catalina/source/lib
./build_all
cd /usr/local/lib/catalina/srecord
./build_all
Step 5: Test Catalina
To check that a user other than root can use the Catalina compiler, log in as a normal user, then execute the following:
cd ~
source /usr/local/lib/catalina/use_catalina
cp /usr/local/lib/catalina/demos/hello_world.c .
catalina -lc hello_world.c
If you get a message similar to the following:
cpp: hello_world.c:4 Could not find include file <stdio.h>
or
cannot open library index /usr/local/lib/catalina/lib/libc/catalina.index
Then you need to set the additional permissions mentioned in step 3.
...or "sudo su -", for those Linuxes that implement that permission escalation system. Just saying...
And, the "-" means take on the root environment, as opposed to just escalating to root in the current user environment.
On some systems that's significant.
I'm writing that for two reasons. One, the sudo bit is just good to document. Will cut down on a question or two.
Secondly, which is the best practice? Build in user land, then install to target, or??
Hi potatohead,
Good points. One day I'll write a proper configure script to build Catalina on Linux (and maybe Windows as well) - and at that point it would make more sense to build it as a user and then install it as root. But at the moment my time is just too limited, and so I just tend to just re-build it "in situ" as root, zip it up and release it.
But if anybody wants to volunteer to improve the Catalina build/install process (for either Windows or Linux) I'd love to hear from them!
I have just posted Catalina patch release 3.0.3. The main purpose of this release is to provide significantly enhanced Code::Blocks and Windows 7 integration, although it also contains a few bug fixes and other minor enhancements.
The patch release applies to both Linux and Windows (but note that if you have 64 bit Linux you will have to rebuild Catalina from source, since the patch only includes 32 bit executables for Linux).
Please read the new Getting Started with CodeBlocks document for more details on the new Code::Blocks integration (I have attached a copy to this post). You still have to download Code::Blocks 10.05 separately, and the installation process is still a bit of a chore, but I will be submitting the required changes to the Code::Blocks team for automatic inclusion in future Code::Blocks releases.
Oh my! You seem to have replicated my entire IDE within code::blocks. Amazing!
Not me - blame the Code::Blocks team! All I did was add the Catalina plugin. But you can take credit for the Tools menu entries - I modelled them on your suggestions.
One thing I've just noticed (drat!) - to get the code completion to include all the functions defined in the standard C header files, you have to tell Code::Blocks where to find them!
You can set the necessary option at the compiler, project or target level, but in this case it probably makes sense to do it at the compiler level so it is inherited by all projects. From the main menu, select Settings->Compiler and Debugger... Make sure Catalina is the selected compiler, then on the Search Directories tab, select Compiler, and add an entry like C:\Program Files\Catalina\include (for Windows) or/usr/local/lib/catalina/include (for Linux).
I'll update the Code::Blocks document next time I issue it.
Just a quick note to let you all know I have submitted the necessary patches to add Catalina support to the Code::Blocks project. While I was preparing the patch, I also fixed to a couple of the minor issues mentioned in the Getting Started with CodeBlocks document:
It is now possible to specify the .binary or .eeprom suffix for executables, which means Code::Blocks will correctly detect when the project executables are up to date and not rebuild them unnecesarily.
It is now possible to include spaces in project names under Windows (Linux still has a limitation caused by mono that I am yet to figure out how to resolve)
These are such trivial issues that I don't see the point in releasing another patch, but I will probably do so when Catalina support is avaliable in the Code::Blocks nightly builds, since that will also change the installation process for those people who want all the nifty new features that have been added to Code::Blocks since the last official release (10.05).
This code::blocks sounds nifty - I'm looking forward to checking it out.
I've been playing around with TV displays, and TVs use 3 pins vs VGA which uses 8. So all things being equal, this means that a TV version of code has 5 spare pins. I have an idea that one could be devoted to audio. So - move the 4 SD pins to, say, prop pins 19,20,21,22, put audio on pin 23, and now there are 16 propeller pins P0-P15 that could be devoted to memory.
I wonder - what is the optimum circuit one could devise to talk to memory in the fastest possible way?
See the attached skeleton schematic.
There are 8 bidirectional data lines, 19 address lines, and /WR and /RD. One could possibly make /CS permanently enabled, saving a line, so that would be a total of 8+19+2 = 29.
My gut feeling is that because the 8 data lines are bidirectional, these would be P0-P7, but maybe there are other options?
Then - could you use the other 8 as high speed SPI lines and decode them to 21 lines?
Or use a 74HC138 and some latches?
Could one devote P8-P11 to drive A0-A3 directly, and so give very fast bursts of data for 16 byte blocks, and use P12-P15 with the dracblade circuit using the 138 and 374 latches?
I feel sure that by going from 12 pins (the dracblade) to 16 pins it ought to be possible to get a faster throughput.
Another thought. With the fsrw code for catalina, can this run independently of the external memory driver for XMM? In other words, could you grab another 4 pins from the SD card, and share pins with the SD card and memory circuit, and read in blocks of data from the sd card, then do some external memory, then read some more sd blocks? Just thinking if one could gain another 4 pins as that would speed up external memory even more.
Input from anyone, especially the 'external memory gurus', would be most appreciated.
I'm not a hardware person (I barely know which end of the soldering iron to hold on to!) but I just thought I'd point out that several platforms - including the C3 and (IIRC) the RamBlade - share pins between the SD card and XMM RAM.
Ok, scratch that last schematic, we now have 20 propeller pins to drive both a SRAM and an SD card. Devote maybe 2 (or 3) to a HC138 and/or an SPI pin expander and you can select between SD and memory. Maybe you only need 1 pin - if High then read memory, if Low then read the SD card?
If so, then that gives us 19 pins for memory access, instead of the dracblade's 12. That ought to speed up the code when running an XMM program.
And I'm particularly interested in that other thread you just posted regarding running spin programs from within C. Faster XMM C plus included Spin is going to open up a lot of possibilities.
I have looked at this memory attaching for a long time and I keep coming back to latched signal lines and so it quickly starts to look DracBlade(ish) again. That was why I started to go down the DRAM route as they had all those latches built in.
My experiments with (second hand) SDRAMs started with some hope but as they don't seem to make socketable ones after the third change of chips, the PCB started to disintegrate. This meant that I was never sure if the chips were banjaxxed on being taken off of the DIMM in the first place. The memory tests never got past 7MBs (on 32MB chips).
Ok, I'm thinking that maybe we have 20 pins to share SD and ram. Take the bottom 16 and you can have 8 for data and 8 for address and do burst reads of 256 bytes. For things like read and enabling sd access and latching in A8-A18, use the upper 4 pins P16-P19. SD can share P0-3 and as long as the ram is disabled then the SD card will be fine.
So - slower writes, but with burst reads you don't even need to turn the /RD pin on and off. Leave it enabled, /CS is enabled (via a latch output) and it might be 6x faster or even more for reads. This could really make catalina XMM fly!
Ok, I'm thinking that maybe we have 20 pins to share SD and ram. Take the bottom 16 and you can have 8 for data and 8 for address and do burst reads of 256 bytes. For things like read and enabling sd access and latching in A8-A18, use the upper 4 pins P16-P19. SD can share P0-3 and as long as the ram is disabled then the SD card will be fine.
So - slower writes, but with burst reads you don't even need to turn the /RD pin on and off. Leave it enabled, /CS is enabled (via a latch output) and it might be 6x faster or even more for reads. This could really make catalina XMM fly!
Have you considered changing the lower latch in DracBlade with two HC161 presettable counters?
You would use the lower latch enable signal to load both counters, retaining compatibility with the standard DracBlade, and with two more lines from the HC138 (no more prop pins!), nRST and CLK, you could do page bursts.
It might be a question for Ross - eg you have some standard C code, and the XMM interpreter is reading that line by line, byte by byte, so that is a counter. But occasionally the code changes something - a read or a write (eg to an array, or a variable). Will that upset a counter? Would you need another bit of code to detect if this has happened and disable the counter??
In a vague sort of way, I'm thinking the lower latch on the dracblade is not needed. So two latches and one 138. But I'd like to brainstorm other solutions like SPI latches. One thing you could do with SPI is you could be presetting the higher address lines *before* the code gets there. Or maybe that is adding another layer of complexity?
It might be a question for Ross - eg you have some standard C code, and the XMM interpreter is reading that line by line, byte by byte, so that is a counter. But occasionally the code changes something - a read or a write (eg to an array, or a variable). Will that upset a counter? Would you need another bit of code to detect if this has happened and disable the counter??
In a vague sort of way, I'm thinking the lower latch on the dracblade is not needed. So two latches and one 138. But I'd like to brainstorm other solutions like SPI latches. One thing you could do with SPI is you could be presetting the higher address lines *before* the code gets there. Or maybe that is adding another layer of complexity?
Hi Dr_A,
What you have described is pretty much how the XMM memory works on some platforms. On the Hydra and Hybrid, Andre's original 512k XTREME RAM card actually keeps its own pointer into RAM internally, and you can read successive bytes without having to specify a new address - you only need to re-address it if you want to access XMM RAM bytes out of sequence. So Catalina also keeps a record in the XMM code of your last memory access, and knows if the next address you are accessing needs the RAM card to be sent a new address or not. Similarly on other platforms Catalina keeps a record of the settings of the latches, and knows whether the next address needs the memory latches to be updated or not.
These tricks are necessary to get the speed up - but the downside is that only one cog can access the XMM RAM - if another cog tried it would upset the addressing, and any attempt to synchronize multiple accesses would make the whole thing too slow to be useful.
Comments
Perhaps I am misunderstanding something here, but if the end result of your download is that the program ends up on the SD card, then just use Catalyst to load it.
Yes, the Catalyst SD card driver is slower than the KyeDos one - but the Catalyst one can also load XMM, whereas (AFAIK) KyeDos cannot. In any case, even for programs megabytes in size, we're talking load times of only a few seconds - just how fast do you need it to be?
Ross.
Can you expand on that a bit more?
I'm getting download times of 20 seconds or more. This fits with my calculations - 115kilobits/sec (baud) = apprx 11kilobytes a second and for a 200k program this is around 20 seconds and these programs are only going to grow if we want to do fun things like a GUI. I think USB 1.0 is either 1.5 Mbit/s or 12Mbit/s. I think USB 2.0 is 480Mbit/s.
Even at the slowest USB 1.0 speed it ought to be more than 10x faster?
Sorry, I meant that to load them from SD card should take only seconds at most. I'm confused about exactly what you are trying to do. If the program is on the SD card, why do you want to download it serially? Just download it via USB to the SD card, then use Catalyst to load it.
Ross.
So the question is - if I have a program on an SD card, and if I am not connected to a PC any more, is it possible to run some sort of loader program from the propeller in order to run an XMM program on an SD card?
Why not just download Catalyst, compiled to auto-execute the program? But you don't really need to download anything. Just program Catalyst into EEPROM and reset the Propeller.
Ross.
I guess that depends on how you intend to specify the file on your end. You could recompile Catalyst each time, but why would you want to? Typically, you would be reloading the same program each time.
Ross.
I see an interesting comment of yours on the GCC thread regarding codeblocks. That thread is going off in lots of interesting directions and there was another comment about splitting the task into and IDE and command line threads.
In a way this is very similar to what we already have. You have the catalina command line. I have written an IDE that pulls together this command line compiler, all your downloaders, plus the homespun compiler, plus a Basic to C converter, plus a tab for pasm development, plus file transfer to SD card, plus TinyC compiler for quick testing.
There is nothing particular clever about what I have done, but it does make for a very convenient development platform, especially when so many things are now "one click" exercises.
So I am very intrigued by what you are looking at with codeblocks. I've not looked at how plugins work, but in general terms, what I have found with the vb.net IDE is that you need to store some parameters somewhere (eg the location of the default directories, the default serial port, your favorite memory model), you need to be able to save/load/edit those parameters, then when you hit the 'compile' button, you need to take some of those parameters, convert them to a batch file, then run the batch file.
Is this the sort of thing you can do with a codeblocks plugin?
Hi Dr_A,
That kind of thing, yes - but Code::Blocks is specifically designed to "wrap" C/C++ type command line compilers like GCC - so it already knows what kinds of things you will probably need to configure, and integrates them all properly into the framework. It's very good at that, and its also far cleaner, simpler and faster to use than many other IDEs - but C/C++ is really all Code::Blocks was ever intended for.
Code::Blocks does not even pretend to be language neutral - fairly extensive knowledge about how typical C/C++ compilers work is "built in" - which is why it is so easy to integrate a new one. But this means you probably coudn't (for instance) easily use it as a development environment for Ada or Java, or any other language that does not "work" the same way as a typical C/C++ compiler does (i.e. in terms of typical utilities, or the way libraries are managed and built etc). It also probably wouldn't cope well with an indentation-sensitive language like SPIN - you'd have to rewrite too much of it.
So I don't think Code::Blocks is a competitor to either the type of multi-language IDE you are working on, or the type of IDE they are currently discussing over on the GCC/Eclipse thread. They seem to think their IDE will need to support all the other languages that GCC itself can support (such as Java, Objective-C and even Fortran) - even though it is very unlikely anyone will ever run those on the Proeller. Personally, I have my doubts about the utility of C++ for professional usage - but I accept that it is desirable for hobby use (mainly because of the Arduino), and I'm prepared to wait and see how it pans out if they get GCC working well enough.
Of course Code::Blocks has all the usual syntax and context sensitive editing features that you would expect - but they're heavily C/C++ oriented. It has various "core" plugins, and also supports third-party ones designed to do useful things for C/C++ programs (for example, to reformat your C code to a new format).
My first attempt at Code::Blocks integration required no coding at all - I just reconfigured the standard compiler "plugin" to add Catalina as a selectable option - you still had to specify the various command line options in obscure ways and places. This is my second attempt, and is a slightly "deeper" integration - it adds Catalina as a compiler "built into" the standard compiler plugin on equal terms with all the others (GCC, ICC, PCC etc) - so (for instance) all the various Catalina command line options are now correctly managed and properly organized as multiple choice option sets in the standard compiler options dialogs (so you don't need to remember them anymore!).
Also, the installation process (when I get it working properly!) will be almost a single step - and will be single step if I can get my plugin modifications included back into the mainstream Code::Blocks releases.
I was going to write another plugin to incorporate the payload loader and blackbox debugger (and I may still!) but so far it has turned out to be so simple to integrate them as "tools" that you can select from the menu that I probably won't bother. Of course, deeper integration is possible, but would take much longer - and who has the time?
Ross.
There are a lot of things code::blocks can do. Indeed, I am starting to wonder if it can do all the important things my vb.net IDE can do.
First, you can add your own custom help. That is nifty because then if people get lost, you can have help specific to catalina.
If we want to compile and download with a few keypresses, I wonder if the 'tools' can do that? I think there are macros in there, so does that mean you can add ${project_filename) and this will add the name of the file into the catalina command line?
Those 4 launch options in tools are just exactly what my IDE does - with the default being "launch in a new window and wait for a keypress'. I have a second option that launches and runs catalina and doesn't wait for a keypress - I use that when I am confident there are no bugs and I don't need to look at the catalina messages coming back. Well - that could be another 'tool' menu.
A huge amount of my IDE is the text formatting, but of course code::blocks has that already done. You can even customise the colors of the text etc. And code::blocks has one thing my IDE does not - the ability to shrink and expand blocks of code. That is becoming very important in huge 200k programs like the IDE, because some blocks of code you work on a lot, and others you just want to shrink down and forget about because you know they work.
I wonder if it is possible to do the following in code::blocks using macros and predefined settings?
FileOpen(1, "C:\Program Files\Catalina\Demos\drac.bat", OpenMode.Output) PrintLine(1, "@echo off") PrintLine(1, "echo.") PrintLine(1, "echo ===================") PrintLine(1, "echo SETTING UP CATALINA") PrintLine(1, "echo ===================") PrintLine(1, "echo.") PrintLine(1, "PATH=C:\Program Files\Catalina\bin;%PATH%") PrintLine(1, "Call catalina_env.bat()") PrintLine(1, "catalina -lcx " + "-D PLUGIN " + MathsString + "-x5 -M " + MemSize + "k -D DRACBLADE -D SHARED_XMM -D " + VGAMode + " " + CatalinaFile) PrintLine(1, "payload -b 115200 -p " + PortNumber + " " + filename_noextension) 'PrintLine(1, "pause") FileClose(1)You can see there are some things that could be added quite easily eg the current filename. What I'm not sure is adding things like "Memsize" which is a variable that I tend to change fairly often as it is quicker to make it smaller for faster downloads. And "portnumber" which is the serial port which is also a user setting that might change from time to time.
Would it break the "purist" model to put these somehow into the C program and the compiler strips them out? Or do they go in a "user settings" file which I think code::blocks can do.
There is one other 'tool' I use often, and that is to compile with catalina but not download, and to leave the window open so any error messages are visible. Because the catalina compiler is so quick, I tend to do these check compiles every few minutes, so that there are never more than one or two errors to fix at any one time. I tend to do "compile plus download" less often.
I'd be fascinated to see what you have working so far.
I may eventually add my own "compile" commands (e.g. "Compile and download to RAM", "Compile and download to EEPROM" or "Compile and Debug" - but apart from looking slightly more integrated, it really doesn't add much to the current functionality, which is that you first press the "build" button, then select the appropriate tool (e.g. "Download and Debug") from the tool menu. But I'll see how much time I get.
Yes, I'm sure it would - but it may require a plugin (something like the source reformatting plugin). Setting the memsize does not make a difference to the size of the resulting file unless you also specify -e to output .eeprom formats. The memsize option is mainly intended as a check used to make sure your program is not growing too large to fit in your fixed size eeprom. If you are using .binary format, just set it to the size of your XMM RAM and then forget about it - the file size will always be the smallest possible.
Also, the payload loader doesn't require you to specify a port - it will find it automatically. And I've now modified the blackcat debugger to do that as well. Now the only reason you would ever want to specify a specific port is because it can make downloading slightly faster (i.e. if the programs don't have to locate the right port each time). But this only takes a few seconds, so I hardly ever bother any more. No, but with an automated IDE and build tool, you would tend to keep things like this in separate files (like a resource file). Like most IDEs, this kind of functionality is "built in" to Code::Blocks.
I hope to have it ready for release on the weekend. My time is a bit limited at the moment because I am changing jobs shortly.
Ross.
This sounds great. Ok, maybe we don't need so many settings. Looking at what I have -
1) VGA and graphics settings - these are now somewhat obsolete with cogjects, as I just paste in all the cogjects as arrays at the beginning of a program and then load them from the C code as needed.
2) Memsize - well if you say that is always the smallest, then maybe just set it at 512k. Or 32Mb?
3) Download speed. I think 115200 is the default for everything now so that never needs to change.
4) The port. If payload finds this automatically, that makes things much simpler.
Well, those were all the settings I have, so if we don't need settings, then it ought to make it even easier to customise code::blocks.
Having used an IDE now for a number of months, I think I can start to say which are the commonly used 'tools' menus:
1) Compile and leave the catalina window open - for debugging
2) Compile and download LMM
3) Compile and download XMM
4) Compile with TinyC, or another compiler, and run on the PC to check out individual functions.
Like you say, this largely what code::blocks was designed for.
I've got five gadget gangster designs being made at the moment and the aim is to start off with a standard GG motherboard, run a LMM program, and when you run out of memory, get a memory expansion board (which might only cost $10 or so) and piggyback that on top. Then just go on with compiling with the XMM tool.
I'm looking forward to seeing what you have working!
Addit - there is a thread running at the moment where sphinx has been mentioned. sphinx can compile spin on the propeller - if the c programs can compile the c part, and sphinx can do the spin and pasm part, is it possible to self host a c compiler on the prop??
Sorry - been busy! I have Code::Blocks working well under Windows, but I still need to recomile it to work under Linux. Hopefully in a day or so.
Ross.
Compiling Catalina for Linux
I recently had a need to do a clean install of Fedora Core 14 (64 bit), and then re-install Catalina. Since the Linux binary distribution of Catalina is for 32 bit Linux, I decided to recompile it from source. This made me realize that the instructions included with Catalina itself are a little "thin" (to say the least!) so I thought I'd better document the process. I will include this in the next release.
The version of Catalina I installed was 3.0.2. The instructions would be very similar for other versions, and also for other Linux distributions - whether 32 bit or 64 bit.
The instructions assume you have downloaded the following files from the Catalina SourceForge site (I stored them in a directory called /Shared)
Catalina_3.0.2_patch.zip
Step 0: Become root
It is easiets to perform the Catalina installation when logged in as root:
Step 1: Install the necessary utilities
Building and running Catalina requires some Linux utilities: Note that you probably already have some of these installed.
Step 2: Set up the catalina base directory and install the sources
The default location for Catalina under Linux is /usr/local/lib/catalina Note that unzipping the patch will overwrite some of the files in the catalina directory - this is normal.
Step 3: Set up the environment and Linux permissions
Ensure the appropriate linux permissions are set: The script Set_Linux_Permissions sets most permissions, but on some Linux platforms you may also need to add permissions to allow users to use the include, lib and large_lib directories. You can do this as follows if you get errors on compiling when logged in as a user other than root:
Also, if you want to be able to build some of the Catalina utilities (such as Catalyst) as a user other than root, you will also need write and execute permission to to the relevant directories:
Step 4: Build Catalina
Step 5: Test Catalina
To check that a user other than root can use the Catalina compiler, log in as a normal user, then execute the following: If you get a message similar to the following:
Ross.
And, the "-" means take on the root environment, as opposed to just escalating to root in the current user environment.
On some systems that's significant.
I'm writing that for two reasons. One, the sudo bit is just good to document. Will cut down on a question or two.
Secondly, which is the best practice? Build in user land, then install to target, or??
Hi potatohead,
Good points. One day I'll write a proper configure script to build Catalina on Linux (and maybe Windows as well) - and at that point it would make more sense to build it as a user and then install it as root. But at the moment my time is just too limited, and so I just tend to just re-build it "in situ" as root, zip it up and release it.
But if anybody wants to volunteer to improve the Catalina build/install process (for either Windows or Linux) I'd love to hear from them!
Ross.
That makes perfect sense. Appreciated.
I have just posted Catalina patch release 3.0.3. The main purpose of this release is to provide significantly enhanced Code::Blocks and Windows 7 integration, although it also contains a few bug fixes and other minor enhancements.
The patch release applies to both Linux and Windows (but note that if you have 64 bit Linux you will have to rebuild Catalina from source, since the patch only includes 32 bit executables for Linux).
Please read the new Getting Started with CodeBlocks document for more details on the new Code::Blocks integration (I have attached a copy to this post). You still have to download Code::Blocks 10.05 separately, and the installation process is still a bit of a chore, but I will be submitting the required changes to the Code::Blocks team for automatic inclusion in future Code::Blocks releases.
Ross.
Not me - blame the Code::Blocks team!
One thing I've just noticed (drat!) - to get the code completion to include all the functions defined in the standard C header files, you have to tell Code::Blocks where to find them!
You can set the necessary option at the compiler, project or target level, but in this case it probably makes sense to do it at the compiler level so it is inherited by all projects. From the main menu, select Settings->Compiler and Debugger... Make sure Catalina is the selected compiler, then on the Search Directories tab, select Compiler, and add an entry like C:\Program Files\Catalina\include (for Windows) or/usr/local/lib/catalina/include (for Linux).
I'll update the Code::Blocks document next time I issue it.
Ross.
Just a quick note to let you all know I have submitted the necessary patches to add Catalina support to the Code::Blocks project. While I was preparing the patch, I also fixed to a couple of the minor issues mentioned in the Getting Started with CodeBlocks document:
- It is now possible to specify the .binary or .eeprom suffix for executables, which means Code::Blocks will correctly detect when the project executables are up to date and not rebuild them unnecesarily.
- It is now possible to include spaces in project names under Windows (Linux still has a limitation caused by mono that I am yet to figure out how to resolve)
These are such trivial issues that I don't see the point in releasing another patch, but I will probably do so when Catalina support is avaliable in the Code::Blocks nightly builds, since that will also change the installation process for those people who want all the nifty new features that have been added to Code::Blocks since the last official release (10.05).Ross.
This code::blocks sounds nifty - I'm looking forward to checking it out.
I've been playing around with TV displays, and TVs use 3 pins vs VGA which uses 8. So all things being equal, this means that a TV version of code has 5 spare pins. I have an idea that one could be devoted to audio. So - move the 4 SD pins to, say, prop pins 19,20,21,22, put audio on pin 23, and now there are 16 propeller pins P0-P15 that could be devoted to memory.
I wonder - what is the optimum circuit one could devise to talk to memory in the fastest possible way?
See the attached skeleton schematic.
There are 8 bidirectional data lines, 19 address lines, and /WR and /RD. One could possibly make /CS permanently enabled, saving a line, so that would be a total of 8+19+2 = 29.
My gut feeling is that because the 8 data lines are bidirectional, these would be P0-P7, but maybe there are other options?
Then - could you use the other 8 as high speed SPI lines and decode them to 21 lines?
Or use a 74HC138 and some latches?
Could one devote P8-P11 to drive A0-A3 directly, and so give very fast bursts of data for 16 byte blocks, and use P12-P15 with the dracblade circuit using the 138 and 374 latches?
I feel sure that by going from 12 pins (the dracblade) to 16 pins it ought to be possible to get a faster throughput.
Another thought. With the fsrw code for catalina, can this run independently of the external memory driver for XMM? In other words, could you grab another 4 pins from the SD card, and share pins with the SD card and memory circuit, and read in blocks of data from the sd card, then do some external memory, then read some more sd blocks? Just thinking if one could gain another 4 pins as that would speed up external memory even more.
Input from anyone, especially the 'external memory gurus', would be most appreciated.
I'm not a hardware person (I barely know which end of the soldering iron to hold on to!) but I just thought I'd point out that several platforms - including the C3 and (IIRC) the RamBlade - share pins between the SD card and XMM RAM.
Catalina is geared to cope with this.
Ross.
Ah, right, well that is some very exciting news!
Ok, scratch that last schematic, we now have 20 propeller pins to drive both a SRAM and an SD card. Devote maybe 2 (or 3) to a HC138 and/or an SPI pin expander and you can select between SD and memory. Maybe you only need 1 pin - if High then read memory, if Low then read the SD card?
If so, then that gives us 19 pins for memory access, instead of the dracblade's 12. That ought to speed up the code when running an XMM program.
And I'm particularly interested in that other thread you just posted regarding running spin programs from within C. Faster XMM C plus included Spin is going to open up a lot of possibilities.
My experiments with (second hand) SDRAMs started with some hope but as they don't seem to make socketable ones after the third change of chips, the PCB started to disintegrate. This meant that I was never sure if the chips were banjaxxed on being taken off of the DIMM in the first place. The memory tests never got past 7MBs (on 32MB chips).
Ok, I'm thinking that maybe we have 20 pins to share SD and ram. Take the bottom 16 and you can have 8 for data and 8 for address and do burst reads of 256 bytes. For things like read and enabling sd access and latching in A8-A18, use the upper 4 pins P16-P19. SD can share P0-3 and as long as the ram is disabled then the SD card will be fine.
So - slower writes, but with burst reads you don't even need to turn the /RD pin on and off. Leave it enabled, /CS is enabled (via a latch output) and it might be 6x faster or even more for reads. This could really make catalina XMM fly!
Have you considered changing the lower latch in DracBlade with two HC161 presettable counters?
You would use the lower latch enable signal to load both counters, retaining compatibility with the standard DracBlade, and with two more lines from the HC138 (no more prop pins!), nRST and CLK, you could do page bursts.
It might be a question for Ross - eg you have some standard C code, and the XMM interpreter is reading that line by line, byte by byte, so that is a counter. But occasionally the code changes something - a read or a write (eg to an array, or a variable). Will that upset a counter? Would you need another bit of code to detect if this has happened and disable the counter??
In a vague sort of way, I'm thinking the lower latch on the dracblade is not needed. So two latches and one 138. But I'd like to brainstorm other solutions like SPI latches. One thing you could do with SPI is you could be presetting the higher address lines *before* the code gets there. Or maybe that is adding another layer of complexity?
Hi Dr_A,
What you have described is pretty much how the XMM memory works on some platforms. On the Hydra and Hybrid, Andre's original 512k XTREME RAM card actually keeps its own pointer into RAM internally, and you can read successive bytes without having to specify a new address - you only need to re-address it if you want to access XMM RAM bytes out of sequence. So Catalina also keeps a record in the XMM code of your last memory access, and knows if the next address you are accessing needs the RAM card to be sent a new address or not. Similarly on other platforms Catalina keeps a record of the settings of the latches, and knows whether the next address needs the memory latches to be updated or not.
These tricks are necessary to get the speed up - but the downside is that only one cog can access the XMM RAM - if another cog tried it would upset the addressing, and any attempt to synchronize multiple accesses would make the whole thing too slow to be useful.
Ross.