Does Code:Blocks support breakpoints? I don't see any way to set breakpoints in the editor...
I remember you said small and large debugging isn't ready yet. Could you just turn off caching to allow debugging and just let it run super slow?
Code::Blocks does not support Catalina breakpoints - you need to use the BlackBox or BlackCat debuggers, which are stand-alone programs.
My solution for debugging programs stored in Flash is to actually use the cache to store the breakpoints - i.e. to simulate the debugger writing to what would normally be read-only Flash memory, by instead caching the writes but not writing the dirty pages back to XMM RAM.
The main thing I am not happy about is that I can only store a small number breakpoints that way - I need to make the cache more efficient in the way it stores each breakpoint - it can't simply leave all the pages with breakpoints hanging around in Hub RAM (as it does now) - this simply runs out of space too quickly!
I didn't think a comparison of code size to a PIC24 was meaningful comparison for LMM Propeller code sizes, so I used the only available alternative to try and get a more reasonable one - just to try and emphasize the point that Catalina's code sizes were not excessive (if anything, they are just the opposite!)
Ross.
As I think I've said, I wasn't criticising the quality of Catalina code generation. I was trying to understand loader speeds.
I'm looking at some C code for the Vinculum II right now... I'm a little surprised to see that they never use a semicolon after braces {};
Is this not required in regular C?
I think it is required in all C++, right?
Just curious...
I'm looking at some C code for the Vinculum II right now... I'm a little surprised to see that they never use a semicolon after braces {};
Is this not required in regular C?
I think it is required in all C++, right?
Just curious...
It is never required in C or C++ as far as I know. The semicolon after a closing brace will be parsed as an empty statement and could cause syntax errors in the case of something like this:
if (a == b)
{ printf("a equals b\n"); };
else
{ printf("a does not equal b"\n"); };
In C braces are used to delimit both block structures and type structures (including type initializers). The semicolon in C is a statement terminator, so it is required after each statement, even if that statement ends in a type structure or a type initializer - such as a declaration. It is not required after a block structure - there it would represent an empty statement, so it looks like it is "optional" whereas in fact it should not be there at all.
However, I think C# (and possibly some C/C++ implementations) make the semicolon optional in places where it would be mandatory in "pure" C.
Catalina 3.5 is not ready for release yet, but attached is a preview of the new payload loader that will be included (Windows only executable at this stage).
This new version of payload is significantly faster - it downloads Catalina LMM as well as normal Spin binaries in the same time as the Parallax Propeller Tool (to within a second on my machine). It is also faster downloading Catalina XMM programs.
Just unzip the attached file into your Catalina\bin directory.
One of the things that slows the download process is leaving it to payload to locate the correct port to use each time (it does this by trying them all in turn). For faster speeds, explicitly specify the ports to use (if you don't know the ports, just use payload - once - without specifying any ports, and it will tell you!).
For example, for a Catalina LMM or Spin binary, specify the port to use for the download via -p:
payload -p2 hello_world
or, for an XMM program, specify both the primary and secondary ports to use (on most platforms they are the same) via -p and -s:
payload -p2 -s2 XMM startrek
If anyone has any problems with this version, please let me know!
Catalina 3.5 is not ready for release yet, but attached is a preview of the new payload loader that will be included (Windows only executable at this stage).
This new version of payload is significantly faster - it downloads Catalina LMM as well as normal Spin binaries in the same time as the Parallax Propeller Tool (to within a second on my machine). It is also faster downloading Catalina XMM programs.
Just unzip the attached file into your Catalina\bin directory.
One of the things that slows the download process is leaving it to payload to locate the correct port to use each time (it does this by trying them all in turn). For faster speeds, explicitly specify the ports to use (if you don't know the ports, just use payload - once - without specifying any ports, and it will tell you!).
For example, for a Catalina LMM or Spin binary, specify the port to use for the download via -p:
payload -p2 hello_world
or, for an XMM program, specify both the primary and secondary ports to use (on most platforms they are the same) via -p and -s:
payload -p2 -s2 XMM startrek
If anyone has any problems with this version, please let me know!
Ross.
Good work Ross! I guess there is no need for me to add Catalina support to propeller-load anymore!
Good work Ross! I guess there is no need for me to add Catalina support to propeller-load anymore!
Hi David,
I appreciate the work you've done. At this point I'm not sure whether to ask that you continue or not - but I guess it would make sense for you to at least put it on hold for a bit. This version mostly improves the propeller detection/connection time, and so should significantly improve the load time for Spin and LMM programs up to 32k. But a download of an XMM program of a meagabyte or more will still take minutes rather than seconds. That's where your loader may improve things.
I hope people will report whether this version is faster, since I have only so far tested it on one machine - and the download times do seem to be at least partly machine-dependent.
I am relatively new with the propeller, but not C programming. After a few months of spin, I have decided I want to give Catalina 3.4 and Codeblocks a shot.
This may be more of a codeblocks issue, but I will ask anyway. Everything works fine on my XP laptop, but I am almost exclusively a linux user. I have tried twice on two different boxes, Ubuntu 9.1 and 10.4, both with the same result. I can create a project but I cannot select the build target from the dropdown box, nor can I select it via the build menu... both are empty. What am I overlooking? I am sure it is something, I am pretty good at doing that.
Although I haven't tried it, I have no problem with a CLI, so if that is what I have to do no biggie.
I am relatively new with the propeller, but not C programming. After a few months of spin, I have decided I want to give Catalina 3.4 and Codeblocks a shot.
This may be more of a codeblocks issue, but I will ask anyway. Everything works fine on my XP laptop, but I am almost exclusively a linux user. I have tried twice on two different boxes, Ubuntu 9.1 and 10.4, both with the same result. I can create a project but I cannot select the build target from the dropdown box, nor can I select it via the build menu... both are empty. What am I overlooking? I am sure it is something, I am pretty good at doing that.
Although I haven't tried it, I have no problem with a CLI, so if that is what I have to do no biggie.
Thanks, Dusty
Hi Dusty,
The Code::Blocks installation on Linux is a bit more manual than on Windows, but it works ok. I have not tried it on Ubuntu recently, but I have done so in the past. I think I still have a virtual for Ubuntu (not sure which version), so I will try it when I get home.
I'm not exactly sure from your description what you mean by "empty". In the "build target" dropdown, you should see "Release" and/Or "Debug" (depending on what configurations you selected in the project wizard. You should see the same thing on the "Build->Select Target" menu. Do you see nothing at all?
Can you provide a screenshot?
Also, on Linux you probably also have GCC installed - can you create a normal GCC project successfully in Code::Blocks?
EDIT: Could you also let me know what version of Code::Blocks you are using?
Thanks,
Ross.
P.S. to use the Catalina from the command line, just open a bash shell and type:
The Code::Blocks installation on Linux is a bit more manual than on Windows, but it works ok. I have not tried it on Ubuntu recently, but I have done so in the past. I think I still have a virtual for Ubuntu (not sure which version), so I will try it when I get home.
I'm not exactly sure from your description what you mean by "empty". In the "build target" dropdown, you should see "Release" and/Or "Debug" (depending on what configurations you selected in the project wizard. You should see the same thing on the "Build->Select Target" menu. Do you see nothing at all?
Can you provide a screenshot?
Also, on Linux you probably also have GCC installed - can you create a normal GCC project successfully in Code::Blocks?
EDIT: Could you also let me know what version of Code::Blocks you are using?
Thanks,
Ross.
P.S. to use the Catalina from the command line, just open a bash shell and type:
source /usr/local/lib/catalina/use_catalina
Yes, the install process is a little more hands on than with windows, but I've been through worse. I started off in the 90s compiling redhat 4.2 and enlightenment for a window manager, but that is a whole different topic.:nerd:
Both the dropdown and menu options are there, but the controls are empty, hopefully the screenshots help explain what I meant.
I verified both release and debug targets were selected when creating the project.
Yes, I was able to create a gcc project, but am unable to compile it due to the same problem, unable to select a target.
I may try to build codeblocks from sources, I just need to install the development files, I was hoping not to do that, though. It makes for an easier sell to PHBs.
Thanks for your time, Ross.
Yes, I was able to create a gcc project, but am unable to compile it due to the same problem, unable to select a target.
Now, that's very odd - does this happen with a "clean" install of Code::Blocks 10.05? - i.e. before you install the Catalina replacement compiler plugin?
... I have tried twice on two different boxes, Ubuntu 9.1 and 10.4, both with the same result. I can create a project but I cannot select the build target from the dropdown box, nor can I select it via the build menu... both are empty. What am I overlooking?
Hi Dusty,
I didn't have either of these versions of Ubuntu, so I am downloading a clean install of Ubuntu 10.4.
While I was waiting I just did a full install of Code::Blocks 10.05 and Catalina 3.5 under Fedora FC12 (32 bit), and everything worked as expected.
Some questions you may be able to answer:
Are you using 32 bit or 64 bit Ubuntu?
Can you tell me what version of wx you have installed? You can find out by executing wx-config --version
On the images you posted, the "Build target" dropdown list has a funny horizontal bar across half of it - is that what you actually see?
I am using Codeblocks 10.05, Catalina 3.4, 64 bit Ubuntu, and wx-config --version returns 2.8.12.
Yes, that funny little horizontal bar is all I see.
...
Rather than fight it, I just went ahead and rebuilt Codeblocks from sources and now everything looked as if it is working.
...
Well, that was until I uninstalled the default compiler plugin and installed the 64bit libcompiler-0.99.cbplugin plugin, now it is back to the original problem.
I am using Codeblocks 10.05, Catalina 3.4, 64 bit Ubuntu, and wx-config --version returns 2.8.12.
Yes, that funny little horizontal bar is all I see.
...
Rather than fight it, I just went ahead and rebuilt Codeblocks from sources and now everything looked as if it is working.
...
Well, that was until I uninstalled the default compiler plugin and installed the 64bit libcompiler-0.99.cbplugin plugin, now it is back to the original problem.
Dusty
Hi Dusty,
I didn't manage to get Ubuntu installed yet, but I think it is the version of wx that is the problem. My compiler plugin was built with 2.8.11.
I will post the source of the compiler plugin tonight and you can rebuild that as well. That should fix it.
Rayman has done some drivers in Spin and I believe there are other drivers out there as well.
I'm hoping this can be done in C, and I'm encouraged to find that a search for some C code turns up some code that ought to be portable to Catalina. I'm not sure yet of the optimum pin arrangement eg 8 bit using 8 (or more) prop pins vs 16 bit via latches and share with the external ram driver. The latter is a bit more messy, but it does free up more propeller pins to be used for other things, eg reading the touch screen.
Do you think this is something we can integrate into Catalina?
/**************************************************************************/
/*!
@file ILI9325.c
@author K. Townsend (microBuilder.eu)
@section DESCRIPTION
Driver for ILI9325 240x320 pixel TFT LCD displays.
This driver uses an 8-bit interface and a 16-bit RGB565 colour palette.
Should also work with SPFD5408B, ST7783 or OTM3225A-based LCDs, though
there are sometimes minor differences (for example vertical scrolling
via register 0x6A isn't supported with the ST7783 controller).
@section UPDATES
26-11-2010: ili9325ReadData contributed by Adafruit Industries
@section LICENSE
Software License Agreement (BSD License)
Copyright (c) 2010, microBuilder SARL
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holders nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ''AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/**************************************************************************/
#include "ILI9325.h"
#include "core/systick/systick.h"
#include "drivers/lcd/tft/touchscreen.h"
/*************************************************/
/* Private Methods */
/*************************************************/
/*************************************************/
void ili9325Delay(unsigned int t)
{
unsigned char t1;
while(t--)
for ( t1=10; t1 > 0; t1-- )
{
__asm("nop");
}
}
/*************************************************/
void ili9325WriteCmd(uint16_t command)
{
// Compiled with -Os on GCC 4.4 this works out to 25 cycles
// (versus 36 compiled with no optimisations). I'm not sure it
// can be improved further, so that means 25 cycles/350nS for
// continuous writes (cmd, data, data, data, ...) or ~150 cycles/
// ~2.1uS for a random pixel (Set X [cmd+data], Set Y [cmd+data],
// Set color [cmd+data]) (times assumes 72MHz clock).
CLR_CS_CD_SET_RD_WR; // Saves 18 commands compared to "CLR_CS; CLR_CD; SET_RD; SET_WR;"
ILI9325_GPIO2DATA_DATA = (command >> (8 - ILI9325_DATA_OFFSET));
CLR_WR;
SET_WR;
ILI9325_GPIO2DATA_DATA = command << ILI9325_DATA_OFFSET;
CLR_WR;
SET_WR_CS; // Saves 7 commands compared to "SET_WR; SET_CS;"
}
/*************************************************/
void ili9325WriteData(uint16_t data)
{
CLR_CS_SET_CD_RD_WR; // Saves 18 commands compared to SET_CD; SET_RD; SET_WR; CLR_CS"
ILI9325_GPIO2DATA_DATA = (data >> (8 - ILI9325_DATA_OFFSET));
CLR_WR;
SET_WR;
ILI9325_GPIO2DATA_DATA = data << ILI9325_DATA_OFFSET;
CLR_WR;
SET_WR_CS; // Saves 7 commands compared to "SET_WR, SET_CS;"
}
/*************************************************/
uint16_t ili9325ReadData(void)
{
// ToDo: Optimise this method!
uint16_t high, low;
high = low = 0;
uint16_t d;
SET_CD_RD_WR; // Saves 14 commands compared to "SET_CD; SET_RD; SET_WR"
CLR_CS;
// set inputs
ILI9325_GPIO2DATA_SETINPUT;
CLR_RD;
ili9325Delay(100);
high = ILI9325_GPIO2DATA_DATA;
high >>= ILI9325_DATA_OFFSET;
high &= 0xFF;
SET_RD;
CLR_RD;
ili9325Delay(100);
low = ILI9325_GPIO2DATA_DATA;
low >>= ILI9325_DATA_OFFSET;
low &=0xFF;
SET_RD;
SET_CS;
ILI9325_GPIO2DATA_SETOUTPUT;
d = high;
d <<= 8;
d |= low;
return d;
}
/*************************************************/
uint16_t ili9325Read(uint16_t addr)
{
ili9325WriteCmd(addr);
return ili9325ReadData();
}
/*************************************************/
void ili9325Command(uint16_t command, uint16_t data)
{
// Provided for convenience sake ... shouldn't be used
// in critical sections since it adds an extra
// branch, etc.
ili9325WriteCmd(command);
ili9325WriteData(data);
}
/*************************************************/
uint16_t ili9325BGR2RGB(uint16_t color)
{
uint16_t r, g, b;
b = (color>>0) & 0x1f;
g = (color>>5) & 0x3f;
r = (color>>11) & 0x1f;
return( (b<<11) + (g<<5) + (r<<0) );
}
/*************************************************/
/* Returns the 4-hexdigit controller code */
/*************************************************/
uint16_t ili9325Type(void)
{
ili9325WriteCmd(0x0);
return ili9325ReadData();
}
/*************************************************/
void ili9325SetCursor(uint16_t x, uint16_t y)
{
ili9325Command(0x0020, x); // GRAM Address Set (Horizontal Address) (R20h)
ili9325Command(0x0021, y); // GRAM Address Set (Vertical Address) (R21h)
}
/*************************************************/
void ili9325InitDisplay(void)
{
// Clear data line
GPIO_GPIO2DATA &= ~ILI9325_DATA_MASK;
SET_RD;
SET_WR;
SET_CS;
SET_CD;
// Reset display
CLR_RESET;
ili9325Delay(10000);
SET_RESET;
ili9325Delay(500);
ili9325Command(0x00FF, 0x0001);
ili9325Command(0x00F3, 0x0008);
ili9325WriteCmd(0x00F3);
ili9325Command(0x0001, 0x0100); // Driver Output Control Register (R01h)
ili9325Command(0x0002, 0x0700); // LCD Driving Waveform Control (R02h)
ili9325Command(0x0003, 0x1030); // Entry Mode (R03h)
ili9325Command(0x0008, 0x0302);
ili9325Command(0x0009, 0x0000);
ili9325Command(0x0010, 0x0000); // Power Control 1 (R10h)
ili9325Command(0x0011, 0x0007); // Power Control 2 (R11h)
ili9325Command(0x0012, 0x0000); // Power Control 3 (R12h)
ili9325Command(0x0013, 0x0000); // Power Control 4 (R13h)
ili9325Delay(1000);
ili9325Command(0x0010, 0x14B0); // Power Control 1 (R10h)
ili9325Delay(500);
ili9325Command(0x0011, 0x0007); // Power Control 2 (R11h)
ili9325Delay(500);
ili9325Command(0x0012, 0x008E); // Power Control 3 (R12h)
ili9325Command(0x0013, 0x0C00); // Power Control 4 (R13h)
ili9325Command(0x0029, 0x0015); // NVM read data 2 (R29h)
ili9325Delay(500);
ili9325Command(0x0030, 0x0000); // Gamma Control 1
ili9325Command(0x0031, 0x0107); // Gamma Control 2
ili9325Command(0x0032, 0x0000); // Gamma Control 3
ili9325Command(0x0035, 0x0203); // Gamma Control 6
ili9325Command(0x0036, 0x0402); // Gamma Control 7
ili9325Command(0x0037, 0x0000); // Gamma Control 8
ili9325Command(0x0038, 0x0207); // Gamma Control 9
ili9325Command(0x0039, 0x0000); // Gamma Control 10
ili9325Command(0x003C, 0x0203); // Gamma Control 13
ili9325Command(0x003D, 0x0403); // Gamma Control 14
ili9325Command(0x0050, 0x0000); // Window Horizontal RAM Address Start (R50h)
ili9325Command(0x0051, 0x00EF); // Window Horizontal RAM Address End (R51h)
ili9325Command(0x0052, 0X0000); // Window Vertical RAM Address Start (R52h)
ili9325Command(0x0053, 0x013F); // Window Vertical RAM Address End (R53h)
ili9325Command(0x0060, 0xa700); // Driver Output Control (R60h)
ili9325Command(0x0061, 0x0001); // Driver Output Control (R61h)
ili9325Command(0x0090, 0X0029); // Panel Interface Control 1 (R90h)
// Display On
ili9325Command(0x0007, 0x0133); // Display Control (R07h)
ili9325Delay(500);
ili9325WriteCmd(0x0022);
}
/*************************************************/
void ili9325Home(void)
{
ili9325Command(0x0020, 0X0000); // GRAM Address Set (Horizontal Address) (R20h)
ili9325Command(0x0021, 0X0000); // GRAM Address Set (Vertical Address) (R21h)
ili9325WriteCmd(0x0022); // Write Data to GRAM (R22h)
}
/*************************************************/
void ili9325SetWindow(uint16_t x, uint16_t y, uint16_t x1, uint16_t y1)
{
ili9325Command(0x0050, x); // Window Horizontal RAM Address Start (R50h)
ili9325Command(0x0051, x1); // Window Horizontal RAM Address End (R51h)
ili9325Command(0x0052, y); // Window Vertical RAM Address Start (R52h) )
ili9325Command(0x0053, y1); // Window Vertical RAM Address End (R53h)
}
/*************************************************/
/* Public Methods */
/*************************************************/
/*************************************************/
void lcdInit(void)
{
// Set control line pins to output
gpioSetDir(ILI9325_CS_PORT, ILI9325_CS_PIN, 1);
gpioSetDir(ILI9325_CD_PORT, ILI9325_CD_PIN, 1);
gpioSetDir(ILI9325_WR_PORT, ILI9325_WR_PIN, 1);
gpioSetDir(ILI9325_RD_PORT, ILI9325_RD_PIN, 1);
// Set data port pins to output
ILI9325_GPIO2DATA_SETOUTPUT;
// Disable pullups
ILI9325_DISABLEPULLUPS();
// Set backlight pin to input and turn it on
gpioSetDir(ILI9325_BL_PORT, ILI9325_BL_PIN, 1); // set to output
lcdBacklightOn();
// Set reset pin to output
gpioSetDir(ILI9325_RES_PORT, ILI9325_RES_PIN, 1); // Set to output
gpioSetValue(ILI9325_RES_PORT, ILI9325_RES_PIN, 0); // Low to reset
systickDelay(50);
gpioSetValue(ILI9325_RES_PORT, ILI9325_RES_PIN, 1); // High to exit
// Initialize the display
ili9325InitDisplay();
// Fill black
lcdFillRGB(COLOR_BLACK);
// Initialise the touch screen (and calibrate if necessary)
tsInit();
}
/*************************************************/
void lcdBacklightOn(void)
{
// Enable backlight
gpioSetValue(ILI9325_BL_PORT, ILI9325_BL_PIN, 0);
}
/*************************************************/
void lcdBacklightOff(void)
{
// Disable backlight
gpioSetValue(ILI9325_BL_PORT, ILI9325_BL_PIN, 1);
}
/*************************************************/
void lcdTest(void)
{
uint32_t i,j;
ili9325Home();
for(i=0;i<320;i++)
{
for(j=0;j<240;j++)
{
if(i>279)ili9325WriteData(COLOR_WHITE);
else if(i>239)ili9325WriteData(COLOR_BLUE);
else if(i>199)ili9325WriteData(COLOR_GREEN);
else if(i>159)ili9325WriteData(COLOR_CYAN);
else if(i>119)ili9325WriteData(COLOR_RED);
else if(i>79)ili9325WriteData(COLOR_MAGENTA);
else if(i>39)ili9325WriteData(COLOR_YELLOW);
else ili9325WriteData(COLOR_BLACK);
}
}
}
/*************************************************/
void lcdFillRGB(uint16_t data)
{
unsigned int i;
ili9325Home();
uint32_t pixels = 320*240;
for ( i=0; i < pixels; i++ )
{
ili9325WriteData(data);
}
}
/*************************************************/
void lcdDrawPixel(uint16_t x, uint16_t y, uint16_t color)
{
ili9325WriteCmd(0x0020); // GRAM Address Set (Horizontal Address) (R20h)
ili9325WriteData(x);
ili9325WriteCmd(0x0021); // GRAM Address Set (Vertical Address) (R21h)
ili9325WriteData(y);
ili9325WriteCmd(0x0022); // Write Data to GRAM (R22h)
ili9325WriteData(color);
}
/*************************************************/
void lcdDrawHLine(uint16_t x0, uint16_t x1, uint16_t y, uint16_t color)
{
// Allows for slightly better performance than setting individual pixels
uint16_t x, pixels;
if (x1 < x0)
{
// Switch x1 and x0
x = x1;
x1 = x0;
x0 = x;
}
ili9325WriteCmd(0x0020); // GRAM Address Set (Horizontal Address) (R20h)
ili9325WriteData(x0);
ili9325WriteCmd(0x0021); // GRAM Address Set (Vertical Address) (R21h)
ili9325WriteData(y);
ili9325WriteCmd(0x0022); // Write Data to GRAM (R22h)
for (pixels = 0; pixels < x1 - x0 + 1; pixels++)
{
ili9325WriteData(color);
}
}
/*************************************************/
uint16_t lcdGetPixel(uint16_t x, uint16_t y)
{
uint16_t preFetch = 0;
ili9325SetCursor(x, y);
ili9325WriteCmd(0x0022);
preFetch = ili9325ReadData();
// Eeek ... why does this need to be done twice for a proper value?!?
ili9325SetCursor(x, y);
ili9325WriteCmd(0x0022);
return ili9325ReadData();
}
/*************************************************/
void lcdScroll(int16_t pixels, uint16_t fillColor)
{
// Note: Not all ILI9325 imitations support HW vertical scrolling!
// ST7781 - Not supported (ex. RFTechWorld 2.8" displays)
// OTM3225A - Supported
int16_t y = pixels;
while (y < 0)
y += 320;
while (y >= 320)
y -= 320;
ili9325WriteCmd(0x6A);
ili9325WriteData(y);
}
Do you think this is something we can integrate into Catalina?
Hi Dr_A,
Apart from the obviously non-portable stuff, it should compile - but it may not run fast enough to be useful. This would be better (and probably much simpler) to write as a PASM plugin - and even then you'd have trouble achieving the kinds of speeds mentioned in the code comments. This code would seem to have been originally written for a faster processor - do you know what it runs on?
In general, when you see C code written quite that badly, it's usually a sign that it has been rewritten in C after being developed in another language - in this case, most likely it was originally written in assembler. There are even comments in there to the effect that "this function should not be used because it adds an extra branch instruction" - if the timing is that critical, it means assembler is probably the answer.
Good point. I have the display drivers in C for the existing VGA/TV drivers and generally it is easier to debug in C and then port things over to pasm once they are working. That code above would probably fit in a cog. Then you could do things like move a picture from sd card to hub ram, then another routine to tell a cog where the picture is in hub, and then fire off a cog routine to move that data out to the display.
Hopefully it should be possible to build it up in blocks of code so that you can do a 'printf" in a variety of fonts/font sizes etc.
I have just uploaded the source for the version of Code::Blocks that supports Catalina to SourceForge (here). This includes the source for the updated Compiler plugin with Catalina compiler support.
Anyone who is having trouble installing Code::Blocks (like those reported on Ubuntu by pinedust) can now rebuild Code::Blocks from source instead of using the binary version included in the various Catalina downloads.
I have just uploaded the source for the version of Code::Blocks that supports Catalina to SourceForge (here). This includes the source for the updated Compiler plugin with Catalina compiler support.
Anyone who is having trouble installing Code::Blocks (like those reported on Ubuntu by pinedust) can now rebuild Code::Blocks from source instead of using the binary version included in the various Catalina downloads.
Earlier in this thread, Jazzed asked for a loader that included serial terminal capability so that users would not need to open a separate terminal emulator window. I can see this would be very useful for boards (like the Parallax QuickStart board) which have no keyboard, TV or VGA ports - so I have now added this capability to payload.
Payload now has an interactive mode (enabled via -i) that makes it act as a simple terminal emulator once the program has been downloaded. This simplifies loading and running programs for those who use the PC HMI option (which does all stdio via a serial port on pins 30 & 31).
Note the addition of -D PC to the catalina command (to tell catalina to compile the program to use the PC terminal emulator HMI option) and the addition of the -i to the payload command (to tell payload to enter the interactive mode when the download has completed).
To exit the interactive terminal mode, just press CTRL+D (i.e. the EOT character) at any time.
Note that interactive mode can be used with any Catalina program (i.e. LMM or XMM) and also with any Spin binary (compiled to use the normal Parallax serial port at 115200 baud).
To use interactive mode from within Code::Blocks, just select Tools-> Configure tools... and add the new -i option to the relevant tool parameters (e.g. to the Download to Hub RAM tool)
If anyone has any problems with the interactive mode, or any suggestions for improvements, please let me know.
I'm having some trouble with the Linux version of the new Payload loader (specifically, with the interactive terminal mode). I am almost sure it is because I run Linux in a virtual machine - but I just need to confirm this.
I don't want to release the code until I'm sure it is working, so I need a few Catalina Linux users (I know there aren't many in these forums!) willing to run a simple test. You just need to have Catalina 3.4 installed, and have Linux installed "natively" (i.e. not in a virtual machine).
Please send me a PM (with you email address) and I will post you an executable and some instructions on the test I need run - it will only take a couple of minutes.
I'm having some trouble with the Linux version of the new Payload loader (specifically, with the interactive terminal mode). I am almost sure it is because I run Linux in a virtual machine - but I just need to confirm this.
I don't want to release the code until I'm sure it is working, so I need a few Catalina Linux users (I know there aren't many in these forums!) willing to run a simple test. You just need to have Catalina 3.4 installed, and have Linux installed "natively" (i.e. not in a virtual machine).
Please send me a PM (with you email address) and I will post you an executable and some instructions on the test I need run - it will only take a couple of minutes.
Thanks!
Ross.
In case you're interested, here is the terminal code I use in propeller-load.
#define ESC 0x1b /* escape from terminal mode */
/**
* simple terminal emulator
*/
extern int check_for_exit;
void terminal_mode(void)
{
struct termios oldt, newt;
char buf[128];
ssize_t cnt;
fd_set set;
int exit_char = 0xdead; /* not a valid character */
int sawexit_char = 0;
int sawexit_valid = 0;
int exitcode = 0;
int continue_terminal = 1;
tcgetattr(STDIN_FILENO, &oldt);
newt = oldt;
newt.c_lflag &= ~(ICANON | ECHO);
tcsetattr(STDIN_FILENO, TCSANOW, &newt);
if (check_for_exit)
{
exit_char = 0xff;
}
#if 0
/* make it possible to detect breaks */
tcgetattr(hSerial, &newt);
newt.c_iflag &= ~IGNBRK;
newt.c_iflag |= PARMRK;
tcsetattr(hSerial, TCSANOW, &newt);
#endif
do {
FD_ZERO(&set);
FD_SET(hSerial, &set);
FD_SET(STDIN_FILENO, &set);
if (select(hSerial + 1, &set, NULL, NULL, NULL) > 0) {
if (FD_ISSET(hSerial, &set)) {
if ((cnt = read(hSerial, buf, sizeof(buf))) > 0) {
int i;
// check for breaks
ssize_t realbytes = 0;
for (i = 0; i < cnt; i++) {
if (sawexit_valid)
{
exitcode = buf[i];
continue_terminal = 0;
}
else if (sawexit_char) {
if (buf[i] == 0) {
sawexit_valid = 1;
} else {
buf[realbytes++] = exit_char;
buf[realbytes++] = buf[i];
sawexit_char = 0;
}
} else if (((int)buf[i] & 0xff) == exit_char) {
sawexit_char = 1;
} else {
buf[realbytes++] = buf[i];
}
}
write(fileno(stdout), buf, realbytes);
}
}
if (FD_ISSET(STDIN_FILENO, &set)) {
if ((cnt = read(STDIN_FILENO, buf, sizeof(buf))) > 0) {
int i;
for (i = 0; i < cnt; ++i)
if (buf[i] == ESC)
goto done;
write(hSerial, buf, cnt);
}
}
}
} while (continue_terminal);
done:
tcsetattr(STDIN_FILENO, TCSANOW, &oldt);
if (sawexit_valid)
{
exit(exitcode);
}
}
Ross - I think some time ago you posted something about running Spin and C together. I was wondering - is it possible to run two C threads at the same time? Let's say, hypothetically, that each thread had access to half the hub ram and 4 cogs. Or, if that is too complicated, one thread is the Input/Output thread which would handle keyboard/mouse/display via stdio, and the other thread talks to the I/O thread via common hub memory?
What I am thinking of is an 'operating system' thread that handles input and output, and a 'program' thread where programs can be loaded and unloaded. Or more specifically, I am trying to write a program in C and it ends up with huge overheads running OS type stuff like loading in fonts from sd card and putting them on a display, and it may be easier to split the task into two.
I'm doing some experiments with 320x240 displays and these have their own internal memory, so this has opened up a whole new way of doing things because no hub is needed for a screen buffer, so essentially all the hub is free.
If the above is possible, is it also possible to have separate caches for each thread? Maybe 4k for each or something?
Comments
Code::Blocks does not support Catalina breakpoints - you need to use the BlackBox or BlackCat debuggers, which are stand-alone programs.
My solution for debugging programs stored in Flash is to actually use the cache to store the breakpoints - i.e. to simulate the debugger writing to what would normally be read-only Flash memory, by instead caching the writes but not writing the dirty pages back to XMM RAM.
The main thing I am not happy about is that I can only store a small number breakpoints that way - I need to make the cache more efficient in the way it stores each breakpoint - it can't simply leave all the pages with breakpoints hanging around in Hub RAM (as it does now) - this simply runs out of space too quickly!
Ross.
I'm looking at some C code for the Vinculum II right now... I'm a little surprised to see that they never use a semicolon after braces {};
Is this not required in regular C?
I think it is required in all C++, right?
Just curious...
if (a == b) { printf("a equals b\n"); }; else { printf("a does not equal b"\n"); };int my_array[] = { 1, 2, 3 };It is also used in other declarations but not in executable statements.Still, it just looks wrong to me to leave them off...
In C braces are used to delimit both block structures and type structures (including type initializers). The semicolon in C is a statement terminator, so it is required after each statement, even if that statement ends in a type structure or a type initializer - such as a declaration. It is not required after a block structure - there it would represent an empty statement, so it looks like it is "optional" whereas in fact it should not be there at all.
However, I think C# (and possibly some C/C++ implementations) make the semicolon optional in places where it would be mandatory in "pure" C.
Ross.
Catalina 3.5 is not ready for release yet, but attached is a preview of the new payload loader that will be included (Windows only executable at this stage).
EDIT : attachment has been removed - you will find an updated version in the second post in this thread
This new version of payload is significantly faster - it downloads Catalina LMM as well as normal Spin binaries in the same time as the Parallax Propeller Tool (to within a second on my machine). It is also faster downloading Catalina XMM programs.
Just unzip the attached file into your Catalina\bin directory.
One of the things that slows the download process is leaving it to payload to locate the correct port to use each time (it does this by trying them all in turn). For faster speeds, explicitly specify the ports to use (if you don't know the ports, just use payload - once - without specifying any ports, and it will tell you!).
For example, for a Catalina LMM or Spin binary, specify the port to use for the download via -p:
or, for an XMM program, specify both the primary and secondary ports to use (on most platforms they are the same) via -p and -s:
If anyone has any problems with this version, please let me know!
Ross.
Hi David,
I appreciate the work you've done. At this point I'm not sure whether to ask that you continue or not - but I guess it would make sense for you to at least put it on hold for a bit. This version mostly improves the propeller detection/connection time, and so should significantly improve the load time for Spin and LMM programs up to 32k. But a download of an XMM program of a meagabyte or more will still take minutes rather than seconds. That's where your loader may improve things.
I hope people will report whether this version is faster, since I have only so far tested it on one machine - and the download times do seem to be at least partly machine-dependent.
Ross.
Found a bug when compiling XMM programs that use the EEPROM loader. The fix is in the second post in this thread.
Ross.
This may be more of a codeblocks issue, but I will ask anyway. Everything works fine on my XP laptop, but I am almost exclusively a linux user. I have tried twice on two different boxes, Ubuntu 9.1 and 10.4, both with the same result. I can create a project but I cannot select the build target from the dropdown box, nor can I select it via the build menu... both are empty. What am I overlooking? I am sure it is something, I am pretty good at doing that.
Although I haven't tried it, I have no problem with a CLI, so if that is what I have to do no biggie.
Thanks, Dusty
Hi Dusty,
The Code::Blocks installation on Linux is a bit more manual than on Windows, but it works ok. I have not tried it on Ubuntu recently, but I have done so in the past. I think I still have a virtual for Ubuntu (not sure which version), so I will try it when I get home.
I'm not exactly sure from your description what you mean by "empty". In the "build target" dropdown, you should see "Release" and/Or "Debug" (depending on what configurations you selected in the project wizard. You should see the same thing on the "Build->Select Target" menu. Do you see nothing at all?
Can you provide a screenshot?
Also, on Linux you probably also have GCC installed - can you create a normal GCC project successfully in Code::Blocks?
EDIT: Could you also let me know what version of Code::Blocks you are using?
Thanks,
Ross.
P.S. to use the Catalina from the command line, just open a bash shell and type:
Both the dropdown and menu options are there, but the controls are empty, hopefully the screenshots help explain what I meant.
I verified both release and debug targets were selected when creating the project.
Yes, I was able to create a gcc project, but am unable to compile it due to the same problem, unable to select a target.
I may try to build codeblocks from sources, I just need to install the development files, I was hoping not to do that, though. It makes for an easier sell to PHBs.
Thanks for your time, Ross.
Ross.
Hi Dusty,
I didn't have either of these versions of Ubuntu, so I am downloading a clean install of Ubuntu 10.4.
While I was waiting I just did a full install of Code::Blocks 10.05 and Catalina 3.5 under Fedora FC12 (32 bit), and everything worked as expected.
Some questions you may be able to answer:
Are you using 32 bit or 64 bit Ubuntu?
Can you tell me what version of wx you have installed? You can find out by executing wx-config --version
On the images you posted, the "Build target" dropdown list has a funny horizontal bar across half of it - is that what you actually see?
Thanks,
Ross.
Yes, that funny little horizontal bar is all I see.
...
Rather than fight it, I just went ahead and rebuilt Codeblocks from sources and now everything looked as if it is working.
...
Well, that was until I uninstalled the default compiler plugin and installed the 64bit libcompiler-0.99.cbplugin plugin, now it is back to the original problem.
Dusty
Hi Dusty,
I didn't manage to get Ubuntu installed yet, but I think it is the version of wx that is the problem. My compiler plugin was built with 2.8.11.
I will post the source of the compiler plugin tonight and you can rebuild that as well. That should fix it.
Ross.
I'm experimenting with various displays at the moment and am hoping to get this one working http://www.ebay.com.au/itm/170709358010?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 which uses an ILI9325. Scroll down that product description for the pinout which is a standard 40 pin header.
Rayman has done some drivers in Spin and I believe there are other drivers out there as well.
I'm hoping this can be done in C, and I'm encouraged to find that a search for some C code turns up some code that ought to be portable to Catalina. I'm not sure yet of the optimum pin arrangement eg 8 bit using 8 (or more) prop pins vs 16 bit via latches and share with the external ram driver. The latter is a bit more messy, but it does free up more propeller pins to be used for other things, eg reading the touch screen.
There is some C source code here http://code.google.com/p/lpc1343codebase/source/browse/trunk/drivers/lcd/tft/hw/ILI9325.c?r=137
Do you think this is something we can integrate into Catalina?
/**************************************************************************/ /*! @file ILI9325.c @author K. Townsend (microBuilder.eu) @section DESCRIPTION Driver for ILI9325 240x320 pixel TFT LCD displays. This driver uses an 8-bit interface and a 16-bit RGB565 colour palette. Should also work with SPFD5408B, ST7783 or OTM3225A-based LCDs, though there are sometimes minor differences (for example vertical scrolling via register 0x6A isn't supported with the ST7783 controller). @section UPDATES 26-11-2010: ili9325ReadData contributed by Adafruit Industries @section LICENSE Software License Agreement (BSD License) Copyright (c) 2010, microBuilder SARL All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holders nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ /**************************************************************************/ #include "ILI9325.h" #include "core/systick/systick.h" #include "drivers/lcd/tft/touchscreen.h" /*************************************************/ /* Private Methods */ /*************************************************/ /*************************************************/ void ili9325Delay(unsigned int t) { unsigned char t1; while(t--) for ( t1=10; t1 > 0; t1-- ) { __asm("nop"); } } /*************************************************/ void ili9325WriteCmd(uint16_t command) { // Compiled with -Os on GCC 4.4 this works out to 25 cycles // (versus 36 compiled with no optimisations). I'm not sure it // can be improved further, so that means 25 cycles/350nS for // continuous writes (cmd, data, data, data, ...) or ~150 cycles/ // ~2.1uS for a random pixel (Set X [cmd+data], Set Y [cmd+data], // Set color [cmd+data]) (times assumes 72MHz clock). CLR_CS_CD_SET_RD_WR; // Saves 18 commands compared to "CLR_CS; CLR_CD; SET_RD; SET_WR;" ILI9325_GPIO2DATA_DATA = (command >> (8 - ILI9325_DATA_OFFSET)); CLR_WR; SET_WR; ILI9325_GPIO2DATA_DATA = command << ILI9325_DATA_OFFSET; CLR_WR; SET_WR_CS; // Saves 7 commands compared to "SET_WR; SET_CS;" } /*************************************************/ void ili9325WriteData(uint16_t data) { CLR_CS_SET_CD_RD_WR; // Saves 18 commands compared to SET_CD; SET_RD; SET_WR; CLR_CS" ILI9325_GPIO2DATA_DATA = (data >> (8 - ILI9325_DATA_OFFSET)); CLR_WR; SET_WR; ILI9325_GPIO2DATA_DATA = data << ILI9325_DATA_OFFSET; CLR_WR; SET_WR_CS; // Saves 7 commands compared to "SET_WR, SET_CS;" } /*************************************************/ uint16_t ili9325ReadData(void) { // ToDo: Optimise this method! uint16_t high, low; high = low = 0; uint16_t d; SET_CD_RD_WR; // Saves 14 commands compared to "SET_CD; SET_RD; SET_WR" CLR_CS; // set inputs ILI9325_GPIO2DATA_SETINPUT; CLR_RD; ili9325Delay(100); high = ILI9325_GPIO2DATA_DATA; high >>= ILI9325_DATA_OFFSET; high &= 0xFF; SET_RD; CLR_RD; ili9325Delay(100); low = ILI9325_GPIO2DATA_DATA; low >>= ILI9325_DATA_OFFSET; low &=0xFF; SET_RD; SET_CS; ILI9325_GPIO2DATA_SETOUTPUT; d = high; d <<= 8; d |= low; return d; } /*************************************************/ uint16_t ili9325Read(uint16_t addr) { ili9325WriteCmd(addr); return ili9325ReadData(); } /*************************************************/ void ili9325Command(uint16_t command, uint16_t data) { // Provided for convenience sake ... shouldn't be used // in critical sections since it adds an extra // branch, etc. ili9325WriteCmd(command); ili9325WriteData(data); } /*************************************************/ uint16_t ili9325BGR2RGB(uint16_t color) { uint16_t r, g, b; b = (color>>0) & 0x1f; g = (color>>5) & 0x3f; r = (color>>11) & 0x1f; return( (b<<11) + (g<<5) + (r<<0) ); } /*************************************************/ /* Returns the 4-hexdigit controller code */ /*************************************************/ uint16_t ili9325Type(void) { ili9325WriteCmd(0x0); return ili9325ReadData(); } /*************************************************/ void ili9325SetCursor(uint16_t x, uint16_t y) { ili9325Command(0x0020, x); // GRAM Address Set (Horizontal Address) (R20h) ili9325Command(0x0021, y); // GRAM Address Set (Vertical Address) (R21h) } /*************************************************/ void ili9325InitDisplay(void) { // Clear data line GPIO_GPIO2DATA &= ~ILI9325_DATA_MASK; SET_RD; SET_WR; SET_CS; SET_CD; // Reset display CLR_RESET; ili9325Delay(10000); SET_RESET; ili9325Delay(500); ili9325Command(0x00FF, 0x0001); ili9325Command(0x00F3, 0x0008); ili9325WriteCmd(0x00F3); ili9325Command(0x0001, 0x0100); // Driver Output Control Register (R01h) ili9325Command(0x0002, 0x0700); // LCD Driving Waveform Control (R02h) ili9325Command(0x0003, 0x1030); // Entry Mode (R03h) ili9325Command(0x0008, 0x0302); ili9325Command(0x0009, 0x0000); ili9325Command(0x0010, 0x0000); // Power Control 1 (R10h) ili9325Command(0x0011, 0x0007); // Power Control 2 (R11h) ili9325Command(0x0012, 0x0000); // Power Control 3 (R12h) ili9325Command(0x0013, 0x0000); // Power Control 4 (R13h) ili9325Delay(1000); ili9325Command(0x0010, 0x14B0); // Power Control 1 (R10h) ili9325Delay(500); ili9325Command(0x0011, 0x0007); // Power Control 2 (R11h) ili9325Delay(500); ili9325Command(0x0012, 0x008E); // Power Control 3 (R12h) ili9325Command(0x0013, 0x0C00); // Power Control 4 (R13h) ili9325Command(0x0029, 0x0015); // NVM read data 2 (R29h) ili9325Delay(500); ili9325Command(0x0030, 0x0000); // Gamma Control 1 ili9325Command(0x0031, 0x0107); // Gamma Control 2 ili9325Command(0x0032, 0x0000); // Gamma Control 3 ili9325Command(0x0035, 0x0203); // Gamma Control 6 ili9325Command(0x0036, 0x0402); // Gamma Control 7 ili9325Command(0x0037, 0x0000); // Gamma Control 8 ili9325Command(0x0038, 0x0207); // Gamma Control 9 ili9325Command(0x0039, 0x0000); // Gamma Control 10 ili9325Command(0x003C, 0x0203); // Gamma Control 13 ili9325Command(0x003D, 0x0403); // Gamma Control 14 ili9325Command(0x0050, 0x0000); // Window Horizontal RAM Address Start (R50h) ili9325Command(0x0051, 0x00EF); // Window Horizontal RAM Address End (R51h) ili9325Command(0x0052, 0X0000); // Window Vertical RAM Address Start (R52h) ili9325Command(0x0053, 0x013F); // Window Vertical RAM Address End (R53h) ili9325Command(0x0060, 0xa700); // Driver Output Control (R60h) ili9325Command(0x0061, 0x0001); // Driver Output Control (R61h) ili9325Command(0x0090, 0X0029); // Panel Interface Control 1 (R90h) // Display On ili9325Command(0x0007, 0x0133); // Display Control (R07h) ili9325Delay(500); ili9325WriteCmd(0x0022); } /*************************************************/ void ili9325Home(void) { ili9325Command(0x0020, 0X0000); // GRAM Address Set (Horizontal Address) (R20h) ili9325Command(0x0021, 0X0000); // GRAM Address Set (Vertical Address) (R21h) ili9325WriteCmd(0x0022); // Write Data to GRAM (R22h) } /*************************************************/ void ili9325SetWindow(uint16_t x, uint16_t y, uint16_t x1, uint16_t y1) { ili9325Command(0x0050, x); // Window Horizontal RAM Address Start (R50h) ili9325Command(0x0051, x1); // Window Horizontal RAM Address End (R51h) ili9325Command(0x0052, y); // Window Vertical RAM Address Start (R52h) ) ili9325Command(0x0053, y1); // Window Vertical RAM Address End (R53h) } /*************************************************/ /* Public Methods */ /*************************************************/ /*************************************************/ void lcdInit(void) { // Set control line pins to output gpioSetDir(ILI9325_CS_PORT, ILI9325_CS_PIN, 1); gpioSetDir(ILI9325_CD_PORT, ILI9325_CD_PIN, 1); gpioSetDir(ILI9325_WR_PORT, ILI9325_WR_PIN, 1); gpioSetDir(ILI9325_RD_PORT, ILI9325_RD_PIN, 1); // Set data port pins to output ILI9325_GPIO2DATA_SETOUTPUT; // Disable pullups ILI9325_DISABLEPULLUPS(); // Set backlight pin to input and turn it on gpioSetDir(ILI9325_BL_PORT, ILI9325_BL_PIN, 1); // set to output lcdBacklightOn(); // Set reset pin to output gpioSetDir(ILI9325_RES_PORT, ILI9325_RES_PIN, 1); // Set to output gpioSetValue(ILI9325_RES_PORT, ILI9325_RES_PIN, 0); // Low to reset systickDelay(50); gpioSetValue(ILI9325_RES_PORT, ILI9325_RES_PIN, 1); // High to exit // Initialize the display ili9325InitDisplay(); // Fill black lcdFillRGB(COLOR_BLACK); // Initialise the touch screen (and calibrate if necessary) tsInit(); } /*************************************************/ void lcdBacklightOn(void) { // Enable backlight gpioSetValue(ILI9325_BL_PORT, ILI9325_BL_PIN, 0); } /*************************************************/ void lcdBacklightOff(void) { // Disable backlight gpioSetValue(ILI9325_BL_PORT, ILI9325_BL_PIN, 1); } /*************************************************/ void lcdTest(void) { uint32_t i,j; ili9325Home(); for(i=0;i<320;i++) { for(j=0;j<240;j++) { if(i>279)ili9325WriteData(COLOR_WHITE); else if(i>239)ili9325WriteData(COLOR_BLUE); else if(i>199)ili9325WriteData(COLOR_GREEN); else if(i>159)ili9325WriteData(COLOR_CYAN); else if(i>119)ili9325WriteData(COLOR_RED); else if(i>79)ili9325WriteData(COLOR_MAGENTA); else if(i>39)ili9325WriteData(COLOR_YELLOW); else ili9325WriteData(COLOR_BLACK); } } } /*************************************************/ void lcdFillRGB(uint16_t data) { unsigned int i; ili9325Home(); uint32_t pixels = 320*240; for ( i=0; i < pixels; i++ ) { ili9325WriteData(data); } } /*************************************************/ void lcdDrawPixel(uint16_t x, uint16_t y, uint16_t color) { ili9325WriteCmd(0x0020); // GRAM Address Set (Horizontal Address) (R20h) ili9325WriteData(x); ili9325WriteCmd(0x0021); // GRAM Address Set (Vertical Address) (R21h) ili9325WriteData(y); ili9325WriteCmd(0x0022); // Write Data to GRAM (R22h) ili9325WriteData(color); } /*************************************************/ void lcdDrawHLine(uint16_t x0, uint16_t x1, uint16_t y, uint16_t color) { // Allows for slightly better performance than setting individual pixels uint16_t x, pixels; if (x1 < x0) { // Switch x1 and x0 x = x1; x1 = x0; x0 = x; } ili9325WriteCmd(0x0020); // GRAM Address Set (Horizontal Address) (R20h) ili9325WriteData(x0); ili9325WriteCmd(0x0021); // GRAM Address Set (Vertical Address) (R21h) ili9325WriteData(y); ili9325WriteCmd(0x0022); // Write Data to GRAM (R22h) for (pixels = 0; pixels < x1 - x0 + 1; pixels++) { ili9325WriteData(color); } } /*************************************************/ uint16_t lcdGetPixel(uint16_t x, uint16_t y) { uint16_t preFetch = 0; ili9325SetCursor(x, y); ili9325WriteCmd(0x0022); preFetch = ili9325ReadData(); // Eeek ... why does this need to be done twice for a proper value?!? ili9325SetCursor(x, y); ili9325WriteCmd(0x0022); return ili9325ReadData(); } /*************************************************/ void lcdScroll(int16_t pixels, uint16_t fillColor) { // Note: Not all ILI9325 imitations support HW vertical scrolling! // ST7781 - Not supported (ex. RFTechWorld 2.8" displays) // OTM3225A - Supported int16_t y = pixels; while (y < 0) y += 320; while (y >= 320) y -= 320; ili9325WriteCmd(0x6A); ili9325WriteData(y); }Hi Dr_A,
Apart from the obviously non-portable stuff, it should compile - but it may not run fast enough to be useful. This would be better (and probably much simpler) to write as a PASM plugin - and even then you'd have trouble achieving the kinds of speeds mentioned in the code comments. This code would seem to have been originally written for a faster processor - do you know what it runs on?
In general, when you see C code written quite that badly, it's usually a sign that it has been rewritten in C after being developed in another language - in this case, most likely it was originally written in assembler. There are even comments in there to the effect that "this function should not be used because it adds an extra branch instruction" - if the timing is that critical, it means assembler is probably the answer.
Ross.
Hopefully it should be possible to build it up in blocks of code so that you can do a 'printf" in a variety of fonts/font sizes etc.
I have just uploaded the source for the version of Code::Blocks that supports Catalina to SourceForge (here). This includes the source for the updated Compiler plugin with Catalina compiler support.
Anyone who is having trouble installing Code::Blocks (like those reported on Ubuntu by pinedust) can now rebuild Code::Blocks from source instead of using the binary version included in the various Catalina downloads.
Ross.
This version works great!
Thank you!
Earlier in this thread, Jazzed asked for a loader that included serial terminal capability so that users would not need to open a separate terminal emulator window. I can see this would be very useful for boards (like the Parallax QuickStart board) which have no keyboard, TV or VGA ports - so I have now added this capability to payload.
Payload now has an interactive mode (enabled via -i) that makes it act as a simple terminal emulator once the program has been downloaded. This simplifies loading and running programs for those who use the PC HMI option (which does all stdio via a serial port on pins 30 & 31).
I have added the new executable to the second post in this thread (Windows only at this stage!).
Here is how you might use it:
Note the addition of -D PC to the catalina command (to tell catalina to compile the program to use the PC terminal emulator HMI option) and the addition of the -i to the payload command (to tell payload to enter the interactive mode when the download has completed).
To exit the interactive terminal mode, just press CTRL+D (i.e. the EOT character) at any time.
Note that interactive mode can be used with any Catalina program (i.e. LMM or XMM) and also with any Spin binary (compiled to use the normal Parallax serial port at 115200 baud).
To use interactive mode from within Code::Blocks, just select Tools-> Configure tools... and add the new -i option to the relevant tool parameters (e.g. to the Download to Hub RAM tool)
If anyone has any problems with the interactive mode, or any suggestions for improvements, please let me know.
Ross.
I'm having some trouble with the Linux version of the new Payload loader (specifically, with the interactive terminal mode). I am almost sure it is because I run Linux in a virtual machine - but I just need to confirm this.
I don't want to release the code until I'm sure it is working, so I need a few Catalina Linux users (I know there aren't many in these forums!) willing to run a simple test. You just need to have Catalina 3.4 installed, and have Linux installed "natively" (i.e. not in a virtual machine).
Please send me a PM (with you email address) and I will post you an executable and some instructions on the test I need run - it will only take a couple of minutes.
Thanks!
Ross.
#define ESC 0x1b /* escape from terminal mode */ /** * simple terminal emulator */ extern int check_for_exit; void terminal_mode(void) { struct termios oldt, newt; char buf[128]; ssize_t cnt; fd_set set; int exit_char = 0xdead; /* not a valid character */ int sawexit_char = 0; int sawexit_valid = 0; int exitcode = 0; int continue_terminal = 1; tcgetattr(STDIN_FILENO, &oldt); newt = oldt; newt.c_lflag &= ~(ICANON | ECHO); tcsetattr(STDIN_FILENO, TCSANOW, &newt); if (check_for_exit) { exit_char = 0xff; } #if 0 /* make it possible to detect breaks */ tcgetattr(hSerial, &newt); newt.c_iflag &= ~IGNBRK; newt.c_iflag |= PARMRK; tcsetattr(hSerial, TCSANOW, &newt); #endif do { FD_ZERO(&set); FD_SET(hSerial, &set); FD_SET(STDIN_FILENO, &set); if (select(hSerial + 1, &set, NULL, NULL, NULL) > 0) { if (FD_ISSET(hSerial, &set)) { if ((cnt = read(hSerial, buf, sizeof(buf))) > 0) { int i; // check for breaks ssize_t realbytes = 0; for (i = 0; i < cnt; i++) { if (sawexit_valid) { exitcode = buf[i]; continue_terminal = 0; } else if (sawexit_char) { if (buf[i] == 0) { sawexit_valid = 1; } else { buf[realbytes++] = exit_char; buf[realbytes++] = buf[i]; sawexit_char = 0; } } else if (((int)buf[i] & 0xff) == exit_char) { sawexit_char = 1; } else { buf[realbytes++] = buf[i]; } } write(fileno(stdout), buf, realbytes); } } if (FD_ISSET(STDIN_FILENO, &set)) { if ((cnt = read(STDIN_FILENO, buf, sizeof(buf))) > 0) { int i; for (i = 0; i < cnt; ++i) if (buf[i] == ESC) goto done; write(hSerial, buf, cnt); } } } } while (continue_terminal); done: tcsetattr(STDIN_FILENO, TCSANOW, &oldt); if (sawexit_valid) { exit(exitcode); } }What I am thinking of is an 'operating system' thread that handles input and output, and a 'program' thread where programs can be loaded and unloaded. Or more specifically, I am trying to write a program in C and it ends up with huge overheads running OS type stuff like loading in fonts from sd card and putting them on a display, and it may be easier to split the task into two.
I'm doing some experiments with 320x240 displays and these have their own internal memory, so this has opened up a whole new way of doing things because no hub is needed for a screen buffer, so essentially all the hub is free.
If the above is possible, is it also possible to have separate caches for each thread? Maybe 4k for each or something?
Is it everything in the usual time.h?