Proton BASIC Community

Bob, I still have it on my list but I need to find the time and also some assistance from Tim B in order to get an ICD going.  I have made a start but got diverted on to solving other issues on the IDE and I am trying to do a PIC project for myself at the same time.

Remember John.... Not too much all at once. :-)

Add things to a list. Then when something is as stable as it is going to get with tests over time, add something else from the list, and do the same tests over time. That way, you know what has previously been added if new anomalies occur.

The whole idea of a software ICD is pretty dubious IMHO... so many things have to be setup and working properly, it changes program timing, it uses resources (and changes the resulting compilation output), etc, etc.

You're probably just as well off just having an LED output, or a "debug uart" output.

You are absolutely correct tumbleweed.

The Debug was something I added when I first created the compiler to mimic what PBP was doing, but it is a "toy"! It calls a debug subroutine before "every single" command and every single assignment and condition etc, and squirts out serial data concerning variables and SFRs. So the program becomes very bloated and very, very much slower than the program without the Debug. It cannot be used from within an interrupt routine, and interrupts cannot be enabled with it, because the interrupt routine will disturb the data being squirted out. The list goes on.....

That is why I dropped it many years ago, because I could not see the point in it. Some of our good users made a lovely program to scan through a program and debug it, but it could only be used as a toy and not for any serious programming. Then when something does not work while debugging because of the bloat and slowness, it is "always" the compiler's fault. :-)

That is why I added true simulation mechanisms to the compilers so they can be be used in "real" simulators for debugging.

Maybe it is just me then but I found P-ICD to be invaluable when doing my CAN stuff, Labcenter (considering they advertise it as used in industry) could not or would not add what is/was probably the most used in industrial and automotive systems.
I did not notice it slowing the program down as I did not just put the Debug at the start of the program, only in the places I needed.
Adding a debugging uart is messy and time consuming as well and bloats the code which you later have to remove.
The other issue is that it is impossible to sim CAN as it has to interact with other devices.

Bob

Quote from: RGV250 on Aug 12, 2022, 03:32 PMAdding a debugging uart is messy and time consuming as well and bloats the code which you later have to remove.

For such debugging I use a conditional compiling.
$define DEBUG 1                   ' setting for debug purposes
'8<----------8<----------8<----------8<----------8<----------8<----------
$if DEBUG != 0
 Hserial_baud 57600
 HserOutLn ["Ready"]              ' just to see if the serial work, first
$endif
'8<----------8<----------8<----------8<----------8<----------8<----------
$if DEBUG == 4
 HserOutLn ["More seriuos stuff"] ' a more verbose level
$endif
So once it's completely working, just to comment one line and all the test into the conditional boundary is not compiled any longer.

Mhmmm I bit out of the thread

My 2pence worth

I recently spent >£400 on a VSM. It works great and has almost paid for its self already. I am currently using 2 pics on the one VSM, very needed as I'm simming a real life system.

The software debugger like P-ICD is not meant to be used like that, the perceived use case is that you know you have an issue around a section of code. You want to step through it line by line. So you encapsulate the section with the debug command. It enables you to very quickly run the code until you hit the section and step through it checking and in some case altering the variables. No £400 VSM needed.

The issues apart from the obvious around the amount of software John would need to write, is how easy it will be to interface to it.
The idea is you to a dedicated board that has a USB connection, it would talk really fast to the main pic using a 2 wire system with the pic as the master. So any interrupts will have no effect on the way it works. You also can work at much higher data rates and it would not use up a USART.

My issue is with amount of work John would have to do. The Positron market is very small and apart from keeping the grey cells of John active there are no enough potential users to warrant the amount of effort required to write the software. I'm all for charity but really its better spent on the needy.

Hi Tim,
I was not suggesting John did it for free, that is why I suggested seeing what the demand would be and how much work.

I am confused by what Les says about real simulators, I can only assume Labcenter VSM which is strange as he has previously said it is awful and full of bugs.

I do have the VSM but it is totally useless where CAN is involved as they will never add support for the peripheral. When i bought it they had it on the cards and then I am told a person left and since then nothing and now I figure Elvis will rise before I see it.

I did use your P-ICD and later DaveS to good use, the only issue I ever had was connecting in the first place but apart from that found it really useful.

Anyway, the idea of my post originally was for John to see if there is a demand for the addition which might cover some of the cost of the licence etc.

Bob

The compilers produce a COF file, so they can run in any simulator that will accept a COFF format file.

The Isis simulator does have problems when it comes to peripheral use on some devices, so it can not be fully relied upon. However, for standard code it can come in useful sometimes, but bloody expensive!

I have been trying to find a way to load a COF file on its own into MPLABX, but they are obsessed with C compilers on there and projects and all the other rubbish that is classed as mandatory these days for some reason! So I have not found a way yet. The original MPLAB accepted a COF file for what it is. i.e. A simulation file with everything in it that is required.

QuoteI have been trying to find a way to load a COF file on its own into MPLABX

MPLABX is very "project" oriented. Things you could easily do in the old MPLAB have to be done via a project in MPLABX.

Here's one way...

- create a folder for the project and put your main .bas source file there (ie 'test_pds')
- using the pds ide, compile the .bas file to create the .cof file
- create an mplabx project, selecting 'prebuilt project' type
    File | New Project | Microchip Embedded | Prebuilt (Hex, Loadable Image) Project | Next>
  this should open the 'Create Prebuilt Project' step

  for 'Prebult Filename', browse to the folder containing the .cof file and select it
    select the device type
    select the hardware tool (try 'simulator' first... you can change this later)
  click 'Next>'
  this should open the 'Select Project Name and Folder' step
   
  the next step is the most confusing part (to me, at least)...
    usually, the 'Project Name' is set to match your main .bas filename (no extension)
    the 'Project Location' should be the same as the project folder from step 1 ('test_pds') and
    to change the default check 'Set as main project' and 'Use project location as the project folder'. This will prevent it from creating another ".X" folder under your main folder.
    If it complains that 'folder exists and is not empty', check 'Overwrite existing project' and that should enable the 'Finish' button'

  click 'Finish' and you should have the mplabx 'nbproject' and 'dist' folders created in your main folder
  you should now be able to compile in PDS and debug in mplabx using the .cof file.

One important thing to note:
When you create a prebuilt project it copies the existing .cof file from your main folder into the 'dist\default\production' folder and this is what it uses to debug.
If you recompile you'll have to manually put a copy of the new .cof file into that folder... I haven't found a way to get that automatically updated.


The simulator built into MPLABX is good for basic troubleshooting, but many of the peripheral simulations don't work too well or aren't even simulated. The hardware ICD debuggers (ICD3/4, PK3/4, SNAP) tend to fair much better.


If you get stuck I can make some screen shots of the various steps. The worst part is getting the basic folder structure setup since MPLABX has it's own idea of where it would like things and wants to create folders upon folders upon folders.

Great write up. I didn't install MPLABX and also i found the simulation cumbersome. A particular case when it comes to make a dialogue with the serial transmission.
I made a different style to see the asm file in VSM. I compile as usual by positron,  then I get the asm into MPLAB (version 8.6 I think) and make a new compiling. The resulting *.cof is imported in VSM so there is the visibility of the positron asm file including the basic statements , which are commented. so I can see if my conception is resolved correctly.

Do I need to recompile with MPLAB to generate a COF file? The following declaration does the job.

Declare Create_Coff = On


The inclusion of the .cof file into MPLABX would make an excellent new thread, because we have, again, gone off the thread's topic. Sorry John.

An excellent list tumbleweed, and a seperate post for them with screenshots would be excellent, and I will add it to my web site as well. If that is OK with you?

Sorry about getting so off-topic. I'll try to get a chance to do this and capture some screen shots.
I'd like to find out if there's a way not to have to manually copy the .cof file over and over.

QuoteDo I need to recompile with MPLAB to generate a COF file?

No. All you have to do is add the 'Declare Create_Coff = On' and build the program outside MPLABX.

Quote from: top204 on Aug 14, 2022, 07:14 PMseparate post for them with screenshots

I vote for moving out the deviation of this thread.