This simple PIC24 assembly code doesn't execute. I don't know why.

jpanhalt said:

Para C oprima ocho por favor

Click to expand...

Wow

Para C oprima ocho por favour!!
I translated it, but I didn't get it!! Am I slow??

That is a common phrase in the US whenever one calls a national institution, like a bank. Other's may use a different number, my bank uses 8 and I like the sound of ocho.

Coming after Rich's comment in post #12, I thought it silly, but fitting.

Rich, Been watching this thread... ( I wanted a scratch head here) You got some very efficient code to flash a led... where you going now ... Its like buying a Ferrari , and not putting any fuel in it....

I am developing a touchscreen controller to control a vacuum chamber that can either run 50...100 amps thru a carbon rod that vaporizes and deposits on a sample, or a low-current 1000 volt power supply that "boils" off gold to deposit on a sample.
These samples are to be prepared for electron microscopes, which need to have a conductive surface. If not conductive, the charge from the bombarding electrons build up and you end up with a white-out image.

The hi-res color touchscreen requires a some intense processing to avoid the user's perception of slowness. Beyond that, I like to keep the software task simple and quicker by spending an extra buck to get the performance out of the software. Simple & quick software can reduce the number of bugs in the software. So the LED flashing is merely a simple "Hello World!" message to prove the compiler/programmer/microprocessor chain. The LED flashing is not the end product!

If you mind me asking what touch screen do you plan on using for your project?

We use a 7 inch touch screen from 4D Systems, and the way we have it setup works well, but there was a lot of development and learning curve to get where we are now. Basically the touch screen acts like a dumb terminal with constant bi-directional communication between the micro and the display. Every event that happens on the display is communicated to the micro and vise versa. The micro runs a "fall through state machine" allowing several state machines to run atomic processes. Imagine a flow chart where each block is assigned an index number ... instead of waiting and getting stuck in a loop each block conditionally sets the index. The micro dispatches to the current index. Multiple indexes allow for atomic functionality. All communication is done as a high priority interrupt, where the low priority interrupt is used for a basic heartbeat mainly as a mechanism to keep timing deterministic. As I said our system works well, but I would be curious how others setup their framework.

Sounds like you have a hi-rel, safety critical system there - I am guessing because it sounds a bit complicated.

I am using a Reach brand screen.
https://www.reachtech.com/support/product-specific-documentation/51-0105-02/
They make OEM screens here in the USA. It has a powerful microprocessor on it that handles all the touch, and draws on the screen. It communicates with my controller at 115,200kbps on a UART.
So all touches, and all display commands are via the UART. The controller can draw lines, shapes, different fonts, etc. and can put up bitmaps that are pre-loaded. It offloads a lot of my processor work to the display.
I'm experimenting with a 4.3" display, but this same UART interface can be scaled up to much bigger touchscreens, I think something like 8 or 10 inches.

I see the reasoning for easing yourself in to PIC24 with a led , Why not write the startup in C , config PLL IO setting etc and put your time critical routines in asm , mind you if you run the PIC at maximum MIPS , wont be much difference....

granddad said:

Why not write the startup in C

Click to expand...

Scroll back and see my comment #18.

C sucks.

Rich D. said:

Scroll back and see my comment #18.

C sucks.

Click to expand...

Once... Sometime ago, I asked a very similar question.. Why use C.. ASM is far superior..

The answer came.... ASM is far superior if you are really good at it. But if you are novice ~ beginner ~ newby... Then you will write more efficient code in C... The reason!! Well C was written by professional ASM programmers..

Even a professional ASM programmer cannot write code at the speed a beginner C programmer can... Debugging C is far quicker than debugging ASM.. So for the several bytes or several nano seconds saved, hundreds of pounds / dollars are saved..
I have always liked coding in C... Of the two, I only use ASM in very rare situations...