Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About DL1968

  • Rank
  • Birthday 10/03/1968

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
  • Interests
    Theorems, firmware, circuits, books, guitars, ladies. Not necessarily in this order.
  1. Fail To Compile

    Suggestion: the preprocessor pattern matching machine must reject partial matches where a non-token character (non-blank, non-operator and a few more non-) closes the otherwise matching pattern in source file. This is not a point to be overlooked: CCS C has a very similar (symmetrical) problem with recursive substitution. You cannot write "#pragma byte KBD_CTRL = PORTA", despite PORTA has been correctly #defined: you have to use explicit addresses. Net result: work twice and introduce more hard-to-find mistakes in porting.
  2. Carefully read the Philips docs before using optocouplers on the I2C bus. You may also have a look at Philips' special ICs like P82B715 and similar. As regards interrupts, only PORTB supports them in the 16F8 series (and in many pin-compatible series, like 18F45x). But you do not really need interrupt for a touch panel. Polling the "touch sense" line a few times per second is more than enough. Are you using discrete transistor/fet switching or a dedicated touch panel controller ?
  3. Your request, as it is stated, could be fullfilled by an experienced PIC programmer with a good insight on I2C (and a large field-proven codebase on his HD as well). But things may be made much simpler at architectural level, with little conceptual redesign. First, do not connect the EEPROM to the "main" I2C bus: use a different couple of pins with bitbang (firmware driven) emulation instead. This solves 50% of problems and avoids unnecessary master/slave mode switching and bus arbitration. Second: one slave and four masters sounds alerting to my ears for such a system. Why do you need the 16F870 to drive the transmission ? Cannot data be simply polled ? Unless there are unavoidable realtime constraints, good practice simply suggests to do the opposite: 1 master and 4 slaves. This way you will have a plain single-master I2C main bus, plus a physically and logically separate I2C emulation to drive the EEPROM. Much simpler to deal with as your first experience in this field.
  4. Walter, for easily guessable safety reasons (antitampering being one) we do not normally use field bootloaders in most of our advanced automotive and industrial products based on PIC18 and other MCUs. Most of them still use OTP MCUs whenever possible, as per MISRA and OSEK recommendations (not to mention IEC61508, and costing issues). Anyway, for lower safety profile applications I've been often using an homebrewed serial bootloader written in assembly. The code is based on Petr Kolomaznic's one, except for a couple of details. The clever idea behind such bootloader (that resides in the topmost 256 bytes of program memory) is that it doesn't give for granted that a PC terminal or controlling (supervisor) MCU is permanently connected to the PIC. It instead features a timed out loading mode, that jumps to resident user code (if any !) if no activity is present on the serial line within, say, the first 300 ms after power-up. This is a very professional approach for standalone devices. If you want to turn to assembly, you can re-use 80% of the same code, while replacing RS232 with USB handling code. Anyway, it all is really worth a glance, at least. Just my 2€c...
  5. Porting Sdcc Code To Boostc

    Sorry, no experience with SDCC. I always keep myself at double safety distance from such permanent-beta stuff (and from linux advocates, as well ). Anyway, I'm not sure I got your point. SDCC, GPUTILS, CYGWIN and all that jazz do exist for windows, AFAIK. Are they so terribly hard to setup for a single shot compilation ? I believe the renowned Scott Dattalo could give you some hint about porting and/or windows setup, if you care dropping him a couple of lines. IIRC, he did the PIC port.
  6. Very well stated, Ted. Manuals, datasheets, examples... are there to be studied. A good book could help, too: for instance Roger Steven's book about serial comms. Everything a beginner or intermediate programmer really must know about PICs and serial lines. A bit of clearly explained theory, flowcharts everywhere, lots of schematics and hands-on practical examples in assembly, few really noticeable errors in code. Really worth the bucks for who's just starting. For those who don't like links, I will not say that Dave's (Benson) and Roger's books have a reference site: http://www.sq-1.com/
  7. The printf() function in itself is heavily deprecated for performance (and "security", whatever this means) reasons, and not only in the embedded world. OTOH, printf() implementations in "small devices" C runtime libraries are nothing but a limited subset of the bloated ANSI function. A good standard approach is using itoa() and strcat() the smart way to build the buffer, which in turn is then sent out over the serial link or whatever. My advice is then: if you don't feel like you would mess with a good, structured, robust serial protocol (maybe the easy MODBUS ASCII or RTU), then look for an acceptable itoa() implementation. Not wanting to mention competitors here, but a top notch $$$ aussie PIC C compiler comes with itoa.c among the examples. As regards the PC side, well: there are just too many serial libraries - DLL - OCX - .NET components available, threaded and not, priced from zero to more than 2,000 bucks. Some of my beloved evergreens are MarshallSoft and TurboPower (yes, I'm just too lazy to avoid using BCB, even though it's cycles & space greedy - but what's not for "modern" PCs with "modern" OSes ?).
  8. Ted, I believe this is due to the fact that most coding examples spread over the net and the books are either outdated (as far as a PC is involved in the communication) or aimed at controlling non-PC serial devices that would not support more than 19200 bauds. Defaulting at 9600 is a wise blind choice: you can never mistake. Of course, 115k is a good choice for modern PC-attached serial devices running at 20 MHz or more. But there are better solutions, of course, if you really have to move back and forth lots of data.
  9. Before the net, there were excellent magazines whose staff did a lot of experimenting before publishing good, reliable reference projects - and yes, they were a sort of Bible for us. FIDOnet and BBS's worked well for peer exchange long before the 'net, too. Anyway, datasheets and appnotes came as big sized books that you normally had to order by mail and pay, though. Under this documental respect, "modernity" is not totally bad and we can for once state that what came chronologically "after" can be identified as a "progress". But this is not a general rule: many modern things are way far worse than they used to be in the past (see the VAX 11/785 and VMS, Amiga, MCI, the Atari ATW800, and even Clipper...).
  10. It just depends on devices. Serial EEPROM memories, for instance, have external address pins, allowing up to 8 elements on the same bus to cohexist. See Microchip's 24xx family datahseet, for instance. Other devices instead have their addess fixed on silicon (see DS13xx RTC, just to name one), and other are nothing but MCUs used as slave peripherals. Older PICs' basic SSP - e.g. PIC16C7x - natively supported only IIC slave interface in hardware, where the device address was user assigned using a dedicated register.
  11. It simply depends on what LCD controller is installed onboard. Anyway, you have a five nines (99.999%) odds that your display hosts some clone of the universally known Hitachi's HD44780U. If this is the case, 4-bit mode must use the high nibble, and it is good practice to tie the low nibble to ground, unless otherwise noted on the LCM documentation (some National "LM-" parts are very sensible to this, while most others are not). I have no practical knowledge of the fresh new PIC you're using (anyway that's simply a sort of 16F73 evolution in a 20 pin package, with the usual backport of some cutting edge register organization trends from the 18 families and some new silicon peripherals), but it sounds very odd that driving a character LCD does not result in an immediate straightforward success. I'm sorry I do not own the related ICE module, just to quickly craft a test for you. In such cases, when any other trivial explaination has been excluded, I tend to suggest a good session with a logic analyzer, with one eye to the HD44780 datasheet. Even one of those low cost USB boxes can be enough to trace what's happening at the LCD data and control inputs. That shall definitively track down any problem and its origin.
  12. Anonymous Reference Not Permitted

    IIRC, Microchip's C18 supports them. That's elegant to read and saves some keystrokes, but can easily confuse lint and other static analysis tools. EDIT: I confirm that MPLAB C18 supports unnamed structures within a union. That's explicitly stated on page 17 of their document DS51288A "MPLAB C18 C Compiler User's Guide" (and I do have on my HD some serial protocol handling code that makes use of this feature, as well). As regards C'99, section 6.7.8 (regarding initialization) of the draft generically mentions "unnamed members of objects of type structure and union" as well.
  13. Eeprom Writes Just Once

    Did you remember to disable interrupts ? This turns out to be VERY important when writing to internal EE. Anyway, here's a chunk of handwritten MPASM assembly code that works on a PIC16F873. Pretty identical to yours (and to Microchip's datasheet EE example), I'd say, apart from the interrupt issue. 03CA 303C 00325 MOVLW MyVar 03CB 0084 00326 MOVWF FSR 03CC 3008 00327 MOVLW 8 03CD 00B2 00328 MOVWF LoopCnt 00329 03CE 3002 00330 MOVLW 2 03CF 1283 1703 00331 BANKSEL EEADR 03D1 008D 00332 MOVWF EEADR 00333 03D2 1283 1303 00334 BANKSEL INTCON 03D4 138B 00335 BCF INTCON, GIE 00336 03D5 00337 STORE_LOOP 03D5 1683 1703 00338 BANKSEL EECON1 03D7 138C 00339 BCF EECON1, EEPGD 03D8 150C 00340 BSF EECON1, WREN 00341 03D9 0800 00342 MOVF INDF, W 03DA 1283 1703 00343 BANKSEL EEDATA 03DC 008C 00344 MOVWF EEDATA 00345 03DD 1683 1703 00346 BANKSEL EECON2 03DF 3055 00347 MOVLW 0X55 03E0 008D 00348 MOVWF EECON2 03E1 30AA 00349 MOVLW 0XAA 03E2 008D 00350 MOVWF EECON2 03E3 148C 00351 BSF EECON1, WR 00352 03E4 1283 1303 00353 BANKSEL PIR2 03E6 00354 STORE_INNER 03E6 1E0D 00355 BTFSS PIR2, EEIF 03E7 2BE6 00356 GOTO STORE_INNER 00357 03E8 120D 00358 BCF PIR2, EEIF 00359 03E9 1283 1703 00360 BANKSEL EEADR 03EB 0A8D 00361 INCF EEADR, F 00362 03EC 0A84 00363 INCF FSR, F 03ED 1283 1303 00364 BANKSEL LoopCnt 03EF 0BB2 00365 DECFSZ LoopCnt, F 03F0 2BD5 00366 GOTO STORE_LOOP 00367 03F1 1283 1303 00368 BANKSEL INTCON 03F3 178B 00369 BSF INTCON, GIE 00370 03F4 1683 1703 00371 BANKSEL EECON1 03F6 110C 00372 BCF EECON1, WREN Of course, if the watchdog is enabled, you really ought to hit it in the tight blocking loop referred to the label STORE_INNER. Style note: just too many BANKSEL directives for my tastes, and the loop slows things down unnecessarily for such a low number of values.
  14. Marco, there's no need to move the library file around. All you have to do is tell MPLAB where it can find the file. To do this, set the project include file directory to the current directory where the libc.pic16.lib file has been installed. You will find this setting among your MPLAB project options. If unsure, please have a look at MPLAB's manual.