• Welcome to Andy's Workshop Forums. Please login or sign up.
May 18, 2024, 01:46:44 am


SMF - Just Installed!

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Andy Brown

General discussion / Re: TFT library speed
February 12, 2015, 02:34:19 pm
Hi Dean,

If you've got enough memory for a full frame buffer and you have enough speed to beat the refresh cycle (about 1/60s) then the ideal method is to synchronize your upload with the TE signal and just refresh the entire display. My FPGA graphics accelerator refreshes the display like that.

The truth is that MCUs are not FPGAs and don't often have the raw grunt to do a full refresh at the required speed so your method of keeping a 'dirty' map seems worth trying. You'll solve the worst flashing visual effect but will still get 'tearing' because you won't be fast enough to avoid the refresh cycle.

I'm not familiar with the Due but if it has an external parallel interface then you might be able to make it fast enough. SPI will be a non-starter. Way, way too slow.

- Andy
I just published an article documenting a little project that's designed to bring powerful graphics display abilities to the 32Kb Arduino Uno R3 by using an STM32 F0 as a graphics coprocessor. As usual there's full documentation, videos, source code and gerbers available for you to build your own shield.
QuotePlease put a heatsink on that porocessor


That CPU is undoubtedly entering thermal shutdown and will eventually be permanently damaged. A heatsink with active cooling rated for at least the TDP of the CPU is mandatory.
Ah yes, HWmonitor shows mine as well and those sensors are actually on the DIMMS which is great. I'm getting mid 40's while idle with 24Gb (which fills all alternate slots). Half mine have heat spreaders and half don't.

For fun I just kicked off a video rendering session and the bare DIMMs are hovering at around 53/43/53. Those with spreaders are running at around 46/41/46 which does fit with Micron's presentation that indicates the spreaders are worth about 5C benefit. None of those temperatures concern me in the slightest. If I see them get into the 70s then I'd be concerned.

Before I go back up to 48Gb I'm going to rig up a pair of these (attached) to blow down on to the DIMMs from above. Not entirely sure how I'm going to fix them yet but it's probably going to involve fitting them with right-angle brackets to the roof of the case.
I don't know what the temperature was when I had all 48Gb installed - where are you finding live RAM temperature readings and where's the sensor positioned? DDR3 DIMMs are rated for 85C at the case (the plastic IC case) so if your 50C is a true reading then you're some way off the maximum safe level.

This is a great presentation from Micron on DDR3 thermal characteristics that's heavy on evidence and light on theory so it's easy to read. The most interesting part I thought was the effect of the heatspreaders in conjunction with airflow and DIMM spacing.
Quote from: Marco Silva on February 02, 2015, 02:18:02 pm
Now it's too late for me, but it's good news for anyone else interested in a set :)

Looking forward to terminate this build, it has been a long journey and it's not finished yet.

I've ordered one; it can't hurt to have a spare. Besides I'm working on upgrading my 002 board to a full 003 BIOS and I'll need a cable to check out the results. Whether it works, or if I create an expensive brick with an HP label on it, I'll be sure to post the results and a how-to on my site.
Quote from: mariusl on February 02, 2015, 07:05:31 am
I did not manage to get the debugger working as Andy describes but I used this tutorial to get going.


I have not done a lot of debugging so I don't know how good it is but the button example works well with break points.

Good to hear that you've got debugging working and that you can link OK. Once you're up and running with breakpoints working you're home and dry as far as debugging goes. Please let me know if you need any more assistance.
Quote from: Marco Silva on February 02, 2015, 01:42:10 pm
It's been a while since I've placed my order for the connectors on the taobao agent....after some miscommunications the connectors finally arrived at the agent. Now I've paid the shipping and hopefully they wont be caught by the customs. I can tell you that this connectors as they sitt are already very expensive  :o

Well, time passes and now these connectors have shown up on Ali Express. If you search for "z800 power cable" then there they are.
Quote from: digitaltrousers on February 02, 2015, 01:25:38 am
Hi Andy. Out of curiosity, was the faulty DIMM a genuine HP one, like those of your first batch? Did it have a heatsink like those original ones?

I've attached a photo of the faulty one. I think these are commonly installed into HP and Dell servers.
I'm assuming that the library has actually been built first before the example for the MCU that you're compiling against - each project (including the library) has multiple MCU targets.

That being the case it's probably the workspace-relative paths that I've configured in Eclipse. For example, on an F4 build the examples linker search path is:


That means you must have a project called 'stm32plus' (the library) in your workspace and it has to have been built for the F4 which will have produced output in the Debug_f4_168 directory. Does this match your workspace?
Yes that's it; the STM32PLUS_BUILD macro is the correct way to identify the version.
Hi Pratip, I do this all the time to get a project up and running quickly:

  • Copy the entire example folder in question to a new one. e.g. make a copy of the "blink" folder and everything in it to a new folder. Do it from Windows explorer or bash "cp -r".

  • Go into the new folder and rename "blink.cpp" to whatever you want.

  • Edit ".project" and right at the top change "<name>stm32plus-examples-blink</name>" to the name you want for your project in Eclipse.

  • Delete any sub-folders called "build" or "Debug_*" because they contain output from the copied project that you don't want.

  • Go into Eclipse and use "File -> Import -> General -> Existing Projects into Workspace" and point Eclipse at your new folder.

That's it, all done.
Hi Dan,

Sorry to disappoint but E49 clears the BIOS password. I did however get my 002 board out of storage and have a poke around with my multimeter; the results of which are now posted in the main article.
That looks excellent, it does fit very well in that case. Smart move with the nuts and bolts that allow you to nudge the board a few mm to get it perfectly positioned - I mentioned in the article that I should have done that with mine.

Is there any room for fans in the roof of the case? I notice that you have fully populated memory slots and that's going to generate some heat that'll need removing from that area.
A few people have asked me if I was willing to extract the BIOS image from my Z800 revision 003 motherboard, the idea being that the image would contain the important bootblock that permits flawless booting from the Westmere X56xx series of hex-core Xeon's.

After doing a bit of research it became clear that BIOS images are mapped into physical memory with the location being dependent on the chipset and the size dependent on the SPI flash device that holds the BIOS image.

Fortunately a very useful utility exists for linux, called flashrom. I ran that on a physical installation of Ubuntu (it won't work properly in a VM) and it seemed to extract an image. Here's the log:

ubuntu@ubuntu:~$ sudo flashrom -p internal -r bios.bin
flashrom v0.9.6.1-r1563 on Linux 3.13.0-32-generic (i686)
flashrom is free software, get the source code at http://www.flashrom.org

Calibrating delay loop... OK.
Found chipset "Intel ICH10R". Enabling flash write... WARNING: Setting 0xdc from 0x2 to 0x3 on ICH10R failed. New value is 0x2.
WARNING: SPI Configuration Lockdown activated.
PR0: WARNING: 0x001f0000-0x001fffff is read-only.
Please send a verbose log to flashrom@flashrom.org if this board is not listed on
http://flashrom.org/Supported_hardware#Supported_mainboards yet.
Writes have been disabled. You can enforce write support with the
ich_spi_force programmer option, but it will most likely harm your hardware!
If you force flashrom you will get no support if something breaks.
PROBLEMS, continuing anyway
Found SST flash chip "SST25VF016B" (2048 kB, SPI) at physical address 0xffe00000.
Reading flash... done.

The 2Mb BIOS image is attached to this post. I hope someone can make use of it and would really like to hear any experiences.