Jump to content

Thermal Runaway

EstablishedMember
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Thermal Runaway

  • Rank
    Regular
  • Birthday 10/23/1979

Profile Information

  • Gender
    Male
  • Location
    South Wales, United Kingdom
  1. Hello all, I have been looking through the lcd_driver.h code (found in the Sourceboost Includes directory) and I am struggling to understand how it all works. For example: 1. What is the purpose of the following Macro? #define _LCD_Write LCD_Write <InterfaceType, UseBusy, DataPort, Data_PortTris, CtrlPort, Ctrl_PortTris, RS, RW, E> There are similar macros defined for other functions as well. They're all the same, but with a different name. What is this for? 2. What is the purpose of the following template? #define _LCD_TEMPL template < unsigned char Inte
  2. I did end up persevering with this for a while in the end. I managed to sort out all the problems I initially listed by referencing the header files by their full path names. Also I had to create my own header file directory in the C:\ root because it didn't seem to be able to find the files if I referenced the sourceboost directory. Perhaps there's some file length issue there, or maybe it doesn't like the spaces. The only question I'm left with after this bit is why doesn't MPLAB X accept my header files using #include <system.h> when I've added the relevant files into the proje
  3. Before I waste anyone's time in responding, I should say that I have now abandoned MPLAB X and gone back to the old V8.56 that I'm familiar with. This is because I couldn't get MPLAB X to work. Even when I "resolved" the header file problems by copying over the relevant files to my project directory, and removed all references to inline assembly, I then was unable to program a target device because, having compiled the source code, MPLAB would complain that it couldn't find its own built file!!! So in the end I decided enough was enough and time to go back to the old version. It works, so w
  4. Hi all, I have recently installed MPLAB X and am trying to integrate the SourceBoost C tools for the first time. I have followed the MPLABX integration guide without a hitch. So now I have created a new project, selected the correct device, selected the Sourceboost tool to use, and have added a source file. The MPLAB enviornment is now complaining about my #include <system.h> file. Apparently it can't find the file. Surely it should just look in the relevant Sourceboost installation folder? In the end I added the file myself and after some faffing around it finally seemed
  5. Ah okay, I always thought this was legal C. I assumed that it gave efficiency savings by only allowing the control variable to exist within the scope of the for loop? Perhaps I should have a look at the compiled code and see if there's any difference between declaring inside the expression or out. Thanks for the information. Brian
  6. Hi all, Has anyone else experienced problems when declaring a control variable within the FOR loop, as shown below? for ( unsigned char i = 0; i < 20; i++ ) { // code goes here } I've experienced some compiler errors with the above kind of code. The compiler complains that a semi-colon is missing, but the solution is actually to delcare the control variable outside of the loop, as below: unsigned char i; for ( i = 0; i < 20; i++ ) { // code goes here } I'm not an expert in C, but it is my understanding that declaring the control variable within the fo
  7. tut, I've found the problem. And yes, I was being stupid with my config words This is the first time I've used in circuit debugging, and I didn't realise that by setting the config option "Debug" to ON, you were restricting the device to debug only. It sounds obvious now, especially when I put it like that, but at the time I just thought setting the debug option in the config word would effectively tie up the ICSPDAT and ICSPCLK pins for debug purposes only (i.e. not available for I/O). I didn't realise that you couldn't just use the device in the normal manner if you wanted to. N
  8. Hi everyone, I've started a new project, and as part of that I wanted to re-use some of my character LCD code that I developed for another project, under Hitech PICC. I ported the code over to BoostC earlier today, and I've been racking my brains trying to get it working ever since. Eventually I found that when I step through my code using the Pickit 3 ICD, then my LCD display initialises properly and displays the required message. It also worked if I allowed the code to free-run in debug mode. For a while this sent me down the path of debugging my delay routines - I thought that pe
  9. Hi BOOSTC development team, I've just started experimenting with Microchip's Explorer 16 development board, which utilises the PIC24FJ128 and the dsPIC33FJ256GP710. I hopped over to your website, curious to see if there was any support for these devices with your compiler. Alas, no. But... if you don't ask you don't get! So this is just a quick message to let you know that if you were to support this range of devices in the future, I for one would definitely make use of your compiler with them. Thanks, Brian
  10. Just to let the developers know I also came here searching for support on the PIC16F193X series. I've just downloaded the beta release as previously suggested so hopefully that's one problem sorted out. In the meantime I've noticed that the PICKIT 2 does not support these devices so now I'm going to have to upgrade. Drat. Thanks for the device support BoostC team. Brian
  11. Okay Ian, thanks very much for the information - very helpful indeed. As it happens I already have a PicKit 2 and it will be very nice to be able to use it for hardware debugging. I think you're right; it is worth sacrificing a couple of I/O pins for this facility. I've tried Reynard's suggestions but I was not able to get his ideas to work on my specific device. I think he's right - it probably is target device specific, so it's working on his but not on mine. Having failed to obtain encouraging results with the simulator I did decide to try it in practice. It resulted in an endless
  12. Hmmmm. Why is it relevant if my PIC can reprogram its own flash? I've just checked Microchip's website and in the spec table for their devices they have a column called "self write". Is this the feature you are referring to? If so, then no my PIC does not have that capability. As it happens I'm going to have to upgrade my target device anyway due to a different limitation, so this might be an opportunity to replace it with a device that can reprogram its own flash. But, I'm still left confused as to why this has any relevance to reading ROM memory and fetching arbitrary data. Plea
  13. Reynard, I've just read your post as I was about to shut down my PC and go to bed, and I felt that I couldn't go to sleep unless I'd tried your suggestion! I've had a quick try and it definitely doesn't seem to work, at least not using the MPLAB simulator anyway. If I make the pointer point to various places (ptr[1], ptr[2], ptr[3] etc) and make a variable 'test' equal to the location that the pointer is pointing to each time, then I get repeatable results (i.e. the same data each time I try it), but the data I get is not the data I have stored at that location in program memory.
  14. Ah, it has just occurred to me that when I try to access address 0x0006, I am probably reading PortB in data memory rather than the information I've manually placed in program memory. So I am not addressing the memory correctly. Question is, how *do* I do this correctly? Okay, time to study some datasheets. Brian
  15. Okay, I seem to be lacking some understanding here. Perhaps someone with a bit more experience than I can help. If I fill my ROM space with data using #pragma data (which I have done), then how can I access the data stored? For example, as a test I wrote the following: #pragma data 0x006 0x80 // This is just some sample data placed at address 0x006 to see if I can access it later on and then, in my program, I tried to access the data using a pointer to 0x006. However, the data I get back is 0x00, not 0x80. Clearly I am doing something wrong, but I cannot see wh
×
×
  • Create New...