My name is Dylan; I’m from Cape Town, South Africa and I am new to the forum. Thanks for having me!
I am having a problem communicating serially with my Spark Core. I open the COM port via the serial window and it will just not connect. I have installed the Windows Driver (I’m running Windows 7 x64).
Another thing that I cannot figure out and I cannot tell if it is related to the serial issue, but after I have flashed my Core with my sketch it goes through the correct routines, but Spark Dev no longer seems to register that it is connected. I have to do a hard reset to be able to flash it again.
Any thoughts would be much appreciated. If you need any more info, please don’t hesitate to ask for it.
Welcome to the forums, glad to have you!
Just some quick things:
Have you got a Serial.begin(xxxx)? And is your Core in listening mode (blinking blue)?
Thanks for the responses. I got Putty to open up a serial port to the Core, but any other program won’t open. Neither the Arduino IDE or Spark Dev.
Another problem I am having is that I cannot flash a new firmware onto the Core without doing a complete firmware reset. Have I missed a step in setting up my core? Or is there something that I am missing?
Sure, no problem. I am simply trying to get an MPU-6050 accelerometer/gyro working with the Core. I got the code and the library’s off this forum from people that have ported it from Arduino.
Please find attached a zip with all the source code.
It hasn’t got anything to do with your problem, but one thing I’d change is this
while (Serial.available() && Serial.read()); // empty buffer
Since this doesn’t necessarily do what the comment suggests. If you do receive NULL bytes your while will leave, but any other present bytes will be left in the buffer.
I’d go for
while (Serial.available()) Serial.read(); // empty buffer
And in the while (!Serial.available()); loop I’d add a Spark.process() call, just to be safe if there is a longer periode without Serial traffic.
I also wouldn’t do this in loop()
// if programming failed, don't try to do anything
if (!dmpReady) return;
If programming succeeded you’ll impact your default program run. I’d rather use a while (true) Spark.process(); inside the fail branch in setup().
As for your serial problem, just try to do this in your setup()
...
// initialize serial communication
Serial.begin(57600);
while (!Serial.available())
Spark.process(); // wait for data
...
This way your program will wait inside that while() till your serial monitor gets connected and you provide at least one byte.
That also should allow OTA flashing after a normal button reset, without the need for a hard reset.
One other thing with Windows and USB serial is, that you shan’t try to open the port before the device got propperly recognized and the driver hooked up - listen for the attach sound and wait a second
And you should close the port before detaching/resetting the Core otherwise it will come back on a different port number.
Another reason for not being able to flash OTA might be that your code gets stuck somewhere - e.g. blocking calls of your libs.
Do you see any indication for this on the RGB LED? Just add some cloud features like Spark.function() or Spark.variable to check cloud accessability.
Thanks for the help! I really appreciate it! Adding in the Spark.process() function helped to make the Core flashable without having to reset the damn thing every time!
I also changed the emptying of the buffer code as you suggested.
All this still hasn’t solved my problem of only being able to open the serial port in PuTTY only. Still no luck in Spark Dev and it is really annoying!
I have done some work on the code now, moving the IMU setup into its own function, calling it in the setup() function, and then also moving the segment of code that actually spits out the YPR values into its own function and then calling it in the loop() function.
Another thing that I am noticing is that when I get the YPR in the serial window, there is some instability. It starts off stable and then after a few seconds the values go haywire! Particularly the yaw gets stuck on 180 degs. I have a variation of this code running on a Teensy 3.0 and it is rock solid!
Another thing that I am a little unclear about is your explanation regarding the
if (!dmpReady) return;
Could you please elaborate?
Please find the code attached for you to have a look at if you don’t mind?
Again, thanks for the help guys! I really appreciate it!
Kind regards,
Dylan
P.S. I also modified the MPU6050_6Axis_MotionApps20.h file to not spit out all the setup verification garble before the sensor gives readings. It is also attached. Having said that, it does spit out a random “A5” just before it commences spitting out YPR values?
I can't help you with the sensor without digging into it, so I only focused on the general things
As for the if (!dmpReady) return; thingy, it's only a very marginal impact, but as a rule of thumb, I'd try to keep my standard code path free of any clutter (e.g. checking things I already know).
So if you've established once that your "programming" worked, you don't ever need to check it again, safeing a couple of clock cycles each time round in loop() - especially since in the fail-case you don't do anything anyway than just go round in circles.
I hope this made my suggestion a bit more understandable
As for the serial monitor of Spark Dev. I'm using V0.0.19 (Win 8.1 Pro 64bit) and it works fine.
I only have to make sure to disconnect before reflashing or resetting the Core and have to wait a brief moment after hearing the Windows attach device sound, before opening the serial monitor and connecting to the Core.
If I do that, the serial monitor even switches over to the correct COM port, only needing to press "Connect".
Maybe in the past you had the Core demand for additional COMs (due to the open port problem mentioned above) tripping Spark Dev (only a crude guess ;-)).
To avoid any of the possible aftereffects, try to remove all the COMs in Device Manager (including hidden and not present devices - for this you might want to add devmgr_show_nonpresent_devices=1 to your global environment variables list).
If this doesn't work, have a check with a very simple sketch, only doing a Serial.begin(115200); in setup() - optionally doing some Serial.println() in loop().
This should definetly show if it's a problem of your code or some Windows driver mess-up.
A thought just crossed my mind:
How many seconds are we talking about?
One of the main differences between Teensy 3.0 and the Core is the cloud action that takes place between each iteration of loop() and if your lib does block anywhere for abour 10sec, you'll trip the cloud connection, which in turn might cause your FIFO buffer to overflow.
Since you don't seem to use the cloud, you could try SYSTEM_MODE(SEMI_AUTOMATIC) to circumvent any of these problems.
By setting up a button to trigger Spark.connect() you could still flash OTA, once you're connected again.
