Help regarding programming for GPIOs on A13, without any linux kernel overhead

Started by Vinuthan, March 11, 2013, 02:49:44 PM

Previous topic - Next topic

Vinuthan

Hi friends,
I want to control the GPIOs present on my A13 olinuxino Wifi without any linux overhead(like debian or android). I know there are API, libraries available on debain in python. But i don't like to use them.
So, how can i program my board without any of these. Are there any IDEs available or any other preferred ways i can use this.

Please help me with this regard.

Thank you.

JohnS

What has IDE (or non-IDE) to do with the overhead you allege?

The only way to avoid kernel overhead is not to have a kernel.  I bet you don't want to go that way!

Take a good look at the just-posted GPIO code.

John

jwischka

Quote from: Vinuthan on March 11, 2013, 02:49:44 PM
Hi friends,
I want to control the GPIOs present on my A13 olinuxino Wifi without any linux overhead(like debian or android). I know there are API, libraries available on debain in python. But i don't like to use them.
So, how can i program my board without any of these. Are there any IDEs available or any other preferred ways i can use this.

Please help me with this regard.

Thank you.

You are basically asking, "How can I run my computer without an operating system?" and the answer is, "You can't."

If you want something that doesn't have an OS overhead, you want a dedicated microcontroller board like an Arduino. Any board with a generic microprocessor is going to need some sort of kernel. You can, if you'd like, put together a rather lean kernel with a minimal OS, or you can try to go with the Xenomai thread to get more RT like performance.

You don't have to use Python (and maybe shouldn't, depending on your application), but you do have to use an operating system.

Vinuthan

The IDE is asked was like there are IDEs for microcontrollers like KEIL and more, So i asked are there any IDEs for ARMv7 processors for programming and compiliation.

The kernel is required to initialize and communicate with all the peripherials on the board.
I just need to interface the GPIOs as they are directly connected to the chip. I know this may not serve that much as i may not make complete use of my board, and also can achieve the objective using a simple microcontroller.
But i wanted to try it out on this board.

jwischka

Quote from: Vinuthan on March 12, 2013, 12:36:09 PM
The IDE is asked was like there are IDEs for microcontrollers like KEIL and more, So i asked are there any IDEs for ARMv7 processors for programming and compiliation.

The kernel is required to initialize and communicate with all the peripherials on the board.
I just need to interface the GPIOs as they are directly connected to the chip. I know this may not serve that much as i may not make complete use of my board, and also can achieve the objective using a simple microcontroller.
But i wanted to try it out on this board.

Again, I think you are misunderstanding how ARM7 processors, and ARM7 SOCs in particular work. But the answer to your question is no, nothing like that for this board, or for ARM7 boards in general. The GPIOs are not connected to the chip, they are a part of the chip itself.

JohnS

With "some" effort I expect Eclipse+gdb+OpenOCD with JTAG would work.

If the above isn't immediately obvious, I suggest to change "some" into "a lot of learning and then some".

John

olimex

is it possible?
yes, sure it is, but I do not see the point to use 1Ghz processor to drive some GPIOs

one AVR will drive GPIOs faster and much easier

people use OS on Cortex-A8 devices as there are *hundreds* of registers you should initialize before you are able even to blink a LED

open imx6 or AM335x users manual and read all 3000+ pages with registers to get a glue what amount of work you are asking about, for A13 all initilizations are in the kernel and there is even no description what register what is doing

JohnS

To be fair, I think the A13 would be a lot faster than AVR!

(But painful.)

John

olimex

ARM GPIOs are slow IIRC imx233 (@454Mhz) max GPIO toggle we achieved was less 6Mhz (about 5.7Mhz), on A13 (@1008MHz) they are even slower something like 3.5Mhz with the Allwinner's kernel and 1.5Mhz with Linux-sunxi kernel as there some internal bus PLL divider is not set correctly

one small AVR will toggle GPIOs at much higher speed, so to use Cortex-A8 @1Ghz to toggle GPIOs is waste of resources, the benefit would be that A13 will keep toggling these GPIOs at 1.5Mhz even if play HD video at the same time, while AVR will not :)

JohnS

I don't see the relevance of the PLL?

I thought the test for how fast a GPIO can be is a software loop essentially:
while (1) sethi(), setlow();

Isn't 1GHz A13 far faster doing that?

Important not to use python and keep code simple (no syscalls, no long-winded libs)...

John

olimex

this loop will execute at 1Ghz in the core cache :)
when it access the AMBA bus where the GPIOs are connected it will have to wait a lot until the bus responds


Vinuthan

Ya, they are part of the chip that is what i referred the metal pins on the board are connected.
But i did not know there were so many registers to be initialized before playing with the GPIOs.

I just now had a look at the AM335x as you referred, and it has some 170kB on chip ROM within it. How much does A13 processor has? So, i think this is the memory(bootloader) which initializes a small part of the chip and passes the control to either the NAND or MMC where u-boot and linux kernel can take over the initialization process and proceed with it.

Am i right about this?

Also, i have an A13 olinixino Wifi which comes with Android onboard the NAND flash. Can i use the MMC to boot another OS or perform other process?. I mean what is the boot order in which the board performes booting.
Is it first MMC, then NAND. Or the other way round.

Please help me with this regard, i don't want to mess up my NAND flash.

crubille

Quote from: olimex on March 13, 2013, 08:47:52 AM
this loop will execute at 1Ghz in the core cache :)
when it access the AMBA bus where the GPIOs are connected it will have to wait a lot until the bus responds

Oh, I thought the long delay (and even min delay) we have in xenomai are cache flush latency, but perhaps it is just that.

I look at the register which define the clock for the AMBA and so if all the divisors are at their maximum value, the APB bus get a 4MHz clock. Coherent with what you see.


crubille

It look like there is no effective configuration for the AMBA in the linux kernel. There is 2 different codes about it in the 3.4.24 kernel but none are active at least with my .config.

I dump the key register which define the divisors between the CPU Clock, AXI, AHB and APB:

- AXI_CLOCK is set at CPU_CLOCK/3 = 333 MHz   
- AHB_CLOCK is set at AXI_CLOCK/8 = 41.6 MHz  # and this is very slow for AHB
- APB_CLOCK is set at AHB_CLOCK/2 = 20.8 MHz  # and 3 cycles per read or write

Sure we can found a better config.