Are there any tips for reading source code samples from manufacturer of MCUs'.
I am a newbie for mcu programming, currently I have a MCU, datasheet and sample codes for them. But problem is sample codes are seems written for experienced users. Too many questions about why they initialized RS232, why they set 4th bit of port 1 and etc.,
Do you have a tips for reading or links where can I get info about how to read datasheets and sample codes of MCU?
I guess experience is the only answer I can give. Just like with programming in general, with time you acquire experience as well as learn buzz words and concepts. With microcontrollers you learn to read datasheets, schematics, etc. Learn about open drain, open collector, weak pull ups, etc. And for serial ports for some reason they are always overcomplicated. The hardest part with microcontrollers and the serial port is usually figuring out what to program to get the right clock divisors, some microcontroller serial ports are straight forward, others are overly complicated, some docs are good some docs are bad, etc.
Another answer is datasheets are always wrong. There are always gaps in the information that you have to hack to figure out. Do not write thousands of lines of code in a vaccuum using only a datasheet, write a small amount of code a few lines to a few dozen, test, and move on, you can get more lines written and debugged in a day when programming from a datasheet than the other path. The datasheets are often not written by the engineers that actually designed the hardware, sometimes it is a junior engineer or a non-engineer. Sometimes the information is simply wrong, sometimes the document is for a different but similar part than the one you have. If they provide software that actually does stuff it is sometimes (not always) more accurate than the datasheet (when I say datasheet assume the users manual, programmers reference manual, whatever the vendor calls the doc with the registers, addressses, and bit definitions for the hardware).
With time and experience you may find, if you take a wide enough view, that some vendors tend to do a better job at providing information to users, others do not, some bury the secrets in libraries, sometimes in binary form and not source. Sometimes the secrets are buried in compilers and other tools they provide (well that is back to apis and libraries). I tend to blacklist such companies, but sometimes you cant always. ARM for example does a very good job of providing the information. the problem is they have so many cores with a number of options each, that are very similar in nature (support the same instruction sets) that it can be difficult to sort through what the one processor you are using that moment does and does not from the docs. Atmel, something about atmel that is hard to put a finger on, the docs are generally well above par, but more than that something about atmel makes them popular with the customers. You will never see an arduino like following, culture, pick a word, with a microchip pic for example. There are a lot of pic followers but it is not like the atmel world (which was there well before the arduino thing happened).
Another note, you might not understand with a single example program and single datasheet the history of a product, there might be code that has been used for a number of chip generations, and there might for example be a bit that is required by an older chip or newer chip and to share the same code that bit is manipulated. that bit might make sense looking at one datasheet and no sense looking at another. this is where hacking comes, in try it without, see what happens. maybe study other parts in the family that this code is said to support it might make more sense.
google is your friend or whatever favorite search engine, find as much open source code and other items for the particular device or whatever. At this level hacking is required, I dont use that term in the bad sense, hacking in the sense that you have to try some of the bits documented in the datasheet, see if that actually works, if not then see what it does if possible, look at other source code and see from that if you can figure it out. Just like there is no perfect car that gets infinite miles per gallon, completely safe, lasts forever, and is inexpensive, there is no perfect chip with the perfect datasheet and sample code. If you want to work at this software/hardware level you have to get your hands dirty, have to not be afraid to let some smoke out of the chips (there is a finite amount of smoke in a chip if you let even a little bit out it wont work), etc.
If the reason you wont ask specifically about the mcu or register you are working with is because it is closed source products or behind an NDA then you probably have access to the company that makes that product and you should be able to get support from them. Usually better support than you would get from a company that you dont have to sign an NDA for. Not that open document, open source companies are bad, just that if the company you buy from is interested in you to the point of showing internally protected information they are interested enough to give you better access to the real engineers that made/know the product. If this is not the case and you are able to talk about it, dont be afraid to just post a question to SO about the register and bits you are wondering about.
Sample code and flow charts in the MCU datasheets are good starting point to initialize a specific peripheral (like RS232).
You just start from there, and track the bit information and what it does, in MCU datasheet.
Related
BACKSTORY
The other day I found a motorized wheel chair that someone was throwing away. Being a maker who spends a lot of time looking at what other people have made online I decided to snatch it and try to make a robot out of it. I also bought an Arduino mega, a Kinect sensor, and a motor controller to try to control the motors and give it some form of vision.
MY VISION
Honestly I don’t intend for this robot to be much more than a fun, and challenging, project. My current goals are to have it run SLAM algorithms to figure out where it is on a map and for it to navigate to predetermined points on the map. However at this point I would be happy with just being able to do a simple teleop control with the keyboard.
MY PROBLEM
I have spent the past week researching ros and how to get it talking to my Arduino. I have installed diff_drive_controller, Turtlebot, ros_control, ros_serial, ros_arduino_bridge, and several others trying to find something that will tell the motors what to do. By now I feel like I have a good barely below the surface understanding about how ros works. Basically there are a series of nodes each publishing info for the other nodes to see and subscribing to info that they want to read. All I want right now is a node that publishes data about the velocity of the motors based on it trying to navigate or teleop or something like that. I think turtlebot is my best bet considering it is an all in one stack that does everything I want it to do. The only problem is I don’t have an iRobot create. But it seems like it should be simple enough to intercept those commands and have them drive my own robot base. However I’m not sure which topic to listen on and how to run turtle bot in a way that doesn’t try to connect to an iRobot create. I could just listen to the /cmd_vel_mux/input/teleop topic but I think that would limit me to just teleop and it might make it hard to move on to autonomy in the future.
What topic should I listen on? Am I going about this the right way? Are there any packages that would be better suited for my needs? Keep in mind that I am new to ros so tutorials would be appreciated.
I look forward to your responses
Thanks, Logan
Nice sounding project! I second the recommendation to take a look at the tutorials, but I think you spend some more time with the basic ROS tutorials before diving into the world of Arduino + ROS.
For instance, I noticed one misconception I believe you may have. It doesn't really matter which topic your nodes listens to, as its just a name that can be easily remapped through a parameter given when launching the node. The important thing is to ensure you are listening to the right type of messages - they specify the interface by which all the different nodes communicate. There's a bunch of options, and if none of them fit your use case, you can define your own.
I suspect that for low-level things, such as drivers for your motors, you will need to write your own ROS nodes. For advanced functionality, such as SLAM; there's a variety of options. You can find one that's suited to the input data you have available from your sensors.
One last recommendation is to take advantage of the features of ROS that allow you to break a big problem into manageable subtasks. Do one thing at a time - implement a motor contoroller, write a teleoperation method; taking care to specify suitable interfaces at each point. The advantage of this approach is that if you made smart choices in defining individual components with good interfaces, it is very easy to replace them with another one should you so wish.
You can find a list of tutorials how to interface Arduino and ROS here.
I've ripped open an old Pentium desktop. The main board is a Zida 5svx. I got to know from the manual (which i downloaded from the internet) the location of the ROM chip on the board, and took it out. It was mentioned in the manual that the chip was a Flash EEPROM.
Now, what I am interested in is this: Is there a way to erase the ROM and flash it with, say a C program to blink an LED (i know this might put you into a fit of laughter, but read on all the same), or control a motor?
I also want to know if I can construct a mega-sized micro-controller with the left-over Pentium, some MBs of RAM, and this ROM.
Any suggestions?
P.S: I know that such a uC will require appropriate power supply setup and things.
The key is in getting and deeply studying the manufacturer's datasheets for each device you remove and wish to reuse. I am supposing that since you asked the question that you did that you are not a professional electrical engineer - that's OK, but you will need to do hours, days, or weeks of study to truly understand the datasheets well enough to successfully reuse your motherboard chips because they are written for professional engineers with years of experience, and unfortunately they were not written to be understood by hobbyists. If you can succeed in acquiring and thoroughly understanding all of the datasheets (and the related user's guides as well for the more complex chips) then you have made it to the point where you might be able to start a custom design based on your recovered parts, on paper at least. In order to test your design and insure that each part of it is working will require at least an oscilloscope and volt meter - and the knowledge of how to use them. An understanding of basic electronics is essential, you will not succeed without it. Very good soldering/rework/assembly skills will be required as well if you hope to have your design truly work - you can do everything else right and it can still fail if your skills in this area are lacking. There is simply not enough time for me to advise you on everything you will need to know - but if you are motivated, dedicated, and you don't give up when setbacks and roadblocks occur (and trust me, they occur all too frequently for even the best engineers and best designs) - meaning that you are not easily frustrated when things don't work - then you have a chance at success. I wish you all the best, and try to have fun while doing it (important in case fun is all you ever get out of your project). :)
All right, let me preface this by saying: I'm not completely confident this is programming-related. I'm trying to use software to solve a problem, but the software I actually trust; I suspect I'm doing something wrong with the hardware. However, I don't know where else to ask this question. Superuser already shot me down, and the Gadgets FAQ makes me think it's not a good fit there, either. If this question really strikes you as too off-topic to permit here, do what you gotta do. But, please. If you could go either way, I beg for your mercy.
I have a Pioneer DVD-V5000 player that I'm trying to control via 9-pin RS-232 port. (As opposed to the 15-pin port that's hard to find cables for.) Trouble is, I can't get the thing to acknowledge any commands. I'm not even getting any error messages back; only silence.
I have the specs for communicating with that port in front of me, and as far as I can tell I'm doing everything right; I'm sending two-character ASCII commands followed by a <CR>. I've gone into the Advanced Setup menu on the player, and have selected the 9-pin port (factory default is the 15-pin). The spec seems to be indicating the 9-pin port is perfectly standard; I don't see any indication I need some kind of custom cable to be using it. And I'm following all the setup protocols from the spec: 8-bit data length, 1-bit stop bit, no parity. Baud rate can be either 9600 or 19200, depending on the Advanced Setup, but neither works.
I'm fairly sure the software handling the COM-port communication isn't the problem. I've used a version of this software to successfully control another device, and I'm getting identical results (no response whatsoever) when I try to manually shove through commands with a serial port terminal.
Is there anybody familiar with Pioneer's serial-controlled electronics who can give me some suggestions about where I'm going wrong, or for other avenues of investigation?
For the sake of anybody else in a similar bind who stumbles across this question, I'll swallow my pride and record the correct solution, rather than just delete this into oblivion and pretend I was never this dumb. (Topicality hawks, I'm now far less worried about you nuking this thing.) The solution is unrelated to the specific hardware. It's all about the RS-232 cables and what NOT to do with them.
Specifically, if the F-F cable you have is too short, do not use a M-F cable as an extender -- or, if you do, use two of them. Regardless, your total number of cables MUST BE odd. What's Pin 2 on one end is supposed to be Pin 3 on the other end -- but if you have an even number of cables, then Pin 2 on one end goes to Pin 2 on the other end. This is wrong, and whatever gadget you're trying to talk to will rightfully ignore you. You will get very frustrated, fruitlessly Google away trying to figure out what you did wrong, and post lengthy questions of dubious topicality on your favorite Q&A site.
And seriously, who needs that?
I'm new to this field - but I need to perform a WAV-to-MIDI conversion in java.
Is there a way to know what exactly are the steps involved in WAV-to-MIDI conversion?
I have a very rough idea as in you need to;
sample the wav file, filter it, use FFT for spectral analysis, feature extraction and then write the extracted features on to MIDI.
But I cannot find solid sources or papers as in how to do all that?
Can some one give me clues as in how and where to start?
Are there any Open Source APIs available for this WAV-to-MIDI conversion process?
Advance thanks
It's a more involved process than you might imagine.
This research problem is often referred to as music transcription: the act of converting a low-level representation of music (e.g., waveform) into a higher-level representation such as MIDI or even sheet music.
The sophistication of your solution will depend upon the complexity of your input data. Tons of research papers address music transcription only on monophonic piano or drums... because they are easy to transcribe. (Relatively.) Violin is harder. Voice is even harder. Violin plus voice plus piano is much harder. A symphony is nearly impossible. You get the picture.
The basic elements of music transcription involve any of the following overlapping areas:
(multi)pitch estimation
instrument recognition, timbral modeling
rhythm detection
note onset/offset detection
form/structure modeling
Search for papers on "music transcription" on Google Scholar or from the ISMIR proceedings: http://www.ismir.net. If you are more interested in one of the above subtopics, I can point you further. Good luck.
EDIT: That being said, there are existing solutions that we can all find on the web. Feel free to try them. But as you do, evaluate them with a critical eye and ear. What types of audio signals would cause transcription to fail?
EDIT 2: Ah, you are only doing this for piano. Okay, this is doable. Music transcription has advanced to the point where it can transcribe monophonic piano pretty well. A Rachmaninov concerto will still pose problems.
Our recommendations depend upon your end goal. You state "need to perform... in Java." So it sounds like you just want something to work regardless of how it gets you there. In that case, I agree 100% with others: use something that exists.
That's actually an interesting question; all of the MIR libraries I know are typically C/C++/Python/Matlab. But not Java. The EchoNest has a Java API, but I don't think it does note-level transcription. http://developer.echonest.com. (Edit: It does note-level transcription. The returned data includes pitch, timbre, beat, tatum, and more. But I find polyphony is still a problem.)
Oh, Marsyas is Java-based. Cool. I thought it was just C++. http://marsyas.info/ I recommend this. It's developed by George Tzanetakis, a professor in MIR. It does signal-level analysis and should be a good option.
Now, if this is for a fun learning experience, I think you can use the sound manipulation utilities in Java to experiment with the WAV signal and see what comes out.
EDIT: This page describes MIR software better than I can: The Tools We Use
For Matlab, you may be interested in the MIR Toolbox
Here is a nice page of common datasets: MIR Datasets
This is a very big undertaking for being new to the field, unless you mean you are familiar with signal analysis and feature detection in general and want to look more specifically into automatic transcription.
There is no API for WAV to MIDI conversion. Vamp is a framework for feature extraction plugins, but to do automatic transcription you would need to use all the functionality of the existing plugins, plus implement functionality that exists in none of them yet.
Browse through the descriptions of the plugins on the vamp download page, any descriptions you do not understand are topics you should start researching if you want to do this.
If you don't need to automate this task (ie, for a website where people can upload MP3's and get MIDI files back), then you should consider using a tool like Melodyne which is already quite good at going this. As Steve noted, this is a very difficult task to accomplish, and even the best algorithms and solutions present at the moment are not 100% reliable.
So if you are just doing studio work and need to do a few conversions, it will probably save you a bit of time (and lots of headache) to use a tool already designed for this task.
This is a field which is still highly under development, yet, there are some (experimental) algorithms available.
You can install sonic annotator and use a few vamp plugins.
For example:
./sonic-annotator file.wav -d vamp:qm-vamp-plugins:qm-transcription:transcription -w midi
./sonic-annotator file.wav -d vamp:silvet:silvet:notes -w midi
./sonic-annotator file.wav -d vamp:ua-vamp-plugins:mf0ua:mf0ua -w midi
Dolphin, sorry to be brusque, but you have completely underestimated the problem. What you want to achieve - a full piano sound transcription involving all parameters that were used while playing would need an enormous amount of research with people who have worked in the field for many years. Even a group of PhDs in signal processing would have to invest a lot of work to even come close to what you mean. Music transcription has needed decades of work to even work halfway reliable. I'd suggest you pick a different problem which you can manage better than this.
Besides Arduino, what other ways are there to learn hardware programming in a hands-on way? Are there any nifty kits available, either a pre-assembled robot, that you can program to move a certain way, or do certain things, or anything similar to that?
Atmel AVR and the PIC both have experiment boards that you can use solder stuff on to, usually they have a couple of buttons and some lights pre-soldered to the area. This let's you program/flash the microprocessor and play with the output pins. You can either write the programs in assembly or C.
Parallax have a number of kits. They have two product lines suited for "playing around", Basic Stamp and something called Propeller. The former is a small microprocessor that runs programs written in Basic (a tad disgusting ;)) and the latter runs something called Spin or assembly (well after compilation obviously.)
I would go with either AVR or the PIC. I've done PIC but I've heard good things about AVR, they seem to ship with better software.
At first look Microsoft's VPL sounds good, but when it comes to actually LEARNING how hardware works it goes a LONG way to hide those details from you. As a matter of fact it is pretty much designed for people who don't program, and is distastful to someone who's actually written embedded software. IF you just want to make stuff happen and not delve into the details it's fine, but if you want to get down to the metal like programming the "Arduino" boards it's not for you.
If you're used to something like the Arduino then something like the PIC will be an easy transistion. SparcFun Electronics has all sorts of DIY type projects and hardware available. If you have a decent bookstore around your area, I would suggest looking for "Circuit Cellar" magazine. It has articles on a monthly basis with project for someone looking to get into hardware projects, everything from homebrew Software Defined Radio to FPGA based 3D graphics. (Raytracing actually) Usually the authors describe the project in an article and "WHY" they made the decisions they did, a description and schematics of the hardware and provide a link to source code.
Cypress Semiconductor has one of the most interesting embedded processors on the market and several high quality dev boards for sale. The PSoC includes the ability to not only configure the software, but also to "drop in" software configured hardware such Analog to digital converters, serial I/O, Digital to Analog and Various amps and filters. It's a REALLY cool concept, and the "touch sensor" capability of the PSoC were actually used in several models of the IPod.
One thing about programming these little micros is they don't have a lot between you and the hardware, you get to see how things really work. It doesn't matter whether you're talking about an 8-bit microcontroller or a quad-core Pentium programming hardware is largely the same concept. You write to a memory mapped register for some piece of hardware like a serial controller, and the hardware responds in someway. If you program a baudrate generator in a PIC or PC it's largely the same idea, you write a value that will be used as a division factor from a given clock to achive a given baudrate. The numbers and names maybe different, but the concepts is the same. On a PC you may have to map to the PCI address of the card, which adds a some complications, but if you looked underneath the OS you would see that that was done just by writing values to registers simalar to programming a PIC to use a different "Page" of memory. Is it worth learning an 8-bitter? Well, there are approximately $5 billion dollars in sales of the little 8-bit micros today with projection only showing growth in that market in the future. I saw one reference that state the average car has 25 Microcontrollers in it. That's not too bad.
I haven't played with it much, but the iRobot looks pretty cool.
The ability to simulate how your robot will work which some of the other answers mentioned is nice, but there's nothing like seeing a real-life robot do what you programmed it to do. That, to me, is what really makes robots fun and cool.
There's the .NET Micro Framework.
It's incredibly simple to use/setup and there's lots of hardware being made to target this framework.
You should take a look at Microsoft Robotics Developer Studio which supports many different kits.
I have always been curious about gumstix. It seems more professional than arduino, and it aims at the Linux programmer. I cannot give you a real suggestion, as I've never played with it, but I would definitely go with one of this toys if I had to do and learn some cool hardware programming.