At my job, I was tasked with making a prototype of a new audio device. The heart of the prototype will be an Analog Devices, Inc. Ez-Board with a SHARC 21469 chip.
Using VisualDSP++ 5.0, I wrote the necessary software in C, and it runs perfectly now. But I only know how to download the program into RAM using VisualDSP++ and the JTAG emulator.
I have been trying to figure out how to program the flash memory on the Ez-Board so that any time the board powers up, it will run my C program. How does that work?
I figured this out.
First, in VisualDSP++, under the "Tools" menu, there is a nice GUI for programming flash memory. However, different hardware platforms need different code to do the flash programming, so the GUI is designed to take a "plugin" program that will do the actual flash programming. The Analog Devices Inc. term for this plugin is a "driver". So, before you do anything else, you need to set the correct plugin for flash programming; you do this on the first "tab" of the flash programmer tabbed dialog (the "Driver" tab). Choose the correct driver .dxe file and click on the "Load" button.
Since I am using the 21469 Ez-Board, the "plugin" is available from the sample code for that board. Here is the full pathname of the driver file:
c:\Program Files\Analog Devices\VisualDSP 5.0\214xx\Examples\ADSP-21469 EZ-Board\Flash Programmer\Parallel\21469EzFlashDriver_Parallel.dxe
With that done, you can now build a "loader" file instead of the usual executable. Open your code project in VisualDSP++, and go to the Project Options dialog (Alt+F7). From the "Project" page, change "Type:" from "Executable file" to "Loader file". An "executable file" has the extension ".dxe" while a "loader file" has the extension ".ldr". There are some options that control how the .ldr file is built, but the defaults work fine (at least they did for me with an Ez-Board).
Now build your project as usual. Instead of building a .dxe file, it will build a .ldr file.
Finally, choose "Tools/Flash Programmer..." to bring up the flash programming GUI, and click on the second tab in the tabbed dialog, "Programming". For some reason the loader file is called the "data" file on this page of the dialog. Choose your .ldr file for programming, and hit the "program" button.
Related
I'm currently working on a Zynq-7000 Software project using Xilinx SDK toolchain.
I've noticed that nearly all of Xilinx's Demo projects automatically generate a "platform.h" file. However, when I start from an empty project in the SDK IDE it never generates "platform.h". This normally this would not be a problem, however, I want to cut and paste code from the "demo" project into my empty application project, and I can't do this because the "demo" projects rely on the "platform.h" header file. (I could create the demo project and delete every file from it, except platform.h, except this solution doesn't work because I need to modify the hardware away from the defaults with a custom FPGA image.)
What's the secret to get Xilinx SDK to auto-generate the "platform.h" file for an empty SDK Application?
For instance, is there an obscure checkbox that I need to click somewhere in the Board Support Package Project that says generate "platform.h"? or something like that? no idea...
It turns out that "platform.h" and "platform.c" are just normal c-code that are part of the Xilinx demo project. This code is not generated automatically generated as part of the Board Support Package. Thus, you can simply cut and paste these files into your new project without causing any problems. This is why an empty Application project doesn't contain these files.
The reason why they called it "platform.h" was just to hide the API differences between different Xilinx CPU types. Thus, the same demo code compiles on multiple platforms.
If you are like me an only using the Zynq-7000 platform, you can simply delete everything else in the platform files that's not related to Zynq-7000.
I am receiving an "Error 1" when using particle io relay - I am using the same exact firmware found here: https://github.com/spark/relayshield. What do I need to change?
1_Blink_a_Relay.cpp:2:37: fatal error: RelayShield/RelayShield.h: No such file or directory
#include "RelayShield/RelayShield.h"
It looks like your code can't find the library you're trying to import. Often (and especially when adapting Arduino code for Particle), the folder name for a library needs to be removed. Try #include "RelayShield.h instead.
If that doesn't work, please provide a little more information, such as your development environment. (Are you using Particle's web-based IDE? Did you import the library from there?)
Cheers!
If you are using the web ide, the one at build.particle.io, then you have to include the library. You have to go to the fifth item on the left menu bar, after flash, compile, save, and code. It should say library, and looks like a bookmark. Click on that. It will pop out a view. Scroll down until you see the Community Library search bar. And search for RelayShield. It will show you the "RELAYSHIELD", which currently is used by 520 people (or something like that). Click on that, and it will open the library. Scroll down on the left side (the one that pops up) until you see the button "Include in App". Click on that, and select your app. After you click on that, it will bring up your app. Then scroll down on that popped out view, until you see "Add to this App". Just click on this button, and then it will include that library in your project.
For Particle Dev on Desktop, it is a lot harder. If you are using Particle Dev, please reply, and I will give you the solution for that. It is very hard to manage libraries with Particle Dev. However, if you want to use the Serial Monitor while using the Particle Build on the internet, what you can do is that you do the regular serial commands on the Particle Build (build.particle.io), and open the Serial monitor on Particle Dev after also connecting to your Particle photon
My application needs to load external swfs with ABC. I checked that this feature is available in AIR 3.7 and later. I managed to get the new SDK - 3.8 with the latest version of FD (4.4.3).
Now I am following this link: http://blogs.adobe.com/airodynamics/2013/03/08/external-hosting-of-secondary-swfs-for-air-apps-on-ios/
According to this post, "During IPA packaging, ADT extracts the ABC code from all child SWFs, adds it to the final executable and generates stripped SWFs in the “externalStrippedSwfs” folder created in the current working directory. The directory structure within the “externalStrippedSwfs” folder remains the same as specified within the text file. The generated stripped SWF’s should then be externally hosted on a web server of developer’s choice."
However, firstly, I could not find any such folder called "externalStrippedSwfs".
Secondly, even if this works, this means that everytime I have a new external swf to load, I will have to get it stripped off the code, put it in the main swf, and then upload the stripped swf (with assets). So everytime I do this, I need to "reupload" my app to Apple.
Are these assumptions right? My app architecture will need to be modified accordingly.
Yes, your assumptions are correct: You can't load an external .swf containing AS3 and have the app execute the byte code.
If we ignore the fact that it would most likely not be approved by Apple it can't technically work. The reason is because the Adobe AIR app doesn't contain a virtual machine capable of interpreting the byte code in the .swf:
When you build your application for iOS, there is no interpreted code
and no runtime in your final binary. Your application is truly a
native iOS app.
Source: http://www.adobe.com/devnet/logged_in/abansod_iphone.html.
You can do it! :) You just need to upgrade to AIR SDK3.8+ and follow the painful process.
The only limitation is that each external swif that you will be loading at run time, must be stripped by your ADT.
But you are right: you will need to update your app everytime your external content needs to be updated.
"externalStrippedSwfs" is arbitrary (name it as you wish I believe), you have to create that folder in your bin and run the command line from there.
Looks like Apple is not ready to lose the leash yet...
For the record, I am an iOS developer, and have absolutely no background on how flash programs work/run/developed...etc.
I have a Flash program that is mostly a collection of SWF files. It does, however, contain some Actionscript, Javascript and other integrated languages here and there..
I would like to convert this project/program to an iPad application. Is it possible?
What I got from searching the net:
Converting Actionscript to LUA script
Using Corona SDK to port the program to iOS
Starting a new iOS project in flash and moving the code somehow..
Other tedious ways which are not feasible at all....
The above mostly handles the actionscript part .. what about the SWF files?
As a last resort, one could at least guide me to a developer/company who can handle this task, or provide training to accomplish this.
Additional details
The flash program app file is already generated, and the program works on desktops perfectly. The program is somehow an interactive e-book, and it has some linked XML files to index the table of contents and other sections...
I've not done a lot of iOS development yet, but here are my experiences so far; maybe they help you form a better idea.
Only the main SWF can contain actionscript code.
I'm not sure how far assets (Sounds, Fonts, MovieClips) in other SWFs which are exported for actionscript are accessible to the main SWF.
It is possible to include additional XML files (and other types) which can be loaded via the normal loader classes.
Recently I came acrosshe tool which allows you to convert and play swf to some cross-platform frameworks. Now they support only Cocos2d-x, Unity 3d and Starling. But I saw the logo of Corona on their homepage. You can go there and ask them. I don't remember the right name of the site, but tool is called GAF converter
I am providing this for everyone to hopefully save you some brain damage in finding this yourself.
As I'm working on a BlackBerry project that will run on various devices I ran into an issue grabbing screenshots from the handset (including the Torch 9850 ... not quite as good as my iPhones or my Android EVO or Infuse, but much better than the Storm and finally starting to look like a real smartphone - great performance and battery life too).
Normally I'd use my trusty BBScreenShooter and everything would be fine, but it kept crashing when attempting to capture images on the 9850. I posted a couple of requests for help on this site, but nobody could tell me why my BBScreenShooter was crashing or why I'd get "Retrieving screen <active> data ... Error: buffer too small" when using RIM's JavaLoader utility directly.
For those who didn't know BBScreenShooter delegates the "heavy lifting" to JavaLoader to grab the images.
With the help of Mark Sohm (easily one of the most knowledgable BB guys I know walking the planet) he asked me to verify I was using JavaLoader that is included in the v7 SDK. Turns out I wasn't. Good catch Mark, and thanks!
From the looks of things it appears the earlier versions of the JavaLoader utility have byte[] buffers they use for image capture that are hardcoded ... and too small.
So, for all those who need to capture screen shots from RIM's new 480 x 800 based handsets I have included a quick "how to" guide to help you get productive ASAP.
Step 1 - Make sure you have the v7.0 SDK downloaded (doesn't have to be installed, though I cannot think of a good reason not to). For Eclipse users:
Step 1a) Go to the Help menu
Step 1b) Install New Software menu choice
Step 1c) Add the "BlackBerry - http://www.blackberry.com/go/eclipseUpdate/3.6/java" items in your "work with" field.
Step 1d) Under the "BlackBerry Java Plug-in Category", look for the "BlackBerry Java SDK v7.0.0.X" checkbox and click NEXT.
Step 1e) Accept the license agreements and continue the download and installation process.
Step 2 - Go to the installation directory for your newly added SDK. We're going to grab a copy of the path to the JavaLoader utility and use it within a BAT file that will automate the capture and naming of screen shots. This will be found at /plugins/net.rim.ejde.componentpack7.0.0_7.0.0.28/components/bin/JavaLoader.exe
Step 3 - Create a folder you'd like to use to save screen captures. This will also hold your BAT file as the BAT file is specific to this particular project.
Step 4 - Create the BAT file. In my example here I keep all my IDEs, SDK, ... effectively all development environments on a different hard drive than my OS. I keep these on drive D, but modify your BAT to reflect the location and needs of your configuration.
Step 4a) It's important to turn the echo off, otherwise you will probably be unable to use the icon on the desktop to launch this script/utility.
Step 4b) If your BAT file is running locally (same folder) as JavaLoader then this step will be unnecessary. On the other hand if your JavaLoader is on a different hard drive and tucked away deep in folders then you'll have to "change directory" to get to it. Notice the "/D" switch that is used with the "change directory - cd" command so that we can change drives and paths in the same step.
Step 4c) As I like to use timestamps for part of my file names ... set local variables to represent the current date and time.
step 4d) The following "for" statements parse out the current date and time from my Windows 7 computer into a format that I want to include as the file names for my screen captures ... file name == BlackBerry_<date image was taken>_<time image was taken>.bmp.
Step 4e) Copy the newly created device screen shot that JavaLoader captured to your target folder and use the file name we've just created.
Step 4f) Now that we've successfully got a copy of the screenshot saved in our desired target folder we can delete the temporary image that JavaLoader created.
Step 4g) I echo a little statement that lets me know it all worked.
Example BAT file:
#echo off
cd /D D:\Program Files (x86)\EclipseBlackBerry\plugins\net.rim.ejde.componentpack7.0.0_7.0.0.28\components\bin
JavaLoader screenshot tempImage.bmp
set timestampdate=%date%
set timestamptime=%time%
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set timestampdate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set timestamptime=%%a%%b)
copy tempImage.bmp "C:\Users\CirrusFlyer\Desktop\<project name>\Testing\Screenshots\BlackBerry_%timestampdate%_%timestamptime%.bmp"
DEL tempImage.bmp
echo Completed "...\<project name>\Testing\Screenshots\BlackBerry_%timestampdate%_%timestamptime%.bmp"
Step 5 - Close and save your BAT file. I kept the BAT in my actual project folder, then created a shortcut and placed it on my desktop. This way I can have my Eclipse up and running and be debugging the application on my handset, and when I want to grab a screen shot simply double-click the shortcut to execute the capture.
This will create screen shots and place them in the target directory: BlackBerry_2011-10-07_1015 PM.bmp, for example.
Step 6 - Your done. Happy coding. Hope this helps.
My next project: extending Eclipse so that I can do screen captures directly from within the IDE the same way I can when doing Android based programming.