Go Down

Topic: Visual Micro - Arduino for Visual Studio (Read 27538 times) previous topic - next topic

graynomad

#45
Feb 04, 2012, 02:17 am Last Edit: Feb 04, 2012, 02:20 am by Graynomad Reason: 1
The SAM3U is the same ARM chip that will be used by the new Arduino Due, as such I think it's worth spending time on because it will (eventually) have native support in the Arduino environment. I have no hands-on experience with the chip, I'm totally flying by data sheet at present :)

It has 5 serial ports and of course you can use any of them for debugging using the time-honored "printf()" method, but that will block after 2 characters then back to square one. And of course using any library function is very intrusive. You can write directly to the UART transmit regs but that doesn't solve the blocking problem. You could also set the DMA controller to send the data to a UART but, that may be starting to use too many resources again I think.

So I am using a portion of the external memory map to write data directly to some external hardware at memory-access speeds. So I see code like this

Code: [Select]

long * dbgPtr = 0x60000000; // point to external RAM address

myVar = getSensorVal();  // get a value from somewhere
*dbgPtr = myVar;        // one write to RAM, job done


Of course this means some fast hardware to read the data and for the moment I'm suggesting a logic analyser. However it would not be difficult to knock up a plug-in board with a FIFO or dual-port RAM to read and display the data or send it to the PC.

Moving one step further if dual-port RAM is used the link can be bi-directional, meaning that you can say map an entire array into the external RAM and view or modify values with almost no effect on the executing program. You could place 2 or 3 system variables in this RAM and tweak them from the PC with no compiling required. When you get the right number then plug it into the program and re-compile.

This could also be used for analysis of data, profiling etc.

Anyway that's where I'm headed with debugging support on this board. How that could be used with Visual Micro I don't know as I don't have much experience with PC-based debuggers.

_____
Rob
Rob Gray aka the GRAYnomad www.robgray.com

Visual Micro

#46
Feb 04, 2012, 07:08 am Last Edit: Feb 04, 2012, 07:15 am by visualmicro Reason: 1
Yes, certainly worth some investigation time. That really is VERY interesting for my projects, not just from a vs point of view. So thanks for the info.

I am not sure why the non-blocking serial will block after 2 bytes? Seems like if we get around this issue then you have simple serial debug options without the extra complexities?

I was wondering which ARM processor arduino has opted for. Iam looking forward to seeing the IDE changes to support it. Enhancing the Visual Studio plugin for arm is going to be fun.
Arduino for Microsoft Visual Studio Pro and Atmel Studio 6.1 http://www.visualmicro.com
Arduino Debugger http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx

graynomad

Quote
I am not sure why the non-blocking serial will block after 2 bytes?

I'm thinking of the transmit data reg and the transmit shift reg in the UART. At the hardware level that's all you have with these AVR chips.

Of course you can buffer the characters but that adds the overhead to test register bits, maintain the ring buffer etc.

So I guess it's not "blocking" in the normal sense of the word, but it does consume quite a lot of resources.

That said a simple debug buffered Tx function could be written to lower the overheads.

All this still uses a whole UART though, which may or may not be free.

The two pulse outputs are for precise timing which is a different issue.

_____
Rob
Rob Gray aka the GRAYnomad www.robgray.com

mariusl

Rob's idea is the closest to how it is done with legacy ICE equipment. I manufactured debugging tools some many years back in the 8051 days.If you have a chip with external memory locations we used to have a small FPGA that located in a space in the memory block. All variables that needed watching was forced by the linker to locate in the same area. The FPGA board would then communicate to the PC the whole block of variables. Secondly, the code was not flashed at the time but run from ram that was located in the program space. The FPGA could then look at the program counter and halt the code at that place.
Maybe a bit more that what the average guy would want to spend and also the flashed program space might be an issue these days. Locating a small block of memory outside though should be doable.
Rather people think you to be a fool than you open your mouth and confirm it.

graynomad

#49
Feb 04, 2012, 07:52 am Last Edit: Feb 04, 2012, 07:54 am by Graynomad Reason: 1
Quote
Rob's idea is the closest to how it is done with legacy ICE equipment.

Ah the good ol' days :), I had an EPROM emulator on the market for some time, this sort of thing has always been an interest for me. There used to be "bondout" chips that gave you extras pins to access the internal address and data busses. I don't think they exist any more, the chips are too complicated I guess.

Quote
Maybe a bit more that what the average guy would want to spend

Certainly back then, $1000s, these days you get a heck of a lot for just $100 of even $50.

I reckon for maybe $20 I could have a plug-in dongle that gave a real-time 1 or 2k window into the application's data (or ever program) space. It's the same principle I used for my emulator, just some dual-port RAM, a processor and a bit of logic allows you to do memory dumps, variable exchanges etc. all from a dumb terminal program (and presumably VS/VisualMicro). I can see a window with data changing in real time, data mapped to the symbol table so just click on "myVar" and change it's value etc etc.

As the ARM can run code from RAM you could possibly download a function that's being debugged so break points could be inserted without worrying about flash, you could also maybe put a monitor in there.

I'm getting excited just thinking about it :)

Only useful for 1% of users probably, but pretty useful to them.

______
Rob

Rob Gray aka the GRAYnomad www.robgray.com

mariusl

Rob,
I see we stem from the same era. My first computer project was just that, an eeprom emulator that connected to the parallel port and you did a binary dump to LPT1 and the code was put in RAM with a socket that plugged into the prom space.
Bondout chips were very expensive and cumbersome. Never had much luck with them.

I think your project has scope. The kind of stuff that one would do with the ARM processor will mostly be more complex and debugging tools are required. Keep hacking at it man, we are waiting.
Rather people think you to be a fool than you open your mouth and confirm it.

graynomad

I guess there's not much call for EPROM emulators these days eh?

Quote
Keep hacking at it man

Yep. I've nearly finished the schematic and component placement on the PCB. Now I need to sit on it and let the design mellow with no additions for a while. Good way to spot bugs.

I may call for people to review the design in a couple of weeks, it's easy to do stupid things when there's nobody looking over your shoulder. Hopefully we'll see the real Due before that.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

mariusl

Quote
I guess there's not much call for EPROM emulators these days eh?


Nah, most guys have never even seen a windowed device let alone work with one. Still have my UV eraser. I must admit I enjoyed the introduction of flash.
Rather people think you to be a fool than you open your mouth and confirm it.

Visual Micro

Okay it's like this... My brain has just exploded
Arduino for Microsoft Visual Studio Pro and Atmel Studio 6.1 http://www.visualmicro.com
Arduino Debugger http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx

avenue33

Even if Visual Micro is targeted at Visual Studio audience, pooling resources and ideas with users of other IDEs may benefit everyone.

So here are some news from abroad: Diligent chipKIT boards, Xcode on Mac OS X

Please find the third release of mpideXcode.

Quote from: Feb 04, 2012 release c - code-sense operational
Code-sense
1. Go to Project > mpideXcode > Search Paths,
2. Define HEADER_SEARCH_PATHS = $(ARDUINO_DIR)/** $(SKETCHBOOK_DIR)/Libraries/**
3. Go to Project > Index > Build Phases > Compile Sources,
4. Add all .h and .cpp files

Bugs and To Do
• Closer integration of the serial console
• Integrate help from Arduino .html files


Enjoy :)

mariusl

Quote
Okay it's like this... My brain has just exploded


Well are you going to explain or must we just guess at your humor? Oh maybe you are in pain, please tell.
Rather people think you to be a fool than you open your mouth and confirm it.

Visual Micro

#56
Feb 04, 2012, 04:03 pm Last Edit: Feb 04, 2012, 04:43 pm by visualmicro Reason: 1
@marius You two are getting very technical my brain couldn't cope:)

@avenue33

Well done on your xcode work, are you handling compiler errors and drilling back down into the code? If so have you found any better compiler switches that produce better output for this? In visual studio we can drill down into compiler errors, this is very useful but its not very easy to code.

I am happy to add chipKit to the visual studio arduino integration but last time I looked they hadn't completed most of the libraries so wasn't quite as great as I had hoped. I am also keen to see if they have implemented things like background serial as with arduino 1.0? Notice the chipKit Jan 2012 release, might have a play with it later today.

How are you handling including libraries and core inside xcode for edit. In VS, we optionally toggle these codes in/out of the project which makes development and class analysis much easier for many.

Good luck with the serial work, it was quite an easy job in vs to allow multiple serial windows to be open and very easy to limit the display rate to 5 hz. I find the java serial is a cpu hog so when you come to do it please try to make it cpu friendly :)

Updated: Just looked at what a windows user has to do to install xcode. Oh dear not very nice! I can't use a Mac because I also use my computers for work. But anyway you know I love Visual Studio :) I think it's great to have different solutions. I could open a new board on the visual micro forum for shared plugin ideas. Would that be useful or have you a better idea?
Arduino for Microsoft Visual Studio Pro and Atmel Studio 6.1 http://www.visualmicro.com
Arduino Debugger http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx

mariusl

Quote
@marius You two are getting very technical my brain couldn't cope:)


Oh ok, I thought you were having a go at the two old goats reminiscing about the days of old.  :(
Rather people think you to be a fool than you open your mouth and confirm it.

Visual Micro

#58
Feb 04, 2012, 07:31 pm Last Edit: Feb 04, 2012, 07:33 pm by visualmicro Reason: 1
One of our Visual Studio users pointed out something simple that seems like a good idea. Compiler warnings are off in Arduino by default, same with Visual Studio. They were switched on if "verbose" mode was also switched on. The problem there was that "verbose" produced a too many messages for normal useage, in addition to this the warnings became lost in the mass.

So the suggestion was to include an option just for "Warnings". It works really well and the drill down to the source code from the warnings is very useful. When clicked, the three lines of warning shown below, jump to the correct source code lines.



This feature will be available in the next release v28 (due shortly)
Arduino for Microsoft Visual Studio Pro and Atmel Studio 6.1 http://www.visualmicro.com
Arduino Debugger http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx

avenue33

Well done on your xcode work, are you handling compiler errors and drilling back down into the code? If so have you found any better compiler switches that produce better output for this? In visual studio we can drill down into compiler errors, this is very useful but its not very easy to code.


Thanks.

Yes, using a trick: declaring a false target based on standard Apple LLVM brings code-sense and error pin-point. Even code analysis when typing!

I am happy to add chipKit to the visual studio arduino integration but last time I looked they hadn't completed most of the libraries so wasn't quite as great as I had hoped. I am also keen to see if they have implemented things like background serial as with arduino 1.0? Notice the chipKit Jan 2012 release, might have a play with it later today.


I think is better to wait for MPIDE 1.0. I raised the question about the roadmap here.

How are you handling including libraries and core inside xcode for edit. In VS, we optionally toggle these codes in/out of the project which makes development and class analysis much easier for many.


I include all of them by default.

Currently, I haven't integrated yet in release c the user's library located at sketchbook/libraries. peplin/arduino.mk does include that feature.

I think it's great to have different solutions. I could open a new board on the visual micro forum for shared plugin ideas. Would that be useful or have you a better idea?


That's a great idea. We could share tips and tricks across various IDEs and maybe lure some Xcode specialist into the project that way!

Go Up