We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I've just started playing with MCB2130 and did some examples.
Now I would like to enable / clear leds with external file. So, I would write a text file, each line would be a led address that would stay on for some time, then it would clear that and enable the second one... till it reaches the end of this file.
My biggest problem is - how to load a file into memory (I was looking at voice player example, so by using flash.ini file, but is this the right way for simple text files??? Do I need to convert them to some other format?)
- how to read such file (Is it always at same memory address, how to determine it's length...)
I'm not sure if this is the right approach to this problem at all, but instructions needs to be in a file.
Use the serial port. Send the list as text - one command / text line. Write code to retrieve serial data. Decode the lines as they are received. Place the decoded data in an array. Let the main loop run through this array and perform the actions there.
If you require the commands to survive a reboot, then you have to modify the code so that you end the command list with a write command. When the decoding sees the write command, then you write the array contents to a flash sector that you can load on boot.
Do not try to program the development board as if it is a PC, with a file system and similar.
If you add TCP/IP support, then you can instead send the commands that way.
Thank you for your fast reply!
I will try that way, since it seems much easier also. However I don't have a com cable right now here, so I'll have to try to do that via usb - hope it isn't too hardcore for a beginner either.
I got a com cable. Does anyone have com port settings for mcb2130?
"Does anyone have com port settings for mcb2130?"
Wrong question. The com settings required for a mcb2130 board will depend on the settings configured by the application running in the board.
If you download an application that opens the serial port for use with 9600 baud 8N1, then that is the setting to use on the PC too. If you download an application that opens the serial port for 38400 baud 7E2, then that is the setting you should have on the PC side too.
I see!
Digging trough more examples and following your advice, I managed to write an application which successfully reads data from com port.
Inside a while loop I execute readchar() (reading char by char), but unfortunately I'm not able to detect end of line.
if (key == '\n') doesn't seem to work, neither if I try to detect '\'' alone. How can I reliably determine when it is end of line or end of file (whole data stream)?
There are no \ character involved. \ is - when used inside a string or character constant in C or C++ - a break character, telling that the following character has a special meaning.
Maybe you should look for '\r' (carriage return) instead of '\n' (newline) - or maybe you should check for both alternatives. That depends on how the PC-side program is configured.
By the way: to really send - or test for - a \ character, you have to write '\\' or "This is a backslash: \\" in the code.
There are no special characters or signaling that will inform about an end-of-file.
You will either have to detect the timeout when no more characters arrives (with the problem that a disconnected cable, rebooted PC or terminated PC program will also look like an end-of-file) or you will have to decide yourself on a suitable convention to send.
You may decide that the transmission of an empty line represents end-of-file. Or a line with only the character $. Or a line with the text "END". Or possibly something else that is unique and will not collide with the lines holding real data. Or you may decide that the first information sent to the microcontroller should be a text line containing the number of bytes to read. There are many possibilities, and figuring out the alternatives and then decide on a good solution is part of being a developer. Google or forums may supply suggestions, but in the end, you will have to make design decisions.
Create a separate document where you do list the different problems you have to solve for this project.
List the possible solutions you see for each problem. Then write down which solution you select, together with the reasons why you made your decision. If you later find that a chosen solution does not work well, then you can return to your document and fill in the problems you saw and see if any of the other alternatives can be used instaed, or if you will have to sit down and think of a complete new alternative.
If this is a school project, you can then supply this document as an appendix to your lab report, showing that you have not just randomly written a number of code lines but also spent time with design issues.
Thank you for your extensive reply!
I managed to write a program that captures com input and then cycles leds like it was instructed.
All instructions are in a linear linked list (dynamic size), you were talking about the possibility to write those data, so they survive reboot. How? Basically I need to "dump" linear linked list and load it at boot...
Store the data in an array.
Look at the application notes how to write to a flash sector.
Combine these two concepts and you have code that can save the data to flash.
Something is bothering me with serial communication. What is the minimum delay between sending bits via serial?
I'm using java and if I don't pause for small time (e.g. 100 ms), then characters are not properly received and program on mcb board doesn't work (this happens from any program).
Also how can I do multiple things at once - e.g. blinking leds and at the same time listen continuosly for incoming data from com port?
Use interrupt-driven serial communication. Many samples available if you google for it.
Then your main loop can run a loop that checks if it is time to change state of a diode or if the input buffer have one or more received characters to process.
If you poll the serial port, then you must poll it often enough that you will react and fetch a received character before the next character arrives - normally around 10 times the baudrate. With 9600 baud, it takes about 10ms for each character to be transmitted. Polling at a slower speed will result in one or more lost character. With interrupt-driven communication, the size of the receive buffer will allow the main loop to take longer time to check if there are received data, without any loss. Sometimes, it can be enough to have a 8 or 16-character receive buffer to solve any problems with lost characters.