Panda II Speed Problem

we are working on a fez panda II dev board for a university project, and having some problems running the board. The actual goal of the project is to do some image computation, so we definitely need the 72 Mhz clock of the Panda. We will also use RLP for that.

We tested the board with the C# code provided to blink a led in the tutorial and we barely reach 5.6kHz.
This is the code we used :

using System;
using Microsoft.SPOT;
using System.Threading;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.FEZ;
using GHIElectronics.NETMF.Native;

namespace MFConsoleApplication1
    public class Program

        public static void Main()
          OutputPort LED;
            LED = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.LED, true);

            while (true)

Then we tried to modify the registers of the CPU because we assumed the PLL was not activated, and the different multipliers. We have some problems with that, and the dev board is bugging as soon as we uncomment the 2 last lines :

 Register CLKSRCSEL = new Register(0xE01FC10C); //met l'oscillateur sur le quartz
            Register PLLCON = new Register(0xE01FC080);
            Register PLLCFG = new Register(0xE01FC084); //contient NSEL et MSEL
            Register PLLSTAT = new Register(0xE01FC088);
            Register PLLFEED = new Register(0xE01FC08C);
            Register CCLKCFG = new Register(0xE01FC104);
            Register USBCLKCFG = new Register(0xE01FC108);
            Register PCLKSEL0 = new Register(0xE01FC1A8);
            Register PCLKSEL1 = new Register(0xE01FC1AC);
            Register SCS = new Register(0xE01FC1A0);

            if ((PLLSTAT.Read() & (1 << 25)) != 0)
                PLLCON.SetBits(0x01);			/* Enable PLL, disconnected */
            PLLCON.SetBits(0);				/* Disable PLL, disconnected */
            SCS.SetBits(SCS.Read() | 0x00000020);
            while ((SCS.Read() & 0x40) == 0) ;
            CLKSRCSEL.SetBits(0x1);		/* select main OSC, 12MHz, as the PLL clock source */
            PLLCFG.Write(0x00000003); //valeur stockée N-1 et M-1 //FCCO = (2 × M × FIN) / N -> M=12, N=1
           // PLLFEED.SetBits(0xaa);

Could you please tell us what’s supposed to be the native frequency ?

The other problem is that as soon as something is not working in the program, the dev board is stucked, and we have to flash the firmware, which is really annoying, is there any solution to avoid that ?

The last thing is we don’t really get how RLP is working. We made a code to blink a LED with a C file launched with RLP which is working, and we worked on the C# file. As soon as the C# code has a problem, we don’t get the Debug.Print any more in the output window, but the LED keeps blinking, even if the code blinking the LED (invoking the C function) is after the Debug.print. How can that be ? Isn’t it supposed to be executed sequentially ?

Thank you very much for your answers, we really need help on that

Image processing on 72Mhz with under 100K of RAM?! This will probably not work for you. You need something like FEZ Hydra to do image processing.

Your test is to test is not to test the pin toggle speed, but it is to test the CLR execiution speed.If you want to see how fast this processor can toggle a pin then use RLP to write native code in C or assembly.

Welcome to the community.

We have an external RAM of 4 MB, so that we can store images (we need only 3 images stored).

We did it, I’m sorry if I forgot to mention it. It gave us the same speed of 5.6 Khz, so there is definitely a problem with the speed.
Thx for the welcome

3 images? How large are the images?

300*300 pixel at maximum, we will get it from a small camera sensor, and will store only the luminance on 8 bits/pixel. I don’t think the size of the picture is a problem here, but if we don’t get the full frequency of the board we won’t be able to make any computation.

The code we use to blink the LED with RLP is the one in the template provided in this thread :
(link of the file : )

// change the pin's state
	state = !state;
	RLPext->GPIO.WritePin(pin, state);

	// reschedule after 100 microseconds

The only thing we changed is the timing which we set to 100 microseconds between 2 blinks (the value 1 and 10 microseconds just freeze the panda board and we have to flash the firmare then to get it work)

I think that our code is okay, and still we get a maximum blinking frequency of 5.6kHz which is extremely low. That’s why we started to try to change the register and assumed that there was a configuration problem.

Should the Panda board run natively at 72 Mhz ? How is it possible then that the blinking frequency would be so low ?

ok good so let us do some latch here

300x300 at 2 byte/pixel = 180000 bytes. You have 3 images = 540000 bytes. How are you going to fit these on Panda? :slight_smile:

As I said we have an external RAM of 4 MB, I don’t get the problem. We communicate with it though the I/O There will never be any image stored in the micro.

External RAM on panda?!

We bought an external RAM of 4 MB,

if I’m not clear, this : [url][/url]

and this RAM communicates with the Panda developpement board using the inputs / outputs of the developpement board (of course we will create another card for that with the appropriate connectors and all). The Camera Sensor will then write directly on the RAM, and the Panda Dev Board will then compute the data only byte per byte, and will not store one full image.

That is a 4Mbit memory (4,194,304 bits)

You will get a total of 512Kbytes (as 8 bit words)

Now, how are you going to interface this with the Panda ? GPIO ? The access speed for this RAM is 55ns.

You need
18 address lines
8 data lines
3 control lines (/CE, /WE, /OE)

FEZ Panda is not the right tool for what you want to do. You need FEZ Hydra.

[quote]That is a 4Mbit memory (4,194,304 bits)

You will get a total of 512Kbytes (as 8 bit words)[/quote]

That’s a typing mistake, and we have 512 kbytes whereas I just said we need 3 pictures at 90k pixel (big maximum) * 1 byte = 270 kbytes… That’s still far enough.

We don’t have to use the RAM at full speed. The 55 ns is just the time between the moment the RAM gets the read instruction and the moment the RAM send the data. But we could use the RAM very slowly too, what do you mean by that ?

[quote]18 address lines
8 data lines
3 control lines (/CE, /WE, /OE)[/quote]

There are enough inputs and outputs for that on the Panda (54 I/O). We really didn’t do the hardware randomly, there is no problem on that side.

Why ? The micro should really be fast enough, and there are enough I/O to communicate with our camera sensor and our RAM.

Could you please help us with the original question which is why is the LED blinking so slow ?

I am not assuming anything :slight_smile:

You say 4MB in atleast 2 of your messages and I wanted to point it out to you.

I looked at the timing digram (look below) and pointed out about speed. I dont have the part with me and all wired up talk about specifics.

I never said anything about a problem with I/O lines, why do you say so ?

Panda had enough I/O lines. I assume that you are not connecting a LCD.

I thought the “forget it” was following the description of the lines. Why do you say to forget it then ?

The 55ns is just the extreme limit of the RAM, we even tested this RAM with a 8 bit PIC and it worked perfectly.

We are not connecting a LCD, that’s true.

Oh !

the “forget it” was supposed to go into a skype chat window to someone else and it landed here instead. I edited it now.

:slight_smile: All fine now .

Now I am curious to know how the data will move from your image sensor to the ram ? does the sensor have the capability to write directly to ram ? or will you read blocks of data from the sensor and write to ram locations and loop to the end of the image ?

Well, there will be a bus between the data pins of the sensor and the ram data pins.
The sensor has some control pins which will be connected to the Panda Board, so the Panda will control the sensor which will write directly into the ram.

Then when the Panda will read the ram the sensor data pins will be in high impedance thanks to some manipulation with the control pins.

Moreover we will have some hardware to protect simultaneous writing from the Panda and the sensor on the bus.

We just need to take 3 pictures, write them to the ram, and them compute them to determine the position of some things.

I really think that’s possible to do that with the Panda, but at the moment we are stucked as long as we can’t get a pin frequency of more than 5.6 kHz :confused:

Ok, please test this and let me know if you see any improvement

  1. Run first test with line 14 on RLP_Native.c comment out, the line reads

    // reschedule after 500 milliseconds
    RLPext->Task.ScheduleTimeOffset(&myTask1, 500 * 1000);

2.Test with a lower value, rather than 500ms

Well, we did 2 already, as I wrote

for 1 : If we comment it out, the board freezes and we have to erase the firmware to get it to work again.

From what we thought, getting an output of maximum 5 kHz means that the CPU would be running at maximum 50 kHz currently.

Thank you for trying to help :wink:

Yes, when you comment the reschedule line, the board will not respond to the debugger. I expect this to happen, because the application is running just the toggle loop.

Are you able to measure the frequency at the “hung” state ? what value do you get ?

I don’t have the frequencymeter with me right now, so I can’t say how it is when the line is commented (I can test that tomorrow in the lab), but we made the measurement with the value 1 microsecond and 10 microsecond today, and the result was a DC voltage accross the LED of about 2 Volts, with no oscillation any more :confused: