I was trying to interface a 64 mb MicroSD card with MicroChip MCU. I sent cmd0-addr3-addr2-addr1-addr0-crc but didn't got any response.
What should I do next?
From the way you've phrased the question, it sounds like you don't have a very good understanding of how to communicate with external peripherals in general, on an embedded device. You should reference Microchip AN1169 which goes into detail on implementing SD card communication with an SD card. If that's not enough help, Microchip's application engineers are usually very helpful - don't rule out calling one.
On the other hand, if the application note is still over your head, you should strongly consider starting off with a less ambitious project - something like driving a motor or other simple IO that is not address-bound. The addressing issues can become very difficult when you already aren't familiar with embedded programming.
I stumbled on this thread because I was facing a similar problem. I know this thread is old but I want to post my experience here just for the record.
I have been doing FS and device programming for more than 8 yrs now so I am not a newbie :)
I was trying out PIC32MX and its inbuilt libraries for the first time and ran into the same problem as mentioned in the question. I double checked my connections after which I started doubting the library. I downloaded the latest versions for fixes but same behavior.
After lot of debugging for both hardware and software I found out that the microsd sockets contact for power was not sticking to the card contact at all! No power No response!
Related
currently I got the task to write a python program to read out measurement devices. I have some trouble fulfilling this task. Right now I try to understand how the communication between drivers, devices and computers in detail (serial devices, USB in particular). I already invested a few weeks searching for information in literature (Internet and library). Indeed, I wasn't succesful. The information I got were either far too detailed or too general. I wanted to ask if someone could recommend me good information sources for this topic.
This is my first post in Stackoverflow. I hope this question is not too general or misplaced for this communitiy, if so I am very sorry.
Firstly, this may be a stupid question or one that has been asked before but I am not quite sure how to google it.
I try to learn a bit about using modbus to communicate over serial interfaces and I have trouble understanding the mechanic of getting your signal on the wire/connection. I do unterstand how protocols (e.g. Modbus) encode and decode their Data. I'm interested in the process of getting your bitcode through the interface (preferably rs232) to the other machine.
In other words: How can I write a piece of code myself (no libraries etc. I want to learn how to do it) where I can input a couple of binary numbers and maybe the baudrate so that another device with a working modbus driver can receive it via direct cable connection.
If the matter is too complicated for an answer here, I'd be happy to get a link to some resources to teach myself as well. Or even some help for the right search terms.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone have especially good (or bad) experiences with any of the following embedded TCP / IP stacks?
uIP
lwIP
Bentham's TCP/IP Lean implementation
The TCP/IP stack from this book
My needs are for a solid, easy-to-port stack. Code size isn't terribly important, performance is relatively important, but ease of use & porting is very important.
The system will probably use an RTOS, that hasn't been decided, but in my experience most stacks can be used with or without an RTOS. Most likely the platform will be an ARM variant (ARM7 or CM3 in all likelihood).
Not too concerned about bolting the stack to the Ethernet driver, so that isn't a big priority in the selection.
I'm not terribly interested in extracting a stack out of an OS, such as Linux, RTEMS, etc.
I'm also not interested in commercial offerings such as Interniche, Micrium, etc...
The stack doesn't need all sorts of bells & whistles, doesn't need IPv6, and I don't need any stuff on top of it (web servers, FTP servers, etc..) In fact it's possible that I'll only use UDP, although I can envision a couple scenarios where TCP would be preferable.
Experiences with other stacks I've missed are of course also very much of interest.
Thanks for your time & input.
I've used both uIP and lwIP extensively.
uIP
Great if youre only wanting something basic like a bootloader
Small footprint.
Uses polling so we've never got over 3kbit with it :-(
No DHCP 'out of the box'
Poor UDP support
lwIP
Fully interrupt driven so much faster (~ x10)
Includes DHCP with failover AutoIP
UDP with multicast
Plus more
EDIT:
And we've never used either with an RTOS as there has never been a need.
+1 for lwIP.
We used this successfully on a project a few years back and found it to be generally very reliable. We found and fixed a few issues (generally corner cases within the TCP code) which we submitted back to the project, and even though the project has moved on quite a bit since then we didn't generally find it lacking in any features.
As you suspect it will work with or without an RTOS. It took about a week to get running on our system with an RTOS, which included changes we had to make to support an unusual DSP compiler. As you're probably using GCC on ARM you can avoid any of that effort.
It does contain many more features than you require, but if your requirements change a few years down the line then you'll be better off having started out with a more substantial stack.
lwIP
I worked on a project with a 3G modem where we needed a UDP/IP stack (no TCP) on top of PPP. We narrowed down to uIP and lwIP. We picked lwIP in the end because it had PPP already (uIP doesn't), and we had enough RAM to spare.
Our particular project didn't use an RTOS, and lwIP was fine to use without an RTOS.
I wasn't directly involved in porting the lwIP code, although I worked on the modem driver to interface with it. My impression was that the porting took a couple of weeks to get everything going smoothly, for our engineer who had previous TCP/IP experience. The lwIP code has been hacked by many people, and consequently has some rough edges (e.g. someone threw in a lone malloc() somewhere) but it worked for us after a little tweaking. We tested it with an independent validation suite.
In summary, it was "suitably functional" for our UDP/IP and PPP needs (but I can't comment on its TCP capabilities).
+1 for lwIP.
It is included in the Luminary Micros (now TI) Serial to Ethernet reference design with some added capabilities (some sort of "server side scripting" and cgi) working on bare metal (without RTOS).
It is rock solid and very performant with only 32KB or RAM.
Regards
PFM
I am pleased with lwip on the Stellaris Cortex-M3.
StellarisWare for the LM3S6965 eval board includes the enet_lwip demo. This is a small web server running over lwip which is running over bare metal -- no FreeRTOS in this case. The system is driven by the timer and Ethernet interrupts. It was pretty easy to rip out the web server and drop in my app. I did not have to become an lwip expert to get this running the first time.
Later I realized that my app was intrinsically up-call driven. At first, it had a sockets-to-upcall gasket. I replaced that layer with a much simpler one that translates lwip native upcalls to the app's upcalls, and optioned out lwip's socket API. This saved more flash and RAM space, and made the whole thing faster and simpler. With a little tweaking I got it running on the S2E board using 52K flash and 30K RAM.
You can try the open-source FNET TCP/IP stack.
I've used the Microchip TCP/IP stack. I've been very happy with it. It was very easy to implement, lots of demo code/tutorials available, and has support for a lot of protocols HTTP, tFTP, SMTP, SNTP, etc. A point that doesn't match your requirements however is that it is not easily portable to another architecture. In fact I think the license for the stack explicitly forbids this because Microchip wants you to run the stack only using their hardware the PIC18, PIC24, and PIC32. There is however an external Ethernet controller they sell that they will allow you to use certain portions of this stack with their ENC28J60.
I have used Interniche on FreeRTOS.
It's a full-fledged stack and supports quite a few features.
Since you are looking for a non-commercial version, my vote is on lwIP.
So I want to learn all about networks. Well below the socket, down to raw sockets and stuff. And I want to understand hubs, routers, access points, etc. For example, I'd like to be able to write my own software to do this kind of stuff.* Is there a great source for this kind of information?
I know that I'm asking a LOT here, and that to fully explain it all requires from high level down to low level. I guess I'm looking for a source similar in scope and depth to Applied Cryptography, but about networks.
Thanks to anyone who can help to point me (and others like me?) in the right direction.
* Yes, I realize using any of my hand-crafted network stack code would be a huge security issue, and am only looking to do it to learn :)
Similar Question: here. However I'm looking for more than just 'what's below TCP/UDP sockets?'.
Edited for Clarification: The depth I'm talking about is above the driver level. So assuming that the bits can make it to and from the other end of the wire, what next?
I learned IP networking from TCP/IP Illustrated. Highly recommended.
This may not help you learn it, but a packet sniffer like Wireshark will give you some insight into what the data looks like at a pretty low-level protocol (TCP/IP).
As you have obviously recognised, the universe does not start and end with the IP Protocol. Take a look at the OSI 7 Layer Model where IP is a Layer 3 (Network) protocol. Common IP Routers will operate at this level, but there is more complexity you probably should understand in the Data Link and Physical layers before you start coding your own network stacks.
Start with the fundamentals of data communications in all its myriad forms and work your way up the stack until you get to where you need to stop. Data Communications, Computer Networking and Open Systems is a good foundation text, and then look for more detail on each area you need to focus on. Previous answers include good links for IP and TCP/IP, and as mentioned Wireshark will let you look down through some of the layers
CISCO CCNA materials contain a great network fundamentals, but does not affect programming aspect. I'm not sure that there is an official free link, but you can try to find them.
You should equip yourself with a c compiler and the necessary libs and headers for your OS and play around. You may want to read for example:
http://snap.nlc.dcccd.edu/learn/fuller3/chap13/chap13.html
I had some more links in my delicious account, but they all went down the digital drain ;-)
Have you any embedded programming experience ? If so I recommend you buy one of these development boards. They are cheap and allow you work on every part of the networking stack plus all the software tools required are free.
Note that getting going on it isn't easy and I ended up reading the CS8900 IC datasheet to learn how to make it communicate with the ARM7 based processor. But if you enjoy that sort of thing (as I do) then they are great fun.
Hmmm ... have you looked into Computer Networks by Tanenbaum ?
The TCP/IP Guide
I have found the networking chapter in "understanding the linux kernel" and "understanding linux network internals" from oreilly to be very helpful.
The TCP/IP stack is a very good start but there is a lot more and a good understanding of how ethernet works and how ethernet != IP != the-interweb will go a long way.
books on network security often do a decent if not goos job explaining how networks work in a concise context.
what really did the trick for me was taking a job implementing NAT :)
This course worked for me: COS 461 at Princeton. Note that it assumes system-level programming experience with C.
Pretty much all the readings and lectures are available online under "Syllabus". And you can try the assignments too (unfortunately, you won't have access to the Virtual Network System).
Check this.. it is a good collection of information:
http://www.tcpipguide.com/free/t_toc.htm
A bit of history: We have an application, which was originally written many years ago (1998 is the first date in PVCS but the app is about 5 years older than that as it originally was a DOS program). This application communicates with a piece of hardware via serial. When we got to Windows XP we started receiving reports of the app dying after a short time of running. It seems that the serial comms just 'died' and the app was left in a stuck state. The only way to recover from this situation was to restart the application.
The only information I can find regarding this problem was apparently the Windows Message system would miss that information was received, the buffer would fill and the system would get stuck. This snippet of information was left in a old word document, but there's no evidence to back this up. It also mentions that this is only prevalent at high baud rates (115200+).
The solution was to provide customers with USB->Serial converters along with the hardware.
Today: We are working on a new version of the hardware that will run across a network as well as serial ports. So to allow me to work on the network code, minus the actual hardware we are using a VSCOM NetCom113 device. It also installs a virtual comm port on the users (ie: mine) machine.
Now I have got the network code integrated with the app, it appears that the NetCom device exhibits the same behaviour as a physical commport. This is undesirable as I need the app to run longer than ~30 seconds.
Google turns up zero problems that we experience.
I was wondering:
Has anyone experienced this before? If so what did you do to fix/workaround the problem?
Does anyone have any suggestions as to whether the original author of the document is correct and what I can do to test the theory?
Unfortunately I can't post code as the serial code is tightly couple with the rest of the system, though if you have questions regarding it I can answer questions about it.
Updates:
The code is written using Win32 Comm routines - so I am using CreateFile, ReadFile. There's also judicious calls to GetOverlappedResult.
It's not hanging per se, it's just that the comms stops. You can access the menus, click the buttons, but nothing can interact with the connected hardware. Using realterm you can see that no data is coming in or going out.
I think the reference to the windows message is that the problem is internal to windows. Data has arrived but the kernal has missed it and thus not told the rest of the system about it.
Flow control is not used.
Writing a 'simple' test is difficult due the the fact that the code is tightly coupled and the underlying protocol is quite complex and would require a lot of work.
Are you using DOS-style serial code, or the Win32 CreateFile approach?
If the former, be very suspicious: if at all possible I'd convert to the latter.
If the latter, do you know on what kind of system call it's hanging? Are you in a blocking read call? or an overlapped I/O call? or waiting on an event? (I'm not sure I have enough experience to help, but those are the kinds of questions that come to mind)
You might also check into the queue size, which you can set with the SetupComm function.
I don't buy the "Windows Message system" stuff -- it sounds fishy; you can write good Win32 serial i/o code that never uses Windows messages.
edit: does your Overlapped I/O use events? I seem to remember something about auto-reset events occasionally missing their trigger... check your overlapped I/O calls very carefully to see whether you're handling the possible outcomes properly. Perhaps there's a way to make your code more robust by automatically cancelling the overlapped i/o and restarting another read. (I assume the problem is in the read half, not the write half?)
edit 2: A suggestion: assuming the win32 side has missed a byte or packet, and your devices are in deadlock because they're both expecting each other to respond to something, can you tweak the other side of the serial I/O to regularly send some type of "ping" packet with an incrementing counter? (and log the ping packets on the PC side; that way you can see whether you've missed any)
Are you sure you have your flow control set up correctly? DTR, RTS, etc...
-Adam
i have written apps that use usb / bluetooth serial ports and have never had an issue. with bluetooth i have seen bit rates (sustained) of 800,000 bps for long periods of time. most people don't properly implement the port.
My serial port
Not sure if this is a possibility for you, but if you could re-write the code using C#.NET you'd have access to the SerialPort class there. It might remedy your problem. I know a lot of legacy code based around the Win32 API for hardware I/O ports tended to fail in XP due to timing (had a small bit of experience with MIDI).
In addition, I don't know if you can use the Win32 method of Serial Port access in Vista, so that might shut out future MS OSes from being able to use your code.