I'm new to Processing and serial communication and my problem seems very elementary. I'm trying to send data over from Processing to an Arduino but it seems that something gets lost in translation.
On Arduino I'm running this super simple sketch:
void setup()
{
Serial.begin(9600);
}
void loop()
{
if (Serial.available() > 0) Serial.println(Serial.read());
}
The intention there is to read a byte from serial and then write it right back so I can see what is going on. Testing this with the included serial monitor behaves as I'd expect: typing in "0" returns "48". So far so good.
Things start to go wrong when I run this Processing sketch:
import processing.serial.*;
Serial myPort;
void setup()
{
//frameRate(10);
myPort = new Serial(this, Serial.list()[4], 9600);
}
void draw()
{
myPort.write("0");
}
I woud expect this code to return an endless stream of "48" with the rate of ten entries per second, since I understand that is the default frame rate. What really happens is something like this:
48
48
488
48
48
48
48
48
48
48
48
48
48
488
48
48
48
It seems like every 10th (give or take a few) byte has a good change of being messed up. Instead of "48" I get back stuff like " ", "488", "4848" or "488". What's even more interesting is that if I uncomment the frameRate(10); line in my Processing script I would expect absolutely nothing to happen, since I'm setting the fps from ten to ten. Instead I start to see stuff like this:
4
44
4848844
444448444844
4
44444444
844
444
844444
8
88
8
4488
84
48
4448444844
444
So basically the numbers make so sense anymore.
It took me quite some time to narrow the problem down to this serial communication and a few hours of Googling around related topics has given me no hints about what might be going on. Any pointers toward further reading or things to try would be greatly appreciated.
I'm using the latest version of Processing downloaded today and my system is a MBP running Mountain Lion with all updates installed.
After some further testing, it seems that having the serial monitor on while sending bytes from Processing messes both up for a yet unknown reason. I assume there is some sort of fighting over serial bus priority and the data ends up broken.
Solution: don't try to use multiple programs to read serial data simultaneously.
As you have figured out, if you have multiple programs trying to read data from Serial, it could result it such problems.
You can also try out the Software Serial Arduino library, which allows you to use any pins as serial pins.
try replace:
myPort.write("0");
with:
myPort.write("0")-'0';
Because
ascii 0 --> 48
ascii 1 --> 49
.
.
.
Related
If I use the Arduino IDE's Serial monitor I can read the pair of comma separated values as below:
I want to first replicate this behavior in SciLab terminal. I used the Serial Communication Toolbox:
h = openserial(7, "9600,n,8,1") // open COM7
disp(readserial(h))
closeserial(h)
which returns either empty or
, 169
228, 179
228,
228, 205
228, 209 228,
putting the disp(readserial(h)) in a while loop also doesn't help. Not only there are too many empty lines, if I stop the while loop it does not close the port (something like try-catch should be used I think). I would appreciate if you could help me know how I could get the same behavior as Arduino's serial monitor?
P.S. Next I want to plot these two values in realtime. So maybe using the csvTextScan function to split the string into two integers.
OK, after a couple of days struggling I figured this out. It turns out that SciLab doesn't have native serial communication functionality and the Toolbox developer has used TCL_EvalStr to run Tcl commands externally. I had to dig into the Tcl serial communication syntax (i.e. read, open, gets, fconfigure ... ), ask another question, get some help and then finally end up with a new function for the Toolbox which I have committed as a pull request:
function buf = readserialline(h)
tmpbuf = emptystr();
while tmpbuf == emptystr()
TCL_EvalStr("gets " + h + " ttybuf");
tmpbuf = TCL_GetVar("ttybuf");
end
buf = tmpbuf;
endfunction
now one can get the above behavior by running:
h = openserial(7, "9600,n,8,1") // open COM7
for ii = 1:40
disp(readserialline(h))
end
closeserial(h)
to read the serial port line by line and print it to the SciLab console. Now to parse the CSV data you may use:
csvTextScan(part(readserialline(h), 1:$-1), ',')
P.S.1. I have used a virtual Arduino board inside SimulIDE and used com0com to create virtual serial ports. More information here on SourceForge.
P.S.2. More discussion with Toolbox developer Aditya Sengupta here on Twitter.
P.S.3. More discussions here on Tcl Google group
P.S.4. A full demonstration plus instructions here on Reddit
P.S.5. For those who might end up here, I have decided to rewrite Aditya Sengupta's repository here with several improvements.
I am not coding neither understand much about it, although have to run an experiment in the laboratory, and have to use HTBasic to receive data from 2 GPIB devices (IEE 488) and one RS232 (this one is a high precision lab scale ).
I am changing/adding to an old script that someone else wrote. It was only to receive data from the 2 GPIB devices.
I must get data only every 15-30 minutes (the experiment will run for a month) and even though I successfully receive data from the lab scale (device interface select code = 12) they only arrive "synchronous" for a loop every e.g. 10ms (milliseconds). If I make it every 1 second the data are "old" e.g. I removed the item from the scale and instead of showing me ZERO "0" it still shows the weight. Imagine what if I ask for a loop every 15 minutes.
It seems that received data arrives in order one by one and displayed with that order. Probably there is an internal buffer or something that stores them. Does any one know how to OPEN and CLOSE the communication with a serial device on DEMAND? e.g. for GPIB devices I am sending a command like TALK (talk) and UNT (untalk) every time the loop takes place, but I can't find out how to do this with the serial device.
I tried the CONTROL 12,100;0 and CONTROL 12,100;1 (XOFF/XON) but it didn't work.
Here is one of the scripts I tried that gives me the correct weighting values, but for loops every 0.01 seconds.
LOOP
ENTER 12 USING "10D";W
PRINT TABXY(70,20),"wEIGHT IS:";W
WAIT 0.01
END LOOP
END
I would suggest trying using handshake control.
You can control the Serial Interface using the HTBASIC CONTROL statement.
For example, you can turn:
CONTROL 9,5;0 ! use DTR and RTS
CONTROL 9,12;0 ! read DSR, CD, and CTS
You should also use Interface handles as such:
ASSIGN #Serial TO 9 ! Opens the Serial Port, and clears buffer
ASSIGN #Serial TO * ! Closes the Serial Port
This should work for 15 Min Cycle (900 Sec):
ON CYCLE 900 GOSUB Get_Serial
LOOP
END LOOP
STOP
Get_serial:!
ASSIGN #Serial TO 12
ENTER #Serial USING "10D";W
RETURN
END
Hi guys and thanks for your answers (they came a bit late though).
Most probably both of your suggestions may work (havent try them ..maybe in the near future)
What I did those days to solve my problem , was basicly something like : LOOP continuusly and print on specific area of the screen (CRT) the serial device values (weight in gramms) , ONDELAY of specific time (eg every 15minutes) go to NEW LOOP (called it LOOOP in the code) which tells program to grab the value of RS232 labscale from the screen (not the device directly) and ofcourse the 2 GPIB devices, and after that repeat the continuus LOOP to show on CRT screen the real/continuus labscale values to prevent bufffer from being full ... and so everything worked smoothly..
I understand that this in not a GOOD way for coding, but as i said i am a rookie in this field ...BUT IT WORKED
So the code i wrote was something like:
[....]
33 ASSIGN #Scale TO 12
52 ENTER #Scale USING "10D";Weight
54 PRINT TABXY(70,20),"Captured LabScaLE Weight=";Weight;" g"
55 A=Weight
90 ON DELAY T GOTO Loooop
92 LOOP
93 ENTER #Scale USING "10D";A
94 A=A
95 PRINT TABXY(65,35);A;TABXY(65,35);
96 !
97 END LOOP
98 !
99 Loooop: GOTO 100 !GRAPSE THN GRAMMH PU AKOLOYTHEI PX 171
100 !
101 !
102 ENTER CRT;A
116 !==============================================START LISTENING FROM RS232 labscale (DISPAY ON CRT CONTINUUS DATA)======
117 !ENTER CRT;Weight
118 Weight=A
119 PRINT TABXY(70,20),"Captured LabScaLE Weight=";Weight;" g"
120 !
121 !==============================================START LISTENING FROM GDS CTRL=======
122 SEND 9;UNL UNT MLA TALK 14 DATA CHR$(255)
123 ENTER 9 USING "#,B,4D,6D";S,Pressurea,Volumea
124 SEND 9;UNT DATA CHR$(255)
128 !=============================================START LISTENING FROM GDS CTRL=======
129 !
130 SEND 8;UNL UNT MLA TALK 13 DATA CHR$(255)
131 ENTER 8 USING "#,B,4D,6D";S,Pressureb,Volumeb
132 SEND 8;UNT DATA CHR$(255)
[.....]
150 GOTO 92 !
I've wrote my very first MSP-EXP430F5529LP LED on/off program.
and I wanted to analyze my program. but I had problem at my first step.
I extracted my LED program from board and I've got unclear data. (3)
that's my first question. what is that file format? I mean I want to know file format for my memory dump file. (3)
my second question is that why CCS 6 doesn't indicate memory address properly?
I know that MSP430 is 16 bit MCU. so every memory address should be 16 bit-width. but my assembly code(2) which is copied from CCS6 Disassembly View show me address just like 01XXXX format.
relative data dereference and execution flow branches work well. but why CSS6 make me confused? I mean I want to know that why CCS6 display memory addresse 24 bit-width??
anyone who know where is TI document which explain what I want to know, please let me know. please just don't mention MSP430xxxx User's Guide.
sorry for my english :(
1.c code
#include <msp430f5529.h>
volatile unsigned int i;
void main(void) {
WDTCTL = WDTPW | WDTHOLD;
P1DIR |= 0x01;
while(1){
P1OUT ^= 0x01;
for(i = 20000;i > 0; i--);
}
}
2.assembly code
0100c2: 40B2 5A80 015C MOV.W #0x5a80,&Watchdog_Timer_WDTCTL
0100c8: D3D2 0204 BIS.B #1,&Port_A_PADIR
0100cc: E3D2 0202 XOR.B #1,&Port_A_PAOUT
0100d0: 40B2 4E20 2400 MOV.W #0x4e20,&i
0100d6: 3C02 JMP (0x00dc)
0100d8: 8392 2400 DEC.W &i
0100dc: 9382 2400 TST.W &i
0100e0: 27F5 JEQ (0x00cc)
0100e2: 3FFA JMP (0x00d8)
0100e4: 4303 NOP
0100e6: D032 0010 BIS.W #0x0010,SR
0100ea: 3FFD JMP (0x00e6)
0100ec: 431C MOV.W #1,R12
0100ee: 0110 RETA
0100f0: 4303 NOP
0100f2: 3FFF JMP (0x00f2)
3.memory dump (MAIN)
:1044000031400044b113ec000c930224b1130000be
:104410000c43b113c200b113f00000000200000011
:10442000840001001a44000000240000ffffffff89
:10443000ffffffffffffffffffffffffffffffff8c
:10444000ffffffffffffffffffffffffffffffff7c
...
...
If one reads the User Guide (which is why they exist) then one is informed that the Program Counter is 20-bit. So, now you know why you see an address in the 20-bit range.
Link to the MSP430 User Guide: http://www.ti.com/lit/ug/slau208n/slau208n.pdf
The 20-bit PC (PC/R0) points to the next instruction to be executed.
Each instruction uses an even number of bytes (2, 4, 6, or 8 bytes),
and the PC is incremented accordingly. Instruction accesses are
performed on word boundaries, and the PC is aligned to even addresses.
Figure 6-3 shows the PC.
The above is an excerpt from the User Guide. I cannot emphasis this enough - but you really need to read the User Guide. Not doing so and attempting to program microcontrollers is perlious to your mental health.
The memory dump seems to be in the Intel hex file format https://en.wikipedia.org/wiki/Intel_HEX
I am an electrical student and want to use arduino due to generate pulses for driving MOSFETs. I am making a inverter and want to generate pulses. I have arduino due with me. My main aims are :
1) one software interrupt for sampling the next time period (this will be changing..). After three cycles I will analogRead() new value of time period and same continues .
2) During one time period,set by RC count of Timer channel TC0, I want to load RA0 and RB0 with appropriate counts to get output pulses with different duty ratios(depending on RA0 and RB0 values).
I wrote a program which gives software interrupts with TC3 which is working fine. i.e. I am able to load new values into RA0 and RB0 automatically for every new sampled value( every 3 cycles new values comes else same values will be loaded).
Now I also used TC0 (i used Olavi Kamppari's library) for stopping, loading new values and starting the timer.
when i checked PIO_PB25B_TIOA0 and PIO_PB27B_TIOB0 in the serial monitor i am getting 33554432,134217728 .
I am really confused.I expected a 1 and 0 output. I just want two pulses from TC0 without interrupt.I set the ACPA value to 3 (Toggle) and I enabled the clock to the timer as well.Still I am not getting the output.
So if possible please provide me a sample program that can output pulses from PB25 and PB27 (TIOA0 and TIOB0). Any help will be greatly appreciated.
Thanks for reading my question.
Thank you.
The following sketch outputs a 3 MHz signal on TIOA6 (Pin 5 from memory)
I am about to post a question regarding the same code - I want to get to 8 (and a little bit) MHz but have hit a conceptual brick wall!
Note that this is under development - the IRQ handler is not used - and the PMC_Enable_Periph should be referring to ID_TC6 (I believe) - then the IRQ handler can be placed in the dust bin of history!
void TC6_Handler()
{
TC_GetStatus(TC2, 0);
}
void startTimer(Tc *tc, uint32_t channel, IRQn_Type irq) {
pmc_set_writeprotect(false);
pmc_enable_periph_clk((uint32_t)irq);
TC_Configure(tc, channel,
TC_CMR_WAVE |
TC_CMR_WAVSEL_UP_RC |
TC_CMR_TCCLKS_TIMER_CLOCK1|
TC_CMR_ACPA_TOGGLE ); // RC compare TOGGLES TIOA)smiley-wink;
TC_SetRA(tc, channel, 1); //50% high, 50% low
TC_SetRC(tc, channel, 1);
PIO_Configure(PIOC,
PIO_PERIPH_B,
PIO_PC25B_TIOA6,
PIO_DEFAULT);
TC_Start(tc, channel);
}
void setup(){
startTimer(TC2, 0, TC6_IRQn);
}
void loop(){
}
I have a bizarre one here with the serial output when trying to write some code for my Arduino Uno.
I have this proto-code:
MyClass myclass;
void setup()
{
Serial.Begin(9600);
Serial.println("Starting...");
}
void loop()
{
int status = myclass.DoWork();
Serial.println("Status: " + status);
}
class MyClass
{
int DoWork()
{
Serial.println("Doing some work...");
return 1;
}
}
Now when this runs I get the following output:
Starting...
Doing some work...
atus: 1
So the strange part is the "Status: 1" missing the first few characters. Is this because I am using serial in an object improperly or something?
I have noticed when I reference another library that also uses serial like MyClass does that I get other strange output behavior... so I assume that I am doing something wrong.
EDIT: In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
You cannot add strings and integers in C++. It would have been better for you if this failed to compile:
Serial.println("Status: " + status);
Instead the compiler guessed at something. It guessed wrong. Use this:
Serial.print("Status :");
Serial.println(status);
or for complete control of outputting numbers and strings learn to use C string formatting, sprintf()
In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
One more possible explanation.
I was running minicom to monitor, and I usually like that it auto-reconnects after resetting my device.
Well I minimized a terminal running minicom last night, and today I started a new instance that somehow also got connected to the same serial port (if that is even possible).
I think the two instances of minicom were each reading ~50% of the serial characters roughly at random, leaving me with quite a mess of text.