Matrix user forums

Will that translate to the i2c version too? If so, the more features the better.

Might be worth looking at circle drawing algorithms such as Bresenham's circle algorithm,
as it uses integer maths and, especially with small circles/low pixel density,
symmetry is more important than accuracy

I'll have a go testing the new component this weekend and yes LeighM (I guess Leigh is your first name and that your last name starts with M but reading it like Leighm does sound like "Lame" ) my symmetry OCD and I think accuracy can take a backseat at low pixel count (the pixel density, or dot pitch, is actually pretty high on these small OLEDs)

Will that translate to the i2c version too? If so, the more features the better.

Here's the I2C component with the additional macros. Let me know how you get on.

Coincidentally I was only this week looking to see if there might be a sizeable touch-sensitive display to code up and use for some new test equipment - and beyond.

I for one will be watching developments as they mature. I wouldn't want to get the case machined and all eyes on the delivered unit, only to be greeted by a box with an embarrassingly-blank display and a few last-minute bodge-buttons thrown in


All the best,

Brendan

Benj wrote:

how would you suggest I go about printing the degree symbol on the display?

The easiest way to do this is to override one of the fonts in the GLCD base font library. To do this click the View menu and bring up the component debugger window. Tick the Expose full component tree checkbox and this allows you to explore all of the components packaged inside the GLCD component.

On the properties window select the drop down list at the very top of the window and select the ASCII2 component located inside the GLCD component.

Change the integer properties from this

Code: Select all

0x36 , 0x49 , 0x49 , 0x49 , 0x36 ,0x06 , 0x49 , 0x49 , 0x29 , 0x1E ,0x00 , 0x6C , 0x6C , 0x00 , 0x00 ,0x00 , 0xEC , 0x6C , 0x00 , 0x00 ,0x08 , 0x14 , 0x22 , 0x41 , 0x00 ,0x24 , 0x24 , 0x24 , 0x24 , 0x24 ,0x00 , 0x41 , 0x22 , 0x14 , 0x08 ,0x02 , 0x01 , 0x59 , 0x09 , 0x06 ,0x3E , 0x41 , 0x5D , 0x55 , 0x1E ,0x7E , 0x09 , 0x09 , 0x09 , 0x7E ,0x7F , 0x49 , 0x49 , 0x49 , 0x36 ,0x3E , 0x41 , 0x41 , 0x41 , 0x22

To this

Code: Select all

0x36 , 0x49 , 0x49 , 0x49 , 0x36 ,0x06 , 0x49 , 0x49 , 0x29 , 0x1E ,0x00 , 0x6C , 0x6C , 0x00 , 0x00 ,0x00 , 0x02 , 0x05 , 0x02 , 0x00 ,0x08 , 0x14 , 0x22 , 0x41 , 0x00 ,0x24 , 0x24 , 0x24 , 0x24 , 0x24 ,0x00 , 0x41 , 0x22 , 0x14 , 0x08 ,0x02 , 0x01 , 0x59 , 0x09 , 0x06 ,0x3E , 0x41 , 0x5D , 0x55 , 0x1E ,0x7E , 0x09 , 0x09 , 0x09 , 0x7E ,0x7F , 0x49 , 0x49 , 0x49 , 0x36 ,0x3E , 0x41 , 0x41 , 0x41 , 0x22

The change is the 4th character in the ASCII LUT where each character consists of 5 bytes equating to the pixels in each column.

0x00 , 0xEC , 0x6C , 0x00 , 0x00 => ;

to this

0x00 , 0x02 , 0x05 , 0x02 , 0x00 => °

This then overrides the ';' character to the '°' character and should also work in simulation.

You can then use things like this in strings: "Temp = 23.4;C" to achieve the following on the display.

Temp = 23.4°C

And you can keep the display I sent you. This works so well that I'm buying plenty more

Thank you very much, much appreciated and should allow me to use it as a test bed to sanity check I don't break things in new releases.
I have just shown it to my MD and he is keen on using them for something

How would I go about making this permanent? Now I have to change the ASCII2 settings every time re-open Flowcode or it will revert to ";"

Hello,

Right the ASCII2 component is held in the GLCD Base component which is dynamically called which is why your settings are not being retained when reloading the project.

You basically need something to automatically override the ASCII2 setting for you, luckily Flowcode can now do things like this.

In the example below I have added an Ev_Start macro and assigned this to run for the events Compile -> Start and Simulation -> Start using the events tab of the project explorer window. This way no matter if you run the sim or download to chip after opening the project the settings will have been restored before your code is executed/compiled.

You can copy the contents or export/import the Ev_Start macro into your project but remember to assign the start events to it to allow it to function. Also remember to change the initial calculation to assign the .Hand variable the correct instance of your specific GLCD component.

Hi Ben,

I cannot get your example to compile and I get the same exact problem when following your instructions with my own program and the SSD1306 component

Glcd_Ascii_Init_Demo.c(1906:13): error: unknown identifier 'FCV_GLCD_EBM001'
Glcd_Ascii_Init_Demo.c(1906:13): error: invalid operand 'FCV_GLCD_EBM001'
Glcd_Ascii_Init_Demo.c(1906:11): error: failed to generate expression

Also, I don't understand the reason for the .Str[20] variable or the calculation ".Str = "Hi" "

Any suggestions?

I believe I fixed it.

Here's the fixed version that will compile and I did get it to work on my hardware as well (using this macro in my program)

I've put comments in the attached example program.

Two other displays I would like to use are these two:

5.0" inch TFT LCD module CPLD SDRAM 800x480:
http://www.ebay.com/itm/121186430206?_t ... EBIDX%3AIT

3.5" inch TFT LCD module w/Font IC 480x320 :
http://www.ebay.com/itm/121057702584?_t ... EBIDX%3AIT

Both are supported by the UTFT library I think so there are code ready to use.

I have the hardware so I can do some testing.

Thanks, they looks like great displays.

I'll see if I can dig out some working code for them. If you know of any code that's known to work with these then that would be appreciated.

Thinking about it there might have been something in the pack of code you gave me originally? I'll re-check.

The UTFT library, which I included in the zip-file has the code examples for these two displays

They seem very nice and fast.

I'm looking at the larger display and it seems to not match up with the software.

The software looks like a standard serial based display but the datasheet shows the display as a parallel data input which will require many pins to control it (31 I/O by my count).

Have you got the screen working now and are you using a serial or parallel type interface?

In the Ebay listing for the 5.0" display it says:
"The LCD module support Henning Karlsen's UTFT library, which can be downloaded here:
http://electronics.henningkarlsen.com/
To run the demo, just choose Demo_800x480 and adjust LCD module name to CTE50CPLD"

And I did have a go at getting this display up and running a couple of months ago but I couldn't. There were a lot of pins yes so 31 sounds correct. I didn't try to use the touch screen functions but it would be nice to have the option even if it uses several IO pins.

Hello,

I'll keep on with this but the library is pretty epic with lots of ifs and buts so not going to be a quick one to churn out and cannot really justify this to my boss at the moment with all the other work on. Might give it a go one night if I get some free time away from my 3D printer.

Would you be willing to send over one of the displays for testing. This will likely inspire me to dig in and get the work done.

I totally understand and to be frank, I would prefer to see a component made for the NRF24L01+ to get nice and cheap wireless communication going

If you think this display is worth persuing I can send you mine. I have one of each. But the 31 IO pins is kind of discouraging. Maybe there's other displays with built in SDRAM and Font IC that uses far less IO pins? Short of using a huge dsPIC I can only see a hand full of uses for which one can justify 31 IO's for the display.

I think it's main selling point is the size of the display. However with PIC and AVR the refresh will likely be quite slow. The built in paging will help this a lot but it will still be slow. One of the newer and faster dsPIC or ARM might be able to do a bit better but I still think this is more of a display for a Processor with tonnes of Processing muscle and tonnes of I/O i.e. intel / amd.

It's certainly possible to do but as you say so many I/O kinda puts you off. I suppose as the Arduino Mega offers so much I/O on a single port it might be worth doing a component just for that. If your willing to send me yours then I will put it on the list as something to do and make sure it gets returned as soon as were up and running.

Let me refresh my memory on the wireless comms module. I'm currently looking at re-versioning the Wifi E-block so might be a good time to think about switching.

Well the Wifi component is still needed (I just bought two expensive Wiznet modules) so any improvements are welcome
The NRF24L01+ is not really wifi even if it uses the 2.4Ghz band. IT is quite powerful and VERY cheap. I think it maxes out at 2Mbit or something. Plenty for most 8-bit and 16-bit projects I would think.

Wifi module looks very good, I've personally just bought 10 of them

The problem comes that we would have to write our own TCP/IP stack to allow the module to filter out messages etc. Might not be too big a job so I'll have a play and see what comes of it.

Are we talking about the same modules?

The current WIFI/WLAN component is for the WIZ610wi module from WIZnet right? I have bought two of those, quite expensive and may be end of life soon.

But the component I hope you'll create is not TCP/IP based I think:
https://www.nordicsemi.com/eng/Products ... /nRF24L01P

"The Nordic nRF24L01+ is a highly integrated, ultra low power (ULP) 2Mbps RF transceiver IC for the 2.4GHz ISM (Industrial, Scientific and Medical) band. With peak RX/TX currents lower than 14mA, a sub μA power down mode, advanced power management, and a 1.9 to 3.6V supply range, the nRF24L01+ provides a true ULP solution enabling months to years of battery life from coin cell or AA/AAA batteries. The Enhanced ShockBurst™ hardware protocol accelerator offloads time critical protocol functions from the application microcontroller enabling the implementation of advanced and robust wireless connectivity with low cost 3rd-party microcontrollers.
The Nordic nRF24L01+ integrates a complete 2.4GHz RF transceiver, RF synthesizer, and baseband logic including the Enhanced ShockBurst™ hardware protocol accelerator supporting a high-speed SPI interface for the application controller. No external loop filter, resonators, or VCO varactor diodes are required, only a low cost ±60ppm crystal, matching circuitry, and antenna.
The nRF24L01+ is available in a compact 20-pin 4 x 4mm QFN package."

I think so

The wiznet module is a 2.4GHz transciever with a inbuilt TCP/IP stack that allows Wifi data filtering based on the destination IP address.

The module you are suggesting can likely be used as a very basic transciever quite easily. With the addition of a software TCP/IP stack it becomes more or less the same as the Wiznet module. At least that's my current understanding, I have been wrong about these kind of things before.

I suppose I'll start out getting the basic transciever comms up and running and then if I'm right I'll have a go at doing the TCP/IP stack.

Ok, I had no idea that they could be used for 802.11x networks, that would be so cool! I would be happy with just being able to communicate between identical modules. Finally a cheap way to implement internet of things

Hello,

My modules have just arrived so done a bit more digging around them.

I'm currently only going via other peoples comments but looks like you can't use the module for Bluetooth or 802.11 Wifi comms which is a shame. Still for the price they are great little modules for communications. I'll keep digging and have a play with the Arduino library to see how much work it would be to get them brought into Flowcode.

Some users have used a raspberry pi as a go between so presumably you could do the same thing with the TCPIP or Wifi E-blocks.

uC -> nRF -> nRF -> RaspberryPi -> Router -> Internet

Shame though as this would be so much neater.

uC -> nRF -> Router -> Internet

I've got a set of those, keep looking at the datasheet then my mind explodes , when you look at the arduino demo, you think oh looks simply then you look at the lib files and think that can wait a while

Had a look at the utft lib and the clpd file looks ok to convert, may have a go sometime but i dont have a display

Hyperion have you got one of the tft's that was asked about the other day ILI9341 if so can you test the component benj posted the other day(mines on a slow boat fron china)

Regards
Dazz

Sorry I don't have that ILI9341 display

Regarding the nRF datasheet I would have to agree, I just couldn't wrap my head around it. But maybe one could do this Ben: uC -> nRF -> nRF -> uC -> WIZnet module -> Router -> Internet?
A form of gateway.

For those of us that haven't played around with RaspberryPi.

Sure it's not as neat as uC -> nRF -> Router -> Internet, but still cheaper than putting a WIZnet module on every node/sensor/controller/etc