I'm doing an speed controller project at University, so, I've had some problems with interrupt routines, I can't find one routine to DIV0Error, SFTACError, COVBError, COVAError, OVBError, OVAError, DAE, DOOVR and SGHT. When I try build this routines, the compiler said that the p33EP256MC502 don't have support for this. How can I solve this problem ?
Thanks.
Related
I am trying to manually set the ISER0 and STIR registrs to invoke interrupt number 3 which is RTC Wakeup Interrup for educational purposes. Here is my code:
I step through the register contents, but somehow the code was not able to write to the ISER0 and STIR registers, as is shown below where i am trying to clear the ISER0 register.
Can someone please explain me what am i doing wrong here?
ISER has one bit for every exception, STIR takes exception number - 16.
In the second image you write 0 to the ISER register. That has no effect as described from both ARM architecture reference manual and STM32 M4 Programming Manual.
I would put a volatile on both register pointers declaration, but in this case I don't think it's an issue.
The issue is solved. Somehow, the stlink debug with openOCD was causing an issue with semihosting enabled to which i have no explanation for now. When I changed the debugging to STLink with SWV viewer, it worked ok...
Upon instantiating a LowPowerTimer, like so:
LowPowerTimer* lowPowerTimer = new LowPowerTimer();
It crashes on my own target. It works 100% on the STM32F429-discovery evaluation board.
What could cause the problem? All other code runs perfectly. There are enough memory and flash. The micro is of the same family. Are there any prerequisites that I do not know of? The micro I'm using is the STM32F413RH with a 26MHz external crystal.
I use the mbed platform and code in C++, FWIW...
My first guess would be that you have not configured the lpticker clock source correctly. Do you have the same crystals as the evaluation board? See which clock source the lpticker is using there and see if it's missing on your final board.
In addition, what is crashing? Do you see a hard fault? Where does it originate from?
So what I found was that in the targets.json file I had to override the lse_available macro. The lse_available macro states that a low-speed external oscillator is connected to the micro - and then the Low Power Ticker would use that as its source. But if you set it to 'not connected', it uses other clock sources.
I am evaluating different multiprocessing libraries for a fault tolerant application. I basically need any process to be allowed to crash without stopping the whole application.
I can do it using the fork() system call. The limit here is that the process can be created on the same machine, only.
Can I do the same with MPI? If a process created with MPI crashes, can the parent process keep running and eventually create a new process?
Is there any alternative (possibly multiplatform and open source) library to get the same result?
As reported here, MPI 4.0 will have support for fault tolerance.
If you want collectives, you're going to have to wait for MPI-3.something (as High Performance Mark and Hristo Illev suggest)
If you can live with point-to-point, and you are a patient person willing to raise a bunch of bug reports against your MPI implementation, you can try the following:
disable the default MPI error handler
carefully check every single return code from your MPI programs
keep track in your application which ranks are up and which are down. Oh, and when they go down they can never get back. but you're unable to use collectives anyway (see my opening statement), so that's not a huge deal, right?
Here's an old paper (back when Bill still worked at Argonne. I think it's from 2003):
http://www.mcs.anl.gov/~lusk/papers/fault-tolerance.pdf . It lays out the kinds of fault tolerant things one can do in MPI. Perhaps such a "constrained MPI" might still work for your needs.
If you're willing to go for something research quality, there's two implementations of a potential fault tolerance chapter for a future version of MPI (MPI-4?). The proposal is called User Level Failure Mitigation. There's an experimental version in MPICH 3.2a2 and a branch of Open MPI that also provides the interfaces. Both are far from production quality, but you're welcome to try them out. Just know that since this isn't in the MPI Standard, the function prefixes are not MPI_*. For MPICH, they're MPIX_*, for the Open MPI branch, they're OMPI_* (though I believe they'll be changing theirs to be MPIX_* soon as well.
As Rob Latham mentioned, there will be lots of work you'll need to do within your app to handle failures, though you don't necessarily have to check all of your return codes. You can/should use MPI error handlers as a callback function to simplify things. There's information/examples in the spec available along with the Open MPI branch.
Well my problem stated when i had my vhdl code up and running on my Spartan-3a but needed to send and receive data from it to the pc,
I need my vhdl code , so i went for a microplaze structure , problem is I cant understand how will my vhdl code and microblaze co-exist at the same time because every time i program fpga with SDK it deletes my vhdl off the fpga and vise versa with ISE, I dont want to use custom peripherals except if this is the only solution.
Some people just tell me to just use microblaze hdl files produced by EDK, OK but theny aren't I using an unprogrrammed MicroBlaze???
And do i need to go through all of this just to be able to communicate with my vhdl code through pc(NO I CANT USE R232 since i need a speed of 56Mbit/sec)
So here is what i don't understand:
1-IF you implemented microblaze through hardware(HDL from edk to ISE) , isnt it then an un-proggrammed processor?
2-PEOPLE TELL ME i can let microblaze and my vhdl code see each other through GPIO , again how will i implement GPIO and how to connect it to both microblaze and my vhdl code , and how to program microblaze while it in hardware in this situation.
Please any help , its kinda a mess.
It is not that difficult, but unfortunately Xilinx documentation is not that clear.
What you need to do after you are done with your Microblaze code and you feel comfortable with it, is to create a new project in ISE or the one you already had, then add a new file to the project, but instead of adding a VHDL or Verilog file, you must add the system file from EDK.
After you added your XPS project into ISE, you need to do some manual work in order to make things work for you.
Here are a list of things that needs to be done:
You have to create a UCF file that includes all the constraints from EDK
You have to make sure that you have enough space inside your FPGA for both the EDK and
your own code
Synthesize and implement your design using the project in ISE.
Program your FPGA from the bit file generated by ISE
In order to communicate between the MB and your own code, you can do it in many different ways, the easiest way is to use the GPIO block from your MB, then connect those signals to your own code on your top level wrapper.
You maybe able to find some useful information on the lab document and lab material from the following Xilinx page:
enter linkXilinx EDK interface class description here
Accessing the GPIO is pretty simple, you can use the information on this page to get you started:
Reading DIP Switch with MicroBlaze
You may also find this document and related files very useful, it is not for your board, but it covers the exact same thing you are asking for:
Avnet MB tutorial document
I hope this is clear enough.
I am running Turbo Pascal 3.01A on CP/M 2.2. Suppose my Pascal program, which I run using the R menu option in Turbo Pascal, has a bug and goes into an infinite loop. Is there a special control character that will interrupt my program and return to the Turbo Pascal menu?
The {U+} directive will cause the compiled code to check after each statement whether a key has been hit. If so, the keystroke will be checked for ^C; if not ^C the keystroke will be discarded. While this usefully allows the program to be aborted, it slows things down and also rather annoyingly kills type-ahead ability. Unfortunately, CP/M doesn't provide any sort of keyboard interrupts (though some CP/M implementations might provide one) so there's not really any better alternative. It would be nice if Turbo Pascal had an option to implement its own keyboard buffering, but I don't know of any.
At the start of your Turbo Pascal 3 program (under the Program statement) is Compiler Directive {$U+}. This should allow you to do a CTRL + C. Always use this only while you're debugging your program as it slows down the execution speed of your program. If it runs okay, remove it and then compile your program.
Typically in Turbo Pascal 3 the compiler has a set of Default Compiler Directives. The "U - User Interrupt" is typically off by default.
The other thing I found in my Turbo Pascal program just recently was I was using this while debugging my program and for some reason it wasn't working. Not sure what was going on there and found I really had to hold down this combination to get the program to exit. Unsure if it had something to do with the execution speed of the program or if it was the use of a nested loop which led to this occurring.