I've been working with a Micron BGA eMMC chip and prototyping a communication scheme with the eMMC chip inside an adapter board that connects to the GPIO pins of a TI microcontroller.
I've essentially created a communication scheme written in C code to walk through the initial handshake and initialization steps to get the eMMC to a Data Write/Read stage where I can write some small amounts of bytes to a part of the sector memory and read back the pattern I've written.
My next task is to format the eMMC into a partition format such as a FAT32 format, which is common among SD cards.
Does anyone know of any useful software or methods I could use to achieve this?
Or I've seen it's possible to format the eMMC using a Linux setup as well, but have little experience when it comes to Linux.
Any insight from anyone with past experience on the topic would be greatly appreciated!
If your system runs Linux that is the best option.
It is easy to format an eMMC using linux.
# mkfs -t fat32 /dev/mmcblk1
Is your TI microcontroller running Linux? If not, it might be diffiult connecting your BGA eMMC chip to a Linux system to format it.
Your second best option is to use a library that already supports it. Maybe something like (http://elm-chan.org/fsw/ff/00index_e.html) or (https://github.com/ryansturmer/thinfat32). There are several options I have not used any of them. To use these layers, you have to fulfill the lower level api.
Related
As per topic. I have very old machine that i cannot replace (some old railway machine). That machine still uses 3.5zip drive. I need to fit the USB instead. Therefore, as i`m completely not familiar with this system, can someone direct me please on where to start to reconfigure this ( if manageable of course) for use with USB? I guess there would a need for drivers etc so the USB is discoverable.
Thanks a lot in advance.
You'll need to download io-usb (the USB server) and Fsys.usb (the USB bulk storage driver).
Start here:
http://foundry27.com/sf/wiki/do/viewPage/projects.qnx4/wiki/InstallationNotesForUSBStack?selectedTab=versions&version=4
Continue here:
https://openqnx.com/phpbbforum/viewtopic.php?t=11230
I am using MicroSD cards as the storage on an embedded system running WinCe. Recently I have found Cards made by the same manufacturer in different parts of the world have differences and cause us issues.
I read at the SD Association about the formatting issues that windows formatters produce so I downloaded their SD Memory Card Formatter. That is good but we run our SD cards in WinCe as TexFat. So what I now do is format the card with a FAT32 partition so the PC will put the software onto the card. Then the WinCE system will format the other partition to TexFat and copy the software onto that on the first boot with the new card.
The question is what is the correct way to format a SD card as TexFat for WinCE from a PC? Any suggestions?
After lots of head scratching I found the answer is simple. The winCE partition has to be formatted TexFAT on the winCE system which was not a problem, the bit I did not know is that I needed to change the clusters. Once I changed the 8GB to have 4k clusters the time to write to the card decreased a lot. I have since tried other sizes and find that you need to play with the cluster size to get the optimum out of the card.
My and my fellow students are deciding on a choosing a simple microcontroller to do very basic image processing. We are basically trying to implement template matching to find a set of objects in specific portions of the image. We'd like to use a connect a webcam to the microcontroller to do the job take the pictures and look for the objects. We also require basic wireless communication (e.g. bluetooth or wifi).
I don't think we will have the luxury of using state-of-the-art microcontroller, but something thats been around for a while (due to budget and stuff). Could anyone please advise on which specs of the microcontrolelr would be the most relevant for the above task (e.g. CPU, MIPS, etc).
Thanks a lot!
For this kind of a task, I would say the amount of RAM is the most relevant spec.
A microcontroller with an external memory interface allows you to extend the data space with additional SRAM to hold your image data.
Also note, that memory is needed for any protocol stacks you need to implement (Bluetooth, TCP/IP even more so).
You probably want to have total RAM in tens of kilobytes, preferably 100+ kB.
It is also nice to have plenty of program memory available when learning and experimenting. Later on you can try to optimize and squeeze your code into a more confined device.
As for the architecture, choose something you can easily find development tools and examples for.ARM, AVR and PIC are all good candidates among others.
Also find out what interfaces you need to use to
control the camera (e.g. I2C or SPI)
read pixel data (e.g. parallel or analog)
Connecting directly to a webcam's USB interface would not be a straightforward task, as the microcontroller would need to act as a USB host.
Good luck with your project!
You may need a microcontroller with following features:
USB 2.0 Host controller
1.2MB of memory for buffer 640*480*2(bytes per pixel)*2(double buffer)
(you may use lower resolution if there are not enough memory)
Wifi controller
CPU power strong enough for your task
Ready open source code
It seems that broadcom controllers may be useful here.
Also, you can by off-the-shell Wifi router with usb port and use it for your project
(i.e. Linksys E3000 )
If I was told I needed to create a driver for some product (say, a game controller), how would I go about creating one? Is this something you could do normally in C/C++?
And what about firmware for external deviced connect to USB? How is this created usually? Is this also done in C/C++, or some lower level language?
Thanks!
Device drivers for desktop computer operating systems are generally written in either C or C++. The operating system you would target will have some form of framework or device driver development environment. Often these development kits can be obtained free of charge.
There are books available for Windows, Linux, and MacOS X (and others) that detail the process of creating a device driver.
If your driver is related to a device on a specific hardware bus (PCI, PCI-X, USB, SCSI, SATA, etc.) you can also get books on that specific technology. An understanding of that hardware system can greatly facilitate the design of your driver.
Another good resource is the open source code for similar devices to yours. You can obtain that from the Linux kernel source or FreeBSD source and study how certain aspects of your type of device are implemented.
EDIT: I nearly forgot to mention that you will also need data sheets, schematics, and/or theory of operation information about the device itself.
I'll add to Amardeep's good answer with the following books that will help you think about the context device drivers operate in, and how they're structured:
Linux:
http://www.amazon.com/Understanding-Linux-Kernel-Third-Daniel/dp/0596005652
Windows:
http://www.amazon.com/Programming-Microsoft-Windows-Driver-Model/dp/0735618038/ref=sr_1_1?ie=UTF8&s=books&qid=1277439434&sr=1-1
Mac OS:
http://www.amazon.com/Mac-OS-Internals-Systems-Approach/dp/0321278542/ref=sr_1_1?ie=UTF8&s=books&qid=1277439467&sr=1-1
You do it in any language that can talk to the interface. If it requires poking ports or addresses directly then you use assembly or C. If there's a higher-level interface such as libusb then you can use almost any language you like.
We are making a lab instrument using an ARM9/RTOS system. The client has asked about printing simple reports from the ARM9 system. In this case, we have USB Host support in the RTOS. I'm thinking about printing bitmaps in generic PCL, hoping that will cover the widest range of printers. Is there a better way to approach this? I'm assuming the RTOS does not have printer drivers, and I don't want to support a lot of printers.
We also support USB device mode on our system, so you could plug in a photo printer, and our device would appear to be a USB stick. So that would work, but it's a bit clunky. This will be a C/C++ embedded system
Pretending to be a digital camera and interfacing with a PictBridge printer actually sounds pretty clever. It would remove the need to deal with different printer drivers, and if my understanding of the technology is correct, you could even control the operation of the printer right from your device.
On the other hand, as someone who has used a fair number of computerized lab instruments (oscilloscopes etc.) I find the ability to save screenshots from an ethernet/web interface to be much more useful. Print is dead.
Have you looked at what all the scope vendors are doing? They all have print options (I think) and I don't know what they are doing to solve this problem.
Last time I was involved with something like this, we used serial ports to talk to HP printers using PCL. That backfired as everyone quickly stopped making serial printers!
PostScript is natively supported by most printers, so you could just send it over the wire, but it would be a lot more cumbersome than straight ASCII. There are libraries, but they're bulky.
Since your device can appear to be a USB stick, a simple solution would be to generate a report as a JPEG image and then have the printer open and print it. This way, the people who want paperless output can use the image as-is, and everyone else can print it.
If I understand you correctly, you could write a formatted text file and do a "print" command through Windows in the "usb stick" mode.
For a simple report, it would be best to stick to straight ASCII. If you need some graphics, PCL would be a good choice for B/W laser printers, but I'm not sure how universal it would be for the more common ink-jet printers.
Edit: the PCL Reference Manual is available as a PDF from HP.