I have to write a small app for the G400S to acquire and log data from an inertial measurement unit (IMU). Depending on which IMU I use, the data rate can be as high as 10,000 samples/sec * 240 bytes/sample = 2.4 MBytes/second. And I need to log 1000s of seconds of data. I’m thinking this might be waly too fast for .Net Micro or TinyCLR so my question is if anyone has used VisualGDB or Atmel Studio or a similar IDE to develop/download/debug native, compiled C/C++ programs with the G400S without a hardware debug module in the loop. The issue I don’t seem to be able to figure out from the Atmel documentation is whether they can support the same kind of JTAG SWD over a USB connection directly from a Windows PC to the G400S module without any debug hardware.
10,000 =2.4MBytes
1,000 ~ 0.24MB = 240K? am I correct?
Dat - I’m not sure I understand your question, here’s a more detailed explanation. The IMU can send messages at up to 10,000 messages per second. Each message can have up to 240 bytes per message. So, I get a maximum data rate of 10,000 * 240 = 2,400,000 bytes per second. I’d like to log several thousand seconds of data, call it 2000 seconds. So a maximum data volume of 4.8 GBytes which should fit OK on a uSD card. Does that make more sense?
You need to to process and save 2.5 megabytes every second. This is a lot to ask of an embedded system that is doing multiple tasks. To accomplish this, you need a system that is doing nothing else but handle your data…
You couldn’t even buffer the data since you need to run continuous for thousands of seconds.
Custom entered solution will be the only way.
Gus - We agree. Here’s the good news:
- That’s all this app has to do. Read data from the IMU and store it to SD card.
- The 2.4 MByte/second data rate is the max and I may be able to run slower (maybe 10X slower) but I won’t know until I do the testing and data analysis.
- The Atmel SAM9X35 on the G400S is a very capable processor and might be able to handle this data rate with a compiled, bare metal app.
The bad news is that it is a pretty sure bet that .Net Micro/TinyCLR won’t handle this app and I’m stuck with a fully compiled non-.Net Micro or TinyCLR approach. I would like to stick with the G400S since I’ve got a bunch and I’m moderately familiar with them. Hence, the original question about whether I can use a C/C++ IDE and connect directly to the G400S. And if so, do I just load SAM-BA on the G400 and connect the USB port to my PC? Or is it more complicated than that?
I remembered this thread after I posted my question about native C/C++ on the G400S.
Can someone point me at Gus’ “excellent series on doing it natively in VS”?
Thanks - Gene
Please forgive my blasphemy… but would not a raspberry pi or beaglebone be an easier solution?
This is a very quick way to drive yourself insane. Any serious native code dev work requires a JTAG-style debugger in the loop. Just don’t go there.
Edit: Removed suggestion for Discovery cards, as Gene said he has a bunch of G400’s he wants to use.
The overall goal here is to see if there is a straightforward way to develop/debug native compiled C/C++ code on a G400S. Preferably with VisualGDB since I’ve been using it for a little while and the Visual Studio IDE works way better for me than the Eclipse based tools. It also makes sense to me for this little app as a learning experience for potential future apps. Since the G400S doesn’t have the JTAG pins exposed, I’m assuming a JTAG debugger won’t work without modifying the G400S or designing a new carrier board. If that isn’t correct, please let me know. For example, if there is a JTAG debugger that just sits on the USB cable between the PC and the G400S USB pins, I think that would be totally workable.
If you’re suggesting I use a Linux solution then I fear for your immortal soul and we can’t be friends anymore. Even if I could put my utter loathing of Linux aside, this is a battery powered application with the need to sleep at very lower power on a regular basis which I think rules out the Pi and the Beaglebone.
If you remember any of my previous posts, you may recall I’m not an experienced embedded programmer. But I have been teaching myself C/C++ using VisualGDB (as you suggested in the “Pointers in TinyCLR” post) and a couple of different ST Micro discovery boards. Once I got a little way up the fairly steep learning curve, the develop/debug/test cycle with the GNU debugger built into VisualGDB has been working quite nicely for me.
Yes, my comment was only meant to suggest that life is so much easier when you can debug. The Discovery boards are great because they have the debugging dongle built in. I guess all I’m saying is that if you can’t find a way to tie a JTAG dongle to the G400S, native coding is going to be hard.
It might be worth checking the G400S Schematics - the pins for JTAG might have been brought out somewhere accessible, but if I recall correctly, by design, they weren’t. Hopefully, I am recalling that wrongly. I’ve never tried this sort of thing on a G400S.
The JTAG pins are brought out to the pads on the G400S, it’s just that they aren’t exposed on the SOM and we didn’t expose them on the carrier board we designed several years ago. Worst case, we can build a carrier board adapter with a JTAG connector on it but then we have to hope the JTAG signals will make it through the submersible connector on our pressure housing or we will have to open the pressure housing to test new code which isn’t a great plan.
Best case, there is some kind of JTAG debugger dongle that we can plug into the PC USB port outside of our pressure housing and it has another USB connector instead of the JTAG header that can talk to the existing USB port on the G400S. We know the USB connection works through our submersible connector without any JTAG dongle since that’s what we do now for .Net Micro.
Is this a marine application?
For an imu controlled gizmo thats a butt load of pitch roll and yaw values…
This will be a nightmare as we do not document this and you need to figure out for to initialize the processor and DDR.
If this is something you need commercially then we can look into irons for you.
It is for an oceanographic research platform and that is a lot of data. However, we’re looking for accelerations in the 10s of microG range reference to the earth’s north, east and down directions so lots of data means we can do some very long period low pass filtering. As I’ve mentioned, the 10K sample rate is the maximum the sensor can do and probably 10X what we need when all is said and done but more data is always better than less data (at least in my experience).
See my note above. We can help in finding an answer. We can discuss your needs and budget directly if you like.
Thanks Gus, I’m just exploring the possibility right now. I’ll get back to you when I’m a little further along.
However, I’m a little confused mostly out of ignorance I’m sure. If I remember, pre-TinyCLR the G400 boards used Atmel’s SAM-BA boot loader. Wouldn’t you expect a G400 (or an older Raptor) with SAM-BA loaded to be able to at least load programs from Atmel’s Studio IDE over the USB port? At least that is what my reading of the current Atmel SAM-BA docs suggests. Debugging isn’t as clear. But again, it seems like if Visual Studio and .Net Micro could download and debug programs to SAM-BA, Atmel Studio and SAM-BA should be able to do the same thing. Unless it was something in .Net Micro that made it all possible.
Programming in C++, and bypassing Tinyclr, means you will need some type of RTOS to support your application. Have you looked at any? Not as simple as using Tinyclr…
Meh, I was hopeing it was a blue whale fart detector using the acc to measure bubble cavatation
Really? I’ve been using VisualGDB quite nicely for a number of little tiny projects. All I really need are effective, well documented examples for I2C, SPI and UART interfaces and a file system. There are plenty of bare metal examples for how to do all of that and I’ve tested several. No RTOS or OS of any kind, just bare metal. The one thing that I really wish was available in C# is the QP Framework ( https://www.state-machine.com/ ) which is one of the few reasons I’m looking at C/C++ for anything.
Actually, that’s next on the list of projects.
I’ll happily be your 2IC 