I started a manual for the web platform, I'll add links and demos as they become available:
http://dangerousprototypes.com/web-platform-manual/ (http://dangerousprototypes.com/web-platform-manual/)
[quote author="ian"]
I started a manual for the web platform, I'll add links and demos as they become available:
http://dangerousprototypes.com/web-platform-manual/ (http://dangerousprototypes.com/web-platform-manual/)
[/quote]
I have an assembled board in front of me. I tried reading your manual page and I still have no idea where to begin. Is there some article I should have read before getting this board? I plan on replacing the firmware because I bought it to help develop the PyMite port for the board. But, I want to know that it all works before I try that.
Then, it will be on to the mysterious world of PIC development under Linux.
Hi Severian,
The hardware design article is the main starting point for the web platform dev-board:
http://dangerousprototypes.com/2009/12/ ... -platform/ (http://dangerousprototypes.com/2009/12/11/prototype-web-platform/)
Then you might find the ds33pic programming intro helpful:
http://dangerousprototypes.com/2010/02/ ... ogramming/ (http://dangerousprototypes.com/2010/02/04/web-platform-introduction-to-dspic33-programming/)
Those are the main article for the board. Then there are smaller demo with firmware and source code that implement various features.
If you have any specific requests please let me know. I'll write up a tutorial or how-to for it.
Cheers,
Ian
[quote author="Severian"]
I plan on replacing the firmware because I bought it to help develop the PyMite port for the board.
[/quote]
Actually, PyMite already works on the Web Platform:
http://dangerousprototypes.com/forum/in ... opic=348.0 (http://dangerousprototypes.com/forum/index.php?topic=348.0)
The dsPIC33 programming page http://dangerousprototypes.com/2010/02/04/web-platform-introduction-to-dspic33-programming/ (http://http://dangerousprototypes.com/2010/02/04/web-platform-introduction-to-dspic33-programming/) says
The only absolutely necessary line in HardwareProfile.h is #include , this file tells the compiler about the features of the PIC and it must be included in all source code.It seems this is not true with current MPLAB. Perhaps the compiler automatically includes the appropriate file (e.g. p33FJ128GP04.h) (based on the MPLAB
Configure ->
Select device choice?)
I think it would be helpful to add a section to the dsPIC33 programming page to discuss interactive debugging options, if any.
Update: At first I thought p33Fxxxx.h was a template file name with the xxxx to be replaced by (presumably) a device specific string. This is because a file search turned a bunch of files with names p33FJ06Gs101.h p33FJ06GS102.h ...
Then I found a file whose name is actually p33Fxxx.h which just has a string of tests to determine which model specific file to include.
But it doesn't seem necessary to include p33Fxxxx.h
The cheapest option for debugging PICs is the PICkit, followed by the ICD2 (what I use). Great suggestion, I think a tutorial on debugging options and what it means and how to use it would be really helpful.
[quote author="wallabybob"]
It seems this is not true with current MPLAB. Perhaps the compiler automatically includes the appropriate file (e.g. p33FJ128GP04.h) (based on the MPLAB
Configure ->
Select device choice?)
[/quote]
What version of MPLAB do you use? I am using version 8.43 and if I connent out the first line in HardwareProfile.h
[tt:]//#include
[/tt:]
I get of course lots of errors.
[quote author="ian"]I think a tutorial on debugging options and what it means and how to use it would be really helpful.[/quote]
Agreed. I've only used the PICkit2, and I don't know how it would differ from the ICD2, so it would be great to hear people characterize various levels of debugging support.
As far as I know there isn't a difference between the abilities (breakpoints, etc) of either debugger. The ICD2 used to debug everything and the PICkit2 only a few chips, but now the PICkit2 programs everything but a few oddball chips.
I also have a question regarding debugging: When I set the 'Debugger' in the menu to 'PICkit 2' and select 'Debug' in the toolbar combo-box, the Memory Usage Gauge shows 82 in the Data Memory meter. But if I select 'Release' in the toolbar combo-box, the Data Memory meter only shows 2.
I read somewhere, that for debugging some extra resources, namely the additional 80 Bytes are used. But for what for? What is the difference between the two settings 'Debug' and 'Release' of the combo-box beside using the additional Bytes when using the 'Debug' setting? What can I do in the 'Debug' setting that I cannot do in the 'Release' setting?
I'm not a debugging expert, but as I understand it the extra bytes are used for the 'debug executive' which is a little program (similar in concept to a bootloader) that runs over top of the executing program and handles stuff like stopping the code at your specified points, pulls values from memory that you have on the watchlist, etc. The debug setting in MPLAB inserts this code into a FLASH and RAM region of your chip, as defined in (most) linker files.
The main features of debug (that I use) are code stepping (walk thourough the code as it executes and see the values change), break points (stop at a certain region of code for closer inspection), and viewing the current values of variables and registers in the chip. This is helpful for finding code bugs, and seeing where the C compiler's ASM might be doing something wrong (it happen more often than I'd like).
Understood, but I can do all those things also in the 'Release' setting without consuming the additional 80 Bytes.
I'm not sure about what's going on there. Maybe it's not needed? Maybe it includes it anyways and doesn't report it in the RAM gauge - you could probably see the extra startup code in the ASM.
I can't debug in release mode with a ICD2, maybe it is a difference there.
The debug setting in MPLAB only does
#define __DEBUG
And the release setting undefines this.
So it probably undefines the switches that include the memory allocation for debug settings, that would make sense on why it would display a RAM use difference.
Maybe the 80 Bytes are used for some advanced debugging features on ICD 2, which are not available on PICkit 2, and it makes therefore no difference for the PICkit 2 whether the setting is Debug or Release? However, the basic debugging stuff (setting of up to two simultaneous breakpoints, single stepping, run to cursor, displaying variable and register values) all work also on the PICkit 2.
[quote author="Markus Gritsch"]
[quote author="wallabybob"]
It seems this is not true with current MPLAB. Perhaps the compiler automatically includes the appropriate file (e.g. p33FJ128GP04.h) (based on the MPLAB
Configure ->
Select device choice?)
[/quote]
What version of MPLAB do you use? I am using version 8.43 and if I connent out the first line in HardwareProfile.h
[tt:]//#include
[/tt:]
I get of course lots of errors.
[/quote]
I use MPLAB 8.46. The build output reports the tools versions as
Language tool versions: pic30-as.exe v3.23, pic30-gcc.exe v3.23, pic30-ld.exe v3.23, pic30-ar.exe v3.23
The build output reports the compile command as:
Executing: "d:Program FilesMicrochipMPLAB C30binpic30-gcc.exe" -mcpu=33FJ128GP204 -x c -c "MainDemo.c" -o"Objects - TCPIP MDD Demo App-C30MainDemo.o" -I"." -I"..MicrochipInclude" -I"%PROGRAMFILES%MicrochipMPLAB C30include" -g -Wall -mlarge-code
I came to speculate Perhaps the compiler automatically includes the appropriate file (e.g. p33FJ128GP04.h) because I started with some of the Microchip sample files and failed to look sufficiently deeply into the nested include files. The -mcpu=33FJ128GP204 compiler command option causes the compiler to define __dsPIC33F__ and __dsPIC33FJ128GP204__ MainDemo.c includes "TCPIP Stack/TCPIP.h" which includes Compiler.h from the Microchip include library; Compiler.h includes (because __dsPIC33F__ is defined) p33Fxxxx.h from the Microchip include library (... MicrochipMPLAB C30supportdsPIC33Fh) and p33Fxxxx.h includes (because __dsPIC33FJ128GP204__ is defined) p33FJ128GP204.h from ... MicrochipMPLAB C30supportdsPIC33Fh
For greatest portability it might be useful to include Compiler.h (#include ) rather than p33Fxxx.h if the code might possibly be built for dsPIC30 or PIC24 targets. At least some of the Microchip C source files used to build the application in Microchip SolutionsTCPIP MDD Demo App include Compiler.h.
I could not find an External Power Supply Specs I only looked for 20 minutes might have missed them.
My Best guess is the connect size is
5.5 mm outside and 2.1 mm inside
Input voltage 4.8 to 8.5 this is a guess can any one confirm.
The voltage range is from the part specs; but, the specs are confusing and cover multiple parts.
Tim S.
From
http://dangerousprototypes.com/2009/12/ ... -platform/ (http://dangerousprototypes.com/2009/12/11/prototype-web-platform/)
at the end of the 'Power supply' section: "5volts is the ideal supply input. Higher voltages will work, but they also increase the amount of heat that the regular must dissipate. The power supply jack (J1) mates with a common 2.1mm DC barrel connector, the center tab is positive."