I want to do a project that prevents elf waves from coming from outside, such as a protection circle, such as a protection ring that keeps elf waves away from the carrier and I want to get information about it. Think of it this way, you are in the middle of the sea, you create a position there, you create an environmental effect mechanism for yourself. The force is not reaching you. I want to develop a test phase for a project. Is there anyone who can help?
Related
I have a little over a month to do a project through LabView. It is a program that needs to translate information from a dbc file (dbc battery file) to a specific battery system. In other words, my LabView program should be a translator of the dbc file, which we get from the customer - since I work in a company that deals with battery testing.
Could someone help me and give me some useful advice, link or tutorial, very specific to this issue of mine?
I would be very grateful.
Cheers.
Since we now know that we are talking about CAN database files:
I would recommend to install National Instruments NI-XNET, which is a framework for LIN, CAN and Flexray. It can import such definition files, and makes it easy to access data from the device via the Bus in LabVIEW. There fore an X-NET CAN/LIN/Flexray interface is needed
You can import a dbc file manually, which is OK if there's always the same DBC file.
To do so, open START > National Instruments > NI-XNET Database editor. Open a database, and load your file. You should then see a tree with lots of info. For example, you should see all available CAN frames, and what signals (values) transported in it. You'll also see which bits of a frame are used for which signal, how the bits are interpreted, and how they are converted for example into a voltage.
Finally, it's not more than this to communicate with the device. Right-click on the signal list, choose the just imported database from above, and then select the signals to read.
There is much much more, but I think this is a good starting point.
I'm working on a personal project and i decided to make some kind of theremin but instead of radio frequencies, i want to make it with code.
I found how to make sound with asm on thissite (very helpful).
And i do have a sensor that sends me a certain voltage depending on distance of my hand and i can read it with an application in vb.net(HID).
Now my question is that is it possible to manipulate an .asm file on the run time with vb.net so i can make a sound with asm depending of the value that my sensor is giving me?
i have been looking for some information with Google, but it seems that i'm not typing the right tags.
I am trying to flash the very first u-boot binary file (uboot.bin) into blank NOR flash of a brand new blank board which has marvel 370 soc(ARM) using Teraterm(xmodem/ymodem/zmodem)
When I compile the uboot, I get two binaries like uboot-uart.bin and uboot.bin.
What is the difference between two binaries?
I have been instructed to make some dip switch changes and then load uboot-uart.bin first into the prototype board.
From manual I understand that the dip switch setting is to set "Boot from Uart" to Boot source list.
I am new to embedded and want to learn more about this from u-boot perspective. Where can I learn about this?
Would also like to know what these xmodem,ymodem,zmodem things are?
And would also like to learn how to customize u-boot for a custom board using marvel 370 soc(ARM)?
I would be happy if someone can point to good resources.
XModem itself is a quite simple protocol which is meant to send files over a serial link it is explained in detail here.
Most Marvell ARM-Chips in the last couple of years have the possibility to upload a binary via UART using the XModem protocol. There are two ways to do that.
By sending a special sequence to the chip during bootup (which can be done without any changes to the bootstrap options).
By setting up the bootstrap options accordingly (via DIP-Switches in your case)
In both cases the chip will then initiate an Xmodem-download. TeraTerm should have an option to upload files via the xmodem protocol. IIRC it is available under File/Transfer/XModem/Send.
If you know just send your "uboot-uart.bin" file to the Armada 370 (which will take some time). The SoC will now boot the file just like if it was loaded from NAND or any other source.
The only difference between your uboot-uart.bin and uboot.bin is most probably the special header which has to be put in front of the actual uboot-binary, it contains the bootdevice type the image was meant for, the address in memory where the image should be loaded to and a lot of board specific settings. The exact structure and content is usually explained in the very excellent datasheets from Marvell.
For customizing uboot I can only suggest to dig into the code provided by Marvell and change it according to your own board. You'll find the board specific files under boards/Marvell.
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.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.