I am very new in Blackfin processors and I suppose to write a tester program for Blackfin, BF527. This tester program should test the connection of the board and 2 peripheral RAMs.
So far I have downloaded and installed VisualDSP++ (90-day trial version).
Can anyone help me to know how can I write a simple program to write in port G and read From port H, including initialization (preferably in C).
I have looked for sample code on internet but unfortunately all the codes are very advance.
I went through the data sheet, but it was on assembly not C, still I couldn't find any solid sample program for my purpose.
Look in the VisualDSP installation folder (under Program Files). There is lots of sample C and C++ code in Analog Devices\VisualDSP 5.0\Blackfin\Examples
To program the hardware peripherals from C/C++ you need the header files which contain the pointer definitions for the memory-mapped registers. These will be found in Analog Devices\VisualDSP 5.0\Blackfin\include
In your code you can automatically select the correct include file for the project's processor using:
#include <blackfin.h>
Related
I am using a SAMD21XPlained Pro board on Mac (OS Big Sur) with MPLAB X IDE v6.00 (XC32 compiler) and I am currently experiencing a problem when trying to display a message on my terminal via the printf() function.
I am a beginner in embedded programming and I try to follow this tutorial about STDIO Serial Communications : https://www.youtube.com/watch?v=3pwdpYj5s_A&t=397s
Based on this tutorial I first tried to do only a printf() but I didn't see anything on the terminal (I didn't try the scanf() for this first try).
The only thing I changed is that I included the stdio.h file and I did a second test with a baud rate 9600 (because I don't really know how to define the baud rate and I wanted to test like that).
I have read on several forums that the problem comes from the fact that the XC32 compiler uses by default the UART2 while the printf() must use the UART1 to be displayed on the terminal.
Several people suggest to include xc.h to redefine the default UART1 (__XC_UART = 1) but this seems to work only for PIC32MX µCs.
According to my research in the XC32 compiler files, the xc.h file for PIC32MX is not the same as the one for PIC32/SAM and only the one for PIC32MX defines __XC_UART.
I also tried to apply what is proposed in "Microchip Developer Help" for "Redirect stdout for Use With printf()" in the XC32 category:
https://microchipdeveloper.com/xc32:redirect-stdout
The problem is that it also seems to be only for PIC32MX µCs (the p32xxxx.h file that is included at the beginning of the code exists only for PIC32MX in the XC32 compiler).
After a few days of research, I tried many solutions proposed on different forums but I still can't find the one that works so I was wondering if you have an idea?
Thank you !
i was wondering if it is possible to modify a piece of C program (or other binary) while it is running ?
I wrote this small C program :
#include <stdio.h>
#include <stdint.h>
static uint32_t gcui32_val_A = 0xAABBCCDD;
int main(int argc, char *argv[]) {
uint32_t ui32_val_B = 0;
uint32_t ui32_cpt = 0;
printf("\n\n Program SHOW\n\n");
while(1) {
if(gcui32_val_A != ui32_val_B) {
printf("Value[%d] of A : %x\n",ui32_cpt,gcui32_val_A);
ui32_val_B = gcui32_val_A;
ui32_cpt++;
}
}
return 0;
}
With a Hex editor i'm able to find "0xAABBCCDD" and modify it when the program is stopped. The modification works when I relauch the program. Cool !
I would like to do this when the program s running is it possible ?
Here is a simple example to understand the phenomena and play a little with it but my true project is bigger.
I have an old DOS game called Dangerous Dave.
I'm able to modify the tiles by simply editing the binary (thanks to http://www.shikadi.net/moddingwiki/Dangerous_Dave)
I developped a small editor that do this pretty well and had fun with it.
I launch the DOS game by using DOSBOX, it works !
I would like to do this dynamically when the game is running. Is it possible ?
PS : I work under Debian 64bit
regards
I was wondering if it is possible to modify a piece of C program (or other binary) while it is running ?
Not in standard (and portable) C11. Read the n1570 specification to check. Notice that most of the time in practice, it is not the C source program (made of several translation units) which is running, but an executable result of some compiler & linker.
However, on Linux (e.g. Debian/Sid/x86-64) you could use some of the following tricks (often with function pointers):
use plugins, so design your program to accept them and define conventions about your plugins. A plugin is a shared object ELF file (some *.so) containing position-independent code (so it should be compiled with specific options). You'll use dlopen(3) & dlsym(3) to do the dynamic loading of the plugin.
use some JIT-compiling library, like GCCJIT or LLVM or libjit or asmjit.
alter your virtual address space (not recommended) manually, using mprotect(2) and mmap(2); then you could overwrite something in a code segment (you really should not do that). This might be tricky (e.g. because of ASLR) and brittle.
perhaps use debug related facilities, either with ptrace(2) or by scripting or extending the gdb debugger.
I suggest to play a bit with /proc/ (see proc(5)) and try at least to run in some terminal the following commands
cat /proc/self/maps
cat /proc/$$/maps
ls /proc/$$/fd/
(and read enough things to understand their outputs) to understand a bit more what a process "is".
So overwriting your text segment (if you really need to do that) is possible, but perhaps more tricky than what you believe !
(do you mind working for several weeks or months simply to improve some old gaming experience?)
Read also about homoiconic programming languages (try Common Lisp with SBCL), about dynamic software updating, about persistence, about application checkpointing, and about operating systems (I recommend: Operating Systems: Three Easy Pieces & OsDev wiki)
I work under Debian 64bit
I suppose you have programming skills and do know C. Then you should read ALP or some newer Linux programming book (and of course look into intro(2) & syscalls(2) & intro(3) and other man pages etc...)
BTW, in your particular case, perhaps the "OS" is DOSBOX (acting as some virtual machine). You might use strace(1) on DOSBOX (or on other commands or processes), or study its source code.
You mention games in your question. If you want to code some, consider libraries like SDL, SFML, Qt, GTK+, ....
Yes you can modify piece of code while running in C. You got to have pointer to your program memory area, and compiled pieces of code that you want to change. Naturally this is considered to be a dangerous practice, with lot of restrictions, and with many possibilities for error. However, this was practice at olden times when the memory was precious.
Just bought an MSP430 launchpad
Been reading through stuff, but I'm unable to learn from all those verbose sources how to stick my C program inside the micro controller. They're not objective (I've started with the manuals that came within, then following hundreds of links on texas website. They are poorly informative).
TO BEAR IN MIND:
I'm a student;
My professor isn't of much help;
I'm completely new to this hardware stuff. Kind of new on C programming too... we can say a year of practice;
I consider the KISS principle a good practice: My teacher accomplishes a firework of LEDs with a .c file, a makefile, and a make.exe that I don't have the least idea of what is and how works.
Below, my steps taken so far: (They did NOT work. That's the reason I'm asking here. I would appreciate a very objective procedure/corrections at first, and later, the brainstorm)
Downloaded mspgcc-20120406-p20120911
Installed that on Code::Blocks, using Settings > Compiler - Toolchain Executables tab
(I've tried Energia, but doesn't seem like a very orthodox .c editor. And I love codeblocks, or devcpp, or, as a third option, notepad++, or even Eclipse)
I've also tried CodeComposerStudio. After downloading packages and starting a full project answering neverending questions, I still don't know how to flash the code.
I even made a simple program to blink a led:
#include <stdio.h>
#include <msp430f5529.h>
#include <msp430.h>
void ConfigureCpu(void)
{
WDTCTL = 0x5a80;
// ACLK = 32768 Hz
// MCLK = 16000000 Hz
// SMCLK = 16000000 Hz
DCOCTL = 0x74;
BCSCTL1 = 0x0F;
BCSCTL2 = 0x88;
BCSCTL3 = 0x84;
P4DIR = 0xff;
}
void delayms(t)
{
int i, x;
for(i=0;i<=t;i++)
for(x=0;x<16000;x++);
}
int main()
{
ConfigureCpu();
while(1)
{
P4OUT=0x42; //0100 0010 = 0x42
delayms(1000);
P4OUT=0x00;
delayms(1000);
}
}
It doesn't work for two reasons:
'DCOCTL' undeclared (first use in this function)|
And if I comment those registers, I get the following:
cannot open linker script file memory.x||No such file or directory|
.
L:\MSP\ is my directory for everything related to this journey
Example:
L:\MSP\GCC
L:\MSP\Flasher\
L:\MSP\Programs //my .c are stored here
(Code::Blocks is installed on the root of C:)
I would like someone to tell me what I need to learn (step by step, if possible, from the very beginning, to the very end - from choosing tools, to uploading to the controller)
The flyer in the box describes what to do.
Go to www.ti.com/launchpad and download either Code Composer Studio 4 or the IAR Embedded Workbench trial.
The TI page also holds all other information that you might need.
Looking at msp430f5529.h file on my system, it seems like this chip doesn't have those registers or they aren't in the header. The code just sets the register to a magic number with no explanation, comment, or calculation, so it's hard to figure out what the purpose is. (It's probably trying to configure clocks.)
Second, you'll probably need that linker file for your chip so the compiler (linker stage) can set up correct memory addresses.
The code actually looks like a blinky, but meant for a different chip or compiler. It would probably work but you'd need to change the parts that are different (port it) for your setup. It would be educational, but perhaps not what you want to spend your time on.
To solve both problems, I'd start by getting a project meant for the particular chip/board you have. Build that and see if it works. Then you know your compiler and the project work. You can go on to modify it for your application.
I'm busy with a massive project where I need write software for a control system for an automotive vehicle. Here's what I am using:
I'm using an STM32F4 for the micro
I am writing the Application (Control app) in Matlab Simulink. I then generate Cortex M4 optimised code from Matlab which I simply Include in my Keil uVision Project. (Works like a charm)
I manually write software for the driver layer and to interface to the Hardware abstraction Layer.
I would like to maintain separation between my Simulink Generated Code and my 'firmware' hand written code. Essentially, I want to be able to change the firmware without affecting my control application.
I would like to use a configuration file to map the variables that Matlab Simulink generates with my Hardware Registers (for GPIO, for instance). I would like to do this via a configuration file (e.g. via an xml file).
Has anyone ever done something like this and is it even possible. I'm looking for an elegant solution that does not consume a lot of RAM.
Thanks so much!
PS: Is it possible to declare variables in your code based on variables names that are stored in say an .xml or .txt file.
So if in the .txt file I have "Pressure_Sensor = 0", is it possible, perhaps using a Macro Definition, to declare a variable in the code: Pressure_Sensor = 0;
If you want to include variables into your c project build from syntax in another type of file whether it be .xml or .txt files there's a couple ways to do it. If you are going to be keeping variables in c compatible declaration style like:
int Pressure_Sensor = 0;
and no other invalid semantics will be in that file you can always just include that file into one of your compilation units. The extensions of the file do not matter. The #include directive literally just inserts that file into place.
If you are going to be doing something along the lines of a non c compatible language such as XML, a standard way to generate and include those variables into your build is to have a script that runs are a pre-build action that parses that .xml file and then generates a c compatible include file that you include into one of your compilation units. One of the most common things to use this for that you could find many examples of is for generating version/build info into the build.
You can do this:
Simplified Problem Statement is:
You want to modify a CPU port register through your code, but you don't know the address of that port register(Port address may change externally).
Solution is:
I)In your code:
Let your program assume that the address of the port register is at at fix location say 0x1000.
Someone/something will letter put address of port register at 0x1000(Your program don't care how)
So to change pin K1 you have to change value of address present at 0x1000.
But Wait ,
You want to only change a single port pin and you don't know which so,
Assume pin bit pattern is at 0x1004
To make pin ON write:
Value of the address present at 0x1000 |= Value at 0x1002
To make pin OFF write:
Value of the address present at 0x1000 &= ~Value at 0x1002
Most Imp:
Reserve these locations in your program somehow so that compiler dont write code there.
II)Outside the code:
Assumptions for explanation: Port1 address : 0xF000
Port2 address : 0xF001
Now have a Excel macro or something to do following:
Suppose you wants port2's 8th pin for contactor K1 then that macro should generate a simple text file as: "F00180".
Now use bin2hex or bin2mot (based) on your compilers output format and convert this notepad file into .hex or .mot(S-record) format.
You have to specify address location as 0x1000 as one of the input to these utilities.
Now remove header ,footer lines from generated .hex file and merge remaining data to your program.hex file.
You are done here,burn the .hex file into target by suitable flash programmer.
I have programmed avr microcontroller , but new to arm.I just looked a sample code for sam7s64 that comes with winarm.I am confused about these files rom.ld , ram.ld , scatter file , cstartup.s file. I never saw these kind of files when i programmed avr .Please clarify my doubts what each of them file do.
I have even more samples for you to ponder over http://github.com/dwelch67
Assume you have a toolchain that supports a specific instruction set. Tools often try to support different implementations. You might have a microcontroller with X amount of flash and Y amount of ram. One chip might have the ram at a different place than another, etc. The instruction set may be the same (or itself may have subtle changes) in order for the toolchain to encode some of the instructions it eventually wants to know what your memory layout is. It is possible to write code for some processors that is purely position independent, in general though that is not necessarily a goal as it has a cost. tools also tend to have a unix approach to things. From source language to object file, which doesnt know the memory layout yet, it leaves some holes to be filled in later. You can get from different languages depending on the toolchain and instruction set, maybe mixing ada and C and other languages that compile to object. Then the linker needs to combine all of those things. You as the programmer can and sometimes have to control what goes where. You want the vector table to be at the right place, you want your entry code perhaps to be at a certain place, you definitely want .data in ram ultimately and .text in flash.
For the gnu tools you tell the linker where things go using a linker script, other toolchains may have other methods. With gnu ld you can also use the ld command line...the .ld files you are seeing are there to control this. Now sometimes this is buried in the bowels of the toolchain install, there is a default place where the default linker script will be found, if that is fine then you dont need to craft a linker script and carry it around with the project. Depending on the tools you were using on the avr, you either didnt need to mess with it (were using assembly, avra or something where you control this with .org or other similar statements) or the toolchain/sandbox took care of it for you, it was buried (for example with the arduino sandbox). For example if you write a hello world program
#include <stdio.h>
int main ( void )
{
printf("Hello World!\n");
return(0);
}
and compile that on your desktop/laptop
gcc hello.c -o hello
there was a linker script involved, likely a nasty, scary, ugly one. But since you are content with the default linker script and layout for your operating system, you dont need to mess with it it just works. For these microcontrollers where one toolchain can support a vast array of chips and vendors, you start to have to deal with this. It is a good idea to keep the linker script with the project as you dont know from one machine or person to the next what exact gnu cross compiler they have, it is not difficult to create projects that work on many gnu cross compiler installs if you keep a few things with the project rather than force them into the toolchain.
The other half of this, in particular with the gnu tools an intimate relationship with the linker script is the startup code. Before your C program is called there are some expectations. for example the .data is in place and .bss has been zeroed. For a microcontroller you want .data saved in non volatile memory so it is there when you start your C program, so it needs to be in flash, but it cant run from there as .data is read/write, so before the entry point of the C code is called you need to copy .data from flash to the proper place in ram. The linker script describes both where in flash to keep .data and where in ram to copy it. The startup code, which you can name whatever you want startup.s, start.s, crt0.s, etc, gets variables filled in during the link stage so that code can copy .data to ram, can zero out .bss, can set the stack pointer so you have a stack (another item you need for C to work), then that code calls the C entry point. This is true for any other high level language as well, if nothing else everyone needs a stack pointer so you need some startup code.
If you look at some of my examples you will see me doing linker scripts and startup code for avr processors as well.
It's hard to know exactly what the content of each of the files (rom.ld , ram.ld , scatter file , cstartup.s) are in your specific case. However assuming their names are descriptive enough I will give you an idea of what they are intended to do:
1- rom.ld/ram.ld: by the files extensions these are "linker scripts". These files tell the linker how where to put each of the memory sections of the object files (see GNU LD to learn all about linker scripts and their syntax)
2- cstartup.s: Again, from the extension of this file. It appears to be code written in assembly. Generally in this file the software developer will initialize that microcontroller before passing control to the your main application. Examples of actions performed by this file are:
Setup the ARM vectors
Configure the oscillator frequency
Initialize volatile memory
Call main()
3- Scatter : Personally I have never used this file. However it appears to be a file used to control the memory layout of your application and how that is laid out in your micro (see reference). This appears to be a Keil specific file no different from any other linker script.