Messages

Hi Markus,

Yes there will definitely be a substantial overhead in using an ISR to manually toggle a GPIO output. Even if you stripped it right back to just your code inside the ISR then you're still going to be much slower than having the hardware do it all for you with a timer routed to an output pin. As you raise the frequency of your ISR eventually you starve the main code of cycles to the point where eventually it will not execute at all.

Last week I pushed a change to the master branch on Github that reduces the overhead of the library's ISR processing by a factor of 2 for the common case of just a single subscriber to the ISR so you might like to get the latest code to see if that helps you.

- Andy

There's a project in progress hosted on the hackaday website that shows a lot of promise regarding DSI. I was going to try it myself but given the size of the task and the fact that this project is well under way I will wait to see the outcome.

I have thought of driving the larger 7"+ LVDS displays with an FPGA - probably an S6 - and some SDRAM. Replacement displays for the old Asus netbooks are cheaply available on ebay.

[ILI9325Test]

Hi,

You mentioned in your other thread that you are using the STM32F103RB device. This device does not have the FSMC peripheral so you cannot use the ili9325 example 'out of the box'. All is not lost though because you can drive it using plain GPIO.

There is an example: hx8352a_gpio that shows how to use the GPIO driver. You will need to modify the ILI9325 example accordingly.

Copy the following enumeration to a public section of the ILI9325Test class. Change the port/pin mappings if your board does not expose the pins I've used:

Code Select Expand


    /**
     * Gpio16AccessMode is templated with the HX8352ATest class. Therefore it will expect to
     * find the following constants available for static access
     */

    enum {
      Port_CONTROL = GPIOE_BASE,        // will use [0..2]
      Port_DATA    = GPIOD_BASE,        // will use whole port as data bus D0..15

      Pin_RESET    = GPIO_Pin_0,
      Pin_WR       = GPIO_Pin_1,
      Pin_RS       = GPIO_Pin_2
    };


Change the LcdAccessMode typedef to look like this:

Code Select Expand


    typedef Gpio16BitAccessMode<ILI9325Test,COLOURS_16BIT,72,50,50> LcdAccessMode


Change the _accessMode declaration:

Code Select Expand


      _accessMode=new LcdAccessMode;


That's the most important stuff. You will also have to delete the parts of the demo that use DMA to transfer graphics to the LCD because DMA to the GPIO pins isn't supported.

The lzg graphics demo will not work without modification because the graphics are saved for a 262K colour depth and the GPIO driver is set to 64K depth.

[_Min_Stack_Size]

Hi Kemal,

You were right to modify the linker script. With only 20Kb of RAM I would recommend shrinking the _Min_Stack_Size as well, perhaps down to 0x200 (512 bytes). One issue might be your value for _estack (end of the stack). This value should point to the last byte in SRAM where the stack will start before growing downwards. Your SRAM starts at 0x20000000 and you have 20Kb of it so _estack should be 0x20004FFF.

I can't recommend a debugger highly enough. Do you have any of the *discovery boards around? There are hacks out there on the internet that document how to use these as a ST-Link debugger.

Regards,
- Andy

Cheers Phil, I'm glad you're there now. Any further questions, feel free to ask again.

It sounds like what you want to do is debug in a virtual STM32 environment without being physically attached to the chip, much like you can with some of the small 8 bit MCUs. I'm not aware of any product that will allow you to do that.

It sounds like you've almost got it all done. So you've built the examples in Eclipse and you're ready to debug.

Firstly you must have your hardware debug server running. For me that means OpenOCD because I use ST-Link to debug. You can also use OpenOCD with JLink (instructions here) but I believe that JLink actually comes with its own gdb debug server that runs in a window on your desktop - I saw it some years ago and assume that it still exists.

Anyway, to connect to the debug server you need to create a Debug Configuration in Eclipse. Select "Run -> Debug Configurations" and you should see "GDB Hardware Debugging" in the panel. Right click on it and select "New". You need a separate configuration for each program you create. I have literally dozens of these. The tabs that you need to fill in on the right contain the important settings for how to connect to the debug server and what commands to send to it.

If you scroll to the bottom of my ST-Link article you'll see screenshots of my own debug configuration. Bear in mind this is for ST-Link so some things may need to change on your system (e.g. the TCP port number of the debug server).

scons is not used at all in Eclipse, it's only used for command line builds and does not get mixed up in any way with the binaries that you build in Eclipse.

Please let us know how you get on.

Hi Kemal,

Welcome to the forum, I've moved your posts to a new topic for you so that we can work together on getting you started.

Hi,
what need to be changed on library portion or in example codes to work on an unofficial development board?
I am currently working with a board which has STM32F103RBT6 chip on it.

I just started with blink example, changed gpio.h in folder "f1hd" according to my boards LED pin (PA2).
changed code as below, even I have a successfull buil, nothing happed after flash.

Code Select Expand


GpioA<DefaultDigitalOutputFeature<2> > pa;
for(;;) {

        pa[2].set();
        MillisecondTimer::delay(1000);

        pa[2].reset();
        MillisecondTimer::delay(1000);
      }

regards,
Kemal

3rd party boards are fine, that's what I use when programming the F103. I'm assuming it's got an 8MHz external oscillator on the board.

Firstly, don't change "gpio.h". The files in there are the ST standard peripheral library and do not need to be modified unless you find a bug. I recommend that you restore the original files.

To test a LED blinker I recommend that you modify examples/blink/blink.cpp in the way that you have quoted here, build with scons and upload the hex file to your board. This is the basic sanity test. When you've got that going you have a known-good platform and can move on to editing and debugging in Eclipse.

I can reproduce that error on one of my laptops but it never happens on my main desktop or other laptop (all Windows 7). It'll be environment-related for sure. I'll investigate it. I noticed that if you clean the project (right-click on project, "Clean Project") then you'll be able to build it, but only once until you clean again. Very odd.

OK I've got to the bottom of that "multiple target patterns" error on Windows/cygwin and it was environmental as I expected.

The problem is that the GNU ARM Toolchain does not come with a "make" or an "rm" command, both of which are required by the Eclipse plugin that does the build. When you run the build it tries to execute "make.exe" and finds the default cygwin "make" executable that does not seem to be compatible with the makefiles generated by the plugin.

We need to install the missing executables ourselves. Follow the instructions on the plugin author's webpage to install cs-make and cs-rm. What I did is just copy and rename (remove the cs- prefix) the two executables into the ARM Toolchain bin directory (same directory as the arm-none-eabi-gcc compiler) and I didn't have to modify PATH settings in Eclipse.

However the next problem I ran into was that two dependent DLLs were missing (you get a cryptic negative error number from make which translates to 0xC0000135 which means a library couldn't be loaded). I needed to download this archive and copy libiconv2.dll and libintl3.dll into the same bin directory as "make" and "rm".

After all that it worked on my misbehaving laptop

I can reproduce that error on one of my laptops but it never happens on my main desktop or other laptop (all Windows 7). It'll be environment-related for sure. I'll investigate it. I noticed that if you clean the project (right-click on project, "Clean Project") then you'll be able to build it, but only once until you clean again. Very odd.

Hi Phil,

Sorry to hear that you're still having problems with it. This does concern me as I really want this to be as simple to use as possible. I'm putting together a new computer at the moment and so I have a clean environment available that I can use to try this myself. I'm going to document the steps required to get everything working in eclipse properly, step by step.

- Andy

Hi Phil,

Yes I do all iterative development in Eclipse Kepler SR1 with "CDT 8.2.1" and "GNU ARM C/C++ Cross Compiler Support" (a.ka. the GNU ARM Eclipse plugin).

The main library must itself be imported and built first because its output will be referenced at the link stage. When you've built the library from Eclipse then you can build the examples.

All the include directories are set up to be relative to the workspace location so there should be nothing in there that's related to my PC.

Please let me know if that helps.

Regards,
- Andy

It doesn't matter where you extract the tar archive to - I use a subdir off my home directory. Then all you need to do is add the extracted bin directory (the one with arm-none-eabi-g++ in it) to your personal PATH environment variable and that should do it. The compiler looks for everything relative to its own directory.

Hi Phil, sorry for the late reply but I've been away and off the internet for a week.

cstdlib is a fundamental c++ header file so it sounds like your environment has something set that's directing the compiler to a different location for its includes. Firstly, let's check your compiler is coming from the right place. Execute which arm-none-eabi-g++ at the command line to verify that you're running the compiler that you think you are.

Assuming that's correct, check your environment for variables that could be overriding the default include search path and review the gcc search path and environment variable documentation to see if you've got anything set that could be interfering with your build environment.

I honestly thought I'd released the gerbers for this project months ago but due to an oversight on my part it looks like I didn't do it. Anyway, they're available now so please do visit the downloads page if you fancy building your own PCBs.