Jump to content

Thermal Runaway

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Thermal Runaway

  • Rank
  • Birthday 10/23/1979

Profile Information

  • Gender
  • 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 InterfaceType,\ unsigned char UseBusy,\ unsigned int DataPort, unsigned int Data_PortTris,\ unsigned int CtrlPort, unsigned int Ctrl_PortTris,\ unsigned char RS, unsigned char RW, unsigned char E> I understand that the purpose of a template is that you create a generic function, and then within your code you can pass it arguments of different types. The pre-processor will collect all of these different types of function call, and create different types of function to suit the arguments that are being passed to it. Like function overloading, but with the advantage that you don't have to write each function out yourself - the pre-processor takes care of it all. I hope my understanding is correct there. But, even with that understanding, I still cannot make sense of the above template. Here's a function that uses it: _LCD_TEMPL void LCD_Clear() { _LCD_FunctionMode(); _LCD_Write( clear_lcd ); // clear display _LCD_Write( return_home ); } So I understand that LCD_Clear is now a function template. But I don't understand what each of the different parameters within the template are for. I completely lacking understanding of the purpose of this, to the point where I don't really know how to phrase my question about it! Can anyone provide a brief explanation? ====== Thanks in advance for any advice. I have been pouring over this source code for a while and I'm just finding myself more and more confused by it! Brian
  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 project under the "Header Files" project tree? Bizarre. I don't like it. After this MPLAB X stopped complaining about my header files and device specific peripherals naming and all that stuff. But unfortunately I still couldn't get my project to compile. It would offer me a bunch of general errors related to some of my functions. It wouldn't elaborate on what its problem was, and for the life of me I couldn't find fault with the functions myself. Indeed, the entire project compiles just fine within the MPLAB V8.x environment. So, after this I'm still of the opinion that MPLAB X and Sourceboost don't mix at the moment. I can't get them to work together.
  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 why change. Brian
  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 to be happy with it. But now it's complaining about all my identifiers such as porta, trisa, osccon, etc etc. I was expecting all this to be sorted out by the system.h include. It's also complaining about my assembly lines such as asm nop. It doesn't like the asm identifier. So, it seems that something's not working right here. If any one else has successfully used MPLAB X with SourceBoost and can provide some advice to get me on the right track, it would be much appreciated. Thanks, Brian
  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 for loop would be more efficient in terms of RAM because the control variable would only exist within the scope of the for loop itself? Is this correct? Has anyone else had similar problems? Thanks all, Brian
  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. Not to worry, sorted now! I certainly won't be making that mistake again any time soon. Brian
  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 perhaps the delays were not working properly and hence causing my issue. As it happens I did find a problem with my delay routine but fixing it didn't resolve the problem. The LCD would not initialise or display any characters unless I ran it in the debugger. Now for the really weird bit... I've since found out (just now, actually) that if I select the Pickit3 ICD, then compile my program, then select the Pickit3 programmer and program my target device, the program works flawlessly. But if I immediately recompile (this time without first selecting ICD) and reprogram my target device, it returns to the original fault symptom. It seems as if my target device does not run when compiled in the normal manner, because I reduced my code to a simple "set all of porta ON" program and it couldn't even manage that. Yet, if I first select the Pickit3 ICD, compile my code, then switch back to Pickit3 programmer mode and program my target device... works like a charm. Has anyone else experienced this? I keep accusing myself of doing something stupid with my config words or something like that, but nope - I've checked it many times and it all seems fine to me. The target device is a PIC16F1936 and it's the first time I've used one of these so I guess it's possible I've done something silly with either the CONFIG words or one of the other registers. It must be something that isn't effected when the program is compiled in debug mode. Bizarre. I'm going to meditate over the datasheet. Brian
  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 loop of crashes. Curiously, the device has refused to power up at all since so I think it has been destroyed?! The GLCD that it is connected to has on board power supplies and is sensitive to their startup parameters. I take care of all this in some initialisation code that I wrote, but perhaps the crash loops have sent it haywire. Now that I think about it, perhaps it's the GLCD that's gone faulty, not the PIC itself, because I was basing my previous suggestion that the PIC has gone faulty solely on there being no output on the display anymore. Anyway, as I said I need to upgrade the device regardless because of a RAM limitation (I'm implementing an SD card and didn't realise they must be read in 512 byte complete sectors) so this will be an opportunity to experiment with a target device that has the self-write functionality. Hopefully I can then get this working, and it'll also be interesting to experiment with the hardware debugger functionality. Thanks again for the advice everyone - very much appreciated. Brian.
  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. Please enlighten me! Thanks very much, Brian
  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. It is occurring to me now that perhaps this is a problem with the simulator, and not with the code I've written. I'll try and use it to send a character to my GLCD tomorrow and see if it works in practice or not. If it doesn't work I should also be able to work out if the practical results agree with the simulator by looking at the pixels that have been enabled on the screen. But it's way too late for that this evening so it's a job for tomorrow. Thanks for your response. Ian: I'll also give your suggestion some thought tomorrow as well, thanks again for your input. Goodnight! Brian.
  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 what it is. Is anyone able to steer me in the right direction? Thanks, Brian
  • Create New...