I have a xbee module that send serial data over COM1 and an IHM on a desktop connected to the USB CDC port.
When I deploy and debug the IHM application I put a jumper on an IO to disable COM instanciation for the XBEE module. To debug the xbee I put a jumper on LMOD and use USB as debug interface. I need now to merge both and disvover that COM1 does not work as I tought. Data are not read properly on COM1. I believe that this is due to the fact that COM1 is the debug interface by default and that it is also the port on wich my xbee is connected (data send by the xbee module are caught by the debug layer of EMX)… Am I wrong? What can I do to solve that? is there a way to declare a fake debug interface? My customer is waiting for its product in less than four hours… so thanks in advance for people who will help me urgently
@ leforban - For a quick fix, you could use a Panda II to provide additional serial ports.
Connect one EMX serial port to the Panda II and then develop a protocol for sending and receiving to the other three available serial ports on the Panda II.
@ andre.m - The solution will be a “fake” debug interface. I can not go back to 4.1 due to issue that are solved only in 4.2.
GHI should mention that EMX chip has not 4com ports and usb client. Its 4 COMport or 3COM port and a usb client this make small difference but a quantic one…
I am sorry that you discovered this four hours before your product shipped. But, you can not blame GHI. This should have been discovered this during your initial evaluation of the EMX board, or full system integration testing.
Initial evaluation of EMX has been made in june 2011 at this time, the platform was supposed to have USB debug +CDC, 4 serial port and this is why we choose it… Today we have only USB and 3 port com or 4 COM port without USB. That it… using 4.1 is not possible due to unreliable EWR, CDC, HashTable and so on… All is not GHI fault but sorry, the constraints of my project have been exposed so many times on this forum that I can not imagine today that the answer is simply NO…
@ leforban - At this point, all we can do is help you find a way of adapting your current system to make it work. Assignment of blame will have to be discussed with your supervisor.
For sure I don’t want to blame GHI, I like EMX and premium lib but I must recognize that the design choice that I’ve made two years ago were maybe not the good ones. I talk about CDC+debug but there’s also debug over network that was supposed to be a feature and that finally disappear, EWR size that have been drastically reduced… GHI job is not simple and a tradeoff has been made between reliability and functionality’s and today I am facing big problems due to that. Anyway I just need now a way to make it work without rebuilding boards or modifying enclosure.
I would like to try UART/I2C bridge or something like that but we don’t have now enough time and money for such investigations.
@ Mike - I am the only person in charge of Electronic and Computer science development in my company discussing with my supervisor will result in nothing more than:With a terrific and loud voice:" It’s just engineering stuff!!! MAKE IT WORK!!!"
@ andre.m - what do you mean in:“is the one com port your only show stopper?” ?
@ leforban - your design decisions were made with 4.1 software and we never promised anything for 4.2. I completely understand your needs but we just need a bit fair. Same goes for any future major release. If you are happy, do not upgrade.
That said, if you have a serious application where you spent years developing then why not give us a call? We can completely rewrite the whole firmware for you if it makes sense
I was not happy with 4.1. That is the reason of moving to 4.2. If all was working properly I would never upgrade. Main reason was to have a better CDC… and that reporting a bug in 4.1 sdk will result in nothing since you and people involved in the .netmf project do not work on it anymore…
I have a serious application on which I am working since two years. The reason of such a long time to develop is that I spent a lot of time to enhance performance and firmware is not the only part of development, there’s also a GUI, an IMU, xbee module, sdcard, usbhost, nmea …
Even on 4.2 all is not solved, I discovered weird behavior on serial port. Let’s see if it will solved or not…
Why not give a call??? maybe because my english is poor… which make me shy
They are connected on headers. As a workaround I have removed for this particular customer the IMU connected on COM2 (since an octans is connected on COM3) and reuse the COM2 to connected TX of XBee. But for the other customers I won’t be abble to do the same. In fact on COM3 usual customers have autopilot which can not be removed.
This is not a GPS but NMEA on a boat with much more information than just RMC and GLL. There’s tons of sentences and usually the serial bus is full (a sentence every 15 ms). IMU is at 38400 bauds and send bytes formatted data. It sounds difficult to achieve a merge in my case.
