From the steps you describe, it seems at least some of the problems are to do with the need to circumvent your security software, not with either Catalina or Windows. I use Microsoft Security Essentials and don't need to do most of these steps, even for a non-admin user. Unfortunately, it's hard to predict or advise people what they may need to do to get around their antivirus software, since every package will have a different idea about what constitutes a security violation (Microsoft's own seems to be fine with Catalina - you can read ino that what you will ).
Blame the Codeblocks installer, not Windows ;-) But, seriously, this is a workaround
and documented to the letter, so anybody can make it work. It took a coupla days
to get here.
And I appreciate your persistence. Yes, Code::Blocks seems to have a few issues when you attempt to install it in a multi-user environment. I'll look into them in the next release, and also document the necessary workarounds.
The security software workarounds are just little details I'm documenting
so people can get from A to B. The other things are more significant. Yes,
they seem to be due to Codeblocks assuming that people just install and
run as root, so the whole drive is fair game for write permissions, which is
more than just a little installer quirk.
I use Comodo, which notices cowboy stuff and calls it out. Up to the user
whether they want to let it proceed. They also offer a sandbox mode, which
is quite useful, though in a case like this, we wouldn't get too far if we
sandboxed the installer or Catalina at run time ;-) Anyway, I'm very happy
to have a working C compiler. Thanks! Now ...
Questions: since I don't yet have a full grasp of how memory is used,
and frankly I've been working with so many environments it's all getting
squonshed together in me little bran, can you give me an idea of how
much we have available to a C proggie, how a typical SPIN program that's
2k relates to the total available, how big an assembly program can be
(2048 bytes to fit in COG RAM? ) and then how does a C program that
Catalina produces as a 4k or 24k .binary file relates to this? Is it
compiled as pure machine code? Where on earth does it get executed?
What sort of debug facilities do we have with Catalina, and how do I
access them? Is there some sort of object that I can include to be able
to examine all of memory and I/O over a terminal link?
I realize I could likely dig through the docs and find some answers, but
take mercy, masked man, I was looking yesterday for a file in the Propeller
directory, only to remember it was an Arduino project, then I was
wondering why I couldn't upload to RAM any longer, before I remembered
that the ATmega328p only has EEPROM executable space, and later
that day I was looking for a C++ Builder file in the ViewPort directory ;-)
What's even funnier, I've been moving hardware between the Quickstart
board and an Arduino Uno, using a Ping module, a bunch of resistors
plugged into connectors and solderlessly twisted together and LEDs doing
similar things, and I look at the board and it takes me a moment to remember
which is which.
The security software workarounds are just little details I'm documenting
so people can get from A to B. The other things are more significant. Yes,
they seem to be due to Codeblocks assuming that people just install and
run as root, so the whole drive is fair game for write permissions, which is
more than just a little installer quirk.
I use Comodo, which notices cowboy stuff and calls it out. Up to the user
whether they want to let it proceed. They also offer a sandbox mode, which
is quite useful, though in a case like this, we wouldn't get too far if we
sandboxed the installer or Catalina at run time ;-) Anyway, I'm very happy
to have a working C compiler. Thanks! Now ...
Let me know of anything you find. Everything is fixable with enough time and effort
Questions: since I don't yet have a full grasp of how memory is used,
and frankly I've been working with so many environments it's all getting
squonshed together in me little bran, can you give me an idea of how
much we have available to a C proggie, how a typical SPIN program that's
2k relates to the total available, how big an assembly program can be
(2048 bytes to fit in COG RAM? ) and then how does a C program that
Catalina produces as a 4k or 24k .binary file relates to this? Is it
compiled as pure machine code? Where on earth does it get executed?
This is a big topic. Here are the highlights:
1. Catalina programs are compiled to LMM PASM, which is the same as the Propellers native (cog) PASM except that certain instructions are replaced by "primitives" - which are just jump instructions into special entry points within the LMM kernel (see 2, below). Generally these are any jump, call and return instructions - i.e. anything that has to refer to an address, since native cog PASM only knows about cog addresses, but LMM PASM has to use Hub addresses.
2. LMM PASM is executed by first loading in an LMM kernel - which has a simple instruction execution loop that fetches each instruction in turn from Hub RAM into cog RAM, then executes the instruction, then fetches the next instruction - etc,etc. The cost of this is that LMM PASM programs run about 1/4 the speed of native cog PASM programs - but the benefit is that they are not limited to 496 instructions. Essentially, the LMM kernel takes the place of the Spin interpreter.
3. On the Prop v1, LMM PASM programs can be up to 32k, since they are executed from Hub RAM, not cog RAM. But 2k is required for the kernel, and with Catalina around 512 bytes are reserved for the Registry (and some other stuff) so essentially you are limited to around 29.5k code size unless you use a special 2-phase loader. With use a 2 phase loader it is possible to get over 31k for program code (i.e. 32k less whatever transfer buffer size you decide to use, less the registry). When loading from SD card, it is convenient to use a 512k buffer size, so I generally say you can run LMM programs of around 31k.
Search the forums for the posts on Bill Henning's original LMM concept.
What sort of debug facilities do we have with Catalina, and how do I
access them? Is there some sort of object that I can include to be able
to examine all of memory and I/O over a terminal link?
Catalina has complete source-level debugger capabilities, as well as an assembly level debugger (note you can't use both at once). To use the source level debugger, simply add the -g option to your compile command (-g3 for full debug information). The source level debugger comes in two flavors - BlackCat was developed by Bob Anderson and is a complete graphical debugger that will be familiar in general operation to Windows users (it runs on Windows only), and BlackBox is a command line version that will be generally familiar to Linux users who have used a source level debugger such as GDB (it runs on Windows and Linux).
I realize I could likely dig through the docs and find some answers, but
take mercy, masked man, I was looking yesterday for a file in the Propeller
directory, only to remember it was an Arduino project, then I was
wondering why I couldn't upload to RAM any longer, before I remembered
that the ATmega328p only has EEPROM executable space, and later
that day I was looking for a C++ Builder file in the ViewPort directory ;-)
What's even funnier, I've been moving hardware between the Quickstart
board and an Arduino Uno, using a Ping module, a bunch of resistors
plugged into connectors and solderlessly twisted together and LEDs doing
similar things, and I look at the board and it takes me a moment to remember
which is which.
I understand perfectly. Context switch time is a function of age - my context switch time is now measured in days.
Just to add a bit to Ross's explanation...
For larger programs we move to XMM (external memory LMM model). There are various solutions for XMM using serial SRAM/Flash/EEPROM or bytewide SRAM in latched or non-latched designs. The Catalina writeup describes some designs supported. I won't go OT here and describe them as they are in other threads anyway.
Thank you, that's very very helpful. I'll figure the details out in time, but let me just ask: so if I can set a breakpoint, single step and examine memory, how on earth and where is this taking place? Is it really looking at the memory in the prop, or some virtual shadow?
Ok, if the C code runs at 1/4 assembly speed, how fast is SPIN, say for simple things like moving variables around, testing for zero, taking a conditional branch, you know, like garden variety yadda yadda with IF statements?
I dare say I don't like languages that lack terminators like braces or semicolons. It's too easy to have or introduce invisible errors, just an inadvertent touch on the SPACE bar. I wasted a couple hours before I realized my SPIN program was failing over the indentation of my conditionals. Why would anyone design a language that way, if the tokenizer has to count spaces, why not require a terminator instead?
I think we are looking at 80 odd PASM instructions per Spin byte code. Best thing is to knock up a simple routine to time Spin language features if you are really wanting to know. Ultimately you need to time your actual applications code if it is critical as determining timing by counting operations or bytecodes (from a compiler listing) then checking the interpretter sources to see how long that takes for each op is nigh on immpossible.
Don't mention the white space (or lack of it) as block delimeters, that debate goes on for ever.....:)
...so if I can set a breakpoint, single step and examine memory, how on earth and where is this taking place? Is it really looking at the memory in the prop, or some virtual shadow?
Breakpoints are physically inserted directly into the code being executed at run time. The debugger interface runs in another cog, interacting with the LMM kernel as required, and communicating with the debugger program running on the PC.
Bob Anderson did most of this work and it is a truly amazing achievement - all I did was help out with the compiler side and the kernel interaction, and then add a command line front-end (so non-Windows users would be able to debug as well).
Ok, if the C code runs at 1/4 assembly speed, how fast is SPIN, say for simple things like moving variables around, testing for zero, taking a conditional branch, you know, like garden variety yadda yadda with IF statements?
Spin is something like 10 to 20 times slower than LMM PASM, and something like 40 to 80 times slower than cog PASM - as Heater points out, it depends very much on the code being executed.
Spin's great attraction is its compact code size, not it's execution speed.
I dare say I don't like languages that lack terminators like braces or semicolons. It's too easy to have or introduce invisible errors, just an inadvertent touch on the SPACE bar. I wasted a couple hours before I realized my SPIN program was failing over the indentation of my conditionals. Why would anyone design a language that way, if the tokenizer has to count spaces, why not require a terminator instead?
Take Heater's advice - don't mention the "indented vs non-indented" Language War in these forums. (I mentioned it once, but I think I got away with it!).
Take Heater's advice - don't mention the "indented vs non-indented" Language War in these forums. (I mentioned it once, but I think I got away with it!).
Ross.
Thanks, Ross, & Heater!
p.s. Oh, dear. Ok, WHAT indented language? Was it Pie-thon? ;-) Are there any FORTH users here? Having once written a FORTH-like language for machine control that used the stack return (NEXT) for a multi-tasking scheduler, I can't even look at that syntax now without feeling ill.
I have been trying unsuccessfully to get the Catalina_SIO_Plugin to work. I understand the concept of driving it via the I/O block but apparently I don't seem to be using the correct code to get the address of the I/O block from the C environment. Can somebody help?
I have been trying unsuccessfully to get the Catalina_SIO_Plugin to work. I understand the concept of driving it via the I/O block but apparently I don't seem to be using the correct code to get the address of the I/O block from the C environment. Can somebody help?
Hi Strelnikov
The Catalina_SIO_Plugin is not directly accessible from C - it is used internally by various loaders, and also by the various "proxy" HMI options intended for use in multi-CPU systems.
Adding the ability to have multiple serial ports on my "to do" list - but so far no-one has needed this. For most applications a single serial port is sufficient - and this can be trivially accomplished by using the PC HMI option - this option gives you a single serial port at 115200 baud on pins 30 & 31 (the pins and the baud rate can be changed by editing the files PC_Text.spin and PC_Keyboard.spin in the Catalina\target directory).
This makes a single serial comms port trivially accessible from C via stdin and stdout.
Thanks Ross that's what I ended up doing, using the PC HMI option. Works for now for me but at some point I am going to need multiple serial ports.
Hi Strelnikov,
Yes, I will add multiple serial ports capability soon. Technically, this is no problem - I just haven't decided how to represent and access the comm ports from C - traditionally, this involves intercepting specific platform dependent device names (e.g. in Windows you might use COM1 .. COMn while in Linux you would say /dev/ttyxxx) and then using the normal streams functions.
However, I'd prefer to be able to do this without having to pull in all the stream processing functions from stdio - doing so tends to make programs to large to run as an LMM program (they would have to become XMM programs) - this seems crazy when having multiple serial ports is so easy on the Propeller!
I'll do some thinking on this issue on the weekend.
I'm playing around with some nifty touchscreen displays, and like before, the 32k memory limit of the propeller has bitten me again! So it is time to port the code over to XMM Catalina.
I have this problem with the download speed. Even at 115200 baud (ha, remember 300 baud modems, they were state of the art once!), it is still taking 2-3 minutes for a decent download.
So I have this idea that you download the program to an SD card at USB speeds. I did some testing with some vb.net code and it is *much* faster. I can get it to about 12 seconds which includes unplugging the sd card and putting it into the board.
Private Sub CompileCopySDcard()
Dim filename1 As String
Dim filename_noextension As String
Dim BytesToRead As Integer
Dim c As String
Dim LineOfText As String
CompilePause = False ' assumes program has been debugged
Compile_C() ' compile the program
filename1 = CatalinaFile
filename_noextension = Strings.Left(filename1, Len(filename1) - 2)
Try
FileCopy("C:\Program Files\Catalina\Demos\" + filename_noextension + ".binary", SDdrive + ":\" + filename_noextension + ".bin")
MsgBox("Remove SD card and move to board. Click OK when done", vbOKOnly)
ResetPropeller() ' boot back into kyedos
Sleep(3000) ' wait for kyedos to start
SerialPortName.BaudRate = Baud ' reopen at 115200 or whatever the default rate is
SerialPortName.Open()
Call ClearInputBuffer() ' clear the buffer into the PC
Call StringToPacket("catlyst2" + vbCr) ' run the serial version of catalyst setup for 38400 baud
SerialPortName.Close()
SerialPortName.BaudRate = 38400 ' catlyst2 talks at 38400 baud
SerialPortName.Open()
Do
BytesToRead = SerialPortName.BytesToRead
SerialPortName.Read(InPacket, 0, BytesToRead) ' read in a packet
For i = 1 To BytesToRead
c = Strings.Chr(InPacket(i - 1))
'If Strings.Asc(c) > 32 Then Label1.Text += c
If c = ">" Then
'MsgBox("prompt")
Exit Do ' prompt has come in so exit - this will hang if catalyst doesn't work so maybe put a counter here
End If
Next i
Loop
' run the program
LineOfText = UCase(filename_noextension) + vbCr ' and run the program
Call StringToPacket(LineOfText) ' talk to catalyst and run this program
SerialPortName.Close()
Catch ex As Exception
'MsgBox("Error - run from vb.net without the error trace to find which error")
End Try
End Sub
And I think I can get it faster again if either Kyedos or Catalyst is recoded to specifically support this mode of running programs.
And even faster with some hardware modifications.
So at the moment, for 12 secs, compile the program (maybe 2-3 secs), copy to an SD card (microseconds) then a prompt to move the sd card to the physical board (2-3 secs), then reboot the propeller into Kyedos, and then run catalyst in serial port mode (all up about 6 seconds) and then tell catalyst to run the program (takes a couple of seconds to run).
Of course this can be improved if catalyst is the default program in the eeprom, not kyedos. There are some *very good arguments* for making this so, for repeated reprogramming and testing.
But I think it can be even faster. Consider a hypothetical program that is able to switch between an SD card connected to a PC (via one of those $1 adapters) and the propeller. At the simplest level it is a 5PDT relay (CS DI DO CLK and switch the supply. Common ground). I think with some smarts it can be done with an electronic circuit. Possibly the supply does not need switching but that does assume the supply is always on. You boot into this program (Kyedos, catalyst or whatever) and it opens a serial link, and at the appropriate time you send a command to switch the SD card, and then switch it back. It would be two USB cables connected to the PC. One is a USB to FT232 cable and the other is a USB to SD card adapter.
For the hardware side there are several possibilities. The first is to put a relay or electronic switching circuit on a board and to leave a space for the USB to SD card adapter. I think this will work, but it will need a custom board.
The other idea only came to me just tonight, and I had this idea while looking at a micro SD to standard SD adapter. Why not pull this apart and solder 9 wires to the inside of the socket and bring these out to a 2x5 header? 4 data. 2 supply.Oh and you need a dedicated pin from the propeller too. So 1 = propeller control to select which device is talking to the SD card. Then you have a separate board which might have a relay on it, and the USB to SD card adapter. Or it might be a switch.
I know this might sound a little crazy, but sooner or later, if the propeller is going to realise its full potential (and I sincerely believe it can) doing things like running html scripts with Pacman in html, and browsing the internet, these sorts of programs are going to be large. They are not going to fit in 32k. But having looked at C code on the internet, I think the code exists. It is just a matter of being able to write and debug it without having to wait an eternity for downloads.
All very clever BUT - it is running out of code space. So Catalina is the answer I know will solve this problem.
So a simple question first. Is catalyst something that can be modified easily for "USB" downloads? Can we tweak it so it has some custom code (via a pin, or via a latch) that can select an SD card input?
Do we think outside the square here and try to port the USB driver code that some clever boffins have written and talk directly to the USB port? @ what speeds cf talking to an SD card reader?
Drac: A little off-topic here, but...
You are into VB. I have a VB6 skeleton that should work for file transfers (an extension to the cpm<->fat file transfer program). My problem was accessing the higher comms ports on my various propplugs and then I ran out of time. The method I have chosen for the fat<->pc is Michael Parks Sphinx because its simple and easy. Are you interested in completing this?
Then you could run a kyedos type program to do the transfer (I have this part).
Ross:
As soon as I can come up for air I shall discuss the loading with you. There is definately a problem that is making Catalina extremely slow in the downloading. The time is in preparing the download rather that the actual download itself.
So a simple question first. Is catalyst something that can be modified easily for "USB" downloads? Can we tweak it so it has some custom code (via a pin, or via a latch) that can select an SD card input?
Yes - Catalyst is just normal Spin program, not a Catalina program. It uses a version of Kye's FATEngine to access the SD card to load programs, but could use anything else. It also uses some of the Catalina plugins, but these are also just normal Spin/PASM programs.
Ah. Excellent news. Well I think I can tweak the code so it accepts downloads from a USB to parallel device. Under $6 on ebay - I have just ordered one (I already have one but it has a centronics plug, and I think a D25 is going to be easier so I got a D25 one). Dump the data either to ram or to the SD card. Back to coding...
So to use Catalina i would open an editor of my choice, write some 'C' source code, go to a command prompt window and run the compiler, check for errors and do the edit compile loop, and then how do i down load the code to the prop?
@richaj45 - it can be simpler than that. See the screenshot below - one keypress downloads. This IDE is my own code and is experimental, but Code::blocks works in a similar way.
@Ross, I'm working on getting the touchscreen working in C. First thing is the downloads and I have an xmodem download working now. This puts the file on the SD card. Other programs like catalyst can run it.
[video=youtube_share;UJKapLxYK-U]
Some technical questions:
To print "Hello World" on the touchscreen will need some sort of graphics drivers. I have been experimenting with several ranging from 20 column to 80 column. The graphics driver for xmodem is fairly basic - when it gets to the bottom of the screen (not shown on the video) it clears the screen and moves the display to the top. I have some better ones that are the beginning of vt100 which scroll the screen. Scrolling is a bit slower though, because unlike TV and VGA where you just move things into hub ram and the graphics driver displays them straight away, scrolling an ILI9325 display takes a bit of time. So if lots of characters are coming in, it may be better to group them and scroll them in groups of 10, or whenever a certain amount of time has elapsed.
Also it would be helpful to have some graphics drivers too.
These are actually very simple and there are only two commands. One is to set a draw screen (x1,y1,x2,y2). And the other is to send out a pixel.
But to speed things up, pixels can be sent in groups, eg Send n pixels from hub location x. Or send n pixels from external ram location x.
In C, you would define an array to use external memory, and it could be handled from within C.
I've got all the code working in spin and pasm to do all the transfers. Font handling could be done in C or Spin.
What I am not sure about is how much to code in 'visible' vs 'invisible' C. For instance, "printf" calls graphics driving code behind the scenes and this is 'invisible' code. But it could just as easily be visible C code that loads fonts into memory and sends out the pixel data.
Maybe one could have a basic 40 column display (8 pixels wide) for printf, and other code for custom font sizes?
At a very simple level, what I am wondering about is adding a few C handles to link to code already written. For instance, I believe you have a function
_coginit()
and so in a similar way you could have a function _hubtodisplay(address,number)
What are your thoughts on getting Catalina running on this display?
I am looking for some example code written in Catalina C.
May some code showing how to use a async serial driver (RS232), an SPI driver, and a parallel LCD driver.
There does not appear to be Catalina code in the object exchange.
Any help getting me started with Catalina would be appreciated.
Download from the website (see first post). There is a huge amount of pdf documents when you install Catalina including lots of examples. See the demo subdirectory.
Ross, quick question for you... I'm working on a couple SSD1963 display controller solutions and wonder if I can use the excess RAM for running C programs...
The SSD1963 has 1,000 kB of RAM but a 4.3" display only needs about 400 kB for a single display buffer. That leaves 600 kB that could be used for other things...
To access anywhere in RAM, you just send about 12 bytes to tell it where you want to read or write from. Then, just toggle the read or write strobe to get or set
data on the data bus.
The data bus can be 8, 16, or 24 bits wide, but I think for the Prop, 8 or 16 bit data bus makes the most sense.
Anyway, the SSD1963 will continue to show image from the display buffer while you read or write program memory, so it's pretty non-invasive.
You just can't update the screen and read/write program memory at the same time...
Ray,
What agreat idea, display and RAM in the same package using the same pins. How many free pins does that leave the Prop?
Now, how to multiplex execution/data access with display up dates.
Is it so that a common cache driver can be used for both?
I'm working on various designs trying to optimise use of propeller pins and at the moment a 16 bit bus looks more efficient than an 8 bit bus. If you use the caching in Catalina, then those pins would be free for other things a lot of the time.
You could maybe cache outputs to the screen as well so that memory accesses are grouped together.
Sorry for the absence - my computer trashed itself recently (thanks heaps, Micro$oft!) and I'm still in the process of rebuilding it. Also, I was relying on getting notified by email when people post in my threads, but the forum software doesn't seem to be generating them any more :frown:.
Comments
What software do you use?
Ross.
And I appreciate your persistence. Yes, Code::Blocks seems to have a few issues when you attempt to install it in a multi-user environment. I'll look into them in the next release, and also document the necessary workarounds.
Ross.
The security software workarounds are just little details I'm documenting
so people can get from A to B. The other things are more significant. Yes,
they seem to be due to Codeblocks assuming that people just install and
run as root, so the whole drive is fair game for write permissions, which is
more than just a little installer quirk.
I use Comodo, which notices cowboy stuff and calls it out. Up to the user
whether they want to let it proceed. They also offer a sandbox mode, which
is quite useful, though in a case like this, we wouldn't get too far if we
sandboxed the installer or Catalina at run time ;-) Anyway, I'm very happy
to have a working C compiler. Thanks! Now ...
Questions: since I don't yet have a full grasp of how memory is used,
and frankly I've been working with so many environments it's all getting
squonshed together in me little bran, can you give me an idea of how
much we have available to a C proggie, how a typical SPIN program that's
2k relates to the total available, how big an assembly program can be
(2048 bytes to fit in COG RAM? ) and then how does a C program that
Catalina produces as a 4k or 24k .binary file relates to this? Is it
compiled as pure machine code? Where on earth does it get executed?
What sort of debug facilities do we have with Catalina, and how do I
access them? Is there some sort of object that I can include to be able
to examine all of memory and I/O over a terminal link?
I realize I could likely dig through the docs and find some answers, but
take mercy, masked man, I was looking yesterday for a file in the Propeller
directory, only to remember it was an Arduino project, then I was
wondering why I couldn't upload to RAM any longer, before I remembered
that the ATmega328p only has EEPROM executable space, and later
that day I was looking for a C++ Builder file in the ViewPort directory ;-)
What's even funnier, I've been moving hardware between the Quickstart
board and an Arduino Uno, using a Ping module, a bunch of resistors
plugged into connectors and solderlessly twisted together and LEDs doing
similar things, and I look at the board and it takes me a moment to remember
which is which.
1. Catalina programs are compiled to LMM PASM, which is the same as the Propellers native (cog) PASM except that certain instructions are replaced by "primitives" - which are just jump instructions into special entry points within the LMM kernel (see 2, below). Generally these are any jump, call and return instructions - i.e. anything that has to refer to an address, since native cog PASM only knows about cog addresses, but LMM PASM has to use Hub addresses.
2. LMM PASM is executed by first loading in an LMM kernel - which has a simple instruction execution loop that fetches each instruction in turn from Hub RAM into cog RAM, then executes the instruction, then fetches the next instruction - etc,etc. The cost of this is that LMM PASM programs run about 1/4 the speed of native cog PASM programs - but the benefit is that they are not limited to 496 instructions. Essentially, the LMM kernel takes the place of the Spin interpreter.
3. On the Prop v1, LMM PASM programs can be up to 32k, since they are executed from Hub RAM, not cog RAM. But 2k is required for the kernel, and with Catalina around 512 bytes are reserved for the Registry (and some other stuff) so essentially you are limited to around 29.5k code size unless you use a special 2-phase loader. With use a 2 phase loader it is possible to get over 31k for program code (i.e. 32k less whatever transfer buffer size you decide to use, less the registry). When loading from SD card, it is convenient to use a 512k buffer size, so I generally say you can run LMM programs of around 31k.
Search the forums for the posts on Bill Henning's original LMM concept.
Catalina has complete source-level debugger capabilities, as well as an assembly level debugger (note you can't use both at once). To use the source level debugger, simply add the -g option to your compile command (-g3 for full debug information). The source level debugger comes in two flavors - BlackCat was developed by Bob Anderson and is a complete graphical debugger that will be familiar in general operation to Windows users (it runs on Windows only), and BlackBox is a command line version that will be generally familiar to Linux users who have used a source level debugger such as GDB (it runs on Windows and Linux).
I understand perfectly. Context switch time is a function of age - my context switch time is now measured in days.
Ross.
For larger programs we move to XMM (external memory LMM model). There are various solutions for XMM using serial SRAM/Flash/EEPROM or bytewide SRAM in latched or non-latched designs. The Catalina writeup describes some designs supported. I won't go OT here and describe them as they are in other threads anyway.
Ok, if the C code runs at 1/4 assembly speed, how fast is SPIN, say for simple things like moving variables around, testing for zero, taking a conditional branch, you know, like garden variety yadda yadda with IF statements?
I dare say I don't like languages that lack terminators like braces or semicolons. It's too easy to have or introduce invisible errors, just an inadvertent touch on the SPACE bar. I wasted a couple hours before I realized my SPIN program was failing over the indentation of my conditionals. Why would anyone design a language that way, if the tokenizer has to count spaces, why not require a terminator instead?
Don't mention the white space (or lack of it) as block delimeters, that debate goes on for ever.....:)
Bob Anderson did most of this work and it is a truly amazing achievement - all I did was help out with the compiler side and the kernel interaction, and then add a command line front-end (so non-Windows users would be able to debug as well). Spin is something like 10 to 20 times slower than LMM PASM, and something like 40 to 80 times slower than cog PASM - as Heater points out, it depends very much on the code being executed.
Spin's great attraction is its compact code size, not it's execution speed.
Take Heater's advice - don't mention the "indented vs non-indented" Language War in these forums. (I mentioned it once, but I think I got away with it!).
Ross.
Thanks, Ross, & Heater!
p.s. Oh, dear. Ok, WHAT indented language? Was it Pie-thon? ;-) Are there any FORTH users here? Having once written a FORTH-like language for machine control that used the stack return (NEXT) for a multi-tasking scheduler, I can't even look at that syntax now without feeling ill.
THAT bad. eh? It's like treading on dinosaur eggs around here!
Hi Strelnikov
The Catalina_SIO_Plugin is not directly accessible from C - it is used internally by various loaders, and also by the various "proxy" HMI options intended for use in multi-CPU systems.
Adding the ability to have multiple serial ports on my "to do" list - but so far no-one has needed this. For most applications a single serial port is sufficient - and this can be trivially accomplished by using the PC HMI option - this option gives you a single serial port at 115200 baud on pins 30 & 31 (the pins and the baud rate can be changed by editing the files PC_Text.spin and PC_Keyboard.spin in the Catalina\target directory).
This makes a single serial comms port trivially accessible from C via stdin and stdout.
Ross.
Hi Strelnikov,
Yes, I will add multiple serial ports capability soon. Technically, this is no problem - I just haven't decided how to represent and access the comm ports from C - traditionally, this involves intercepting specific platform dependent device names (e.g. in Windows you might use COM1 .. COMn while in Linux you would say /dev/ttyxxx) and then using the normal streams functions.
However, I'd prefer to be able to do this without having to pull in all the stream processing functions from stdio - doing so tends to make programs to large to run as an LMM program (they would have to become XMM programs) - this seems crazy when having multiple serial ports is so easy on the Propeller!
I'll do some thinking on this issue on the weekend.
Ross.
I'm playing around with some nifty touchscreen displays, and like before, the 32k memory limit of the propeller has bitten me again! So it is time to port the code over to XMM Catalina.
I have this problem with the download speed. Even at 115200 baud (ha, remember 300 baud modems, they were state of the art once!), it is still taking 2-3 minutes for a decent download.
So I have this idea that you download the program to an SD card at USB speeds. I did some testing with some vb.net code and it is *much* faster. I can get it to about 12 seconds which includes unplugging the sd card and putting it into the board.
Private Sub CompileCopySDcard() Dim filename1 As String Dim filename_noextension As String Dim BytesToRead As Integer Dim c As String Dim LineOfText As String CompilePause = False ' assumes program has been debugged Compile_C() ' compile the program filename1 = CatalinaFile filename_noextension = Strings.Left(filename1, Len(filename1) - 2) Try FileCopy("C:\Program Files\Catalina\Demos\" + filename_noextension + ".binary", SDdrive + ":\" + filename_noextension + ".bin") MsgBox("Remove SD card and move to board. Click OK when done", vbOKOnly) ResetPropeller() ' boot back into kyedos Sleep(3000) ' wait for kyedos to start SerialPortName.BaudRate = Baud ' reopen at 115200 or whatever the default rate is SerialPortName.Open() Call ClearInputBuffer() ' clear the buffer into the PC Call StringToPacket("catlyst2" + vbCr) ' run the serial version of catalyst setup for 38400 baud SerialPortName.Close() SerialPortName.BaudRate = 38400 ' catlyst2 talks at 38400 baud SerialPortName.Open() Do BytesToRead = SerialPortName.BytesToRead SerialPortName.Read(InPacket, 0, BytesToRead) ' read in a packet For i = 1 To BytesToRead c = Strings.Chr(InPacket(i - 1)) 'If Strings.Asc(c) > 32 Then Label1.Text += c If c = ">" Then 'MsgBox("prompt") Exit Do ' prompt has come in so exit - this will hang if catalyst doesn't work so maybe put a counter here End If Next i Loop ' run the program LineOfText = UCase(filename_noextension) + vbCr ' and run the program Call StringToPacket(LineOfText) ' talk to catalyst and run this program SerialPortName.Close() Catch ex As Exception 'MsgBox("Error - run from vb.net without the error trace to find which error") End Try End SubAnd I think I can get it faster again if either Kyedos or Catalyst is recoded to specifically support this mode of running programs.
And even faster with some hardware modifications.
So at the moment, for 12 secs, compile the program (maybe 2-3 secs), copy to an SD card (microseconds) then a prompt to move the sd card to the physical board (2-3 secs), then reboot the propeller into Kyedos, and then run catalyst in serial port mode (all up about 6 seconds) and then tell catalyst to run the program (takes a couple of seconds to run).
Of course this can be improved if catalyst is the default program in the eeprom, not kyedos. There are some *very good arguments* for making this so, for repeated reprogramming and testing.
But I think it can be even faster. Consider a hypothetical program that is able to switch between an SD card connected to a PC (via one of those $1 adapters) and the propeller. At the simplest level it is a 5PDT relay (CS DI DO CLK and switch the supply. Common ground). I think with some smarts it can be done with an electronic circuit. Possibly the supply does not need switching but that does assume the supply is always on. You boot into this program (Kyedos, catalyst or whatever) and it opens a serial link, and at the appropriate time you send a command to switch the SD card, and then switch it back. It would be two USB cables connected to the PC. One is a USB to FT232 cable and the other is a USB to SD card adapter.
For the hardware side there are several possibilities. The first is to put a relay or electronic switching circuit on a board and to leave a space for the USB to SD card adapter. I think this will work, but it will need a custom board.
The other idea only came to me just tonight, and I had this idea while looking at a micro SD to standard SD adapter. Why not pull this apart and solder 9 wires to the inside of the socket and bring these out to a 2x5 header? 4 data. 2 supply.Oh and you need a dedicated pin from the propeller too. So 1 = propeller control to select which device is talking to the SD card. Then you have a separate board which might have a relay on it, and the USB to SD card adapter. Or it might be a switch.
I know this might sound a little crazy, but sooner or later, if the propeller is going to realise its full potential (and I sincerely believe it can) doing things like running html scripts with Pacman in html, and browsing the internet, these sorts of programs are going to be large. They are not going to fit in 32k. But having looked at C code on the internet, I think the code exists. It is just a matter of being able to write and debug it without having to wait an eternity for downloads.
Just in case you haven't seen this thread http://forums.parallax.com/showthread.php?137266-Propeller-GUI-touchscreen-and-full-color-display
All very clever BUT - it is running out of code space. So Catalina is the answer I know will solve this problem.
So a simple question first. Is catalyst something that can be modified easily for "USB" downloads? Can we tweak it so it has some custom code (via a pin, or via a latch) that can select an SD card input?
Do we think outside the square here and try to port the USB driver code that some clever boffins have written and talk directly to the USB port? @ what speeds cf talking to an SD card reader?
You are into VB. I have a VB6 skeleton that should work for file transfers (an extension to the cpm<->fat file transfer program). My problem was accessing the higher comms ports on my various propplugs and then I ran out of time. The method I have chosen for the fat<->pc is Michael Parks Sphinx because its simple and easy. Are you interested in completing this?
Then you could run a kyedos type program to do the transfer (I have this part).
Ross:
As soon as I can come up for air I shall discuss the loading with you. There is definately a problem that is making Catalina extremely slow in the downloading. The time is in preparing the download rather that the actual download itself.
Yes - Catalyst is just normal Spin program, not a Catalina program. It uses a version of Kye's FATEngine to access the SD card to load programs, but could use anything else. It also uses some of the Catalina plugins, but these are also just normal Spin/PASM programs.
Ross.
Still to sort out a bug on why Catalina will not run on the RamBlade3. But I can go into ZiCog/CPM2.2 and back to Catalyst.
So to use Catalina i would open an editor of my choice, write some 'C' source code, go to a command prompt window and run the compiler, check for errors and do the edit compile loop, and then how do i down load the code to the prop?
Not very modern a tool flow but doable.
Thanks for answers.
rich
@Ross, I'm working on getting the touchscreen working in C. First thing is the downloads and I have an xmodem download working now. This puts the file on the SD card. Other programs like catalyst can run it.
[video=youtube_share;UJKapLxYK-U]
Some technical questions:
To print "Hello World" on the touchscreen will need some sort of graphics drivers. I have been experimenting with several ranging from 20 column to 80 column. The graphics driver for xmodem is fairly basic - when it gets to the bottom of the screen (not shown on the video) it clears the screen and moves the display to the top. I have some better ones that are the beginning of vt100 which scroll the screen. Scrolling is a bit slower though, because unlike TV and VGA where you just move things into hub ram and the graphics driver displays them straight away, scrolling an ILI9325 display takes a bit of time. So if lots of characters are coming in, it may be better to group them and scroll them in groups of 10, or whenever a certain amount of time has elapsed.
Also it would be helpful to have some graphics drivers too.
These are actually very simple and there are only two commands. One is to set a draw screen (x1,y1,x2,y2). And the other is to send out a pixel.
But to speed things up, pixels can be sent in groups, eg Send n pixels from hub location x. Or send n pixels from external ram location x.
In C, you would define an array to use external memory, and it could be handled from within C.
I've got all the code working in spin and pasm to do all the transfers. Font handling could be done in C or Spin.
What I am not sure about is how much to code in 'visible' vs 'invisible' C. For instance, "printf" calls graphics driving code behind the scenes and this is 'invisible' code. But it could just as easily be visible C code that loads fonts into memory and sends out the pixel data.
Maybe one could have a basic 40 column display (8 pixels wide) for printf, and other code for custom font sizes?
At a very simple level, what I am wondering about is adding a few C handles to link to code already written. For instance, I believe you have a function
and so in a similar way you could have a function _hubtodisplay(address,number)
What are your thoughts on getting Catalina running on this display?
I am looking for some example code written in Catalina C.
May some code showing how to use a async serial driver (RS232), an SPI driver, and a parallel LCD driver.
There does not appear to be Catalina code in the object exchange.
Any help getting me started with Catalina would be appreciated.
cheers,
rich
The SSD1963 has 1,000 kB of RAM but a 4.3" display only needs about 400 kB for a single display buffer. That leaves 600 kB that could be used for other things...
To access anywhere in RAM, you just send about 12 bytes to tell it where you want to read or write from. Then, just toggle the read or write strobe to get or set
data on the data bus.
The data bus can be 8, 16, or 24 bits wide, but I think for the Prop, 8 or 16 bit data bus makes the most sense.
Anyway, the SSD1963 will continue to show image from the display buffer while you read or write program memory, so it's pretty non-invasive.
You just can't update the screen and read/write program memory at the same time...
What do you think? Make any sense?
What agreat idea, display and RAM in the same package using the same pins. How many free pins does that leave the Prop?
Now, how to multiplex execution/data access with display up dates.
Is it so that a common cache driver can be used for both?
I'm working on various designs trying to optimise use of propeller pins and at the moment a 16 bit bus looks more efficient than an 8 bit bus. If you use the caching in Catalina, then those pins would be free for other things a lot of the time.
You could maybe cache outputs to the screen as well so that memory accesses are grouped together.
Sorry for the absence - my computer trashed itself recently (thanks heaps, Micro$oft!) and I'm still in the process of rebuilding it. Also, I was relying on getting notified by email when people post in my threads, but the forum software doesn't seem to be generating them any more :frown:.
I will respond to recent posts over the weekend.
Ross.