Help with compile errors
Dr_Acula
Posts: 5,484
Thanks to David Betz helping out over the last few days on a thread started by __red__, we have a super simple external memory solution with just one 23K256 8pin chip. Connect to any 4 propeller pins.
Flushed with the inner glow of success, the next project is to trya big program like Kyedos. So, run Kyedos through Spin2cpp and it passes with no errors.
Compiling it with SimpleIDE is producing 7 errors, and compiling with GNU GCC on codeblocks is producing 8 errors. Not bad for a first run!
The error list seems similar so hopefully these are easily fixed.
The error list for simpleIDE is below
and attached is a zip of all the files.
If anyone has a chance to take a look at this it would be most appreciated
Flushed with the inner glow of success, the next project is to trya big program like Kyedos. So, run Kyedos through Spin2cpp and it passes with no errors.
Compiling it with SimpleIDE is producing 7 errors, and compiling with GNU GCC on codeblocks is producing 8 errors. Not bad for a first run!
The error list seems similar so hopefully these are easily fixed.
The error list for simpleIDE is below
Project Directory: C:/Propeller/Centimanes/Kyedos C experiments/Kyedos/
propeller-elf-c++ -o a.out -Os -mxmmc -I . -m32bit-doubles -fno-exceptions -fno-rtti Kyedos3_TV.cpp
Kyedos3_TV.cpp: In member function 'int32_t Kyedos3_TV::Shell()':
Kyedos3_TV.cpp:67:5: error: assignment of read-only variable 'Kyedos3_TV::_clkmode'
Kyedos3_TV.cpp: In member function 'int32_t Kyedos3_TV::Programreboot(int32_t)':
Kyedos3_TV.cpp:221:5: error: assignment of read-only variable 'Kyedos3_TV::_clkmode'
Kyedos3_TV.cpp: In member function 'int32_t Kyedos3_TV::Programtime(int32_t)':
Kyedos3_TV.cpp:651:138: error: invalid conversion from 'int32_t* {aka int*}' to 'int32_t {aka int}' [-fpermissive]
DS1307_RTCEngine.h:44:11: error: initializing argument 7 of 'int32_t DS1307_RTCEngine::Writetime(int32_t, int32_t, int32_t, int32_t, int32_t, int32_t, int32_t)' [-fpermissive]
Done. Build Failed!
Click error or warning messages above to debug.
and attached is a zip of all the files.
If anyone has a chance to take a look at this it would be most appreciated
zip
40K
Comments
As for the clock mode issue, IIRC the system clock speed is setup somewhere else (based on board configuration). However, the class has _clkmode defined as a static constant which interferes with the clkset macro (and its idea of _clkmode). I'd suggest removing the offending line in Keydos3_TV.h (line 20) as it's not used anyway.
The c line of code
is what Spin2Cpp is producing with the Spin instruction "reboot". So maybe that might be a Spin2c issue?
I commented those two lines out. I also commented out the errors in line 651 - I don't need the time stamp on SD files as I don't have a real time clock at the moment.
So that means no errors any more in the main routine.
But it then went and generated over 50 new errors - lots of "undefined reference to..."
and the compilers (SimpleIDE and GCC) are being difficult and not jumping to the error any more when you click on the error line, so it is unclear where the error is. Are they linker errors? I'm still on the steep part of the learning curve!
This is the start of the error log
I've attached the modified files. Many thanks in advance.
Ok, looks like it is back to syntax errors again. List of errors:
Project Directory: C:/Propeller/Centimanes/Kyedos C experiments/Kyedos/ propeller-elf-c++ -o a.out -Os -mxmmc -I . -m32bit-doubles -fno-exceptions -fno-rtti tv_text.h ASCII0_STREngine.h cog.h DS1307_RTCEngine.h Kyedos3_TV.h pcFullDuplexSerial2FC.h Pocketerm_Keyboard.h propeller.h SD3.01_FATEngine.h Timing.h tv.h tv_text.h ASCII0_STREngine.h cog.h DS1307_RTCEngine.h Kyedos3_TV.h pcFullDuplexSerial2FC.h Pocketerm_Keyboard.h propeller.h SD3.01_FATEngine.h Timing.h tv.h tv_text.cpp ASCII0_STREngine.cpp DS1307_RTCEngine.cpp Kyedos3_TV.cpp pcFullDuplexSerial2FC.cpp Pocketerm_Keyboard.cpp SD3.01_FATEngine.cpp Timing.cpp tv.cpp Kyedos3_TV.cpp ASCII0_STREngine.cpp: In member function 'int32_t ASCII0_STREngine::Tokenizestring(int32_t)': ASCII0_STREngine.cpp:146:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ASCII0_STREngine.cpp:147:59: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ASCII0_STREngine.cpp: In member function 'int32_t ASCII0_STREngine::Integertodecimal(int32_t, int32_t)': ASCII0_STREngine.cpp:267:27: error: invalid conversion from 'uint8_t* {aka unsigned char*}' to 'uint8_t {aka unsigned char}' [-fpermissive] DS1307_RTCEngine.cpp: In member function 'int32_t DS1307_RTCEngine::Clocksecond()': DS1307_RTCEngine.cpp:28:10: error: invalid conversion from 'uint8_t* {aka unsigned char*}' to 'int32_t {aka int}' [-fpermissive] SD3.01_FATEngine.cpp:32:12: error: invalid suffix "_FATEngine" on floating constant SD3.01_FATEngine.cpp:32:12: error: expected initializer before numeric constant tv.cpp:19:9: error: 'tv' has not been declared Done. Build Failed! Click error or warning messages above to debug.First error line 146:22 is
while (((uint8_t *)Tokenstringpointer)[0]) {147:59 is 267:27 is 28:10 is 32:12 isuint8_t SD3.01_FATEngine::dat[] = {19:9 isuint8_t tv::dat[] = {If these errors are quirks of spin2c, then maybe can recode the spin so they don't occur? These are mainly Kye's code, and he may be using super advanced spin methods
I guess I need to understand what the errors mean first. Thanks again for the help!
Token string pointer is probably a 16 bit (word) variable. You could probably get rid of the warning by casting to an int first, before casting to the pointer.
For the 267:27 error it's complaining because you are trying to put 4 bytes into 1 (a pointer into char). I don't know why the original code was like that, so I'd start by figuring out that logic. You could get rid of the error by casting to a uint8_t. It might be that in Spin, if you put a long into a byte array it "automatically" puts the last three bytes in the array.
There was a bug in an older version of Spin2cpp where it would not put the [0] on arrays if the Spin version didn't have it. That may be an issue here. Although, looking at the code, I don't think you can have a "." character in a class name.
Spin2cpp also sometimes names the classes with a "spin" suffix, but not in all files. For example, a spin file "numbers" might be declared as "numbersSpin" but used as "numbers".
It might also help if you post your converted files.
fred vs fred[0] (OK in SPIN, NG in C/C++)
fred vs fred[0] (OK in SPIN, NG in C/C++)
For some reasons the DAT array doesn't have its name cleaned up. It should read uint8_t SD3_01_FATEngine::dat[] = {.
Similar to the one above, it should read tvSpin::dat[].
The last two sound like bugs although I don't understand the one about tv vs tvSpin (e.g. the serial driver conversion is OK). fred vs fred[0] can be solved in SPIN land but you might as well fix the generated C/C++ code instead, I mean you do get an error. HTH
Eric
As pointed out by SRLM and Kuroneko, many of the errors are due to arrays being declared eg myarray[5] and then used as myarray[1], myarray[2],myarray[3] but spin seems to let you use myarray as a variable as being the same as myarray[0]. So I have changed those to have the 0 so they explicitly declare it as the first variable.
Also the filename was causing this error
uint8_t SD3.01_FATEngine::dat[] = {as the filename has a period in it, and spin is ok about that but c is not. So changed that to SD301_Fatengine and a number of errors have gone.Fixed the tv error - it was declared as "tv" instead of "tv.spin"
Ok - it now gets through the compilation with no errors. But a bunch of new problems have appeared. Ignoring the first two warnings, what do all the comments mean regarding "multiple definition"
But I'm guessing what to do next. Tried adding the files in that panel, tried adding links, tried all the .cpp and then all the .h and then both. Tried adding a link to the directory. How does the Project Manager part of SimpleIDE work?
I've just got the .cpp files in the project manager now. Getting a slightly different list of errors
Nice find. I'll write a bug report on it. Sorry for the confusion. Thanks for your help - I'm overloaded !
Is there a manual fix for this?
Edit the .side file by hand with notepad. Just remove the duplicate line.
Thanks++ Jazzed, that fixed heaps of errors. Very close now. Just one error (undefined reference to `_main'). In a slightly recursive fashion, a search for this error took me back to this very forum with a posting by myself trying to do the very same thing back in July last year. Darn it, I'm going to get this working!
So this is the error log
Attached is the zip.
spin2cpp doesn't automatically add a main() function, because it doesn't know if you're converting a .spin file for use as a driver (to link with your own main program). You can tell it to add a main() automatically by specifying --main (or --elf); in this case it will create a very simple main that just calls the first method in the first Spin object, the same way the Spin interpreter does.
The other thing to beware is that you're compiling an SD card driver in XMMC mode. It's very likely that the XMMC cache driver will conflict with the Spin driver you're converting. Have you tried it in CMM mode to see if it will fit in hub memory?
Eric
I changed my batch file to
But no, unfortunately it does not fit in hub ram. The Spin program is about 22k. The C program (optimised for size) is about 57k.
So no, it does not fit in hub memory, and it does not fit in the 23K256 chip either
Looks like it is time for an upgrade to one of Microchip's bigger ram chips!
I'm hoping there are no conflicts between drivers. This Spin program has all its own drivers - it doesn't use stdio and it doesn't use the SD drivers in the C library. The pins for the SPI ram and the pins for the SD card are separate. So I am hoping there are no conflicts.
But am I using the correct memory model. I'm using XMMC. I want the program cached in sram, not cached on the SD card. Is XMMC the right one, or should it be XMM or something else?
Addit: doing some more experiments. brb
Ok, removed the SD card so this can't possibly end up cached on the SD card. Tested with the sram plugged and unplugged. The program will still be downloaded to the sram even if it is unplugged so from that, assume that it doesn't do a read/write test first. So the test is whether the program runs or not.
In c:\propgcc\propeller_load is a new board type called sram_spi.cfg
# sram_spi.cfg clkfreq: 80000000 clkmode: XTAL1+PLL16X baudrate: 115200 rxpin: 31 txpin: 30 cache-driver: spi_sram_cache.dat cache-size: 8K cache-param1: 0x05070601 # 0xooiiccpp - oo=mosi ii=miso cc=sck pp=cs-protocol cache-param2: 0x04000000 # 0xssxxxxxx - ss=cs load-target: ramThe C program is
#include <stdio.h> #include <propeller.h> int main(void) { int n = 1; while(1) { waitcnt(CLKFREQ/10+CNT); printf("Hello World %d\n", n); n++; } return 0; }and the .side file is
So that compiles to the sram with this
This code appears to be running from the sram. So I think that will get around any cache conflicts?
I have ordered some 23LC1024 chips from both Radio Spares and Element14 - they usually deliver within a few days so should be able to continue experiments then.
I'm still looking at all the memory models. I think some split the program and the data - program in 'write once, read often' memory and data in ram. I think there is a split mode for that.
What I would like to do with kyedos is devote more ram to video (TV or VGA). That can't be done with Spin but it can be done with C
What exactly is the XMMC model? Is the data stored in hub?
XMMC means XMM code. That is, code is kept in a device like Flash or even EEPROM (much slower than Flash). Flash is only written to change the code. All data is in HUB RAM. XMMC is the fastet external memory model because the kernel doesn't have to decide what to do with data. Code is always in XMMC, and data is always in HUB, so the kernel can save time. It is also faster because there is only one device used with the cache and there is no write-back required from the cache for data. Other XMM modes like XMM-Single must use the cache to handle code and data. It's quite slow.
You can still use SRAM for XMMC. Your SDcard can have programs on it that get loaded to SRAM by the loader. The problem with SRAM is density (SPI SRAM <= 128K per device) and some cases massive number of pins required. SDRAM doesn't have density issues, but it requires many pins and is relatively slow to access.
Also, you don't necessarily have all of hub memory available just because you're using xmmc mode. First, there is an 8k cache at the top of hub memory that is used to speed up access to the external memory. Beyond that, the stack is always in hub memory no matter which memory model you choose so you have to reserve enough space for that.
Ya, just love that unique GCC feature. How could I forget it ?
Or does the flash chip need to be a particular brand to work with the software driver?
Well sure, but as I recall it is by address and pointer in most solutions which is clunky.
All you need in Propeller-GCC is to add the HUBTEXT (from propeller.h) decoration before a function.
Data can also be assigned to HUB by using HUBDATA (from propeller.h).
__attribute__((section(".hubtext")))
Not all platforms use sections.