cheaper large instrument displays - mast mount

[AngusMcDoon]

hmm..pot is connected but does not seem to alter it very much..i have ploughed on anyway and now have everything connected.

Having a bit of trouble compiling the code..i get the following:

[cc] c:/gnu_tools_arm_embedded/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/bin/ld.exe: mast_display.elf section `.co_stack' will not fit in region `ram'

[cc] c:/gnu_tools_arm_embedded/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/bin/ld.exe: region `ram' overflowed by 144 bytes
[cc] collect2: ld returned 1 exit status

Any ideas?

I made a change to link.ld file that Coocox generates. This is to force some constant data into flash rather than in RAM, which was where it was putting it. If this constant data goes into RAM, you run out, which is what the above error messages are about.

I added this to link.ld...

.const :
{
*(.const .const.*)
} > rom

just below the .text section. The problem is that Coocox is trying to regenerate the link.ld file every time you compile and overwriting my added section. The solution is to get link.ld out of the zip file I sent you again overwriting the one you have in your project folder, and then using Windows Explorer (or a DOS command) make link.ld read only. This should stop Coocox zapping it on every compile. I guess the read-only attribute didn't survive the zipping/unzipping.

 

[AngusMcDoon]

I just made my link.ld writeable and got the same message, although curiously mine overflowed by 216 bytes!

Changed link.ld back, made it read-only, and it compiled.

 

[ShaunG]

thanks angus, i have checked the attributes in both windows and coocox and the read only and archive attributes are set to on...still the same error

 

[ShaunG]

ignore the above...me being stupid..so long as i copy and paste from the original file to link.ld in coocox it compils

 

[AngusMcDoon]

thanks angus, i have checked the attributes in both windows and coocox and the read only and archive attributes are set to on...still the same error

This is a good demonstration of how short of memory we are getting.

 

[ShaunG]

sure is..guess we need more..as you suggested the next one up is about 20p more.

I have the code uploaded to the disco board, the pot working on contrast control etc.


should i see anything on the screen if the contrast is turned down until the black just fades??

going to post a pic shortly

 

[ShaunG]

 

[AngusMcDoon]

sure is..guess we need more..as you suggested the next one up is about 20p more.

I have the code uploaded to the disco board, the pot working on contrast control etc.


should i see anything on the screen if the contrast is turned down until the black just fades??

going to post a pic shortly

Does the contrast fade in and out when the pot is adjusted? Mine goes from all black to nothing.

Can you debug the code and break in main() and step over lines of code in main?

I usually at this point have to write a simple app that flips the values of each GPIO pin every second and check them on the pins on the display with a scope or multi-meter. I usually cock up a connection or two.

 

[ShaunG]

Contrast does go from blck to nothing using the pot, I will debug and see what happens..I used the wiring as per your previous post, which does seem different to that in the text file..which should I be using as the master wiring?

 

[mikefleetwood]

Ah... blue wire - should have used brown

 

[ShaunG]

Ah... blue wire - should have used brown

I know..I reckon that must be the problem

I can step into main.c and everything seems to be good...must be my connections

 

[AngusMcDoon]

Contrast does go from blck to nothing using the pot, I will debug and see what happens..I used the wiring as per your previous post, which does seem different to that in the text file..which should I be using as the master wiring?

Text file is out if date, I forgot it was there. I will update it now. Post is correct.

When you step through the code step into lcd functions lcd_send_command(), lcd_send_data() and lcd_init() and when you see comments like...

// /WR=1

check on the display with a voltometer that the value is actually at the correct value after the line of code following.

 

[AngusMcDoon]

I know..I reckon that must be the problem

I can step into main.c and everything seems to be good...must be my connections

Don't forget I don't actually have the display you have, I have the older version. There may be timing differences. It doesn't matter how slowly you drive these displays though, so you can always single step in the debugger every line of code that changes a port C value.

 

[AngusMcDoon]

From your picture, I'm not sure what the line from 5V to PB9 is.

Also on the mid-right hand side there are pins PC0, PC1, PC2, PC3 which all need connecting. It looks like you have only 3 wires here.

 

[ShaunG]

The 5v line to pb9 is 5v from disco board to power line on breadboard giving the rest of the board 5v (it is in 5v even though it looks like pb9

I have re-wired and corrected some mistakes, that will teach me for not writing down a pin out, I have the following

Fg 0v
Vss 0v
Vdd 5v and upper pin of pot
Vo middle pin of pot
Wr pc10
Rd pc9
Ce 0v
C/d pc8
Nc not connected
Reset pc11
Db0-db7 pc0-pc7
Fs 0v
Vout lower pin of pot

Does this seem right..

 

[AngusMcDoon]

The 5v line to pb9 is 5v from disco board to power line on breadboard giving the rest of the board 5v (it is in 5v even though it looks like pb9

I have re-wired and corrected some mistakes, that will teach me for not writing down a pin out, I have the following

Fg 0v
Vss 0v
Vdd 5v and upper pin of pot
Vo middle pin of pot
Wr pc10
Rd pc9
Ce 0v
C/d pc8
Nc not connected
Reset pc11
Db0-db7 pc0-pc7
Fs 0v
Vout lower pin of pot

Does this seem right..

Looks right.

 

[ShaunG]

In that case I think I may leave it for tonight...I am on re wire 37 and no joy..each time I have found a mistake in what I have connected...I think that it's right this time but I thought that the previous 36 times

I can step into the code and see the LCD, wr1, change state section, pc 10 hits first, what am I looking for, a voltage between pc10 and ov?

 

[AngusMcDoon]

In that case I think I may leave it for tonight...I am on re wire 37 and no joy..each time I have found a mistake in what I have connected...I think that it's right this time but I thought that the previous 36 times

I can step into the code and see the LCD, wr1, change state section, pc 10 hits first, what am I looking for, a voltage between pc10 and ov?

For a line of code line this (for example) ...

// /WR=1
GPIO_SetBits(GPIOC, GPIO_Pin_10);

You need to connect a multimeter between OV and the /WR pin on the display and check that the voltage after you have stepped over the line of code is correct, i.e. 3.3V in this case. The voltage won't necessarily change because the port output may have been high already. In code like this...

// /WR=0
GPIO_ResetBits(GPIOC, GPIO_Pin_10);
// /WR=1
GPIO_SetBits(GPIOC, GPIO_Pin_10);

you should definitely see a change as we are setting the output low and then high. You should check the pin on the display, not on the processor pin, because then you know that you have got the wiring correct.


If you put a breakpoint on line 145 of lcd.c and single step over the next 4 lines then you can check C/D as well.

 

[ShaunG]

For a line of code line this (for example) ...

// /WR=1
GPIO_SetBits(GPIOC, GPIO_Pin_10);

You need to connect a multimeter between OV and the /WR pin on the display and check that the voltage after you have stepped over the line of code is correct, i.e. 3.3V in this case. The voltage won't necessarily change because the port output may have been high already. In code like this...

// /WR=0
GPIO_ResetBits(GPIOC, GPIO_Pin_10);
// /WR=1
GPIO_SetBits(GPIOC, GPIO_Pin_10);

you should definitely see a change as we are setting the output low and then high. You should check the pin on the display, not on the processor pin, because then you know that you have got the wiring correct.


If you put a breakpoint on line 145 of lcd.c and single step over the next 4 lines then you can check C/D as well.

I can see wr and c/d changing voltage...I guess I need to work through all the pins and test...sounds like a job for tomorrow

 

[sarabande]

OK, this is going to show my ignorance, but...

Would a Raspberry Pi be a good "driver" for this unit ? Good open source knowledge and support available: increasing number of apps available; perhaps more scaleability than the present chip (IT projects always seem to end up using a couple of factors more processing power than first envisaged. )

There might also be support from one or two university electronics departments, and perhaps e.g. Plymouth or Southampton with their yacht design departments.

It might mean taking the project a bit wider than the forum, though, with issues for NDA, design registration, issues of electronic interference.

Or go small, go quick ?