Jump to content

ChipGuy

EstablishedMember
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ChipGuy

  • Rank
    Newbrie
  • Birthday 07/21/1973

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Atlanta, GA (Alpharetta)
  1. I did the same thing on devices with only one hardware SPI peripheral. As a matter of fact, I used a two-wire serial-in, parallel-out (SIPO) circuit to derive as many slave select lines as needed. It is relatively fast to carry out via a simple bit-banging routine. (2 or 3 wire would work) That was for a a multiplexed SPI network of identical slaves with "only 16 possible" addresses, with only one SPI peripheral, in order extend the address range I could use (like banking sort of). I always prefer to use the hardware SPI instead of bit-banging as I can free up the CPU and rely on the "done" flag to trigger an ISR for the next SPI byte.
  2. The solution I used for my recent Parallax RF Design Contest entry was to never use floating point math. It killed my PIC's remaining code space to do so, and wasn't so efficient anyway. So I had this: integer number (ulong, or whatever) * floating point coefficient. Example: 1,023 (0x03FF) * 0.003 can be expressed as: 1,023 x ( 3/1000) -> 1,023 x 3 x 1/1000 ..and this gives an integer number 3096 x 1/1000 I then just divided by a 10's power divisor, then decrement divisor by 10 when the dividend was less than my divisor. For each division, increment a count and add 0x30 to the quotient (result) to get your ASCII characters. Insert decimal where you need to manually. Example: Display floating point value for 1023 x .003V = 3.069V ASCII = 0x33, ".", 0x30, 0x36, 0x9 1023d * 3 = 3069 (Now divide and drop remainders) 3069 / 1000 = 3 + 0x30 = 0x33 3069 / 100 = 0 -> 0x30 3069 / 10 = 6 -> 0x36 3069 / 1 = 9 -> 0x39 ..insert decimal point where needed. Change the divisor (power of tens) for the needed # of digits before and after the decimal point. Store each in a string array and insert decimal point as you do so. Then write the string array to the LCD. That's what I did. Hopefully some variation of this will help you. :angry:
  3. Thanks, that was very helpful reply! I recently started looking into job opportunities for embedded design/electrical engineers (w/ embedded design skills) here in the USA and a number of them list C++ as a skill for potential candidates. Granted, that is not typically for PIC-related/8-bit hardware, but nonetheless the C++ concepts would be more meaningful when applied to real-world problems. Using the Boost C++ would be a great way to practice some of the concepts in a very meaningful & fun way by using a PIC. I'll purchase a Full level license. Thanks again for the prompt reply!
  4. Hi, I posted this question here in case others need to see it... I currently already have a Boost C Pro license, but I have questions regarding moving to Boost C++: A. License features B. Performance/requirements of the Boost C++ compiler Questions: A. As the C++ Pro license includes the source code libraries, are these the same as included with licensed Boost C or are they specific to Boost C++? If so, I could simply add the Full license? B. What impact on the PIC resources does using the Boost C++ (vs. say, Boost C) in terms of codes size, performance, etc? I just learned C++, and...I was under the impression that C++ would by nature eat much more resources than I would expect a PIC like those supported to provide. I'd appreciate knowing more about the PIC C++ implementation, in general. Thanks!
  5. Actually, I should have mentioned "COM Port Toolkit" for a shareware version of a UART terminal, I meant to say "COM Port Toolkit" instead of "Adv. Serial Port Monitor"! The difference is that while COMP Port Toolkit is pretty nice, it can't separate Rx lines when a CR/LF is received. Otherwise, COM Port Toolkit is very helpful, and can do some fancy things....very helpful for debugging your UART code. You can find it at Cnet.com/downloads. You can also use the PICKit 2 (most recent) software for its UART terminal, but I haven't any experience with that one yet.
  6. Can I make a suggestion? When dealing with serial communications over RS232/RS485, etc, I have found it far better to use some program other than Hyperterminal. When using something like Advanced Serial Port Terminal, etc., you can see the actual hex values received (as well as ASCII characters) and more easily debug funny serial UART problems. Also you can send whole messages or files via the TX output.
  7. Hello-unless I'm mistaken, didn't you post this question and get my reply at the Hi-Tech forums? If not, please disregard that. The PICKit 2 will work quite well and is (generally) easy to use. There are new features as well, including a UART terminal function for your PC using the PICKit 2 as the interface and GUI as the terminal window. The PICKit 2 does not taken any extra amount of effort to use UNLESS you are attempting debugging on a PIC that does not provide on-chip in-circuit debugging (ICD) provisions. Those require a PCB with special "ICD" version of the chip you will use, but still just plugs into the circuit in question. The PIC is programmed & debugged via a 6-pin .1" header and may provide low-current power to the target circuit if needed. You basically provide provisions for the PICKit 2 header in the circuit, and should be able to leave the PIC in-circuit from then on. The progrmr/debugger will identify the target PIC in MPLAB when you attempt to establish a connection to the PIC. It uses: - /MCLR / VPP line - ICSPDAT ("PGD" on some PICs) data line - ICSPCLK ("PGC" on some PICs) clock line - VCC, ground lines I think you will find it very convenient once setup properly and in use. The lines dedicated to ICSP can typically still be used for I/O functions in most cases. These lines are usually "isolated" using 470 resistors or physically isolated in your design depending upon application. It's not perfect, but has gotten better. Works well with Sourceboost C & MPLAB.
  8. Hi everyone, just thought I would let you & the SourceBoost team know that I found a pretty-much perfect hardware demo board to get the NOVO motor speed control example up and running in minutes. I used the Sure Electronics DB-DP113 "Hybrid of PIC18F4520 Dem2PLUS and Low Power Demo Board" hardware to get the NOVO example running out of the box, only change was one line to PicConfig.h! I was hoping my first time with learning an RTOS will go more smoothly, so I found this by chance from eBay seller fcb_electronics ($32 USD incl. shipping, ships worldwide). Has many features including LCD, temp, USB port, 7-seg. LEDs. /* PICConfig.h NOVO configuration example file */ /* The following are marked where changes were made for the Sure Elect. PICDem2 board, for */ /* the PIC18F4520 as needed */ #pragma DATA _CONFIG1H, _OSC_XT_1H /* Use provided external oscillator (for purposes of getting example running) */ It will run with internal oscillator or 12MHz oscillator. Note that timing will not match the example code's number without modification. Coincidentally, the motor control pin RB1 is also connected to an LED so you'll be able to see the NOVO operation even if you can't get a motor! I did add, in my case: - Motor and transistor: scrap motor from bubble jet printer, N-ch. MOSFET - .1" 6 pos. header, solder to provided pin holes, for PICKit2 use - Pushbuttons for entry (I did not use on-board buttons): used spare I/O header pinouts provided - .1" 2 pos. header for +5V, GND from external supply as PICKit2 did not sufficiently power board Makes a great board for customization.
  9. I think perhaps there's some information missing; what are the circumstances of the read/write code you have? There should not be an issue with the PIC corrupting EEPROM values on power up-are you sure the following are ok?: 1. Successfully write values to EEPROM 2. Validated EEPROM values are correct when read 3. Never doing a write by accident which may change data unintentionally How did you verify data was not as expected?
  10. Thanks for replying-that did work once I changed this: rom char std_font_array1[256] = {...data...}; To this: rom char * std_font_array1_256 = {...data...}; Very unaccustomed to no longer specifying the array size when declared! [256]. I had assumed specifying array lengths was valid in most compilers. If there is any way to retain the option in Boost C that would be great. Thank you for the help.
  11. Hi, I seem to be unable to successfully compile my program in BoostC (full, licensed), or at least I cannot find appropriate documentation to ensure I'm defining/placing my ROM arrays correctly. Target is PIC16F886 (8K words) I want to use: rom char std_font_array1[256] = {...}; /* Break 1,024 byte image array into 4 256 byte arrays */ rom char std_font_array2[256] = {...}; rom char std_font_array3[256] = {...}; rom char std_font_array4[256] = {...}; ..also defined, of course, in my global_definition.h file: extern rom char std_font_array1[256] = {...}; Result: Compilation fails, and I receive: Optimisation level:1 Error: Memory allocation failed - No remaining memory block (on target) big enough for: 'std_font_array1' in file: C:\....standard_font.c size:256 bytes HOWEVER I clearly do have sufficient unused memory when compiled in Hi-Tech PIC C (code size 22% of 8K words). Am I missing a directive or method for using ROM arrays? I wonder what it could be... Thanks
×
×
  • Create New...