I need Help....Generating a square wave with the dsPIC33FJ256GP710

Toggling a pin (i.e., generating a square wave) is the embedded equivalent of displaying "Hello, world!" to the shell or screen in a hosted environment.

What you need to do is read the datasheet for the device and for the assembler or compiler you are using. You may need to learn about controlling the system clock, using (or avoiding) a bootstrap loader, configuring I/O ports, setting and responding to interrupts, fuse settings, and the mechanics of actually getting the compiled/assembled program from your PC onto the chip itself.

Vendors generally publish application notes and "getting started" guides that cover the basics.

Thanks Rick for your reply...Actually, I am already familiar with configuring I/O pins, writing simple C codes to play with the LED's, and to program the chips. I also have all datasheets for the device and the compiler.

As to controlling the system clock, using bootstrap loader, working with interrupts and fuse settings, that I am not hands on with. That's what I need help with.

I need help developing sort of a pseudo architecture of how the code might look like. After that, I'll proceed to write the code. As long as I can develop a square wave (using the simplest way available), that would be enough.

--------------------------------------- Posted through

Generally (there are exceptions, of course, and I'm not familiar with your specific chips) a typical setup may be something like this.

Note that "void main(void)" is not permitted in a hosted environment but it is common in embedded systems where main() doesn't have anything to return to. Also, lots of void is used in the functions, with no error checking, just to keep it to a reasonable size.

#include #include "app_headers.h"

volatile unsigned tick; // 8-bitters may want an unsigned char instead

void main(void) { sys_init();

while(1) {

if (tick) { tick = 0;

toggle_io_pin(); }

// Do other stuff. } }

// Stuff from here down would typically be in a separate file, keeping // the device-specific items separate from the front end.

#include #include #include "app_headers.h"

extern volatile unsigned tick; // Would normally be in a .h of course

void sys_init(void) { clock_init(); port_init(); timer_init(); enable_interrupts(); }

void clock_init(void) { // Handle the system clock. Some devices boot off an internal RC // oscillator and need to be told to switch to a crystal. Others can // use PLLs for clock multipliers or use clock dividers to run a // peripheral clock at a slower speed. }

void port_init() { // Set up the digital I/O (inputs (with pullups?), or outputs with a // 0 or 1) and connect alternate functions to I/O pins. May also be a // good place to power-up or -down peripherals if that feature is // available. }

void timer_init(void) { // Set up a timer to handle system ticks; 10 msec may be a reasonable // value if nothing else drives this. // This function will typically also need to diddle with enabling an // interrupt to fire when the timer hits. }

#pragma interrupt timer_isr // Different compilers will have their own way to flag an interrupt // handler. Some decorate the declaration line instead of using a // pragma.

void timer_isr(void) { // Reset the interrupt flag, if any. Possibly reload/reset the timer. tick = 1; }

void enable_interrupts() { // May be a compiler macro or an embedded asm statement. }

void toggle_io_pin(void) { // I prefer to keep all code that actually touches the hardware // wrapped in functions (usually off in their own file). That lets // main() and friends worry about logic flow and they only see the // processor as an abstract device. }