I am an embedded systems engineer and our company is planning for a USB 3.0( host and device )protocol compliance suite/ Post silicon validation covering functional test cases. Actually i have previously worked with functional validation of low speed peripherals like I2C,SPI developing bare metal(without any OS) test cases,running on a simple microcontroller. I am not sure whether i can do the same with USB,as i think the protocol by itself is complex.Does it require to develop test cases using OS or RTOS? Can the functional test cases be run on a uniprocessor system? I am aware linux kernel and U-BOOT has USB support.If it's better to use kernel,how the existing USB stack in kernel can be used to write test cases? Can anyone shed light on this ?
USB 3.0 (particularly superspeed) is not a simple block, and validation of it covers the entire gamut of hardware and software specs, plus interoperability testing. See http://www.usb.org/developers/compliance/
You really need to engage a professional services company with experience doing this if you're the person that's being relied upon for post silicon validation of this block, otherwise your company runs the risk of shipping a product that can't get the logo (or worse). You should probably engage them prior to tape out so your company can lessen the chances of very expensive mistakes. And I don't say this to insult you, but to make it plain to you that if you're asking about it stack overflow, you're not equipped to do the job in the near future.
BUT, when I did USB2.0 high speed certification for an ASIC, we had to have a functional stack on the device under test (our chip, which was an ARM with integrated USB PHY), and we ran a USB certification test on a windows pc, with a specific set of USB peripherals attached to it (the "golden tree"), plus we had to do eye diagrams, etc. to verify our waveforms were compliant. We also did testing with a Mac, but that was more a marketing decision than a compliance issue.
Related
There was a discussion here that is now closed: https://stackoverflow.com/questions/25871579/what-is-the-difference-between-rtos-and-embedded-linux#:~:text=Many%20RTOS%20are%20not%20full,essentially%20the%20scheduling%20kernel%20only.&text=Critically%20Linux%20is%20not%20real%2Dtime%20capable
The accepted answer could be summarised as "Critically Linux is not real-time capable".
However, I think this is misleading. When it comes to an OS like linux, you have to distinguish between applications, the kernel, and device drivers.
According to my understanding (having written many Unix device drivers and worked on the Unix kernel decades ago), the device drivers and the kernel are real-time capable.
Device drivers respond to hardware events (interrupts) and the kernel, in turn, can perform actions based on these events.
So, yes, while it's true that certain real-time features are not available to applications, if you have the capability of writing a device driver, you can circumvent this limitation by moving your application logic into a specialised device driver or kernel module.
(Of course it has to make logical sense to do that...)
Have I missed something? Does anyone disagree with this?
I have a usb modem with MT6272M chipset, can I take out its chipset and program it? I know that some ICs are programmable and some are not but I really want to program an IC without investing on arduino, rhasberry pi, or intel gallileo so trying to recycle electronic wastes.
Most of the ICs in the electronic waste are not programmable. Because they are specifically designed to do one job efficiently and that program is bound to the IC.
What you are searching is Programmable Integrated Circuit or Micro-controller chips. These are specifically designed to re-program again and again.
Anyhow if you find a specific Integrated Circuit from the waste,
First and most importantly, find its data-sheet (mostly available
in their manufacturer's website for free).
check whether is it a Programmable Integrated Circuit.
if yes, what is the hardware requirement to program it and build the
hardware circuit
write the program according to the specific requirements using
compatible libraries.
connect to the PC
Find the correct boot loader and upload it to the IC.
upload the program, which you have written, to the Programmable Integrated Circuit.
Test it
As you can see, you will need to build different hardware for different Programmable Integrated Circuit. So it is cheaper for you to buy arduino or raspberry circuit board. Then you can reprogram more chips using same board again and again plus the help of the community and the thousands of libraries.
Edit
If it is not mentioned in the datasheet whether you can program it or not , most probably it can't reprogram.
And other thing is that the main function of a modem is signal processing. For example, old cable modems are converting analog signals into digital signals. So they are not designed to reprogram or to do logical calculations. With my personal experience, you better start with a simple micro-controller and once you know the basics, you can go for higher level. Anyway I admire your idea to recycle the waste ICs.
I'm new to fpga programming, and I'm wondering how to make my fpga design distributable. Here's the scenario I have in mind. I have a network of computers, each deployed with an fpga based peripheral. I want to update the fpga design on the peripherals periodically. How do I accomplish this without spending a fortune on software licenses?
I have a small dev kit for an fpga that shipped with an executable to load example design files (it was an Altera fpga FYI). Does anyone know how I would create such an executable?
Some specifics:
My fpgas are Xilinx Spartan 6Es. I'm using Xilinx ISE for fpga development. The host computers are running debian linux.
Thanks for any and all advice!
If youre dealing with Altera: one computer would have the software tools and licenses needed to synthesize the project. Assuming all the FPGAs are the same model on each station/node, Quartus will generate an .sof file which you can copy and open from station to station. All you would need to do is download the Altera programmer tool (I believe you can download it separately from Quartus II) on each station which is free. Then upload the .sof to the board using the programmer, where you can permanently store it on the fpga prom using a technique similar to the following:
https://m.youtube.com/watch?v=ZrMe8JS7Ktk
However if you have Xilinx and Altera mix, Xilinx has .bit/xdl files, and uses another tool (impact) to upload their bitstreams. They can't be converted to and from bit and sof. So it's recommended that you probably stick to one make (Xilinx or Altera) and model based on your plans.
It looks like what you are looking for is how to make your FPGA's field upgradable. Assuming your FPGA is loading from an external memory such as an SPI flash chip, then you need to modify your design so that it is capable of writing to the SPI chip (or whatever) itself. This is most simply done by putting a register in your design which maps to the individual pins on the flash chip, and then "bit bang" the register from a connected computer. Assuming your FPGAs feed data into your own software running on the computer, then you would modify this software to have the functionality of manipulating this register to reflash the flash device. Obviously, if this goes wrong you bricked your device until it can be flashed again with the JTAG, but it provides a way for all the devices to get updated in the systems they operate without needing to buy a JTAG cable for every single station.
If you have Ethernet on your board you can use the remote programming tool from fpga-cores.
Then you can remote login to the network and program the FPGAs or mail the new config file to you customer and they run the programmer. This is how we remotely updates our boards.
Spartan 6 is supported. As a bonus you can also do some remote debugging with the remote logic analyzer.
Everything is free for non commercial use.
I'm working with various (mostly Bluetooth) development boards (ConnectBlue, Ubertooth, USRPs etc.) in order to research about Bluetooth communication behaviour at PHY level. In order to get some more insights I'm looking for a way to debug the Bluetooth stack on a Windows 7 Desktop computer. My use-case is relatively simple: I have custom baseband implementations, which establish connections with the Windows computer. I'd like to see everything the Bluetooth hardware/driver does.
I'm not sure how to approach this: I'd like to see when the Bluetooth Chip/Windows driver receives a Signal, and how it (the message) gets interpreted/formatted/passed through the various APIs concerned. Mostly this relates to kernel debugging.
Is there a way to display the state of the attached hardware in Windows in WinDBG? Maybe to perform (Kernel) API logging on the Bluetooth kernel service?
I hope somebody more familiar with device driver debugging and Windows Kernel services can give me some pointers here.
Since you don't appear to have gotten any hits on this, I'll post what I can.
I don't have any definite answers, but on the NTDebugging blog they often do hardware level debugging in windbg.
I.e.
http://blogs.msdn.com/b/ntdebugging/archive/2007/06/22/where-the-rubber-meets-the-road-or-in-this-case-the-hardware-meets-the-probe.aspx
To be honest this is going to require extensive knowledge not only of your hardware, but also of the deep internals of windows, and how the bluetooth stack is written, but the WDK would probably be a good place to start for understanding the bluetooth stack. I would also check out the blog for tips and tricks.
The other place to check and ask questions is http://osronline.com/ It's one of the better communities about device drivers, so they should have some reasonable tips on doing what you're trying to do.
I'm creating an application that needs to use some kernel level modules, for which I've divided the app into 2: one user-level program and one kernel level program.
After reading about device drivers and walking through some tutorials, I'm a little confused.
Can there be a device driver without any specific device associated with it? Is there anything other than the device driver (kernel code or something) which works in kernel mode?
How do anti-virus programs and other such applications work in kernel mode? Is device driver the correct way or am I missing something?
Yes, device drivers can work without an actual piece of hardware (i.e. the device) attached to the machine. Just think of the different programs that emulate a connected SCSI drive (CD-ROM, whatever) for mounting ISO images. Or think about TrueCrypt, which emulates (removable) drives using containers, which are nothing more than encrypted files on your hard drive.
A word of warning, though: Driver development requires much more thought and has to be done more carefully, no shortcuts, good testing and in general expects you to know quite a good deal about the Windows driver model. Remember that faulty and poor drivers put the whole system's stability in jeopardy.
Honestly, I don't think reading a tutorial is sufficient here. You might want to at least invest in a decent book on that subject. Just my 2 cents, though.
Sorry, but the Windows Internals book is more of a general reading for the curious. I cannot recommend it if you want to engage in driver development - or at most as prerequisite reading to understand the architecture. There are plenty of other books around, although most of them are a bit older.
Depending on your goal, you may get away with one of the simpler driver models. That is not to say that driver development is trivial - in fact I second all aspects of the warning above and would even go further - but it means that you can save some of the more tedious work, if instead of writing a legacy file system filter you'd write one based on the filter manager. However, Windows XP before SP2 did not have it installed by default and Windows 2000 would require SP4+SRP+patch if I remember correctly. WDF (Windows Driver Foundation) makes writing drivers even easier, but it is not suitable for all needs.
The term device is somewhat of bad choice here. Device has a meaning in drivers as well, and it does not necessarily refer to the hardware device (as pointed out). Roughly there is a distinction between PDOs (physical device objects) and CDOs (control device objects). The latter are usually what you get to see in user mode and what can be accessed by means of CreateFile, ReadFile, WriteFile, DeviceIoControl and friends. CDOs are usually made visible to the Win32 realm by means of symbolic links (not to be confused with the file system entities of the same name). Drive letter assignments like C: are actually symbolic links to an underlying device. It depends on the driver whether that'd be a CDO or PDO. The distinction is more of a conceptual one taught as such in classes.
And that's what I would actually recommend. Take a class about Windows driver development. Having attended two seminars from OSR myself, I can highly recommend it. Those folks know what they're talking about. Oh, and sign up to their mailing lists over at OSR Online.
Use Sysinternals' WinObj to find out more about the device and driver objects and symlinks.
As for the question about AVs, yes they use file system filter drivers (briefly mentioned above). The only alternative to a full-fledged legacy FSFD is a mini-filter.
It is possible to load a special kind of DLL in kernel mode, too. But in general a driver is the way into the kernel mode and well documented as such.
Books you may want to consider (by ISBN): Most importantly "Programming the Windows Driver Model" (0735618038), "Windows NT Device Driver Development" (1578700582), "Windows NT File System Internals" (0976717514 (OSR's new edition)), "Undocumented Windows NT" (0764545698) and "Undocumented Windows 2000 Secrets" (0201721872) - and of course "Windows NT/2000 Native API Reference" (9781578701995) (classic). Although the last three more or less give you a better insight and are not strictly needed as reading for driver developers.
Anti-virus (and system recovery) software generally make use of file-system filter drivers. A device can have multiple filter drivers arranged like a stack, and any event/operation on this device has to pass through all the stacked up drivers. For example, anti-viruses install a filter driver for disk device so that they can intercept and scan all file system (read/write) operation.
As mentioned in above post, going through a good book would be a nice way to start. Also, install DDK/WDK and refer the bundled examples.