FYI, this is an i2c driver written using COG mode in PropGCC.
/* i2c_driver.c - i2c single master driver
Copyright (c) 2012 David Michael Betz
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#ifndef __PROPELLER2__
#include <propeller.h>
#include "i2c_driver.h"
/* minimum overhead per half cycle */
#define MINIMUM_OVERHEAD 32
#ifdef PARALLAX_I2C_BUS
/* set sda high by allowing it to float high, set low by forcing it low */
/* actively drive scl */
#define i2c_set_scl_high() (OUTA |= scl_mask)
#define i2c_set_scl_low() (OUTA &= ~scl_mask)
#define i2c_set_sda_high() (DIRA &= ~sda_mask)
#define i2c_set_sda_low() (DIRA |= sda_mask)
#else
/* set high by allowing the pin to float high, set low by forcing it low */
#define i2c_set_scl_high() (DIRA &= ~scl_mask)
#define i2c_set_scl_low() (DIRA |= scl_mask)
#define i2c_set_sda_high() (DIRA &= ~sda_mask)
#define i2c_set_sda_low() (DIRA |= sda_mask)
#endif
/* i2c state information */
static _COGMEM uint32_t scl_mask;
static _COGMEM uint32_t sda_mask;
static _COGMEM uint32_t half_cycle;
static _COGMEM volatile I2C_MAILBOX *mailbox;
static _NATIVE void i2cStart(void);
static _NATIVE void i2cStop(void);
static _NATIVE int i2cSendByte( uint8_t byte);
static _NATIVE uint8_t i2cReceiveByte(int acknowledge);
_NAKED int main(void)
{
I2C_INIT *init = (I2C_INIT *)PAR;
I2C_CMD cmd;
uint8_t *p;
uint32_t count;
/* get the COG initialization parameters */
scl_mask = 1 << init->scl;
sda_mask = 1 << init->sda;
half_cycle = init->ticks_per_cycle >> 1;
mailbox = init->mailbox;
/* make sure the delta doesn't get too small */
if (half_cycle > MINIMUM_OVERHEAD)
half_cycle -= MINIMUM_OVERHEAD;
/* tell the caller that we're done with initialization */
mailbox->cmd = I2C_CMD_IDLE;
#ifdef PARALLAX_I2C_BUS
/* initialize the i2c pins */
OUTA |= scl_mask;
OUTA &= ~sda_mask;
DIRA |= scl_mask;
DIRA &= ~sda_mask;
#else
/* initialize the i2c pins */
DIRA &= ~scl_mask;
DIRA &= ~sda_mask;
OUTA &= ~scl_mask;
OUTA &= ~sda_mask;
#endif
/* handle requests */
for (;;) {
uint32_t sts;
/* wait for the next request */
while ((cmd = mailbox->cmd) == I2C_CMD_IDLE)
;
/* dispatch on the command code */
switch (cmd) {
case I2C_CMD_SEND:
case I2C_CMD_SEND_MORE:
p = mailbox->buffer;
count = mailbox->count;
sts = I2C_OK;
if (cmd == I2C_CMD_SEND) {
i2cStart();
if (i2cSendByte(mailbox->hdr) != 0) {
sts = I2C_ERR_SEND_HDR;
break;
}
}
while (count > 0) {
if (i2cSendByte(*p++) != 0) {
sts = I2C_ERR_SEND;
break;
}
--count;
}
if (mailbox->stop)
i2cStop();
break;
case I2C_CMD_RECEIVE:
case I2C_CMD_RECEIVE_MORE:
p = mailbox->buffer;
count = mailbox->count;
sts = I2C_OK;
if (cmd == I2C_CMD_RECEIVE) {
i2cStart();
if (i2cSendByte(mailbox->hdr) != 0) {
sts = I2C_ERR_RECEIVE_HDR;
break;
}
}
while (count > 0) {
int byte = i2cReceiveByte(count != 1);
if (byte < 0) {
sts = I2C_ERR_RECEIVE;
break;
}
*p++ = byte;
--count;
}
if (mailbox->stop)
i2cStop();
break;
default:
sts = I2C_ERR_UNKNOWN_CMD;
break;
}
mailbox->sts = sts;
mailbox->cmd = I2C_CMD_IDLE;
}
return 0;
}
static _NATIVE void i2cStart(void)
{
i2c_set_scl_high();
i2c_set_sda_high();
waitcnt(CNT + half_cycle);
i2c_set_sda_low();
waitcnt(CNT + half_cycle);
i2c_set_scl_low();
}
static _NATIVE void i2cStop(void)
{
/* scl and sda should be low on entry */
waitcnt(CNT + half_cycle);
i2c_set_scl_high();
i2c_set_sda_high();
}
static _NATIVE int i2cSendByte(uint8_t byte)
{
int count, result;
/* send the byte, high bit first */
for (count = 8; --count >= 0; ) {
if (byte & 0x80)
i2c_set_sda_high();
else
i2c_set_sda_low();
waitcnt(CNT + half_cycle);
i2c_set_scl_high();
waitcnt(CNT + half_cycle);
i2c_set_scl_low();
byte <<= 1;
}
/* receive the acknowledgement from the slave */
i2c_set_sda_high();
waitcnt(CNT + half_cycle);
i2c_set_scl_high();
result = (INA & sda_mask) != 0;
waitcnt(CNT + half_cycle);
i2c_set_scl_low();
i2c_set_sda_low();
return result;
}
static _NATIVE uint8_t i2cReceiveByte(int acknowledge)
{
uint8_t byte = 0;
int count;
i2c_set_sda_high();
for (count = 8; --count >= 0; ) {
byte <<= 1;
waitcnt(CNT + half_cycle);
i2c_set_scl_high();
byte |= (INA & sda_mask) ? 1 : 0;
waitcnt(CNT + half_cycle);
i2c_set_scl_low();
}
// acknowledge
if (acknowledge)
i2c_set_sda_low();
else
i2c_set_sda_high();
waitcnt(CNT + half_cycle);
i2c_set_scl_high();
waitcnt(CNT + half_cycle);
i2c_set_scl_low();
i2c_set_sda_low();
return byte;
}
#endif // __PROPELLER2__
Hi David,
I now have this program compiling in Catalina's new COG mode. I haven't written an optimizer for COG mode yet, so it's probably quite a bit larger than it needs to be - but at least it fits!
How many LONGs does this program take in PropGCC's COG mode?
Catalina's overhead will probably always be slightly higher than PropGCC, since Catalina implements everything in the cog.
Currently Catalina's size for this program is well over 300 longs, but based on previous experience, I expect even fairly simple optimizations will be able to bring the size of this program down under 300 longs, so it should be quite comparable with PropGCC, which seems to be 256-290 (depending on optimization level).
[*]All code, local and global variables, as well as the stack, must fit entirely within in a single cog. The stack will occupy any cog space not used by anything else, so to make best use of the limited cog space, using global or register variables, and a single main() function consisting mainly of linear code (i.e. as few function calls as possible) is strongly recommended.
PropGCC uses fixed 16 Registers in Cog, stack is in HUB. I always needed stack only on function calls, if (all) register were used.
Do Catalina (lcc) necessarily need a stack ?
Could the register count made be flexible instead of a stack ?
Is a stack in cog not difficult to make ? Is it then really faster than a stack in HUB ?
[*]The only way currently to refer to Hub RAM (other than by inserting RDxxxx and WRxxxx instructions inline) is to call special readbyte(), readword(), readlong(), writebyte(), writeword() or writelong() functions. I'll probably also provide functions for copying larger objects (structures, arrays etc) to and from Hub RAM.
Does this mean that a structure mailbox like in the i2c example is not possible ?
Would be very bad !!!
[*]The only way to use the compiled code at the moment is to compile it, extract the compiled data segment manually as a binary blob, and then use that blob in another program via a coginit() function (much like the spinc utility currently does). I will make this easier before release - not sure how yet. I am currently thinking that I add facilities so that the compiled C program can be turned into a loadable "plugin" in a single command.
So I need a separate project for every cog programm/driver ?
How do I then test/debug this ?
PropGCC uses fixed 16 Registers in Cog, stack is in HUB. I always needed stack only on function calls, if (all) register were used.
Do Catalina (lcc) necessarily need a stack ?
Could the register count made be flexible instead of a stack ?
Is a stack in cog not difficult to make ? Is it then really faster than a stack in HUB ?
Having the stack in COG ram is actually pretty easy. And a COG stack is twice as fast as a Hub stack. But the overhead is one additional instruction per stack access. The real solution for COG mode is to write code that doesn't need to make much use of the stack.
[/quote]Good question - the current source-level debugger uses a separate cog to examine and manipulate the state of Hub RAM. But you can't do that to stuff executing completely in another cog, and there is not enough space in that cog to add in all the additional debug code required to support source-level debugging. But I also support the POD PASM-level debugger (which I still use sometimes to debug the kernel itself) - maybe I can look at adding POD debugger support in for COG mode - it would add an overhead of about 36 longs to each COG program, but in most cases it should fit.
The real solution for COG mode is to write code that doesn't need to make much use of the stack.
We agree! But that depends on how the compiler handle the things. We will see.
But the overhead is one additional instruction per stack access.
Than it is maybe better to have one or two registers more, if lcc can make use of it !?
Yes. of course it will be possible. But you may have to read/write structures held in Hub using "helper" macros or simple functions.
Sorry, I think, I don't understand.
In gcc I use addressinpar->bytevariable1, addressinpar->wordvariable3, addressinpar->longvariable4 ....
The compiler calculates the address of the structure members at compile time.
In catalina I would have to calculate the address myself? Do I know how the structure is packed/padded?
Or miss I something here ?
No, you can have as many COG mode modules in the same project as you need.
I think we're talking past each other. If I want a COG mode module I have to compile it separate to my project, right? In propGCC the cogmode file has the extension .cogc, so the compiler knows that this file has to be compiled in COG mode, while the other files are lmm or something else. But I have things together, so I can 'feed' my COG module with data, to look wether it works. If not, I can change things very easy/fast.
I don't like this extension thing. In my opinion a C-File has to have the extension .c, so every editor/tool do 'syntax highlighting'. But 'decoration' ("section COG" or something like that) in the file you don't want! So I will have a project where I compile my driver and hopefully can put that file/binary/plugin in my main project somehow automated.
maybe I can look at adding POD debugger support in for COG mode
Make this to 'I will look at and try very hard to adding...' and you will be the hero ;-). Because this then will be the first real IDE for the propeller. At least what I call an IDE.
Sorry, I think, I don't understand.
In gcc I use addressinpar->bytevariable1, addressinpar->wordvariable3, addressinpar->longvariable4 ....
The compiler calculates the address of the structure members at compile time.
In catalina I would have to calculate the address myself? Do I know how the structure is packed/padded?
Or miss I something here ?
If you have a standard way of interacting with cogs (with PropGCC I guess it is some kind of "mailbox", while in Catalina it is always the registry) then providing a few simple macros or functions solves the most common hub usage problem quite effectively.
I think we're talking past each other. If I want a COG mode module I have to compile it separate to my project, right? In propGCC the cogmode file has the extension .cogc, so the compiler knows that this file has to be compiled in COG mode, while the other files are lmm or something else. But I have things together, so I can 'feed' my COG module with data, to look wether it works. If not, I can change things very easy/fast.
I don't like this extension thing. In my opinion a C-File has to have the extension .c, so every editor/tool do 'syntax highlighting'. But 'decoration' ("section COG" or something like that) in the file you don't want! So I will have a project where I compile my driver and hopefully can put that file/binary/plugin in my main project somehow automated.
A cog program is just a ".c" file, like any other. You can use makefiles or custom build command with Code::Blocks (or plain old makefiles) with Catalina, so this is not really a problem. Just specify the appropriate dependencies between the files and you still have a very simple "compile-load-test" cycle no matter how many COG programs your program uses.
Make this to 'I will look at and try very hard to adding...' and you will be the hero ;-). Because this then will be the first real IDE for the propeller. At least what I call an IDE.
Actually, it costs almost nothing to add, so I can easily say POD will be supported for COG programs.
I think we're talking past each other. If I want a COG mode module I have to compile it separate to my project, right? In propGCC the cogmode file has the extension .cogc, so the compiler knows that this file has to be compiled in COG mode, while the other files are lmm or something else. But I have things together, so I can 'feed' my COG module with data, to look wether it works. If not, I can change things very easy/fast.
I don't like this extension thing. In my opinion a C-File has to have the extension .c, so every editor/tool do 'syntax highlighting'. But 'decoration' ("section COG" or something like that) in the file you don't want! So I will have a project where I compile my driver and hopefully can put that file/binary/plugin in my main project somehow automated.
Actually, PropGCC doesn't require ".cogc" as an extension to compile COG mode programs. That is a convention used by SimpleIDE. Any C source file can be compiled in COG mode by passing the appropriate command line argument to the compiler (-mcog).
Yes,sorry, I should have said Simple-IDE. But If I talk of the compiler, then I mean the Tool (IDE). I never touched any makefile the last 15 Years. I click on setup, then I make my Projekt, add some files,file pathes, click on a few checkboxes and go. The internals don't touch me.
This confusion between the compiler and the editor/IDE is an aberration propagated by MS and co. for many years.
I'm hoping that now as MS is on the way out and other systems get a look in understanding will return to normal.
Good. If Catalina makes good use of it. Then a stack for most cases is not necessary.
If you have a standard way of interacting with cogs (with PropGCC I guess it is some kind of "mailbox", while in Catalina it is always the registry) then providing a few simple macros or functions solves the most common hub usage problem quite effectively.
With PropGCC I make a pointer to my self defined structure, table, a single long, whatever... The header file for my COG module tells the other part how to use. That's how it is elsewhere in the world.
I searched for registry in the manual and I read something of 8 longs, plugins and targets, but I can say, that I not really understood what the registry should be and how I should use it.
What I understood from you in this thread (a few posts back) is: You want no "decorations", because this is not C and you then can not compile this with another compiler. Now I should use a registry, because then.... what?
At this point I am somehow frustrated, again.
This confusion between the compiler and the editor/IDE is an aberration propagated by MS and co. for many years.
I'm hoping that now as MS is on the way out and other systems get a look in understanding will return to normal.
What other systems ? What is normal ? You mean not this fu***** thing where I have to use a shell and type in some funny things to get where I not wanted to be.
Yes, I mean exactly "this fu***** thing where I have to use a shell and type in some funny things to get where I not wanted to be."
When I want to communicate with you, like here and now, that is exactly what I do. I don't point and click on your buttons and, God forbid, I don't mess with your touch interface.
No, I have to know your language and syntax and grammar and even your local weird dialects or cultural references.
Why should communing with a computer, especially if one is programming it, be any different?
Admittedly C and it's libraries and it's headers and Makefiles and all that nonsense makes things a bit awkward and that is a problem IDEs tried to simplify. They try to make "type code and go" easier.
That's great until you want to use a different IDE on a different machine or OS. Or perhaps you just want to use your favourite editor.
What other systems ? What is normal ? You mean not this fu***** thing where I have to use a shell and type in some funny things to get where I not wanted to be.
With Catalina, you also have the option of using Code::Blocks - a professional grade IDE, and perhaps the best one around for C/C++, since it was designed from the ground up specifically for these languages.
Personally, I find that once you know how to program and are familiar with the language, all an IDE does is just slow you down and get in the way. However, I realize that we are all different, which is why Catalina also supports Code::Blocks.
With PropGCC I make a pointer to my self defined structure, table, a single long, whatever... The header file for my COG module tells the other part how to use. That's how it is elsewhere in the world.
I searched for registry in the manual and I read something of 8 longs, plugins and targets, but I can say, that I not really understood what the registry should be and how I should use it.
If you understand mailboxes, then understanding the registry should be fairly straightforward, since that is one of its primary functions. But even before you can use a mailbox, you have to find it - and that is another primary function of the registry - i.e. to allow cogs to register the run-time services they offer, so that this doesn't need to be hard-coded into your C program.
What I understood from you in this thread (a few posts back) is: You want no "decorations", because this is not C and you then can not compile this with another compiler. Now I should use a registry, because then.... what?
At this point I am somehow frustrated, again.
This may be because you seem to be looking for something complicated, and Catalina is deliberately not complicated - not at the C level. Many users will never need to use the registry directly at all. For instance, if you want to use a VGA text driver with PropGCC you need to do some special preparation in your C program, and then also use special functions to access it. And of course, having done that, your program is then not much use if you later decide you want to use some other display driver (here is a recent thread on just this subject).
With Catalina you just tell your program (usually at compile time, although in some cases you can even defer this to load-time or even run-time) that you want to use a VGA display, and your C program just works. The same C program can also use a TV display, a PC terminal emulator or a simple serial port.
All this is accomplished via the registry, which means you don't need to worry about it in your C program. Even if your needs outgrow the basic drivers and other plugins Catalina provides and you want to start writing your own drivers or plugins, then that is also much easier with Catalina - precisely because it makes all the standard registry infrastructure available for you to use, which means you don't have to redevelop it every time.
For instance, if you want to use a VGA text driver with PropGCC you need to do some special preparation in your C program, and then also use special functions to access it. And of course, having done that, your program is then not much use if you later decide you want to use some other display driver (here is a recent thread on just this subject).
Hmm, it seems you are blowing that out of proportion Ross. The common simpletext functions can be used with any text input or output driver.
The simpletext philosophy is minimalist for common text IO functions. Device specific functions were encouraged because they allow better control of devices.
It's ok to have such differences of opinion of what is good - everybody has opinions.
The simple libraries offer Spin-like device startup and control over interfaces. There is nothing going on in the background like your mailboxes as requested by Parallax education ... I've tried to convince them that the mailboxes that you use have value because it allows a second stage loader, but I keep getting shot down.
Everything in the Parallax Propeller C simple libraries were written, specified, and/or included there by Parallax. It is their product. I just help whenever they ask.
Hmm, it seems you are blowing that out of proportion Ross. The common simpletext functions can be used with any text input or output driver.
The simpletext philosophy is minimalist for common text IO functions. Device specific functions were encouraged because they allow better control of devices.
It's ok to have such differences of opinion of what is good - everybody has opinions.
The simple libraries offer Spin-like device startup and control over interfaces. There is nothing going on in the background like your mailboxes as requested by Parallax education ... I've tried to convince them that the mailboxes that you use have value because it allows a second stage loader, but I keep getting shot down.
Everything in the Parallax Propeller C simple libraries were written, specified, and/or included there by Parallax. It is their product. I just help whenever they ask.
Your thread just happens to provide a handy "current" example to point to. There are lots of others. Real-time clock? Catalina supports several implementations. SD Card drivers? Catalina supports multiple ones of those as well. Are you seriously proposing we should have a separate interface to each different variant of hardware, all implemented at the C level? What a nightmare that would be!
As to the utility of having "mailbox" functions - well, Catalina's registry is really too simple to be called a "mailbox", but I understand what you mean. But mailboxes (or whatever you want to call them) are such a mind-bogglingly useful concept that I would claim that is really Parallax who is out of step here. In practice we all use mailboxes - PropGCC does, Catalina does, many Spin programs do, and David Betz does (in his Spin to C/C++ "spinwrap" wrapper). The main difference is that Catalina predefines them, whereas with other languages/compilers you have to define them yourself.
But if Parallax doesn't want them in their educational compiler (forcing everyone to re-invent them for themselves when they eventually discover they need them) then so be it. I guess you can validly claim that this approach is "educational". I would use a different word for it.
There I agree 100%. What one finds easy, is difficult for others.
But even before you can use a mailbox, you have to find it.
No. There is a header where I can see what's in the mailbox. I include the header and use the mailbox. And if I wrote the code myself, I know exactly how to use it.
But maybe I don't understand what you want to tell me.
... and you want to start writing your own drivers or plugins, then that is also much easier with Catalina - precisely because it makes all the standard registry infrastructure available for you to use, which means you don't have to redevelop it every time.
Therefor you have to understand, how the things work, and you have to adjust your things to something, what you maybe not want.
Maybe there once comes the moment, when I understand the registry. For now catalina is too much an OS instead of a compiler for me.
Maybe there once comes the moment, when I understand the registry. For now catalina is too much an OS instead of a compiler for me.
Actually, Catalina provides what one needs to provide in order to claim to be ANSI C compliant - not less, and not much more.
Of course, if you don't want all those features, then by all means don't use them - there is very little overhead if you don't use them (8 longs). But they are there for you if and when you do.
I tried to send you a private message but your inbox is full. So I feel free to ask it in this thread here:
Heater pointed me towards your c-compiler Catalina and mentioned Lua.
If I understand right you used Lua to support your compiler not to run a Lua-interpreter on the propeller-chip itself.
Anyway would it be possible to compile Lua to run inside a propeller-chip?
Especially the eLua-sourcecode for microcontrollers which has modules for onewire, I2C, SPI Uart, etc?
How much space would be left for the callstack of Lua? (if the result is negative would it be possible to run Lua in LMM or XMM-mode?
Lately Ken Gracey was asking for python on a propeller-chip. From the answers I guess python is too big.
But how about eLua? To me it seems small enough. And could be a useful alternative for teachers (who asked for python)
How much effort would it be to compile the eLua sourcecode for a propellerchip?
Two to three hours? Seven to eight months? I have no idea.
Would this be an interesting project to you? Could you answer with a rough estimation of the time it would take?
As a general rule, for a 32-bit CPU, we recommend at least 256k of Flash and at least 64k of RAM. However, this isn't a strict requirement. A stripped down, integer-only version of eLua can definitely fit in 128k of Flash and depending on your type of application, 32k of RAM might prove just fine. We have built eLua for targets with less than 10K RAM but you can't do much than blinking an LED with them. It really largely depends on your needs.
I see that Ross has not logged in since 9/2014. I hope he is OK.... or just lurking.
I exchanged email with Ross a few days ago. He's fine but he's been busy with other things lately. He said that he intended to come back to the forums at some point though. He hasn't abandoned us or Catalina.
I exchanged email with Ross a few days ago. He's fine but he's been busy with other things lately. He said that he intended to come back to the forums at some point though. He hasn't abandoned us or Catalina.
Thanks David,
Tell him we miss him.
He' probably chomping at the bit to get started on so P2 development.
Thanks David, Publison, and others who have inquired as to my absence ...
I've been busy for the last few months going "off grid". Last year my wife and I purchased the Clyde River Retreat (www.ClydeRiverRetreat.com) - an eco-retreat on the south coast of NSW - and I have been spending the last few months getting it ready to accept guests. For a couple of months there I had neither telephone nor internet, so I was unable to check the forums. There is still a lot of work to do here, so my presence in the forums may still be sporadic for a while, but the worst of it seems to be over (we just had our first guests staying, and it seemed to go well).
I hope to get back to Catalina sometime soon - perhaps over winter when we expect fewer guests - but in the meantime feel free to post here or send me a message, either via Parallax PM (I have emptied my inbox) or email to Ross@TheVastyDeep.com.
StephanL38 - I included a version of Lua as a demo program for the Catalyst run-time environment because it was easy to do so (and pretty cool!). Lua was written in ANSI C so all I had to do was compile it. However, I have little experience with eLua so I don't know how long it would take to port. My quick googling says that eLua depends on NewLib (which Lua does not) so I think it would not be so easy to support eLua with Catalina. You may be able to do it more easily with GCC.
Ross,
Wondered where you have been. Looks like a nice place to relax!
It is indeed. The Clyde River is very beautiful here, and completely unspoilt. I believe the fishing is good (Australian bass and freshwater crayfish mostly) but I haven't had time to try it yet!
Any forum members who want to pay us a visit would be welcome. We do a special rate for Propeller-heads
Wow, ClydeRiverRetreat, that has to be the best project anyone has ever mentioned here!
As a kid I spent a year in Sydney. That involved spending every weekend fishing and just hanging around in the Blue Mountains. Fantastic, always wanted to get back there.
So, how much do I need to come and stay for a month. Or a year or two....:)
Comments
http://it-ebooks.info/book/1255/
Hi David,
I now have this program compiling in Catalina's new COG mode. I haven't written an optimizer for COG mode yet, so it's probably quite a bit larger than it needs to be - but at least it fits!
How many LONGs does this program take in PropGCC's COG mode?
Ross.
Catalina's overhead will probably always be slightly higher than PropGCC, since Catalina implements everything in the cog.
Currently Catalina's size for this program is well over 300 longs, but based on previous experience, I expect even fairly simple optimizations will be able to bring the size of this program down under 300 longs, so it should be quite comparable with PropGCC, which seems to be 256-290 (depending on optimization level).
Ross.
Do Catalina (lcc) necessarily need a stack ?
Could the register count made be flexible instead of a stack ?
Is a stack in cog not difficult to make ? Is it then really faster than a stack in HUB ?
Does this mean that a structure mailbox like in the i2c example is not possible ?
Would be very bad !!!
So I need a separate project for every cog programm/driver ?
How do I then test/debug this ?
Ross.
Than it is maybe better to have one or two registers more, if lcc can make use of it !?
Sorry, I think, I don't understand.
In gcc I use addressinpar->bytevariable1, addressinpar->wordvariable3, addressinpar->longvariable4 ....
The compiler calculates the address of the structure members at compile time.
In catalina I would have to calculate the address myself? Do I know how the structure is packed/padded?
Or miss I something here ?
I think we're talking past each other. If I want a COG mode module I have to compile it separate to my project, right? In propGCC the cogmode file has the extension .cogc, so the compiler knows that this file has to be compiled in COG mode, while the other files are lmm or something else. But I have things together, so I can 'feed' my COG module with data, to look wether it works. If not, I can change things very easy/fast.
I don't like this extension thing. In my opinion a C-File has to have the extension .c, so every editor/tool do 'syntax highlighting'. But 'decoration' ("section COG" or something like that) in the file you don't want! So I will have a project where I compile my driver and hopefully can put that file/binary/plugin in my main project somehow automated.
Make this to 'I will look at and try very hard to adding...' and you will be the hero ;-). Because this then will be the first real IDE for the propeller. At least what I call an IDE.
Thank you for your time to discussing this ?
No worries!
Ross.
This confusion between the compiler and the editor/IDE is an aberration propagated by MS and co. for many years.
I'm hoping that now as MS is on the way out and other systems get a look in understanding will return to normal.
With PropGCC I make a pointer to my self defined structure, table, a single long, whatever... The header file for my COG module tells the other part how to use. That's how it is elsewhere in the world.
I searched for registry in the manual and I read something of 8 longs, plugins and targets, but I can say, that I not really understood what the registry should be and how I should use it.
What I understood from you in this thread (a few posts back) is: You want no "decorations", because this is not C and you then can not compile this with another compiler. Now I should use a registry, because then.... what?
At this point I am somehow frustrated, again.
I will wait an see how things come out.
What other systems ? What is normal ? You mean not this fu***** thing where I have to use a shell and type in some funny things to get where I not wanted to be.
Yes, I mean exactly "this fu***** thing where I have to use a shell and type in some funny things to get where I not wanted to be."
When I want to communicate with you, like here and now, that is exactly what I do. I don't point and click on your buttons and, God forbid, I don't mess with your touch interface.
No, I have to know your language and syntax and grammar and even your local weird dialects or cultural references.
Why should communing with a computer, especially if one is programming it, be any different?
Admittedly C and it's libraries and it's headers and Makefiles and all that nonsense makes things a bit awkward and that is a problem IDEs tried to simplify. They try to make "type code and go" easier.
That's great until you want to use a different IDE on a different machine or OS. Or perhaps you just want to use your favourite editor.
With Catalina, you also have the option of using Code::Blocks - a professional grade IDE, and perhaps the best one around for C/C++, since it was designed from the ground up specifically for these languages.
Personally, I find that once you know how to program and are familiar with the language, all an IDE does is just slow you down and get in the way. However, I realize that we are all different, which is why Catalina also supports Code::Blocks.
Ross.
This may be because you seem to be looking for something complicated, and Catalina is deliberately not complicated - not at the C level. Many users will never need to use the registry directly at all. For instance, if you want to use a VGA text driver with PropGCC you need to do some special preparation in your C program, and then also use special functions to access it. And of course, having done that, your program is then not much use if you later decide you want to use some other display driver (here is a recent thread on just this subject).
With Catalina you just tell your program (usually at compile time, although in some cases you can even defer this to load-time or even run-time) that you want to use a VGA display, and your C program just works. The same C program can also use a TV display, a PC terminal emulator or a simple serial port.
All this is accomplished via the registry, which means you don't need to worry about it in your C program. Even if your needs outgrow the basic drivers and other plugins Catalina provides and you want to start writing your own drivers or plugins, then that is also much easier with Catalina - precisely because it makes all the standard registry infrastructure available for you to use, which means you don't have to redevelop it every time.
Ross.
The simpletext philosophy is minimalist for common text IO functions. Device specific functions were encouraged because they allow better control of devices.
It's ok to have such differences of opinion of what is good - everybody has opinions.
The simple libraries offer Spin-like device startup and control over interfaces. There is nothing going on in the background like your mailboxes as requested by Parallax education ... I've tried to convince them that the mailboxes that you use have value because it allows a second stage loader, but I keep getting shot down.
Everything in the Parallax Propeller C simple libraries were written, specified, and/or included there by Parallax. It is their product. I just help whenever they ask.
Your thread just happens to provide a handy "current" example to point to. There are lots of others. Real-time clock? Catalina supports several implementations. SD Card drivers? Catalina supports multiple ones of those as well. Are you seriously proposing we should have a separate interface to each different variant of hardware, all implemented at the C level? What a nightmare that would be!
As to the utility of having "mailbox" functions - well, Catalina's registry is really too simple to be called a "mailbox", but I understand what you mean. But mailboxes (or whatever you want to call them) are such a mind-bogglingly useful concept that I would claim that is really Parallax who is out of step here. In practice we all use mailboxes - PropGCC does, Catalina does, many Spin programs do, and David Betz does (in his Spin to C/C++ "spinwrap" wrapper). The main difference is that Catalina predefines them, whereas with other languages/compilers you have to define them yourself.
But if Parallax doesn't want them in their educational compiler (forcing everyone to re-invent them for themselves when they eventually discover they need them) then so be it. I guess you can validly claim that this approach is "educational". I would use a different word for it.
Ross.
No. There is a header where I can see what's in the mailbox. I include the header and use the mailbox. And if I wrote the code myself, I know exactly how to use it.
But maybe I don't understand what you want to tell me.
Therefor you have to understand, how the things work, and you have to adjust your things to something, what you maybe not want.
Maybe there once comes the moment, when I understand the registry. For now catalina is too much an OS instead of a compiler for me.
Actually, Catalina provides what one needs to provide in order to claim to be ANSI C compliant - not less, and not much more.
Of course, if you don't want all those features, then by all means don't use them - there is very little overhead if you don't use them (8 longs). But they are there for you if and when you do.
Ross.
I tried to send you a private message but your inbox is full. So I feel free to ask it in this thread here:
Heater pointed me towards your c-compiler Catalina and mentioned Lua.
If I understand right you used Lua to support your compiler not to run a Lua-interpreter on the propeller-chip itself.
Anyway would it be possible to compile Lua to run inside a propeller-chip?
Especially the eLua-sourcecode for microcontrollers which has modules for onewire, I2C, SPI Uart, etc?
How much space would be left for the callstack of Lua? (if the result is negative would it be possible to run Lua in LMM or XMM-mode?
Lately Ken Gracey was asking for python on a propeller-chip. From the answers I guess python is too big.
But how about eLua? To me it seems small enough. And could be a useful alternative for teachers (who asked for python)
How much effort would it be to compile the eLua sourcecode for a propellerchip?
Two to three hours? Seven to eight months? I have no idea.
Would this be an interesting project to you? Could you answer with a rough estimation of the time it would take?
https://github.com/elua
best regards
Stefan
Google is you friend. In a trice I find this :
As a general rule, for a 32-bit CPU, we recommend at least 256k of Flash and at least 64k of RAM. However, this isn't a strict requirement. A stripped down, integer-only version of eLua can definitely fit in 128k of Flash and depending on your type of application, 32k of RAM might prove just fine. We have built eLua for targets with less than 10K RAM but you can't do much than blinking an LED with them. It really largely depends on your needs.
From the FAQ.
Tell him we miss him.
He' probably chomping at the bit to get started on so P2 development.
I've been busy for the last few months going "off grid". Last year my wife and I purchased the Clyde River Retreat (www.ClydeRiverRetreat.com) - an eco-retreat on the south coast of NSW - and I have been spending the last few months getting it ready to accept guests. For a couple of months there I had neither telephone nor internet, so I was unable to check the forums. There is still a lot of work to do here, so my presence in the forums may still be sporadic for a while, but the worst of it seems to be over (we just had our first guests staying, and it seemed to go well).
I hope to get back to Catalina sometime soon - perhaps over winter when we expect fewer guests - but in the meantime feel free to post here or send me a message, either via Parallax PM (I have emptied my inbox) or email to Ross@TheVastyDeep.com.
StephanL38 - I included a version of Lua as a demo program for the Catalyst run-time environment because it was easy to do so (and pretty cool!). Lua was written in ANSI C so all I had to do was compile it. However, I have little experience with eLua so I don't know how long it would take to port. My quick googling says that eLua depends on NewLib (which Lua does not) so I think it would not be so easy to support eLua with Catalina. You may be able to do it more easily with GCC.
Ross.
Wondered where you have been. Looks like a nice place to relax!
It is indeed. The Clyde River is very beautiful here, and completely unspoilt. I believe the fishing is good (Australian bass and freshwater crayfish mostly) but I haven't had time to try it yet!
Any forum members who want to pay us a visit would be welcome. We do a special rate for Propeller-heads
Ross.
Good to hear form you.
Wow, ClydeRiverRetreat, that has to be the best project anyone has ever mentioned here!
As a kid I spent a year in Sydney. That involved spending every weekend fishing and just hanging around in the Blue Mountains. Fantastic, always wanted to get back there.
So, how much do I need to come and stay for a month. Or a year or two....:)