Cannot turn led on with C, using the Catalina compiler
robdog
Posts: 7
I have a bare propeller chip hooked up on a breadboard and connected to my pc via a prop plug. I want to turn on an led that is hooked up to P0.
This is my code:
It compiles fine and, as far as I can tell, uploads to the propeller fine, but the led does not turn on. If I write an equivalent program in spin, it works just fine.
Could this be due to my clock speed? I don't have a 5 MHz crystal (I only have 24 MHz), so I've been using the on chip rcfast oscillator. I've change the costum_DEF.def file to look like this:
Is this right?
This is my code:
#include <catalina_cog.h>
int main(int argc, char *argv[])
{
_dira(0x1,0x1);
_outa(0x1,0x1);
while(1);
return 0;
}
It compiles fine and, as far as I can tell, uploads to the propeller fine, but the led does not turn on. If I write an equivalent program in spin, it works just fine.
Could this be due to my clock speed? I don't have a 5 MHz crystal (I only have 24 MHz), so I've been using the on chip rcfast oscillator. I've change the costum_DEF.def file to look like this:
CLOCKMODE = rcfast ' (QuickStart)
XTALFREQ = 12_000_000 ' (QuickStart)
CLOCKFREQ = 80_000_000 ' (QuickStart) Nominal clock frequency
' (required by some drivers)
Is this right?
Comments
I just tried your program, and it works ok for me. Can you tell me what command you are using to compile? Are you compiling with -C CUSTOM? Also, what version of Catalina? Prior to Catalina 3.5, you would have had to explicity specify CUSTOM, since the default platform was HYDRA.
Here is the command I used to compile your program (I called it led.c) - this command should work on any version of Catalina:
Ross.
By the way - if you are using Catalina 3.6, you can simplify your program to:
extern volatile DIRA; extern volatile OUTA; int main(int argc, char *argv[]) { DIRA |= 1; OUTA |= 1; while(1); return 0; }Ross.
Also, when I invoke catalina manually using the same options as you and load the resulting binary file onto the propeller it doesn't work either. Could there be a problem because I don't have an EEPROM attached to the propeller?
Ah, I should have asked that as well - you don't need to add CUSTOM if you are using Catalina 3.6 and Code::Blocks and have already specified it as your Propeller platform. Now it is being added twice. You can look through your Project->Build Options to find out why (it should be specified for at most one of the nodes in the left hand panel) but in this case it may be easier to just re-build the whole project from scratch.
Here is what I did (sorry if you did all this already - but redoing it will help eliminate any possible configuration error):
- Start Code::Blocks and select File->New->Project..., then choose the Catalina Project icon. You will be presented with a project wizard opening screen - just press Next.
- Enter a title and directory for the project (I used the title leds and the directory C:\Users\ross\ - yours will differ, of course). Then press Next.
- You will be asked if you want to create both debug and release versions. Unselect "Debug" since we don't want it. Then press Next.
- You will be asked for your Propeller platform. Select CUSTOM. Then press Next.
- You will be asked for which library you want. Choose Standard C Library (no maths or file system). Then press Next.
- You will be asked for your HMI device. Chose None. Then press Next.
- You will be asked for the memory model. Choose TINY. Then press Finish.
- Open up the Sources node in the Code::Blocks project navigation panel, and edit the main.c file - paste in your program code.
- Select Build->Rebuild (or hit Ctrl-F11).
- Select Tools->Download to Hub RAM.
- The LED should turn on.
Not sure - but it seems unlikely since you said it works from Spin. All TINY Catalina programs are just plain old Spin programs, so if the above doesn't work for you (it does for me, using the clock speed RCFAST) then I am a bit stumped. Post a copy of your resulting binary files here (both the Spin version and the C versions) and I will have a look at them and also try loading them on my Propeller.Ross.
I created a new project and followed your steps exactly and the led still doesn't light up.
I've attached the binary generated by catalina and the one generated by the propeller tool. led.binary is the one generated by catalina.
Something strange is going on. The file led.binary you posted was not compiled with Catalina 3.6!
Perhaps you still have a previous version of Catalina installed, and somewhow it is still being used when you compile.
Can you please make sure your LCCDIR environment variable is set to point to the correct version of Catalina? Just open a command window and type echo %LCCDIR%
Also, in Code::Blocks, can you go to Settings->Compiler and debugger and hit the Reset Defaults button? This will force Code::Blocks to re-detect Catalina. It will tell you where it found it - this should match the LCCDIR setting.
Then try rebuilding your program and posting the resulting binary.
Ross.
Here's the new version of the binary.
Weird! I have looked in the binary, and what is in there is not Catalina 3.6 code! Some parts of it do not appear to be valid code at all, although other parts of it look like an earlier version of Catalina. I still think that somehow it must be combining parts of Catalina 3.6 with an earlier version.
Can you please add the listing option in Code::Blocks, rebuild and then post the leds.lst file? That file will tell me where everything comes from.
To add the listing option, go to Project->Build options, select the category Listing and Output options and select Generate Listing [-y]?
EDIT: I just installed the compiler on the linux side of my computer. The compiler works fine, but loading the code onto the propeller fails, however if I copy the binary file to my windows partition and load them onto the propeller, it works fine. So at least we know it isn't a problem with my propeller chip.
EDIT2: Uninstalled catalina and re-installed and everything seems to be working fine now. I guess whatever was causing the issues earlier was a one time deal.
Hi robdog,
Well, I can see the problem ... but I can't figure out how this could have happened. You appear to have the Catalina 3.6 kernel (Catalina_LMM.spin) but some of the other target files you are definitely from Catalina 3.4 (e.g. catalina_default.s, lmm_progbeg.s). I changed the meaning of some of the primitives in between these releaases, so there is no way this combination will ever work. But what is confusing me is that all these files are in the same directory (i.e. Catalina\target) and I can't think of a way that the compiler could be looking in one directory for some of these files, and in another diirectory for others.
One possibility is that you installed Catalina 3.6 over Catalina 3.4 but some files were "locked" at the time (or you didn't have permission to write them) and so they didn't get overwritten. However, while I have not tried this myself, I would have expected the installer to complain (or at least warn you!). Another possibility is that you have accidentally copied some target files between versions, not realizing that they had changed.
In any case, I don't think it is worth trying to recover your existing installation - there may be other incorrect files we have not found yet. I'd recommend completely uninstalling Catalina, deleting the installation folder entirely (save your actual C programs, of course!) and then re-install Catalina 3.6.
Ross.
Do you run Linux in a virtual? I do, and this seems to cause some problems accessing serial ports. I generally have to use a command like:
Another problem with Linux is that you have to explicitly give users permission to use the serial ports - this is not automatic. To see if this is the problem, log in as root and tryt it - if it loads, payload will tell you the port it used, and you can then give users read/write permission to that port.
Good! Let me know if you have any more problems.
Ross.
EDIT: looking at the binary, it says that the XIN frequency is 0 and the clock frequency is 0, but my custom_DEF file has them listed correctly.
EDIT2: I've figured it out, XTALFREQUECY and CLOCKFREQUENCY must be same the same in order for it to work.
HI robdog,
The CLOCKFREQ needs to be set to the actual clock speed for serial comms to work since this value is used by some of the serial drivers to set their serial bit timing. It does not need to be the same as XTALFREQ, but the actual relationship depends on CLOCKMODE. I don't think XTALFREQ is used in RCFAST mode, but the CLOCKFREQ value is still required.
The Propeller manual is probably your best source of information here.
Ross.