I am currently working on a project which requires to use a embedded soft core. I wrote a pong game using VHDL (ISE) and synthesised it onto the FPGA, the next step is going to shift the numerical calculation part to soft core which means i need to rewirte this code in C. However, ISE can not achieve this function, what design suite (software) i can use? Can EDK work?
You have to add a soft processor to your project using EDK and synthesize the new project. Then you can write the software code to run on the soft processor using SDK (Software Development Kit).
Related
I got some source code in plain C. It is built to run on ARM with a cross-compiler on Windows.
Now I want to do some white-box unit testing of the code. And I don't want to run the test on an ARM board because it may not be very efficient.
Since the C source code is instruction set independent, and I just want to verify the software logic at the C-level, I am wondering if it is possible to build the C source code to run on x86. It makes debugging and inspection much easier.
Or is there some proper way to do white-box testing of C code written for ARM?
Thanks!
BTW, I have read the thread: How does native android code written for ARM run on x86?
It seems not to be what I need.
ADD 1 - 10:42 PM 7/18/2021
The physical ARM hardware that the code targets may not be ready yet. So I want to verify the software logic at a very early phase. Based on John Bollinger's answer, I am thinking about another option: Just build the binary as usual for ARM. Then use QEMU to find a compatible ARM cpu to run the code. The code is assured not to touch any special hardware IO. So a compatible cpu should be enough to run all the code I think. If this is possible, I think I need to find a way to let QEMU load my binary on a piece of emulated bare-metal. And to get some output, I need to at least write a serial port driver to bridge my binary to the serial port.
ADD 2 - 8:55 AM 7/19/2021
Some more background, the C code is targeting ARMv8 ISA. And the code manipulates some hardware IPs which are not ready yet. I am planning to create a software HAL for those IPs and verify the C code over the HAL. If the HAL is good enough, everything can be purely software and I guess the only missing part is a ARMv8 compatible CPU, which I believe QEMU can provide.
ADD 3 - 11:30 PM 7/19/2021
Just found this link. It seems QEMU user mode emulation can be leveraged to run ARM binaries directly on a x86 Linux. Will try it and get back later.
ADD 4 - 11:42 AM 7/29/2021
An some useful links:
Override a function call in C
__attribute__((weak)) and static libraries
What are weak functions and what are their uses? I am using a stm32f429 micro controller
Why the weak symbol defined in the same .a file but different .o file is not used as fall back?
Now I want to do some white-box unit testing of the code. And I don't want to run the test on an ARM board because it may not be very efficient.
What does efficiency have to do with it if you cannot be sure that your test results are representative of the real target platform?
Since the C source code is instruction set independent,
C programs vary widely in how portable they are. This tends to be less related to CPU instruction set than to target machine and implementation details such as data type sizes, word endianness, memory size, and floating-point implementation, and implementation-defined and undefined program behaviors.
It is not at all safe to assume that just because the program is written in C, that it can be successfully built for a different target machine than it was developed for, or that if it is built for a different target, that its behavior there is the same.
I am wondering if it is possible to build the C source code to run on x86. It makes debugging and inspection much easier.
It is probably possible to build the program. There are several good C compilers for various x86 and x86_64 platforms, and if your C code conforms to one of the language specifications then those compilers should accept it. Whether the behavior of the result is representative of the behavior on ARM is a different question, however (see above).
It may nevertheless be a worthwhile exercise to port the program to another platform, such as x86 or x86_64 Windows. Such an exercise would be likely to unmask some bugs. But this would be a project in its own right, and I doubt that it would be worth the effort if there is no intention to run the program on the new platform other than for testing purposes.
Or is there some proper way to do white-box testing of C code written for ARM?
I don't know what proper means to you, but there is no substitute for testing on the target hardware that you ultimately want to support. You might find it useful to perform initial testing on emulated hardware, however, instead of on a physical ARM device.
If you were writing ARM code for a windows desktop application there would be no difference for the most part and the code would just compile and run. My guess is you are developing for some device that does some specific task.
I do this for a lot of my embedded ARM code. Typically the core algorithms work just fine when built on x86 but the whole application does not. The problems come in with the hardware other than the CPU. For example I might be using a LCD display, some sensors, and Free RTOS on the ARM project but the code that runs on Windows does not have any of these. What I do is extract important pieces of C/C++ code and write a test framework around it. In the real ARM code the device is reading values from a sensor and doing something with it. In the test code that runs on a desktop the code reads from a data file with fake sensor values and writes its output to a datafile that can be analyzed. This way I can have white box tests for the most complicated code.
May I ask, roughly what does this code do? An ARM processor with no peripherals would be kind of useless. Typically we use the processor to interact with some other hardware like a screen, some buttons, or Bluetooth. It's those interactions that are going to be the most problematic.
The existing project is running well on STM32F0. The code should be converted to Atmel SAMD21.
The code is written in Visual Studio and using the IntelliSense configuration (ARM Paths). Both projects should use the I2C interface. The package which is used is ChibiOS for STM32.
Because I didn't write the code from scratch, Which part should I change in the code or read carefully? In other words, what is common and different in programming 2 different arms?
Do I need to do my own bootstrap (I mean the initialization part) and linker script? What else is needed?
Also, is there any configuration file for arm definition that I should change?
As I should change chibiOS and add the libraries for Atmel, Which library or package is better to use for Atmel SAMD?
Is there any idea or example that is helpful to compare between these
2 arms?
Much appreciated for any helpful suggestion, in advance.
I have been trying to open c files in the Arduino IDE (which some people claim is possible).
I have not been able to do so.
How can I program the Arduino in c given that I have a project/files in another IDE? (for example, MPLABX)
I am not sure what you are trying to archive. Is it that you want to open it via the Arduino IDE or also compile the source code?
I am not aware of programming in bare c in the Arduino IDE. But if you're looking into using real c code, it might be a good time start either compiling and uploading via terminal yourself, or use an IDE which is suited for development with micro controllers.
I think you can tell the Arduino IDE to more elaborately log outputs. This would tell you exactly the commands the IDE is using (uses avrdude). Then you can use an IDE/Editor of your choice for coding.
Otherwise, have a look at eg. Atmel Studio. They also support Arduino.
There are two answers in one:
If you really want to use the ArduinoIDE you have to have a basic *.ino file having at least the defines and includes which are in the project file and the reqiured setup() loop() usually whats in main in c goes to loop() in ArduinoIDE. Thats the stoney path because there are some specific issues coming from the philosophy behind ArduinoIDE (help makers with little (no?) programming skills to get started quickly).
If you just need the Arduino tool-chain and want to work more comfortable you have two other options:
EclipseIDE with the Sloeber add-on. Download the Sloeber-AllInOne-Package for an easy start and THEN add the other modules you need (like for web development or similar)
PlatformIO an IDE for micro controller development - there is also a cloud based version for testing around.
All mentioned tools are real open source and available cross PC platform and not a gift from a company like MS for probably later lockin of devs
I'm using PlatformIO as an IDE for programming AVR MCUs. I'm beginning AVR programming (I have a background in C/C++ and programming on OS's, not embedded, although I have done some Arduino stuff in the past) and using PlatformIO gives me code completion for the registers/pins, which is why I use it.
It seems I can't switch framework from Arduino to avr-gcc in PlatformIO without losing code-completing.
I am wondering if there's any drawbacks in keeping Arduino as the
framework?
I know Arduino uses avr-gcc in the back, but I read that it still does a bit of setup without the users knowing it (such as Timer0 setting for delays, which I need since I'm using it as a clock source for USI on my ATTiny85).
Otherwise, is there anyway in PlatformIO to keep code completion and
use avr-gcc instead of Arduino?
Thanks!
EDIT: I'm on either OSX or linux (ubuntu).
As pointed out by ivankravets on the PlatformIO community platform (see: https://community.platformio.org/t/avr-programming-without-arduino-framework/525/4), it is as simple as removing the line framework = arduino from the platformio.ini file to get rid of the Arduino framework and work in bare C for avr-gcc.
I have never used PlatformIO, and my answer is only based on my (extended) knowledge of AVR development and the Arduino mess…err…framework.
The Arduino framework is using AVR-libc (the standard low level framework that gives you all the tools you need to program on AVR), and adds a layer of abstraction so you're not directly handling registers, but use a more easily understandable interface.
So when you write on a pin, instead of looking at the AVR's IC leg number, looking for the matching PORT address to configure it and mutate it, you're using digitalWrite() on the board's pin number. So, whatever the IC is, the pin will stay the same with consistent capabilities.
The pin definition is done using a header file that's given to the compiler depending on your target setting in your IDE (so whether you use an Arduino Mega or a Leonardo the matching between AVR port/pin and board pinout will change radically).
Given your description of PlatformIO, it's using that information to give you appropriate pinout completion based on the board configuration. It's also certainly taking advantage of the object oriented approach of the Arduino framework, so that you can easily have method completion when using singletons (like when you use Serial).
Using raw AVR-libc, on the other hand, it's harder to get any meaningful completion, because most of the operations are being done on registers which are being declared through preprocessors aliases, and the whole code is pure C, so code completion is not really helpful (you cannot list all the methods that applies to a given object… like with the Serial example).
Then, Arduino offers a nice high level approach to prototyping embedded code, that you can then curate when you need to optimise in time and/or space. And some projects (like the Marlin firmware for repraps) use some sort of hybrid approach, reimplementing many parts of the Arduino interface in a more optimised way (like digitalWrite or the Serial object).
In the end, my advice to you would be to drop platform.io or the arduino IDE, and switch to eclipse if you're really into IDE GUIs, or better, use your preferred powerful editor (like vim/nvim, emacs, atom, sublime…) to have it handle AVR code like any other C code.
If you work on an Arduino project including avr-gcc internals using VisualMicro plugin and VisualStudio (Community Edititon) all the code completion / syntax highlighting / goto declaration etc. works for anything in your project and all libraries.
Is this what you're looking for?
Of course, VisualMicro is annoying if you use them "for free"
I'm trying to generate C code from a Matlab-Simulink simple model (eg.: sine wave generator with a DAC at the output). This code must be executed with Code Composer Studio
for TMS320C6748 DSP (Texas Instrument C6748). Specifically, for the development board OMAP-L138 ZOOM ™EVM DEVELOPMENT KIT.
For this, I am using the following versions:
Simulink (Version 7.7 - R2011a)
Embedded Coder (Version 6.0 - R2011a)
Code Composer Studio v3.3
I tried several options (with generic modules in Simulink and programming the C6748 timers, configuring a module "Target Preferences" with "OMAP_L138/C6748 EVM"...) but it isn't working.
Is it possible to implement this idea? Is there an example working?
Thanks
Code generation for OMAP-L138 EVM / C6748EVM is supported in Simulink in R2011a. Before opening the Target Preferences block, import the processor definitions from DSP/BIOS. On the MATLAB command line, type the following:
getDspBiosFolder % This returns which DSP/BIOS MATLAB is seeing. If the value returned matches your installation of MATLAB, then you are OK. Otherwise, you need to use setDspBiosFolder to set the installation folder for DSP/BIOS (i.e. setDspbiosFolder('C:\CCStudio_v3.3\bios_5_33_06') on MATLAB command line).
importDspbiosConfig('proc', 'all')
importDspbiosConfig('board', 'all')
After these steps, you should be able to open the Target Preferences block and examine the settings. Before proceeding with code generation, run checkEnvSetup() utility to make sure that you installed all TI software required for code generation:
checkEnvSetup('ccs', 'omapl138evm', 'list')
The command above gives you a list of what you need to install. After making sure you have all of the software installed above with correct version numbers, execute the following:
checkEnvSetup('ccs', 'omapl138evm')
This sets all environment variables needed for code generation. MATLAB sees the location of the tools through environment variables created this way.
After these steps you should be able to generate code.
Code generation for OMAP-L138 EVM and C6748 EVM is not supported for older versions than Matlab 2011a.
For the release 2011a, the setup process is not trivial and it is not well documented. But Matlab has a patch for this version supports and works with certain specific requirements.
The release 2011b has improvements (hyperlinks required for products of thirds work with CCStudio v4 for this processor) and supports code generation for OMAP-L138 EVM and C6748 EVM.
For the release 2012a, Matlab has considered adding specific sections in the documentation for configuration and automatic code generation with these processors.