Jump to content

trossin

Moderator
  • Content Count

    243
  • Joined

  • Last visited

Everything posted by trossin

  1. Thanks Reynard and Pavel. I too have been running into issues with structures using the large memory model but have been mostly seeing it in the simulator when using custom plugins so I blamed myself. I have not had much time to play lately so I have not taken the time to root cause my issues. It sounds like this could be part of it. I'll try the new version and keep an eye out for the next problem I see since older ones go away as I change code.
  2. I attached a little screen shot of a tiny program with a structure array that was initialized to have the 32-bit tag set to 0xffffffff and the cache state set to 0. When debugging, the watch window shows 4 of the 5 states as 0xff and only one with the correct value of 0. Reading the element named state at the end shows that it does have the correct value. The only problem is the watch window. I should also mention that it is not possible to add a variable to the watch window with a very long name since there seems to be a character limit. I attached a little project to demonstrate the problem. I'm using Version 7.10 and a 18F4620 Issue.zip
  3. I have one for the 18F parts you mentioned and other 16F part here: http://tedrossin.net46.net/Electronics/Pic/Pic.html#Pic%20Boot%20Programmer This works for code produced with the C compiler. I have not tested it with the output of the Basic compiler but it may work. You will need MPLAB to assemble the boot loader source and select your processor. Let me know if you have questions.
  4. // FIXME: Add code to create new file The above comment in my file caused the IDE to blow it. To make a long story short, I can not save a file with the word FIXME in the file. FIXM is fine but FIXME is verboten! So is lowercase fixme. int fixme; will also cause the bogus message. I'm pretty sure there is some code in the IDE looking for this string that needs to be removed. --------More rambling--------------------------------- If I delele this line from my file, it can save it. If I put it back in, it can not. Here is the context: else if(SectorBuf[index]==0){ // Remaining indexes are free Done = 1; if(OpenForReadWrite){ // FIXME: Add code to create new file } } If I leave the line in, I get the error. If I do a cut, I can't. If I paste it back in, it fails. Here is a much smaller case I was able to make fail. I attached the file. Just like before, cut the line with FIXME and you can save the file without the error message. Paste it back and the error message goes away. /* CBLearn.c: A file to play around with the compiler 18F2620 */ // FIXME: Add code to create new file #include <system.h> void Poo(unsigned long Sec) { unsigned long Value; Value = Sec; } #define OFFSET 3 char SectorBuf[512]; void main() { unsigned long Sector=0x12345678; unsigned char Loop; unsigned int Index; union{ unsigned long lw; unsigned char b[4]; } It; Sector = *(unsigned long *)&SectorBuf[index]; Poo(Sector); while(1); } CBLearn.c
  5. I'm using v7.05 but got the same results with v7.10 I have a file in my project that grew a bit and now when I make changes and go to build it I get a "File can not be saved" error. The file is 39.2K and if I start SouceBoost, add a space and click the save icon I get the error. reduced file down to 31.2K and it fails reduced file down to 21.3 K and it works. I created a brand new project and copied the files to a new directory and it fails the same way. I should mention that the smaller files of the project save just fine but once I try to save the large file, even the small files start failing. It seems that the files do get saved, it is just this message pops up. A work around is to split the file in two and add a bunch of function definitions but I wanted these functions to be hidden from other files. Has anyone else seen this problem. I see it on Windows 8 and Windows 7. I should mention that I removed all my plugin dll from the SourceBoost directory in case they were causing the problem and it did not solve the issue.
  6. What can I say. I went for the $40 upgrade to Windows 8. Thought I would share that our favorite tools work. I was able to compile and simulate the few projects that I tried with a couple of my plugins.
  7. So I just modified my SpiWrite and SpiRead functions to wiggle a bit after changing sspbuf and then made my plug in get a callback when sspcon1 changed. This allows me to create the SDCard plugin with just a little change to my SourceBoost PIC code. I have a ways to go but I'm interpreting commands and returning responses while getting the emulated SDcard out of the init state. unsigned char SpiWrite(unsigned char DataOut) { sspbuf = DataOut; #ifdef SDCARD_PLUGIN_MODE sspcon1 += 0x80; // Trigger callback to look at sspbuf #endif while(!sspstat.BF); return(sspbuf); } unsigned char SpiRead(void) { sspbuf = 0xff; #ifdef SDCARD_PLUGIN_MODE sspcon1 += 0x80; // Trigger callback to look at sspbuf #endif while(!sspstat.BF); return(sspbuf); }
  8. Thanks for the responses. The status flags do not exist Jorge since the SPI is not modeled in the simulator. This is the reason that I'm looking at the register writes directly so that I can model the SPI. I understand that it would be a large change Dave so I will just modify my PIC code to toggle a free port bit or some other unused register when doing spdbuf writes so that the plug in can trigger on the write. I can just ifdef this code in and out based on the build type (debug or release) or just a #define at the top of the file. Again thanks for looking into this. Having the plugin API is really a great feature of your tools.
  9. I finally got busy and started working on an SD card plugin using the above technique with call backs but ran into a couple problems. The SPI port writes and reads throught the same register spdbuf. So in my plug in if I read a command from spdbuf when it changes then write the result back to spdbuf, I get another call back for what I wrote. No big deal, I just ignore every other call back. There is an exception here which is my 2nd problem: The big problem is that if my PIC code writes the same value twice, the call back is not called on the second write. So say I'm trying to write a sector worth of 0xff to the card and the card will return 0xff until the write is complete. Each write to the spdbuf will get a return value of 0xff but the call back will only be called once for the 512 writes so my plug in will not know that the PIC code did 512 writes and hang up. Polling the register every clock tick does not help either as the register did not change. Is there a way to register a call back which is called every time a register is written? If not, I don't see a way to make this plug in work. Thanks for any help.
  10. This looks like string copy to me. The for loop says copy the character pointed to by Y to the location pointed to by X. Advance the source pointer (Y) after the character is read and advance the destination pointer (X) after the character is written. Keep doing this while the character transfered is not zero. Once a zero is copied (the string terminator), break out of the loop. When the loop is finished return a pointer to the begining of the string copied (original value of X); Note that for has spaces for statements. The first space is optional and says what to do before the loop is started, the 2nd space is not optional and requires a statement which when evaluated to 0 will break out of the loop. The 3rd space is for an optional statement to be performed at the end of the loop. So the for could have been replaced with while(*X++ = *Y++); for(a,b,c){ d } is the same as a while( b ){ d c } the for loop is just a little more compact but was not really needed for the language. I hope this helps. Ted. P.S. if you changed the *Y++ to *++Y the first character will be skipped since the pointer is advanced before the character is read.
  11. if angle is greater then 90 and less than or equal to 180 then sin(angle) = sin(180-angle) if angle is > 180 then sin(angle) = -sin(angle-180) So, you only need a table of 90 degrees if you are wiling to do a little work before and after the lookup. I don't know how many hardware PWM units the device you mentioned has. If it does not have enough, you will need to implement it yourself in a little interrupt service routine. Either way, the input to the PWM (either software based or hardware based) is just an N-bit number where the pulse width is varied from 0 to full on. full on is when the input is at the max number. It sounds like you would like the vary the amplitued to regulate the voltage so you will need to scale the output of your table based on the current set point. To do this you will need to mulitply the output. Since the PICs do not natively do floating point math, you need to use fixed point math. You can put the binary point anywhere you want by simply shifting the final result by a fixed amount. For example the binay number 00110100 can be thought of as 3.25 if you imagine the binary point between bits 3 and 4 (0011.0100). If you multiply this number by 4 you get 11010000 or 13.0. To convert this back to an integer that you can stick into the PWM. Simply shift it right by 4 to get 00001101 or the value 13. I did this example with 8 bit math but you would rather do it with 16 bit math so that you have more bits of fraction to play with.
  12. trossin

    Variable Scope

    When I try to compile with gcc on Linux (removed the nop) I got this error: poo.c:5: error: 'for' loop initial declaration used outside C99 mode When using g++ I got: poo.c:1: error: '::main' must return 'int' poo.c: In function 'int main()': poo.c:8: error: name lookup of 'x' changed for new ISO 'for' scoping poo.c:3: error: using obsolete binding at 'x' The first line is no big deal. They just want a return code. But I believe this is the complaint you were looking for. Normally, the scope is taken care of with compilers by allocating and deallocating stack space. In BoostC because PICs are a bit evil, they do not allocate and deallocate the stack since there really is none for variables. Instead, the compiler cleverly reuses fixed variable locations based on the scope (and I believe subroutine nesting) to reuse memory. This may be why the compiler does not complain since it just reuses the last location. I do believe this should be flagged at compile time since x is not defined out of the for loop and clearly the coder made a mistake.
  13. Way cool. Thanks. P.S. Sorry about not reading the manual closer.
  14. I just updated to Windows 7 and thought I was screwed until I found this last post. Dang. It seems that the Source Boost installer should mention that this is required to get the product to work. So I made the changes and now I can bring up SourceBoost IDE and registration code (which succeeded) but I can't compile a project. Even though it installed to the default location of "Program Files (x86)", the tool is looking for executables in "Program Files". I'll try uninstalling and forcing into Program Files and see if that fixes it. I would think new users would be really crying about this or shopping elsewhere. I figured out the build problem and it is due to the old project pointing at the old path. I was able to update the path in Settings --> Options --> Tools and my old project built. Shame on me. I still think the "Data Execution Prevention" issue needs to be addressed by the install program with a read me. I didn't have this problem with Vista, just Windows 7.
  15. Is it possible to get a call back or monitor internal control register writes and is it possible to deposit values into status registers? For example, it seems that the SPI machine is not emulated in the simulator so it would be nice to be able to have a plugin monitor writes to the SPI register and be able to drive values back into the SPI read register and status to be able to emulate an SD card attached to a PIC. Since plugins get to look at what is going on every clock cycle it seems that if the plugin had access, it could emulate any hardware that might be missing from the simulator or at least emulate the hardware at a high level. I'm just not sure if the internal state of the simulator is exposed to the plugin API.
  16. Is you problem with the simulator or reality (running on a PIC)? I think there is a problem with the simulator for the A-to-D in version 7 that there is a patch available for. If you search through the topics you should be able to find it.
  17. My free website company killed off my site (after 2 years) so I have a new address: http://www.tedrossin...cs/Pic/Pic.html I uploaded my latest project which reinvents the wheel by interfacing a 5V PIC to 3.3V MMC, SD or SDHC cards and providing access to FAT12, FAT16 and FAT32 file systems with long filenames. I used BoostC version 7.05 with the large memory model (worth the upgrade!) so that I could implement a sector cache with simple C code. I also want to say that the type casting in BoostC worked very well so that I could cast sector data into 8,16 and 32 bit variables without it generating lots of shifting and data copying. The section on the project has more details: http://www.tedrossin...SDCardInterface The example project is lacking some major features like being able to write the the card but if you have an application that just needs to read large files (<4GB) , what I have seems to work good enough. For example, if you are building an MP3 player or if you want to read a large list of screen coordinates to control a LASER vector display. The example that I have on the web implements a tiny unix like shell that lets you examine the files on an SD card using the following commands entered through a RS-232 terminal. ls will list the current directory (the attributes are listed as 3 letters drw. d is - for plain files and d for directories) cd path will change the current directory to that given in path. For example: cd Zero 7/Simple Things pwd will display the current directory path cat filename will echo the file to the terminal window. Not a real good idea to do on binary files. For example: cat ../../TedDir/CBSDfileSystem.c
  18. Defining variables in header files is dangerous/dirty as if more than one file includes that header file an error will result. Also, it makes it hard to figure out what the variable type is when you can't search for it in the file you are playing with. Please ignore me if you know better.
  19. strcmp to be exact. I don't know off hand how Puts and Gets are implemented in your context but if they are done according to the spec, strcmp should work for you. Just remember to use: if(!strcmp(received,‚ÄĚSTART")){ // received == START. Status = 1; } Most folks forget that it returns 0 if they equal since strcmp is used to compare less than, equal or greater than it will return -1,0 or 1 (usually). Here are some notes from cplusplus.com int puts ( const char * str ); Write string to stdout Writes the C string pointed by str to stdout and appends a newline character ('\n'). The function begins copying from the address specified (str) until it reaches the terminating null character ('\0'). This final null-character is not copied to stdout char * gets ( char * str ); Get string from stdin Reads characters from stdin and stores them as a string into str until a newline character ('\n') or the End-of-File is reached. The ending newline character ('\n') is not included in the string. A null character ('\0') is automatically appended after the last character copied to str to signal the end of the C string. Notice that gets does not behave exactly as fgets does with stdin as argument: First, the ending newline character is not included with gets while with fgets it is. And second, gets does not let you specify a limit on how many characters are to be read, so you must be careful with the size of the array pointed by str to avoid buffer overflows.
  20. Here are some code fragments from a little project I wrote some years ago to make a volt meter on an LCD display. I tried to highlight the main crud in red. unsigned char SampleADC(void) { set_bit(adcon0,GO); // Start conversion while(test_bit(adcon0,GO)); return(adresh); // Fetch high 8 bits of result } int main() { unsigned int i; int voltage,whole,frac; unsigned char Raw; trisb = 0x00; // Porb B[7:0] is output trisa = 0x01; // Port A[0] is input for A/D adcon1 = 0x0e; // (left justified) 1 A/D channel adcon0 = 0x81; // FOSC/32, channel=0, ADON=1 portb = 0xaa; /* turn on some lights */ RS232Init(RS232_20MHZ_BAUD_115000); InitTimer(); InitTerminal(); RS232putch(TERM_CLEAR); SetCursor(0,0); DisplayString("Cheap Volt Meter"); for(i=0;0<1;i++){ SetCursor(0,1); Raw = SampleADC(); voltage = ((200*(unsigned int)Raw)/255)*25; whole = voltage/1000; frac = (voltage - (whole*1000) + 5)/10; sprintf3(Buf,"ADC=%d.%02dV Raw=0x%02x\n",whole,frac,Raw); DisplayString(Buf); sprintf1(Buf,"\tLoop=%u \n",i); DisplayString(Buf); DisplayBarGraph(voltage/84); Waitms(10); portb = i&0xff; } }
  21. Your math is wrong. I get 791Hz for your settings which is pretty close to what you measured. Tosc when Fosc is 4 MHz is not 4us but 1/4000000 which is 0.25us (not 4us). This is your factor of 16 error. So (PR2+1)*4*Tosc*Prescale is (78+1)*4*(1/4,000,000)*(16) = 1.264ms or 791 Hz To get 50 Hz you need: 1/50 = (PR2+1)*4 * (1/4000000) * 16. Solve for PR2 and you get: PR2 = (1/50)*4000000/4/16 - 1 = 1250-1 or 1249 This does not fit so you need a larger prescale value which I do not see in the data sheet so you are out of luck. The slowest you can go with a PR2 setting of 0xff and a 4MHz crystal is 244 Hz. There is a note about using the Timer2 postscaler for servos but I did not look that closely. Since your rate is so slow, you could do it the old fashioned way with interrupts and software counters and then you could have lots of PWM outputs for many servos. I have a little toy example here: http://www.tedrossin.0sites.net/Electronics/Pic/Pic.html#PlugIns Check out the BoostPWM files (there is a little plugin to show the PWM outputs).
  22. You're on fire sir! Thanks for the quick fix. Works great.
  23. Well done. You will make many folks happy with the 7-segment display plugin. Glad to hear there is another person out there who grew up on the 1802. I forgot to remind folks that porting from version 6 to 7 just requires you to copy 4 files from the plugin example to your current project and recompile. My quote from a year or so ago: "So, it looks easy to port to version 7. Just copy over the version 7 plugin.def, PluginAPI.h PluginApp.h and Pluginhookup.cpp and it should compile without problem as I never modified code in these files."
×
×
  • Create New...