Jump to content

Reynard

EstablishedMember
  • Content Count

    687
  • Joined

  • Last visited

Everything posted by Reynard

  1. "rom char fonteeprom[256] = { ... };" This method is not described in the manual and may be copying the array from rom to ram at startup. Have you tried "rom char *fonteeprom[256] = { ... };" i.e. a pointer to your rom data. I have tried rom char myrom[3] = {1,2,3}; fred = myrom[1]; // From listing file. rom char myrom[3] = {1,2,3}; 0313 3000 MOVLW 0x00 0314 00BF MOVWF main_1_myrom fred = myrom[1]; 0315 083F MOVF main_1_myrom, W 0316 00CB MOVWF __rom_get_00000_arg_objNumb 0317 3001 MOVLW 0x01 0318 00CC MOVWF __rom_get_00000_arg_idx 0319 2010 CALL __rom_get_00000 031A 00B4 MOVWF gbl_fred 0045 label3 0045 3401 RETLW 0x01 0046 3402 RETLW 0x02 0047 3403 RETLW 0x03 and it worked as expected. Data is retrieved from rom into fred. I have only tested with PIC16 though. Maybe it is not ready yet for PIC18. Cheers Reynard
  2. I have not seen just a backslash used to represent a null character. BoostC will give you a literal error if you do use just a '\'. For an end of string null use (baskslash0). The backslash is a special character to allow you to use \n, \r, \t etc. for ascii control characters. '\\' will give you a single '\' (0x5c). while(buffer[i] != '\') Cheers Reynard
  3. getc() will wait for a single character to be recieved then pass it back to you. gets(*mybuffer) will wait for characters and put them into your supplied buffer. The function will continue to collect received characters until a carriage return (0x0d) is received. When a CR is received, a NULL (0x00) will be placed at the end, then control returned back to you. Your buffer must be large enough for the maximum string you expect to received plus the null. OERR is a recieve error flag so should not occur when transmitting unless your receiving device is echoing. You cannot use puts(*mybuffer) to send your message as it contains a null (0x00) within it which will terminate the transmission early. You need to put your message into an array and set up a byte counter to count out all yout putc()'s. You should try to avoid using these functions as they prevent your main loop processing other tasks while waiting for something to be recieved unless you poll kbhit() or something similar. Any comm that I do are usually interrupt driven and run as background tacks. You give it a message to send and let it get on with it while you are off doing something else. Cheers Reynard
  4. I am running out of ideas here dude. The docs say RS232 should be TX1/2 and RX5/6. The UART registers should work with most bits in the default (reset) state. The bootloader according to the docs does not use the UART. Must be bit-banging through port B bits 0 and 3. Try using a PC with a real serial port and something like HyperTerminal. An oscilloscope would be helpful to see exactly what is going on down at pin level. Good luck. Reynard
  5. Do you have both links on the controller board set for RS232 ? If you have one set for RS232 and the other set for TTL, you will get an invertion in one of the signals. Also check BAUDCON is not set to invert RX data and you are not set for 9 bits. Cheers Reynard
  6. No fancy S required. Select the plug-in you wany, say Button, right click plug-in and connect it to a port and pin. If connected to port B pin 0 it will also generate interrupts (INTF). LED plug-ins will light on an output port etc. In debug mode timers will count, interrupts will be serviced. There may be some limitations. Have a play around with them there plug-ins and you will figure out what they do. Cheers Reynard
  7. You say you are using an EZ Controller Turbo running at 20MHz. Looking at the schematic it only has a 10MHz crystal so it can only run at 10MHz or 40MHz using the 4x PLL. Check your chip silicon version number. A good programmer should tell you this if it is not printed on the package. The 18F2520 has a bug list as long as your arm. Read all the errata sheets, they make scary reading. Your boot loader is obviously working if you can download your program so the UART must be working correctly. Cheers Reynard
  8. CREN is not an error bit but a Continuous Recieve Enable bit set or cleared by software. CREN should be set if you intend to receive serial data. FERR and OERR are error bits. Cheers Reynard
  9. To all Newbries out there reading this forum I would like to recommend an excellent book on the PIC Micrcontroller. The book is "The Quintessential PIC Microcontroller" by Sid Katzen published by Springer, ISBN 1-85233-942-X This book covers practically all you need to know about the 16 series and its peripherals. Most examples are in assembler so you can see exactly what is going on with a few examples in CCS C. It gives an excellect explanation of the adc for the 16F87X. Cheers Reynard
  10. A lot of programmers use a switcher or charge pumps to generate the 12-13 volts required for programming. LVP is generally used for "on-board" programming when your only voltage source is the Vcc supply (Vdd). Cheers Reynard
  11. Your CONFIG says you are using low voltage programming (default). If this is what you want, have you taken all the precautions about RB3 pin not floating etc. If you don't use LVP then add _LVP_OFF to your CONFIG. Cheers Reynard
  12. If you don't mind adding extra hardware, you can multiplex all your counters into a single port using something like 75LS244 and a 74LS138 (or similar CMOS versions). You then have 4 bits to read your counters and 4 bits to do the multiplex selection. OR Latch all your counters into a shift register and use SPI to read it all in. Cheers Reynard
  13. Could it be that BoostBasic does not support the float data type ? The float libraries seem to be only for C and C++ according to the reference manual. Cheers Reynard
  14. %c and %s are usually lower case but are they supported by lprintf ? Cheers Reynard
  15. The value of 7 indicates the bit number within the register and is not a bit mask. OSFIF is bit number 7 (most significant) of the PIR2 register. The compiler will sort out the details whether to use the number 7 or 0x80 etc. Regards Reynard
  16. The LCD library is probably compiled without the extended instruction set. It is not usually recommended to mix standard and extended instrustion as standard instructions can be interpreted differently in extended mode. Read the extended instruction section of the pic manual for a fuller explanation. If you have the LCD library source code you can always try recompiling though I am not sure if BoostC supports extended mode. Cheers Reynard
  17. Do you have the watchdog timer disabled ? It's enabled by default usually. Do you have a loop somewhere to stop main() falling out of the bottom. You need to give us all a few more clues to what you have done or not done. Cheers Reynard
  18. Try casting the pointers to int's. length =((int)pnd_point - (int)dec_point); // line 244 Cheers Reynard
  19. Hi Steve, Not really sure what this plud-in does. Looks like it applies (simulates) a waveform onto a digital input and provides a 0 or 1 onto the pin when the switching thresholds of the input pin are passed through (i.e. 2.5V). It may have a use to someone though. Cheers Reynard
  20. Are you running this on a real PIC or using the debug tool ? The debug tool will not give you a conversion complete signal. i.e. GO_DONE will always be set. Regards Reynard
  21. The value of _EEPROM is usually defined as address 0x2100 for most chips. To fill the first 6 bytes of EEPROM you need: #pragma DATA _EEPROM,0,0,0,0,0,0 You should see something like this at the end of the assembler listing. The config data and the eeprom data. 2007 3F3A DW 0x3F3A 2100 0000 DW 0x0000 2101 0000 DW 0x0000 2102 0000 DW 0x0000 2103 0000 DW 0x0000 2104 0000 DW 0x0000 2105 0000 DW 0x0000 To set the data in EEPROM, check that your programmer is capable of performing this feature. There may be option to erase the EEPROM when programming prior to writing. Cheers Reynard
  22. Have you tried putting the defualt EEPROM data value into your source file which will then be transferred into the PIC by the programmer when you program the device. #pragma DATA _EEPROM,0,1,2,3; or #pragma DATA 0x2101,1; etc. Cheers Reynard
  23. You can try using "Project -> Quick", then select the source (.c) file you are interested in, and a mini project will be created containing only that single file. When you are done, just delete the mini project file and go back to the main project. Cheers Reynard
  24. This basically does what you suggested. Just format the intPart and fracPart with a decimal point between into a string. void main(void) { float myfloat; int32 intPart; int32 fracPart; myfloat = 3.14; intPart = float32_to_int32(myfloat); fracPart = float32_to_int32(float32_mul(float32_sub(myfloat, float32_from_int32(intPart)), 10.0)); } Cheers Reynard
  25. Did you add the libc.pic18.lib to your project. See page 20 of the manual. Cheers Reynard
×
×
  • Create New...