As a hardware illiterate software guy trying to do a hardware prototype, will appreciate an answer to this.
One of the hardware components that I need to integrate supports only lpc interface. Is there a way to have it work with arduino? Does the question even make sense? What are my options with this?
I tried doing a bit of research on this, but simply didn't understand anything, nor was there any direct reference to anything that makes this possible.
I guess you're talking about Intel's Low Pin Count protocol.
And I guess, you're trying to make a BIOS flasher, aren't you? ;-)
Is there a way to have it work with arduino?
yes
Does the question even make sense?
of course
What are my options with this?
Have a look at that article and this thread… It shows and gets into some details in how to implement it.
As you say you're a software guy, just consider that you're trying to implement some kind of network procotol stack, starting from the basic building blocks. You need to take care of sending the bits over the pins, take care of the timings, output the start/end stop flags if there are… And then implement a buffer on top of that to parse a byte, and then bytes, etc…
All you need to do that is to follow the sepecification, and plug a few pins on the Arduino.
Well, your question should be closed for lack of research effort, but hence you say you tried but are still lost, I hope my insights will help you come back and ask a real on-topic question with something you actually tried.
HTH
Related
I am asking this well ahead of applying it to get myself a chance to study content of answers.
Basically the question is if there is Arduino compatible chip (I am not interested in boards) which does not need external crystal to keep it in close enough sync to run serial (232) communication. To mine knowledge the atmegas builtin crystals are not very well calibrated. The speed of communication does not need to be high in fact I see no problem for less then 0.3kb per second.
I know its off topic, but best I have found was RTL8710 Roughly the the atmegas price, enough i/a with extra wifi as bonus. In case somebody is looking for answer
for an art-project I want to control an array of say 60 to 600 lightbulbs. Each lightbulb should have his own radio-remote. So one remote should switches only one bulb on and off.
I want to do this with an arduino Uno. Do you think this is possible? Is there a better choice?
The remotes I thought of using have 8bit encoding.
As I`m only in possession of dangerous half-knowledge, I thought I ask you guys first.
thanks in advance
Without more details it is hard to say. I think it would be more appropriate to use only one remote and 600 receivers though. If you have only 8 bit encoding you will be limited to 256 receivers unless you introduce an additional code on top of the existing protocoll.
However you would have to keep in mind that the Arduino has only very limited RAM. So the tight RAM constraints could be another issue.
But unless you provide more details (what are you aiming at, which remotes, how fast do you want to switch the bulbs) it is impossible to provide a better answer.
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.
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?
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm interested in building a little (commercial) device on top of Arduino. I want it to be able to interface with network. Network as in standard Ethernet, Cat5, RJ-45, etc.
I know that there is an Ethernet Shield, but it costs even more than the Arduino itself, and it's pretty big. Naturally, I want my device to be as small and as cheap as possible.
So I'm thinking about recreating an Ethernet module myself. The problem is - I haven't got any experience with Ethernet, nor do I have a good idea where to start looking. Thus I can't even say if my ideas are feasible.
Ultimately I would like the device to have three ports - one for incoming signal, two for outgoing, so the device is essentially a little switch where it is plugged in itself as well. The switching capabilities need not be very fast - the volume of data will be low. 10Mbit is more than enough, can be even slower.
If that is not possible, a single port for controlling the device itself will also do.
Another possibility I'm considering is power line communications - sending information through power lines. That's another area I've no experience with. What hardware should I be looking at, and where can I find information about the necessary software?
So - can anyone tell me if these ideas are feasible, and if yes - where should I start looking?
It's feasible, but you're going to need to delve deep into layer 2 of the network stack, especially if you want to build a tiny switch. If you steer clear of layer 3 you can avoid having to implement your own IP stack which would be a major pain.
I'd recommend starting with fully understanding how layer 2 works, from top to bottom. Once you've got a solid grasp of what's going on, especially with regards to the Ethernet spec, then you can worry about how you'd go about doing that on an Arduino. I don't have that much experience with the Arduino, but a buddy of mine implemented a layer 2 hardware stop-and-wait protocol on an FPGA a few weeks ago, so you should be able to get at least something rolling. you probably won't be able to go any faster than 10 Mbit unless you've got a pretty fast clock, though.
First of all I wouldn't think about the powserline technology is too complex, may be wi-fi can be possible, even though you have to deal with microwave frequency.
The best solution is as you said to find an Ethernet Shield, try to find an open hardware solution (drawing of the circuit). If you want to deal your own, you have to fnid a chip and threre are available, have a look on RS components. Probably most of the chips available are SMD, which means that is a pain to solder them, unless you are pretty clever and you have a microscope.
You can find a chip or a ready made solution here; http://www.beyondlogic.org/etherip/ip.htm
You could switch to Rabbit semiconductors, they have microcontroller ready with ethernet, but the dev kit is more expensive and the programming too.
This is a chip that you can use; http://www.wiznet.co.kr/en/pro02.php?&ss[2]=1&page=1&num=102