Using Interrupts in RLP and .netMF on G400D

Hi Folks,

just a question about the implementation details of the .netMF on the G400D.

I found a text snippet in the manual of the AT91SAMx35 processor, which the G400D module is besed on:

13.8.3.3 Interrupt Vectoring
The interrupt handler addresses corresponding to each interrupt source can be stored in the registers AIC_SVR1 to
AIC_SVR31 (Source Vector Register 1 to 31). When the processor reads AIC_IVR (Interrupt Vector Register), the value
written into AIC_SVR corresponding to the current interrupt is returned.
This feature offers a way to branch in one single instruction to the handler corresponding to the current interrupt, as
AIC_IVR is mapped at the absolute address 0xFFFF F100 and thus accessible from the ARM interrupt vector at address
0x0000 0018 through the following instruction:
LDR PC,[PC,# -&F20]
When the processor executes this instruction, it loads the read value in AIC_IVR in its program counter, thus branching
the execution on the correct interrupt handler.
This feature is often not used when the application is based on an operating system (either real time or not). Operating
systems often have a single entry point for all the interrupts and the first task performed is to discern the source of the
interrupt.
However, it is strongly recommended to port the operating system on AT91 products by supporting the interrupt
vectoring. This can be performed by defining all the AIC_SVR of the interrupt source to be handled by the operating
system at the address of its interrupt handler. When doing so, the interrupt vectoring permits a critical interrupt to transfer
the execution on a specific very fast handler and not onto the operating systems general interrupt handler. This
facilitates the support of hard real-time tasks (input/outputs of voice/audio buffers and software peripheral handling) to be
handled efficiently and independently of the application running under an operating system.

Is this possible, or is this done, or which restrictions were to take into account to use Interrupts in RLPs?

With best regards

Gerhard

there is a SAM9 implementation in the porting kit that is very close to what we have

… and this means?

Sorry I am not so familar with the details of the .netMF implementation.

I just have to find out: Is the module an option or not, because this effects my hardware.

So the main problems I found out uptil now:

Data transfer between RLP domain and .netMF domain, because I need to kick off a cycle carrying out 4880 ADC measurements timed in hardware and stored somewhere using DMAC and SPI or SSC. This needs 100ms and I woudn’t block the system for that long time.
Saving this data on SD or other persistant memory.
Sending messages over serial line, hope I can do that in background also.
Having cron task that starts an action every 4 hours.
Sending mails.
Having a small ‘web site’ for monitoring and configuration purposes.
Accessible via mobile Internet.

And please, put a note in the store, that we need the G400D, the G400HDR AND an USB Power module to start. I only ordered the stick and the HDR and have now to pay extra shipping to get the rest (sorry I am in Europe, so shipping costs were not soo less).

Especially for newbees, this info will be helpful.
As I start with the EMX, I just bought the development sys and here we go …

With best regards

Gerhard

What I mean is that looking at the code will show you how interrupts are handled in NETMF. I am assuming you are comfortable with that since you are reading the processor manual.

Typically, users will use interrupts through the extensions we provide in RLP.

ok.

Whatever method is needed, I will use.

I think of using the DMAC to pump the data (16 * 4880 Bytes) from the SPI/SSC to the memory and after that some counter reaches zero and with that interrupt I will fire a managed event and stop sampling.
The administrative part of the code creates some filename and gets the data somehow (this is quite unclear uptil now) and write it to that file.

Than, some messages went over the serial line and some timeout (relay switching) is to await and the next cycle starts over.
As fast as a cycle can follow the other as better for the over all performance.

After some hundrets of that cycles the system gets about 4 hours to post process the data and calculate results.

Once a day this data went via email to the research center, and some retries sending the mail shold be taken if needed.

Thanks for the Input.

With best regards

Gerhard