I've recently started exploring and reading about Microchip's PIC32 MCUs, most specifically for motor control. I had some job done over the years but was a long while and haven't used the IDE with evaluation board since university years. Been using Arduino-compatible boards since or boards, compatible with the Arduino IDE.
So I'm running MPLAB X IDE v6.05 with the latest XC32 Compiler.
My Development board is DT100113 Curiosity Pro board, utilizing PIC32MK0512MCJ064 MCU and an on-board PicKit4 (PKoB4) for programming/debugging/serial connection purposes.
What I try to do is light up the two user LEDs on pins RA10 and RE13 respectively.
As I begin with creating new project, select my device, my program/debug tool and give my project a name, next step is to create a new main.c file.
I create the file and write the following:
#include <stdio.h>
#include <stdlib.h>
#include <xc.h>
int main(int argc, char** argv) {
//Define corresponding port bits as outputs (0 = output, 1 = input).
TRISAbits.TRISA10 = 0;
TRISEbits.TRISE13 = 0;
//Latch the outputs to HIGH (1) and hold.
while(1)
{
LATAbits.LATA10 = 1;
LATEbits.LATE13 = 1;
}
return (EXIT_SUCCESS);
}
When I build and run it - nothing happens. Build is successful, connected to programmer, erase/flash device OK, but nothing with the LEDs.
I think I'm missing the #pragma directives (read about that it must be defined first prior anything else), but am unaware on how to set configuration bits (used peripherals, internal clock speed, etc.).
Any pointers to how-to articles, posts, etc. will be highly appreciated. I was not able to find step-by-step tutorial for my development board so far :((
Thank you in advance!
Cheers,
Iliyan
I tried creating a new project, it compiled and ran, but the LEDs were not lit.
Obviously was missing some vital parts in the code.
Application software examples and driver libraries are included as part of the MPLAB Harmony V3 Framework. Add Harmony to 'Embedded' under the 'Tools' tab of the MPLAB IDE.
Related
I had installed CUDA 9.1 previously and tested my OpenCV with the code below, all worked fine but later on I had to remove it and install 8.0. Now the below code gives errors since the previous dlls are searched.
Here is my test code:
#include <iostream>
#include "opencv2/opencv.hpp"
#include "opencv2/core.hpp"
#include "opencv2/highgui.hpp"
#include "opencv2/cudaarithm.hpp"
using namespace cv;
int main(int argc, char* argv[])
{
try
{
cv::Mat src_host = cv::imread("hdd.png", cv::IMREAD_GRAYSCALE);
cv::cuda::GpuMat dst, src;
src.upload(src_host);
cv::cuda::threshold(src, dst, 128.0, 255.0, cv::THRESH_BINARY);
cv::Mat result_host(dst);
cv::namedWindow("Result", cv::WINDOW_NORMAL);
cv::imshow("Result", result_host);
cv::waitKey();
}
catch (const cv::Exception& ex)
{
std::cout << "Error: " << ex.what() << std::endl;
}
return 0;
}
Here is the error:
The code execution cannot proceed because cudart64_91.dll was not found. Reinstalling the program may fix this problem.
It asks for 2-3 more dlls when I click on OK button, but I am not gonna write them here as I suspect the problem arises from the same source.
The problem is rather obvious. The dlls which are tried to be loaded, belong to the uninstalled version of CUDA (9.1), whereas I have now 8.0. I do not know why my Visual Studio 2013 tries to load the previous ones still.
Before anyone asks, yes I do have my newer installation (8.0) in my PATH. I am using Windows 10 x64, if it matters.
The real problem behind your error:
OpenCV was built with CUDA 9.1, this will not change even if you change the CUDA installation, thus it will the DLLs from CUDA 9.1 will always be required for every program that is compiled with OpenCV. Maybe a module does not have this linked and you can use it... but I am almost sure the main ones do and you won't be able to use them.
Possible solutions:
Build OpenCV with CUDA 8.0 then it will require is CUDA 8.0 DLLs and not the 9.1 ones.
Install CUDA 9.1. Both CUDA can be installed in the same computer, that is why they have this _80 or _91, this way you can have both paths and the computer decide which one is needed... I think it is not possible to have BOTH in the same program though, so be careful with this option. If it is only used by OpenCV then it will be ok.
I would recommend the first option, it is safer to stick to one library version...
I'm a noob to Xcode and am reading the Big Nerd Ranch book and its asking me to do example programs in simple C to get me familiar with the language, however its asked me to create a program that calls a method from main and passes an int and does a square calculation and the printf to defog screen. Here is the program:-
#include <stdio.h>
void doTheMath(int numberToSquare)
{
int numberSquared = numberToSquare * numberToSquare;
printf("%d squared is %d\n",numberToSquare,numberSquared);
}
int main(int argc, const char * argv[])
{
doTheMath(5);
return 0;
}
As you can see I am passing the value 5 to the method and it prints 25 on screen when i run the code. IF I then change 5 to 15 to get it to write out a different value, it doesn't. It still writes out 5 squared, not 25 squared.
In debug and step through the value is wrong and isn't changed.
I've closed the project and Xcode and still it doesn't work all of the time and then sometimes it does reflect the changed value.
The project Type is an OSX application / command-line tool. The project is stored on my NAS.
Your code is correct and when I test it in Xcode and change the 5 to 15 and run it, I get the correct answer returned. Make sure you save your file after you make the change, and you could also try to clean your project (Product > Clean).
Sometimes Xcode just does strange things . . .
In clang, is there a way to enable bounds checking for [] access to std::vectors and other STL containers, preferably when building in debug mode only?
I just spent hours hunting down a subtle bug that turned out to be caused by us accessing past the end of a std::vector. It doesn't need to do anything clever when it detects the error, just trap in the debugger so that I can find out where it happened and fix it in the code.
Is there a way to do this other than "create your own type that inherits from std::vector", which I'd like to avoid?
(I'm using clang version 3.1 if that makes a difference.)
libstdc++ has a mature debug mode using -D_GLIBCXX_DEBUG.
libc++ also has a debug mode using -D_LIBCPP_DEBUG but as we can see this mailing list discussion: Status of the libc++ debug mode it is incomplete:
| My understanding is that this work was never completed and it's
probably broken/incomplete.
That is correct.
It’s on my list of things to fix/implement, but it’s not something that I will get to anytime soon.
It does seem to work for std::vector on 3.4 and up see it live, give the following program:
#include <vector>
#include <iostream>
int main()
{
std::vector<int> v = {0,1,2,3} ;
std::cout << v[-1] << std::endl ;
}
it generates the following error:
vector[] index out of bounds
Aborted
If you're using Linux or OS X you should look into the address sanitizer:
http://clang.llvm.org/docs/AddressSanitizer.html
It introduces a 2x slowdown, but does a bunch of memory checking and may catch your bug.
Another amazing tool that has saved me countless times is valgrind. If you can run with valgrind it will catch a ton of memory bugs and leaks.
#define _GLIBCXX_DEBUG
This enables all kinds of inline checking (see vector and debug/vector)
I have three question for you, all related to dyld :)
I have been using this dyld man page as a basis. I have compiled the following code and successfully executed the binary on my jailbroken device.
#include <stdio.h>
#include <mach-o/dyld.h>
int main(int argc, const char* argv[]) {
uint32_t image_count, i;
image_count = _dyld_image_count();
for (i = 0; i < image_count; i++) {
printf("%s\n", _dyld_get_image_name(i));
}
return 0;
}
I thought that these functions let me find all the shared libraries that are loaded in my program's address-space. On my mac, the output is pretty straightforward: It shows the paths to all the libraries that are currently loaded in memory. On my iPhone the output is nearly the same - i also get filepaths - but there are no files at the specified location. (On my mac on the other hand, i can locate the files!)
This is a sample line from the output:
/usr/lib/system/libdyld.dylib
According to ls, iFile and all the other tools i've used, this directory (/usr/lib/system/) is empty. Why? Where are those files?
Another thing i'd like to know is: Is it possible to locate a library in memory? From what offset to what offset the library is mapped into memory? I think i know how to find the beginning but i have no idea how to find the end of the library. To find the beginning, i'd use the address returned by _dyld_get_image_header - Is that correct?
Last question: I wanted to load a dynamic lib system-wide so i assumed i could use DYLD_INSERT_LIBRARIES to do just that. However, every binary i try to execute after inserting my lib crashes and produces a bus error! Did i forget something or is it the dynamic library that causes the crash?
the libraries are located at :
/System/Library/Caches/com.apple.dyld/dyld_shared_cache_armv6 (_armv7)
This is a big file were all the single libraries have been joined into one large one.
See http://iphonedevwiki.net/index.php/MobileSubstrate for hooking on jailbroken device
Yes one can determine the position of a dylib in memory, even on non jailbroken devices.
parse the LC_SEGMENT(_TEXT)-Section Header(_text) of the library then you can get the base address of the library and the size of the TEXT __text segment. Then query for the vmslide. Add this to the base address of the TEXT __text.
A detailed description of the mach-o file format can be found here:
https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html. Pay special attention to "segment_command"-structure.
I followed Claus's post to set up code coverage on Xcode 4.2 with LLVM 3.0. I'm able to see test coverage files, but they're only for my unit test classes, not my actual project classes. I've tried setting Generate Test Coverage Files and Instrument Program Flow to Yes on my main target, but that didn't help, as it failed with the following error:
fopen$UNIX2003 called from function llvm_gcda_start_file
To clarify, I don't think that's even the right approach - I just tried it to see if it would generate code coverage on my project classes.
At this point, I'd be happy to try anything that gets code coverage working on my app. Any suggestions?
You are expecting linker problem, profile_rt library uses fopen$UNIX2003 and fwrite$UNIX2003 functions instead of fopen and fwrite.
All you need is to add the following .c file to your project:
#include <stdio.h>
FILE *fopen$UNIX2003( const char *filename, const char *mode )
{
return fopen(filename, mode);
}
size_t fwrite$UNIX2003( const void *a, size_t b, size_t c, FILE *d )
{
return fwrite(a, b, c, d);
}
This code just remaps the missing functions to standard ones.
Note on $UNIX2003 suffix:
I've found an Apple document saying:
The UNIX™ conformance variants use the $UNIX2003 suffix.
Important: The work for UNIX™ conformance started in Mac OS 10.4, but was not completed until 10.5. Thus, in the 10.4 versions of libSystem.dylib, many of the conforming variant symbols (with the $UNIX2003 suffix) exist. The list is not complete, and the conforming behavior of the variant symbols may not be complete, so they should be avoided.
Because the 64-bit environment has no legacy to maintain, it was created to be UNIX™ conforming from the start, without the use of the $UNIX2003 suffix. So, for example, _fputs$UNIX2003 in 32-bit and _fputs in 64-bit will have the same conforming behavior.
So I expect libprofile_rt to be linked against 10.4 SDK.
I use CoverStory http://code.google.com/p/coverstory/ a GUI for .gcda and .gcno files.
The documentation explains the settings needed to generate these files http://code.google.com/p/coverstory/wiki/UsingCoverstory.