Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by DL1968

  1. 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
  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 t
  5. 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
  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
  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
  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 so
  12. 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. 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
  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.
  • Create New...