Major CODE UPDATE (04/01/13)

I purchased one of these and have tried compiling and running some basic serial programs with the mbed compiler. Works Brilliantly! Is this something you plan to create a library for the board based on the MBED libraries? I dont use the lpcexpresso stuff but this board works with MBED so that was the purpose for me of buying it.

Good Work!

There is some info about using other PHYs on this page: http://mbed.org/forum/mbed/topic/3684/?page=1#comment-18473 See Emilio's comment.

I have used the Landtiger LPC1768 board from the same manufacturer as the mini-DK. The mbed code runs fine on that board too. Just note the differences in pins (eg LEDs) and remember that you dont have the mbed interface chip which means that localfile, serialnumber and the derived MAC address are missing. See http://mbed.org/users/wim/notebook/landtiger-baseboard/

Thanks for the info. If i understand correctly, all i need to do is finding/creating a new lpc_phy_DM9161.c or check both existing lpc_phy_...c files for compatibility (never did this before - don't know how hard it will be)? The Emac.c and .h files i found in the Keil sample code have all the DM9161 registers described, so i think i'll start from there.

Matt, I published my current code. I switched back to the default SPI interface (Peter Drescher's code uses DMA) but it does run at an acceptable speed. The demo in main.c shows some text and graphic possibilities (copied from Peter Drescher's sample code) + a RGB demo and a simple sketch tool (touching the bottom area just outside the LCD area allows you to clear the screen).

Porting the code back to mbed was troublesome (as was porting from mbed to LPCXpresso). Man, i wish compilers were more compatible (i know there's something as 'writing code for portability' but still, when code for the same platform is ported from one compiler to another, it should compile without problems).

Beware that this project is still under heavy development: I still need to optimise the code, remove global variables, add more comments, add ethernet functionality...

Frank

I get several errors when I try to compile this project. I will attach the image of the errors. Any thoughts on why I cannot compile?

Hi Matt,

You only have one error and several warnings. For now, ignore the warnings. They also exist in Peter Drescher's project. However, i will look into these or perhaps get in touch with Peter to get them sorted out.

I ran into the same problem when i ported my code back to mbed: I created a new project (the compiler automatically inserts the latest mbed library) and copied all my LPCXpresso files into it. Compiling gave me the same error.

I found a similar topic at http://mbed.org/questions/141/m3pi-No-instance-of-constructor-mbedStre/#answer202. So i modified Stream(name) to Stream() in TextDisplay.cpp. The code compiled but, strangely enough, the Arial12x12 font did not display.

I managed to resolve the issue by importing Peter Drescher's micro paint (http://mbed.org/users/dreschpe/code/touch/) project, remove the mbed library in my project and moved the mbed library from the touch project to my project. Everything went fine.

Please check following items before you try this solution : 1. Did you import the entire project (either directly from the compiler or from the project page) OR 2. did you create a new project in the compiler and just copied the code OR 3.did you replace the mbed library file? (my guess is that you used the second option).

First, try to load the project again using the first option and compile again (i tested it, it works). If this does not work, then try the solution with the micro paint project.

I hope this allows you to resolve the issue - keep us posted.

My mini-dk is also on its way to me, so looking forward to trying this code.

Regarding the warnings, there were same ones in a related library, he fixed them quickly after a report. But it was just adding virtual keyword at the function it complains about in SPI_TFT, and moving the GraphicsDisplay to the front of the list in the SPI_TFT.cpp constructor.

Erik,

can you post the link where you saw the fix?

http://mbed.org/users/dreschpe/code/C12832_lcd/rev/6b96b16aad47

Was that library, links to the revision which removed the warnings (were different functions, but looks to be the same issue, just a virtual keyword lacking in a header file).

The declaration order apparently wasnt changed, yet the warning is gone. Dunno about that.

Frank Yes I downloaded the program and immediately updated the mbed libraries. I redownloaded the project and did NOT upgrade and it compiles. What changed? Weird.

Anyway I used FlashMagic to download it successfully but it doesnt do anything. When I reset the board it doesnt display anything at all.

Matt

Matt,

1. I mentioned a topic in my previous reply about the compilation problem (http://mbed.org/questions/141/m3pi-No-instance-of-constructor-mbedStre/#answer202). It seems the Stream() option has changed.

2. Did you convert the BIN file to HEX (Flashmagic only accepts HEX files)? I read several topics where bin2hex tools are available but some cause conversion problems (some have size limitations of 128KB, others do not use 32 bit by default). I know it works with Hex Workshop - tested with the trial version : File - Export - Intel Hex (32 bit). Perhaps other (free) HEX tools can do the same.

I have used the bin2hex for production boards so I know there isnt a problem there. I also have the full licensed version of flashmagic so that should be fine. It compiles fine and gives only the errors I mentioned above now.

I uploaded the working BIN and HEX files i last created with mbed : /media/uploads/frankvnk/lpc1768_mini-dk_lpc1768_from_mbed.zip.

Please try the HEX file and compare both files to your files.

Can you tell me where you obtained the bin2hex tool (or perhaps upload the tool) in order to allow me to give it a try?

Important note : The Mini-DK board is available with an SPI or parallel LCD. The code presented here only works with the SPI interface.

Frank How would I know which display I got? I dont see any distinct markings. That would be a bummer if it didnt work with the library you have created.

UPDATE: Well your hex file works on my board so I must have the same LCD. I dont have a clue why mine doesnt work when I compile it. I might try compiling it once more just to see. I will also compare the hex and bin files.

Matt

Well now I just get the following warnings when I try to compile my downloaded version from your import. Are any of these a problem even though they are just warnings?

Weird the two hex files look different.

below are the two hex files. One is larger and the actual content is pretty different. I have always used my bin2hex and not had a problem.

/media/uploads/buckeyes1997/mattslpc1768.hex

/media/uploads/buckeyes1997/lpc1768.hex

Below is my bin2hex file. I run 64bit windows so that version is for 64bit but always worked before. Rename from .txt to .exe to run.

/media/uploads/buckeyes1997/bin2hex.txt

Well I just looked at the file sizes and the bin2hex converted size is about 173kb and the file converted with objcopy is 206kb. The file you sent is also 206Kb. I think my version of bin2hex is not compiling the large file or something. I will continue to look into it but this is very strange. The objcopy must be 64bit because it works and produces good hex code.

The reason i mentioned both interfaces is because there are several E-bay shops where you can buy this board. I bought mine at Haoyu electronics (http://stores.benl.ebay.be/HAOYU-Electronics?_trksid=p4340.l2563). This was the only one mentioning a CD with source code and all cables were included (this was not the cheapest one but, for 2 Euros more, i found it the best buy). They also mention you can get a board with parallel LCD interface. I don't know if the other sellers also provide the CD and cables.

If your bin2hex tool is the one from KEIL (http://www.keil.com/download/docs/113.asp) then i can confirm it does not work (tried it myself with Windows XP).

Matt,

The warnings are due to the use of a window() function in both GraphicsDisplay and SPI_TFT. I already did a little research - it could cause some problems - need to investigate it further (perhaps get in touch with Peter Drescher for assistance).

Matt,

My hunch about the bin2hex tool seems to be correct. As i mentioned before, several of these 'older' tools have a size limitation and/or are not able to convert 32 bit binaries. I ran into the same problem, that's why i switched to the Hex Workshop trial (since HW is quite expensive, i'm still looking for a cheaper, if possible free, Windows tool).

Did objcopy create a working output?

Yes objcopy makes a working output.

c:\objcopy -I binary file.bin -O hex file.hex

must have objcopy installed before this works.

I can compile all of my normal binaries with my version of bin2hex and they work however maybe your project is larger than anything else I've compiled to date. Good to know objcopy works for all my old stuff AND the larger new stuff.

Matt

Teaches me to read all comments first. Just got my mini-DK, happily tried the code here, didnt do anything. But that was the same bin2hex problem.

As 'alternative' tool, if you have a version of AVR studio installed (for atmels), you should have the avr-objcopy tool. Same command as what Matt wrote, only don't use 'hex' but ihex, so:

avr-objcopy -I binary file.bin -O ihex file.hex

Thanks for the objcopy info.

Note that i also got the ethernet part working - see link at the top of this page : DM9161 Ethernet CODE - EasyWeb (21/12/12).

Please feel free to post any remarks/improvements for the current code (i know it still needs to be cleaned up).

For Bin to Hex conversions and vice versa i can recommend Hexplorer. It's a free tool for Windows with Hex editing capabilities and whole load of other functionalities. It can import and export a long list of Hex and Bin formats including Intel Hex and of course with support for the extended notation (so no 64KB- or 128KB-limit). Unformatted Bin is loaded simply with File->Open.

You can get it here: http://hexplorer.sourceforge.net/

Best regards
Neni

Won't be using ethernet myself (was in plan A via a wifly module, but I dont want RTOS and since its main goal would have been synchronizing the time I just use a radio time module).

Regarding your code, few ideas and stuff: You give p15 as reset for the LCD, but the reset is not connected, I cant also find in the code where it would actually be used, so I just put it on NC.

It might be an idea to split the touchscreen and the LCD libraries, since they dont have much to do with each other. They are only used both when calibrating, and then you could also give a pointer to the LCD in the calibration function.

Finally I just started a bit, will add more later, but I think it is handy to give the minis pins seperate names from mbed pinnames, since they arent really related:

#define DK_KEY1     P2_11
#define DK_KEY2     P2_12

#define DK_LED1     P3_25
#define DK_LED2     P3_26

#define LCD_SCK     P0_15
#define LCD_CS      P0_16
#define LCD_SDO     P0_17
#define LCD_SDI     P0_18
#define LCD_BL      P1_26

#define TP_IRQ      P2_13
#define TP_CS       P0_6
#define TP_SCK      P0_7
#define TP_SDO      P0_8
#define TP_SDI      P0_9

FYI, the LCD_BL pin (for backlight) works nicely with a PwmOut.

Edit: Another one. Downside of SPI compared to parallel is obviously the throughput rate, even with it set at its maximum it is simply slower. But it can be a bit faster than now: it writes 16-bit words by writing two 8-bit ones. However the SPI controller can also support 16-bit words.

Current code takes 232ms to clear the LCD. Using 16-bit SPI it takes 154ms, so not shocking, but a significant improvement. Only did it now for cls, a bit more will have to be changed, but it is fairly simple. Replace in the cls code the for loop with:

     _spi.format(16,3);
     
     for( index = 0; index<width()*height(); index++ )
     {
        _spi.write(_background);
     }
     
     _spi.format(8,3);

By using the SSPs fifo buffer it can probably be again a few ms faster. DMA would be nice too, but I dont think it is possible to use it when filling it with a single color, unless you have a whole memory block with that color like a bitmap. For writing bitmaps DMA should be the best solution.

Regarding bin2hex , It seems there is a "hidden" trick using these old tools , as mentioned in the options documentation! You have to apply the /4 option Get an updated BIN2HEX and use the /4 option for either 24 or 32bit addressing range, not the standard 16bit range. Example 'bin2hex /4 test.bin test.hex'. Have a look here as well ...

http://mbed.org/forum/electronics/topic/3291/?page=3#comment-18103

Regards, Christos

Got another one from the _putc routine in SPI_TFT.cpp

Main goal of the screen for me is to be a clock, and try letting it update for example time every second, it doesnt look good. As simple test you can let it update the same string in the same place at maximum speed, it should be a static screen, but it flickers.

The problem is the _putc routine in combination with the fonts. The arial28x28 fonts have a maximum size of 28x28, (or 27x28), and they are stored like that in the memory. However by far most chars are alot less wide, so if you write a '1' the next char wont start 28 pixels further, but for example only 10 pixels further. Still not really a problem, until you start overwriting your old string. When you have '12', and you overwrite that with '12', writing the '1' will also result in the left half of the '2' being removed, since that falls within its 28x28 box which it writes. Of course a fraction of a second later the '2' is written and everything is okay again, but you can see the display blink.

Solution is luckily fairly easy. In the _putc routine there is a variable 'w', which is the actual width of the char. Move its calculation above the command which sets the window, and then in the window function and in the loop replace 'hor' with 'w'. It is faster, and it gives a nice image without the flickering.

Thanks for the valuable info.

I will modify the character routine (called by putc) in SPI_TFT.cpp.

.

regarding your previous comment (http://mbed.org/comments/cr/83/2654/#c4754)

The ethernet code is not RTOS based. The 'quote of the day' example within this code can probably be modified to obtain the time from a time server.

The reset option needs to be removed. It is a leftover from my idea to modify the PCB: drive the reset pin from a CPU pin rather than having it connected directly to the main reset button.

My initial code contained separate TFT and Touch libraries but i ran into trouble when calling the LCD routines from within the Touch library. Perhaps this is a noob question (i'm still learning alot about C++), but can you tell me how to setup the pointer to the LCD library from within the Touch library?

The pin naming changes will be implemented and i'll also modify the CLS routine (a 34% speed gain is certainly worth it).

I did a test with your modification to the character (putc) routine using my sample code: the screen output gets garbled since you change a proportional font into an equispaced font. How did you output the time to the LCD: entire string with formatted printf or each digit separately? Can you post your clock code?

I think it is easiest if the code is in library form, so we can include one library like mbed.h, but then Mini_DK.h which includes everything relevant. I think you can then also include other people which can change the code in a repository, then several people here can make modifications.

Regarding a pointer to the LCD library, that should be something like adding as argument: TFT_LCD *lcd. Then in the code you can do lcd->_putc('a');. I know you can do it several ways, but for me it is also generally trial and error until I got it correct.

Also it isnt just CLS, that is the largest one, but every function which uses 'wr_dat_only' function benefits from it.

Finally the character routine. I also had the output garbled, my mistake was not also changing the window function with the new width. The output should stay exactly the same: the only change is you dont write a whole bunch of background space without need, but the place of each char stays equal.

My clock code: http://mbed.org/users/Sissors/code/Mini_DK_clk/

That includes some of the changes I started making which imo improve the readability of the code. I converted libraries back to folders since otherwise I already had to publish them. This has the faster cls routine (but not other wr_dat_only uses changed), different _putc and a single Mini_DK.h which not only has pin definitions, but also all other includes specific to mini_dk.

Has anyone tried with the mini-dk, or any other similar board, to use both the SD card and the LCD screen? Seperate they go fine, but if I try to use both at the same time the SD-card doesnt work. I already checked, they share the same SPI hardware, so something goes wrong there. Before I spend even longer attempting to fix it, anyone who knows a solution?

Edit: Okay I got it. Sadly putting it on different pins belonging to the same peripheral probably wasnt that great a design choice, it costs you pins and doesnt add anything besides more complexity to your code (it isnt like you can have them working in parallel, since they belong to the same peripheral). Anyway did some testing, and the mbed library sets the pinsel registers in the constructor, and after that ignores it. Result for TFT/SD is that they are both set as connected to the same peripheral. Lets go to the user manual:

In other words, SCK and MOSI arent a problem, they are connected to both. However MISO is only connected to the lowest one: guess which one that is, the LCD. So the output of the SD card is ignored.

Tried adding: (LPC_PINCON->PINSEL1) &= (0x0F<<2); into my code, which disabled TFT MOSI/MISO pins. And then indeed SD card works again. However the issue: what is easiest way to add that to the code? Can add it to the SPI write command, but that takes time and especially for TFT we dont want extra overhead. So probably best choice is adding it to the TFT/SD libraries, but how and where is something I have to think about.

Edit2: Eureka! Had it working with macros that completely disabled either the LCD or the SD SPI, and that worked fine, but of course not ideal. So plan B went to only disabling the LCD MISO, the spi controller then always drives both scks and mosis, of course _CS still determines which one is actually listening, and only the SD card could send data back. Since the LCD has nothing to send back (well its version number, woopdiedoop), that is not a problem, and this way we only had to include one macro at the beginning of the code and we could do everything. But then I realised there was a more elegant solution, simply in the LCD constructor give an "NC" for the LCD_SDO, and the MISO pin isnt initialized in the first place. So that way they both work at the same time without need for any special code.

Those of you who have used flashmagic to program the board, can you tell me what settings you used? I get an autobaud error whatever I try.

Cheers,

Matt

First, (if you are using Windows) check in device manager if the USB/serial device is correctly installed in 'Ports(COM &LPT)'- mine shows Silicon LabsCP210x... . Also note the COM port (mine is COM3). Make sure the USB cable is connected to the connector next to the LAN connector.

Next, in flashmagic, check if 'Communications' settings are correct : CPU type, COM port (make sure it is the one mentioned in device manager) and Interface (set to 'None (ISP)').

Last but not least : start at a low baudrate (i am able to work at the max. baudrate but i sometimes get a timeout - temporarily lowering the baudrate to 115200 or 57600 solves it).

The only other option i got checked is 'Erase blocks used by hex file'.

I hope this helps.

I generally get the error when I didnt put it in ISP mode with the buttons: Press reset button, press ISP button, release reset button, release ISP button. And the buttons arent the best quality there is, so sometimes it fails (when currently a program is running that uses the LCD screen you know it is reset when the screen blanks, since the screen is connected to the same reset pin, when you correctly enter ISP mode the screen should stay blank).

You can also check it by firing up random terminal program to correct com port, type '?', and it should respond.

And I dont know how it responds to the com port not being available, you would guess another error. But if not, did you install the serial drivers? Windows doesn't automatically install them (it will fail finding drivers, if you then press button to find solutions it will give you a link to the drivers on the manufacturers site).

Ahh, yes. I'd forgotten about the ISP & Reset buttons. :-)

That's got it working now, thanks.

It's too bad that the board doesn't use the RTS and DTR controls of the serial/USB port to reset and activate the ISP mode. All it takes are two transistors and small stuff for RS232 or just a simple connection using a resistor for the USB/serial converter. Flashmagic supports this feature and it will automate the reset/ISP procedure without pressing any buttons. Note that you can still use the buttons manually after the modification just as before. You can find examples of the circuitry in the schematics for the Keil MCB1700 or the Landtiger board. DTR drives reset, RTS will control ISP mode (p2.10).

Nevermind! ;-)

Just got my Mini-DK2 today. Very fun! At some point, it would be good to do a "getting started" page for this board. $40 with a touch screen is quite a deal.

All the info below was previously stated, but to make it easier to get started I'll try to summarize.

Drivers are on the Haoyu site, find your Com port, USB plugged into USB-Com, hold ISP button while resetting to put in ISP mode. As above, the Flash Magic settings that worked for me are as follows:

It appears to be very similar to the Blueboard, and someone else made a summary of differences so that Blueboard code can be adapted: http://foro.ieeeuah.org/index.php?action=printpage;topic=25.0 (use Google translate)

Which leads me to the following... I wonder if it's possible to use the Blueboard USB bootloader to turn this thing into a USB mass storage device that works with the mbed online compiler. That would really be cool. For reference, here are instructions for the Blueboard... http://shop.ngxtechnologies.com/download/header/LPC1768/BlueBoard_LPC1768_USB_BL_UM.pdf

I will mess around with this a bit, hopefully one of us can get it working if it's possible.

Hello all, so I've just received my board that I ordered, and I am trying to get it fired up. I have been developing code using Peter Drescher's code and the Freescale FRDM board, but thought this looked like a nicer all in one solution for the project I'm developing, plus the extra flash will come in handy for bitmaps!

I have imported the base library and copied my code in, and changed pin names where appropriate, but I can't get it to compile properly. I get a lot of errors about pins in the Mini_DK.h not being defined, and that "sector start address" is undefined, along with some flash start and end not being defined.

I am assuming this is down to the fact that my compiler device (top right hand corner) is set to Freescale KL25Z, and since I don't have an NXP board I can't change this. Is there any way to force the compiler to compile for the LPC1768 device rather than the KL25Z?

You are probably stuck unless you buy the mbed LPC1768 board. As an alternative, you can switch to Adam Green's offline Eclipse+GCC4mbed solution (http://mbed.org/cookbook/eclipse-for-building-and-debugging), but porting code to it needs a little more work since you can't export from the online compiler using LPC1768 libraries because you don't have the LPC1768 license (you need to download the code from the repo pages and import it manually into Eclipse/GCC4mbed).

Thanks Frank. I'll give the offline one a go as my code is pretty much ready for what I want it to do, so hopefully shouldn't need to add much more. I'll get an original mbed board eventually but right now I'm trying spend as little as possible!

Ewan,

What i forgot to mention: Use the mbed library delivered with the GCC4mbed+Eclipse download (there are some modifications).
There are some problems when the Mini-DK code is compiled with GCC4mbed : The screen ouptut is not always correct and there is more static when reading the touch data - haven't had the time to check what is causing this - need to debug with Adam Green's MRI (optimisation settings, modified mbed library, ...).

Hello again, I'm having a bit of trouble getting an image to display correctly but I can't figure out what is causing it.

I have the following image which I would like to display in the top right of the screen:

So I have converted the bmp to a C array using the usual method, and using the code:

extern unsigned char data[]; 

TFT.Bitmap(218,0,101,80,(unsigned char*)data);

But what I actually get displayed looks like it has started outputting the image part way through, then adds the beginning at the end:

The odd thing is, if I make the image smaller to 80x63px it works fine. Any ideas?

EDIT: I've cracked it, if the image has an odd width it doesn't seem to work properly, but if I resize the image to an even number width it works fine! I'm assuming its something to do with the way the bits are processed, but as long as you have an even width its fine.

Glad to hear you got it solved.
There was also a clue on Peter Drescher's page about checking the array size.
I should have mentioned it on this page and in the source code (sorry for that):

https://mbed.org/users/dreschpe/notebook/qvga-tft-with-hx8347d-controller/
How to transfer a graphic to the mbed ? mentiones we need to check if the resulting array size = x * y * 2.

On the other hand, i think there is a problem with Gimp + WinHex (or even HexEdit) when the array is created.
I found another program to convert a bitmap to C code at http://code.google.com/p/lcd-image-converter/.
This program creates a usable array even when the width is an odd number.
The only problem with this program is that the resulting color palette is incorrect.
This would be an excelllent replacement for Gimp + WinHex if we can solve the color palette problem.

Advantages of this program

• Small size.
• Only one program needed to convert.
• Powerful options to control the output.

Frank, is possible to use this on the KL25Z chip? I see I would have to specify the parameters in the IAP.h file. I do not need to copy graphics to the flash, only need text and lines, however total flash size is only 128k. My code takes around 50% flash and 10% Ram. Can I use Ram only rather than flash to drive the display? Reason is the chip is very low power and that's what I need.

Also one other general SPI question, is it possible to use the same lines for both LCD & TOUCH and seperate CS lines to direct the code to the relavent device?

(I have ordered one these Mini-DK's they look good!!)

All bitmap (flash related) code can be removed (or introduce conditional compiling) since the flash memory is only used for storing and retrieving bitmaps.
As for sharing the SPI bus using separate CS lines: This is possible but will slow down the LCD throughput. If you have spare pins on your KL25Z project, perhaps an interrupt driven softSPI would be another solution - I don't know which one will be faster but implementing the softSPI will probably be easier (provided you have enough free flash memory).
Another way to read a touch panel would be to directly interface to it as Peter Drescher did : https://mbed.org/users/dreschpe/notebook/touchscreen/
NOTE : The ILI9320 code uses Erik Olieman's burstSPI (https://mbed.org/users/Sissors/code/BurstSPI/) - I don't know if this has been tested on the KL25Z.

Thank you Frank, I have plenty of SPI ports on the KL25Z so I will connect individually. The speed of this display code is remarkable!

I see I can rem out the flash parts, however I have some errors on the BurstSPI.cpp file, indicating _spi.spi->SR has no member SR and _spi.spi->DR has no member DR. Would this be the LPC1768 SPI registers and therefor I would need to find the equivalent KL25Z registers?

Otherwise the code compiles for the KL25Z and I'm quite confident it will work apart from I will have to split the 16bit SPI writes and reads to 2 x 8 bit as Mbed defaulted the SPI to 8bit on this chip for some strange reason.

I have done this for another Chinese 1.8" LCD and it worked fine.

Paul,
All 16 bit SPI code needs to be changed to 2x8 bit.
As for the register set, this topic has a link to the reference manual : http://mbed.org/handbook/mbed-FRDM-KL25Z#c5697. Chapter 37 contains SPI info - page 661 describes the register names.
What I forgot to mention : The KL25Z has 2 SPI ports - info , see https://mbed.org/questions/557/No-access-to-SPI1-on-mbedFreedom-board-K/ and https://mbed.org/handbook/mbed-FRDM-KL25Z (•FRDM KL25Z User Manual). So there's no need to use softSPI.

Got my DK2 today :)

I carried out the following steps and works great.

1. install the cp210x usb driver (already installed on my pc)

2. download and install Flash Magic (see http://www.flashmagictool.com/)

3. download and install the ICY hexplorer as per Nenad's post, it runs okay on 64bit windows. (You can get it here: http://hexplorer.sourceforge.net/)

4. hold the 'ISP' button on your DK2 and plug into USB-COM to your PC

5. go to control panel and check the com port for the usb driver and set the baud rate to 115200 (make a note of the com port)

6. apply the settings in Flash Magic as per Arons post and set the com port to match your cp210x usb driver in step 5

7. compile your code in mbed and save the bin file to desktop or any other file location you use. (I tried Frank's code first to test)

8. start Hexplorer and open your bin file

9. export your file as an "Intel Hex" (using the .hex extension) file and save to desktop or any other file location you use.

10. using Flash Magic, browse to your exported hex file from step 9

11. click 'Start' on Flash Magic and the code will load and verify

12. unplug the DK2 and plug back in to reset

13. this is step 13 and may be unlucky for some, but if it has worked the DK2 will run your code

Here is a DCF77 clock code (set for UK time) that can be flashed using Flash Magic

/media/uploads/star297/dk_2_lpc1768_ili9320_dcf.hex

Connector P2.5 is the DCF signal input.

Something I noticed when trying the BURST fastWrite code on mbed and did mention to Eric.

Overwriting text will leave some pixels from the previous text. Eric suggested to change the following line in the CHARACTER function in SPI_TFT_ILI9320.cpp, changing the 'w' to 'hor'

<<for (i=0; i<w; i++) { // horz line>>

to this

<<for (i=0; i<hor; i++) { // horz line>>

I also found I had to change the following line

<<window(char_x, char_y,w,vert); // char box>>

to this

<<window(char_x, char_y,hor,vert); // char box>>

This has worked, tested for a few days now.

Just as a by-the-way, the BURST fastWrite code works very well with the smaller LCD display (HY-1.8 SPI) by adding in the BURST libray to the ST7735 library

Still having trouble getting it to work on the KL25Z cpu, if anyone has ideas please post.

Thanks for the notification - Library has been updated.

• Note :
  Future issues can be reported through the issue tracker - see Emilio's blog at https://mbed.org/blog/entry/Issue-Tracker/
  I already enabled the issue tracker for each library and code repo.

Frank, which variables can I define preset values in the Touch library to save calibrating the touch screen every time its reset? This only needs to be done once and I could define the preset values in the Touch.h file.

When you look at

void TouchScreenADS7843::TouchPanel_Calibrate(void) 

in Touch.cpp, the calibration data is stored in the matrix variable. This is the one you need to save/set.
Also note that this variable is declared in the protected area in Touch.h.
If you need it globally, move the declaration to the public area.
Adding an option to store the calibration data (either in flash memory or on SD card) is on my todo list.

Someone asked about a bootloader. Has anyone tried this with the mini-dk2? http://smoothieware.org/flashing-the-bootloader

Hello All!

I have recently purchased the LPC1768 Mini-dk and running into an issue.

When I got it out of the box from China, a demo program would run and the screen would work fine. But when I tried using Code Red Suite's Xpresso IDE to create a .bin , things went wrong... I accidentally tried flashing a .axf file, not a .hex file. That, obviously, didn't work.

Now the screen is always light up(color is white), even if I push the reset button, the screen will not turn off. I have tried to use the examples you all have provided but nothing seems to work! :(

I have been successful in getting an LED to flash on and off, so I didn't "brick" the device.

Any thoughts would be helpful!

I don't think loading/running the .axf file will damage the board or LCD.
A white LCD indicates the backlight is on (default) and/or the LCD is incorrectly initialised at runtime.
As a test, you could also try to switch the LCD backlight on/off (pin LCD_BL - see Mini_DK.h).
Also note there are 2 Mini-DK models available (depends on where you bought the board) : LCD with parallel or SPI interface. You can check this by looking at the label on the bottom side of the LCD (LCDB = SPI). It should be possible to check this without removing the LCD as the label is at the board edge on the bottom side of the LCD - facing towards the switches on the base board.
When you do disconnect/reconnect the LCD from the base board, take care to lift each side evenly. When you put the LCD back, double check if it is correctly fitted as it is possible to put it the wrong way around (the white arrows on the LCD need to match the arrows on the base board).
Did you get a CD with sample code when you bought the board? If so, it contains sample HEX files you can upload using Flash-Magic.

Frank,

Finally had a moment to look back here. Thanks for the speed response and apologizes for my lag.

I have the SPI version.

I'll try to see if the LCD responds to the backlight being turned on and off.

Report back later.

Again thanks for the speedy reply!

Edit:

Okay so it seems that the LCD screen is working. I got it to blink on and off with this code called "Hello World" from the online compiler community. Just had to change the "LED1" mapping in PinsName.h to the right pin for the back light control.

1. include "mbed.h"

DigitalOut myled(LED1);

int main() { while(1) { myled = 1; wait(0.2); myled = 0; wait(0.2); } }

This got the screen to blink on and off.

I also realized that I have the LPC1768 Mini-DK2, not the DK1. This could be causing me some of my head aches, though the data sheets for the two don't look that much different.

I'll see what the difference are and report back...

I'm having problems with my mini-dk and I was wondering if anyone could offer some advice.

I've installed the easyWeb code which displays the appropriate details on the display, but when plugging it into a switch it doesn't bring the port up. So there's no ethernet communications.

Is my board screwed up? Or am I missing a vital step?

Cheers,

Matt

What version is your mini-DK - I f it's the Mini-DK2, EasyWeb will not work as the PHY has changed from DM9161 to LAN8720A.
Compatibility between LAN8720A and mbed DP83848 is better - the mbed EthernetInterface lib can be used with this one with little modifications (see http://mbed.org/users/frankvnk/code/Mini-DK/ - 14/01/13).
As stated on the wiki page, to match your network setting, do not forget to change the IP adress/mask/gateway in tcpip.h?
When I tested the software, I always kept my lan cable connected.
Did you update the mbed lib to the latest revision or did you use the mbed lib from the download (rev : 54:71b101360fb9).
As I did not run it anymore since I published it, perhaps changes in the mbed lib are causing this problem?
If necessary, I can run a new test tomorrow and get back to you with the results.

Hi Frank,

It's the standard Mini-DK, not the DK2. I've updated my IP settings to my home network (172.16.0.0/24) however there's something wrong at the Ethernet layer, it's not even bringing up the port lights on the switch, and on the Mini-DK board Ethernet port the yellow light comes on, but not the green one.

I've tried different Ethernet cables and plugging into a PC as well as my switch.

.... And I've just made it work.

If I just plug it in and power it on it doesn't work, but if I hit the reset button then it works. Odd.

Matt

The reset issue is mentioned at http://mbed.org/users/frankvnk/code/LPC1768_Mini-DK_EasyWeb_DM9161/.
Something I forgot to mention In my reply, sorry for that.
As to pull the users attention to it, I'd better put this text in a warning block.