Jump to content

asmallri

EstablishedMember
  • Content Count

    169
  • Joined

  • Last visited

Everything posted by asmallri

  1. No the driver uses or emulates an asynchronous UART
  2. Have you tried the test code? //////////////////////////////////////////////////////////////////////////// // Serial Communications Test Program // // Exercises the serial driver code in <rs232_driver.h> by reading and // writing to the serial port //////////////////////////////////////////////////////////////////////////// // Author(s): Andrew Smallridge // Date 17 November 2004 // // Copyright (C) 2004-2006 Andrew Smallridge // Copyright (C) 2004-2006 Pavel Baranov // Copyright (C) 2004-2006 David Hobday // Initialially developed on the PIC18F452 //////////////////////////////////////////////////////////////////////////// #pragma CLOCK_FREQ 40000000 #include <system.h> //////////////////////////////////////////////////////////////////////////// // The following three sections have been copied from the serial_driver.h file // USART software implementation template arguments and variables // USART hardwareware implementation template arguments //////////////////////////////////////////////////////////////////////////// // // **** START OF DEFAULTS USED FOR SOFTWARE USART EMULATION **** // // RAM used by the software USART driver to emulate the equivalent serial hardware registers // Note this section is really just reserving the space. The defines in the subsequent section // overlay these RAM locations unsigned short sw_SPBRG@0x47; // define location for the emulated SSPCON1 unsigned short sw_RCREG@0x48; // define location for the emulated SSPCON2 unsigned short sw_TXREG@0x49; // define location for the emulated SSPSTAT unsigned short sw_TXSTA@0x4A; // define location for the emulated SSPBUF unsigned short sw_RCSTA@0x4B; // define location for the emulated SSPADD unsigned short sw_TXIF_PIR@0x4C;// define location for the emulated TXIF_PIR1 unsigned short sw_RCIF_PIR@0x4C;// define location for the emulated RCIF_PIR1 //////////////////////////////////////////////////////////////////////////// // USART software implementation template argument values //////////////////////////////////////////////////////////////////////////// // variables cannot be passed as template arguments. The following constants map to // the PIC registers and software emulated USART RAM locations. These constants are // then used by the templated functions. When changing the address of an emulated // register the corresponding constant mapping must also be changed. // PIC18F defaults for software emulated USART support #define TX_PORT 0x0f8b #define TX_TRIS 0x0f94 #define TX_BIT 6 #define RX_PORT 0x0f82 #define RX_TRIS 0x0f94 #define RX_BIT 7 #define e_SPBRG 0x47 #define e_RCREG 0x48 #define e_TXREG 0x49 #define e_TXSTA 0x4A #define e_RCSTA 0x4B #define e_TXIF_PIR 0x4C #define e_RCIF_PIR 0x4C #define e_TXIF_BIT 4 #define e_RCIF_BIT 5 #define MODE (USART_reset_wdt) //////////////////////////////////////////////////////////////////////////// // bit_time is used by the software emulated USART and is the number of CPU // instruction cycles per bit. // // bit_time = FOSC / 4 / BAUDRATE // The maximum value of bit_time currently limited to approximately 24000 // and is determined by the maximum word size supported by the compiler. // this will change when 32 bit variables are supported. // At FOSC of 40MHz the minimum standard baud rate is 600 baud. // When using the software emulated USART functions ensure that the baud rate // can be realistically supported by the FOSC used. bit_time values below // 36 will likely lead to unreliable comms. // // The software UART takes 8 instruction cycles in a bit time loop. Therefore // the driver software divides the bit_time value by 8. If experimenting with // different values for bit_time use increments of 8 to guarentee a different // bit time is selected //////////////////////////////////////////////////////////////////////////// #define bit_time 86 // 115200 baud at 40MHz //#define bit_time 1041 // 9600 baud at 40MHz //////////////////////////////////////////////////////////////////////////// // Serial Control Flag Bits used for the MODE parameter // // DO NOT REMOVE THE COMMENTS FROM THE FOLLOWING FLAGS // These flags are defined in serial_driver.h and are include here for information // only. These flags are used in the MODE parameter. // // The USART_invert flag is used to signal the software UART that the serial // input and output signals are inverted from normal RS232 communications. // Hardware implementations that use standard RS232 transievers // such as MS1488/MC1489 or MAX232 line drivers / receivers do NOT require this flag. // // The flags USART_HW and the USART_invert are mutually exclusive. // // Sample use: #define MODE (USART_reset_wdt | USART_HW) // //////////////////////////////////////////////////////////////////////////// // define USART Mode bits //#define USART_HW 0x01 // specifies use the HW USART in the PIC //#define USART_invert 0x02 // invert the tx and rx bits //#define USART_reset_wdt 0x04 // reset the WDT while waiting for a character in getc() // **** END OF DEFAULTS USED FOR SOFTWARE USART EMULATION **** #include <rs232_driver.h> void main() { // for the hardware UART the paramter passed is the divisor // the hardware usart enables dynamic reconfiguration of the baud rate // the software emulated USART baud rate is defined by constants in // serial_driver.h - this file alos contains the address mapping for // RAM required to support the software emulated USART uart_init(1,21); // set high speed divisor mode and divisor value puts("Hello, world"); while (1) { if (kbhit()) { putc(getc()); } } }
  3. The zener diode is approach is not suitable for your application. I thought I had already mentioned that in my initial post but having reread it I realized the omission. A zener diode has a tolerance of +/- 5% nominal (some are much worse) as well as a transfer function that varies with temperature. In addition you need to ensure you bias the diode to operate beyond the knee region. Here is a link that discusses these points: http://www.edn.com/article/CA426083.html In your application a +/- 5% tolerance means that the zener voltage variance, ignoring temperate is 2 volts.
  4. The previous responses were in context of the original question deviating from it when the original poster expressed more interest in understanding the mechanics. Once he undertands the mechanics he can choose the resolution that meets his requirements.
  5. You cannot just use a zener or you risk killing the PIC. You need to add at least a resistor from the PIC A/D input to ground. You are looking at a 4 volt range. Without using the vref inputs your A/D converter will do a conversion from 0 to + 5 volts. Assuming an 8 bit a/d converter the resolution will be 5v/256 = 19.53mv per bit. If instead you raised -vref to 1.0volts then the conversion range of the A/D is from 1 to 5 volts (4 volt range). IN this case the resolution is 4v/256 = 15.63mv per bit. If you were only interested in a 2 volt range then you could apply +3.0v to the -vref input. In this case the resolution is 2V/256 = 7.81mv per step. You could tweak the values to make subsequent maths easier. For example instead of a 4volt range, if you had a 4.096 volt range then the resolution would be 4.096/256 = 16mV per step. 16 is a nice binary number simple maths operations. What is i wanted 10mV per step? In this case you need a span of 10mV x 256 = 2.56volts.
  6. No it is not that easy. If the input impedance into the A/D input is too high, the input impedance impacts the measurement. What you want to do is relatively easy for do. It requires two resistor voltage dividers and two halves of a dual opamp. The first voltage divider is on your battery. You feed the output of the voltage divider into one half of the opamp configured as a voltage follower and the output of the voltage follower into the A/D input of the PIC. This now gives you a low impedance source. The second voltage divider comes off the + 5 volt rail and connects to the second half of the opamp also in a voltage follwer configuration. The output of this voltage follower connects to the -Vref input of the A/D. When you do an A/D conversion the converter performs the conversion over the range of -vref to +vref. By increasing the value of -vref you are increasing the resolution of the subsequent conversion.
  7. Hey sdujolo, Nice discovery, I haven't seen that but I'll certainly give it a try. It would be nice for a logging application to be able to write directly to an SD card. Anyone else playing with this? cheers Ian. I have ported it to Microchip C18, C30 and CCS compilers but not to BoostC.
  8. I developed such a bootloader for the PIC24 family which bootloads from an SD/MMC card using the FAT file system. This bootloader was developed using Microchip's C30 compiler. I intended to port it to support the PIC18F family but it requires a lot of program memory to support the FAT file system and it therefore is really only viable for PIC18F processors that have a lot of program memory.
  9. The rs232 driver rs232_driver.h (actually serial interface driver) supports either the use of an embedded hardware USART in the PIC if it has one or the software emulation of a USART. You would use software emulation if either the PIC does not have an embedded USART or if, for some reason you cannot use the embedded UART possibly because you have used the PICs supported by the hardware USART for some unrelated function. Using the hardware USART is far far far better than the software emulated USART. The e_ designation on the driver variables signifies an emulated register with the same characteristics as the corresponding physical register for a hardware USART. The software USART, which can be used on any family of PIC, was modeled on the hardware USART used in the PIC18F452 microcontroller family. If you are using a software USART, you need to tell the driver which port and which port bit is to be used for the transmit and receive pins. The following #defines tell the driver the port used for tx and rx, the TRIS setting to set the i/o direction for the specific bit and the specific port bit used for tx and rx on the associated port. #define TX_PORT 0x07 #define RX_PORT 0x07 #define TX_TRIS 0x87 #define RX_TRIS 0x87 #define TX_BIT 6 #define RX_BIT 7 If you wanted to, you can examine the contents of the emulated ports just as if they were real hardware ports. You can place the emulated registers anywhere in memory. The option USART_reset_wdt tells the driver that the wdt is to be reset within the serial handler. If you did not do this and where the application is looping waiting for a byte to be received, the WDT, if enabled, could cause the PIC to reset.
  10. The driver supports only a single hardware UART however it will definitely work with the PIC18F8722.
  11. I think you misinterpreted what the driver is telling you. I have used this driver on 16F series PICs. The I2C driver was originally designed to emulate the hardware I2C found on a PIC18F series processor. From time to time Microchip improves the various peripherals found in the PICs. The reference to the 18F2xx and 18F4xx is intended to let the developer know that the emulation closely matches the I2C found in these devices. In this way a developer can reference the hardware peripheral information for the 18F series PICs listed to understand how to use the emulated I2C driver. There is nothing to stop you using this driver on 16F series PICs. If you look at the e_xxx defines above, you will notice that e_SSPBUF corresponds to the SSPBUF register in the 18F series PIC. The e_ indicates the name of the register that is being emulated. If your PIC has free memory at say 0x40 (typical for a 16F series) then you could start mapping these addresses. For example you could have... #define e_SSPCON1 0x40 #define e_SSPCON2 0x41 #define e_SSPSTAT 0x42 #define e_SSPADD 0x43 #define e_SSPBUF 0x44 #define e_SSPIF_PIR 0x45 #define e_BCLIF_PIR 0x46
  12. Unless you really are using Low Voltage Programming (very few hobbyists are) you want LVP_OFF
  13. Forget worrying. You can achieve reliable, rock solid 115200 baud operation with this configuration.
  14. If you want a voltage free contact (not tied to PICs supply) you either need to use a relay or you could use an opto coupler (or a back to back pair of opto couplers). If you want lower current consumption than a low power relay (such as a reed relay) then you ideally want to use darlington optocouplers.
  15. I disagree. Lockup of the PIC's USART is a common trap for newbies - they waste a lot of time chasing phantom problems.
  16. Software UARTS implemented with cycle counting and interrupts are mutually exclusive. Using a RTOS does not solve the problem for such a SW UART implementation. For most applications it is not necessary to implement a transmit interrupt handler. This is a task that can (usually) be handled as a polled function from a mainline task. This minimizes context switching and overhead especially when you consider that intercharacter latency variation for transmitted characters in a asynchronous environment is usually a non issue. A general exception to this guide would be in the event that each character received must also be echoed or repeated to another asynchronous port. To minimize the interrupt overhead, ensure all variables within the handler are 8 bit variables. Clearing the RCIF flag is handled automatically when the rxreg is read. Clearing it manually (as shown above) can result in character loss in race conditions (don't do it). The PIC is brain dead with respect to its asynchronous port, in the event of an overrun error (not clearing the RXREG before the next character is received) the PIC disables the asynchronous receive logic - to avoid this problem the receive interrupt handler needs to check the error status and in event of error it needs to disable and immediately reenable the receive logic. An alternative method of implementing a rx handler is to use a ring buffer with head and tail pointers. When a byte is received it is added to the buffer -rxCapture[head++]; if (head >= buffer_size) head = 0; To determine if there is anything in the buffer then if (head != tail) // something is in the buffer ; To extract a character from the buffer: new_char = rxCapture(tail++); if (tail >= buffer_size) tail = 0;
  17. The Microchip specific issue in question was regarding the level of X-Ray radiation sheilding. But it seems he has now discovered burnt out pins are his issue. <{POST_SNAPBACK}> I suspect this is cause and effect related.
  18. Non-polarized cap and a very bad ground loop current might cause you problems. <{POST_SNAPBACK}> Some of your earlier comments describe a common latchup problem (not Microchip specific) that occurs when you have two systems that are powered independently with floating earth that are subsequently connected together without ensuring that the ground is the first connection made. 1. CONNECT A GROUND FROM THE PIC TO THE PC. Do this before powering up either system. This will avoid the latch up problem. 2. Remove the capacitor 3. Check that the power supply of the PIC to make sure you are not tripping the BOR
  19. Impressive that you did this with the MCHP stack and a possible sign of craziness :-)
  20. The PIC's CPU and the Ethernet Module compete for access to the PIC's Ethernet modules RAM. This is why the driver code has the NOPs embedded. The ICD2, when it accesses this memory, does not "know" when it should introduce NOPs and therefore when tracing with the ICDs the values return may (and often are) garbage. These implementations are not attempting to drive an Ethernet controller.
  21. I think this is a bit over the top for a PIC Microcontroller. For the amount of money spent I think a Rabbit platform would be more cost effective and versatile. I think the PIC is a poor choice for a generalised networking development platform for multiple reasons. Two problems with the ICD, Microchip have effectively superseded it and the PIC's CPU and embedded Ethernet controller have to content for access to the PIC's RAM. I wasted a lot of time debugging non existing faults before I realised this solution (ICD2 with EtherPIC) was fundamentally flawed. I use a bootloader for developing and debugging the 18FxxJ6x family. It is very effective and significantly faster than using an ICD2 with this PIC family. If you are holding on a pending ICD2 fix you are likely to be waiting for the next ice age. There are a number of challenges with the RTOS, and generalized open source approach, To be attractive to the wider community you need to support multiple compilers. While this may seem trivial in a PC environment, it is not trivial in an embedded PIC environment because there is no common hardware abstraction layer. Each compiler has their own unique approach to dealing with low level I/O. No two compilers use the same native base types. Take the obvious, an 18F series PIC's base type is 8 bits. You would naturally expect all PIC C compilers would have an 8 bit integer base type but instead you have CCS with 8 bit, MCHP with 16bit, BoostC with 32 bit etc. The challenges represented by these vastly different implementations of compilers and linkers are not insurmountable but it does tend to mean the stack would initially be developed for the largest potential market as opposed to the "general" market, in this case the MCHP C18 compiler. However, MCHP already has a free (but expensive) stack so not a lot of incentive except for developers that do not like the unreasonable licensing conditions tied to the Microchip stack. Consequently the niche market for this stack gets even smaller.
  22. If you are using an 18F series PIC then just do a reset instruction.
  23. The level shifting is for 5 volt PICs. If you look at the PIC18F97J60 reference schematic (3.3 volt PIC) you will see there is no level shifting.
×
×
  • Create New...