cheaper large instrument displays - mast mount

[AngusMcDoon]

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 ?

I think we have been through this many pages back. In my opinion - no, it's not suitable, for the following reasons...

1) It's way over specified for the job.

2) It is far more expensive. A STM32F100 processor costs about £2, and a PCB to mount it on will be a pound more in small numbers.

3) The RP is power hungry compared to the STM32 processors. If you have 4 of these the power consumption will add up.

4) The RP does not have enough GPIO pins for all the connections we need.

5) RP foundation are talking about a LCD in the future, but it won't be at all suitable for our needs, i.e. sunlight viewable, cheap, low power.

6) The RP does not have the interface circuitry that we need (for example line drivers), so a PCB will be needed with this extra stuff on anyway.

If a manufacturer was going to produce a mast display design there is a good chance that they would choose an ARM Cortex M3 (various manufacturers) as well for the above reasons. It's very easy to up the power/memory on the STM32 range, for example spend another 20p for a pin compatible processor. The reason we are using the current processor is that ST make a very cheap (less than £10) evaluation board which has flashing/debugging capabilities on the board. For a couple of pounds more they make a ARM Cortex M4 board which is way more powerful and featured.

I think a RP is more suited to projects like chart plotters.

 

[ShaunG]

now debugging, i have breakpoints set on the following section

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

I can see the pins on the LCD going from 0v to 3V (2.96V) in this section. However when entering debug mode the debugger does stop at the following section (uint8_t update_now=FALSE

int main(void)
{
uint8_t button;
uint8_t update_now=FALSE;

I will carry on debugging further Pins

 

[ShaunG]

ok..
Further debug results

PC8, C/D - All Good
PC10 WR - All Good
PC9, RD - All Good
PC11, Reset - All Good

All of these are changin from/to 0v and 3V

There is some change in the LCD, from a straight black line, to a solid black to a fuzzy sort of black (as though its trying to initialise but nothing is readable)

 

[ShaunG]

stepping over each line in Main.c i do stop at

serial1_send_string(" Initialization complete\r\n"); and cant seem to go any further..

 

[ShaunG]

the above looks like duff info...a clean build and download allows me to pass that section

 

[AngusMcDoon]

In lcd_init() in lcd.c after GPIO_Init(GPIOC, &GPIO_InitStructure); it may be worth putting in...

GPIO_ResetBits(GPIOC, GPIO_Pin_0);
GGPIO_SetBits(GPIOC, GPIO_Pin_0);
GPIO_ResetBits(GPIOC, GPIO_Pin_1);
GGPIO_SetBits(GPIOC, GPIO_Pin_1);
GPIO_ResetBits(GPIOC, GPIO_Pin_2);
GGPIO_SetBits(GPIOC, GPIO_Pin_2);
GPIO_ResetBits(GPIOC, GPIO_Pin_3);
GGPIO_SetBits(GPIOC, GPIO_Pin_3);
GPIO_ResetBits(GPIOC, GPIO_Pin_4);
GGPIO_SetBits(GPIOC, GPIO_Pin_4);
GPIO_ResetBits(GPIOC, GPIO_Pin_5);
GGPIO_SetBits(GPIOC, GPIO_Pin_5);
GPIO_ResetBits(GPIOC, GPIO_Pin_6);
GGPIO_SetBits(GPIOC, GPIO_Pin_6);
GPIO_ResetBits(GPIOC, GPIO_Pin_7);
GGPIO_SetBits(GPIOC, GPIO_Pin_7);
GPIO_ResetBits(GPIOC, GPIO_Pin_8);
GGPIO_SetBits(GPIOC, GPIO_Pin_8);

and stepping over each line and testing the DBx pins on the display to make sure all the data lines are connected correctly.

 

[ShaunG]

i dont know what i have done, a clean and rebuild followed by stepping through line by line and

its working !!!!!! although i do wonder if i have a duff LCD as there is a line through the middle of the screen

 

[ShaunG]

now to see if i can connect up some buttons

 

[ShaunG]

Angus....your frankly pretty amazing

 

[Jabamusic]

Watching (lurking) with mouth agape with what you guys are doing/achieving.

Well done!

Looking pretty damn good.

 

[ShaunG]

buttons sussed out

 

[AngusMcDoon]

Congratulations! Those displays are pretty robust and can take mis-wiring. I've done it a few times. You do have a faulty display though with the line missing. RS will replace that without quibble. If you look at my pictures 3 pages back you will see I also have a vertical line missing, but my display is a decade old.

 

[ShaunG]

Thanks Angus..I will Give RS a shout and see if they will replace it

I now have the buttons working (i finally managed something on my own)

whats next on the list of things to do???

 

[AngusMcDoon]

whats next on the list of things to do???

Connect a MAX232 and its capacitors and start sending some NMEA messages from Hyperterm (if you have XP) or download PuTTY if you have a later version of Windows. NMEA data input goes into pin PA3 (via the MAX232 line driver).

For real NMEA we will eventually fit a RS422 line receiver, but RS232 will do for now.

 

[ShaunG]

Will do...will be at the boat this weekend so should be able to collect a load of nmea data

I have xp, win7 and Linux so should be good on serial..I will run through the code and try to work out what pins to use for the serial and wiring the max232

It looks like I need max232a and a bunch of 0.1 uf caps, or a max232 with 1uf caps, is this correct?

The screen is ok, a little reflective and not the widest viewing angle, the contrast range adjustment is very slim, not a lot either way between black and nothing...

 

[ShaunG]

Looks like its this one

http://uk.rs-online.com/web/p/line-transceivers/1951195/

And 4? 1uf caps

 

[AngusMcDoon]

Those LCD screens tend to look better as the light gets brighter - at their best in bright sunlight or complete dark with the backlight.

That's the line driver. Wire up the caps as on page 6 of the datasheet getting the polarity of the caps right. Note that the +/-8.5 volts on pins 2 and 6 of the MAX232 are outputs that you don't connect to anything (other than the caps on those two pins).

Then connect pin 3 of your RS232 to pin 8 of your MAX232, pin 5 of your RS232 to your ground common to the processor and the MAX232, and pin 9 of the MAX232 to pin PA3 on the processor.

 

[ShaunG]

Thanks Angus...will get those bits together...I may ges a max233 as well to save breadboard space..no caps needed then

 

[ShaunG]

I will try the LCD in the sunlight tomorrow and try to post some pics taken with a decent camera..and eventually with the backlight...reading through your code it looks like Pwm for the backlight?

 

[ShaunG]

I have been playing with the menus a bit, the 3 user definable presets that are accessible from the buttons (the 3 presets can be set from the menu)

What a brilliant idea, why has no one else done this already..absolute genius idea Angus and could sell a shed load based on this alone...other manufacturers should take note