Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. We are a formal Microchip Development Partner. This gives us access to Development and other key sources to assist us.
  3. Sadly, the debug protocols for PIC16, PIC18 and AVR have never been published.
  4. Will look into this. Thank you,
  5. OpenOCD is not really CPU specific. It supports debugging via GDB. It allows you to set breakpoints and single step the code. This is all the stuff you had to implement already. If you have GDB support via OpenOCD for the programmer you will be able to use it with IDE's such as VSCode, Eclipse etc. to debug the device.
  6. Interesting - does Open OCD support LGTs, PICs and AVRs?
  7. We have been pondering doing something like this for ages. Bonus points if you can debug using Open OCD using that thing !
  8. PICKitPlus Many of you will have used or may be using Microchip’s PICkit2 and PICkit3 in-Circuit Debugger/Programmers. Our PICkitPlus software is a total replacement for the original PICkit 2 and PICkit 3 software. It has many new capabilities designed to facilitate programming of 8-bit PIC microcontrollers using a genuine or clone programmer.. Our software provides support for the newer 8-bit microcontrollers, and, we maintain support for old chips and new chips. The PICkit2 programmer was released back in 2005, and allowed the user to program and debug most of the 8 and 16 bit PIC microcontrollers and dsPIC controllers as well. Its successor, the PICkit3 programmer, was released some years later. In 2009 and 2012, Microchip stopped providing support for the PICkit 2 and PICkit3 software , respectively. They released the source code for the Windows GUI software, making it possible for users to update and maintain it themselves. This resulted in the launch of the PICkitPlus software in 2018 by the PICkitPlus team. We are now in 2021 a Microchip Development Partner - which is good recognition of our work. We provide PICkitPlus software for Windows, Linux and PIs. For all operating systems we have command line utility, and for Windows we have PICKitPlus GUI for the PICkit 2 and PICkit 3, PKEasy, PKAutowatch and PICkitPlus Gang Programmer. Supporting nearly 1000 PIC MCUs, includes PIC10F, PIC12F, PIC16F, PIC18F, PIC24, PIC32, dsPIC30 and dsPIC33 family Manages Microchip HEF and SAF memory Retains support for programming CAN I/O Expander & KEELOQ series: MCP2502X/5X & HCSxx Retains read and write operation for serial EEPROM 11LCxx, 24LCxx, 25LCxx and 93LCxx Supported operating systems (32bit/64bit): Windows XP ,Windows Vista, Windows 7, Windows 8, Windows 10, Linux and Pi New programming protocols support for new classes of 8-bit Microchip PIC microcontrollers Updated and managed database for Microchip PIC microcontrollers Improved user interface, help, guidance and direct access to the 8-bit Microchip PIC microcontroller database. Supports TURBO mode to decrease time to program and verify ---- If you have the original Microchip software you can use our improved database - this will give you new legacy parts and you can get the corrections for the existing legacy parts. If you new support for the newer Microchip PICs - you will need PICKitPlus. We have new capabilities that just do not exist in the old Microchip software. ---- To see all our software and hardware. See www.pickitplus.co.uk. If you are interested - ping me a message I we can provide a microforum discount for a few months! Cheers, Evan
  9. Earlier
  10. The way I2C works when you add a second device no changes should be required in your configuration. If the working address stops working it is usually either because of multiple devices with the same address or it is due to an electrical problem. Could be the capacitive loading on the bus or even reflections if you have a star with long lines without termination (could also be incorrect size of or even missing pullup resistors). What I would suggest is to try and reduce the speed after ensuring that you have different addresses. Also look at the lines with an oscilloscope and check to see if the bus is being pulled down (ACK) after the address. If not no device is recognising the address.
  11. Im not sure which problem im having actually but I have one stm32 device as a master and i have two peripherals( 1 is OLED and then other is an Stm32 device(same product number)) and I am trying to get the master to recognize both peripheral addresses; however, when the OLED is only connected the address is found but when i also connect the stm32 device both address are not found and the debug keeps running.. im not sure if its an bus problems (#4 or #5) or is my initialization wrong even though I have followed the datasheet thoroughly and have set the address properly... hopefully anyone else has experienced this and figured out a way to fix this please let me know
  12. Evan, This sort of news sounds very pertinent to the members of this forum. Please show us your technology!
  13. Hi guys. This is Evan Venn - UK developer of Great Cow BASIC and PICKitPlus software. Question: What is the right etiquette for posting? I am asking before posting. 🙂 1. I can share release news, progress and updates on Great Cow BASIC. Great Cow BASIC is an open source compiler for Microchip 8-bit PICs & AVRs and Logic Green Technology PICs & AVRs. Is there interest in the news, progress and updates on Great Cow BASIC? 2. I can share release news, progress and updates on PICKitPlus. PICKitPlus is the software to support PICkit2 and PICkit3 programmers across Windows, PI, Mac and Linux. This is a low cost but commercial product - so, not free. Is there interest in the news, progress and updates on PICKitPlus? I would want to share as we are adding new capabilities almost every month and we have an ever grown user base.
  14. You have mis-interpreted the table, each row is meant to be independent. I thought the same thing, until I realized that the columns were not to be taken as a whole, but just defining low, medium, or high for each independent category column.
  15. I have also catalogued a number of typical I2C errors including typical addressing errors in this blog post
  16. Was any solution found? I note the CONFIG bits have not been shown. The chip will not run if the oscillator has not been set up correctly, and it will be rapidly resetting if the WDT has not been disabled.
  17. I've decoded your scope plot. The first one looks right, but note you get a NAK back, which simply means no device feels addressed to respond. The second one is shifted by one with an added 1, this doesn't seem to be right according to the datasheet. What about the A0 and A1 pins? Look here: The A0 and A1 pin will determine the address, the default case seems to be an internal pull up, so A0 and A1 are both 1, not 0. Might this be the problem why the chip doesn't react?
  18. Hello, I am trying to communicate with an MCP4441 chip using the I2C interface and using an Aardvark I2C cable from Total Phase. I am trying to read the registers which have non-zero default values (2,3,8,9), but always get back 0. It appears from the data sheet for the part that the control byte should be 0x59 is A1:A0 = 00 (see attached page from datasheet) I have attached scope captures of SCL and SDA when I tried setting the write and read address to 0x59 and 0x2c. Both of these attempts read back 0. Any ideas on what I am doing wrong? Thanks.
  19. I think the list will complete with books on networking protocols. TCP/IP Illustrated, Volume 1 by W. Richard Stevens I found this to be one of the best books to understand how Internet protocols work. I have read the first edition, have not read the second one. Companion book on Unix socket programming, I like the first edition which is very concise, but expects a lot of Unix background. Unix Network Programming, First Edition by W. Richard Stevens Or subsequent edition, if you want more explanation, equally good. Unix Network Programming, Volume 1
  20. Perhaps I can explain it better with an example. If you wrote code like this, which is using a non-compound literal int i = 7; where do you expect the 7 to be located in the map file? Of course the correct answer is that it gets encoded as part of the assignment code, so it would end up in the TEXT segment with the other code, but there is no rule for this, if this is an auto variable it will just be in the TEXT segment, if it was statically allocated though the compiler may, as an optimization, copy variables in bulk into the ram location of i, but I would say even in that case it goes in TEXT. The problem is not whether or not the literal is valid C or not, of course it is valid, but I think your expectations of where (or perhaps more accurately IF) memory is allocated for the struct are not quite right. I think if you look at the ASM generated for your initializer it will make more sense. In the Microchip PIC's I spent a lot of time on your initializer would compile to something like this MOVLW 2; MOVWF actualCat MOVLW 17; MOVWF actualCat+4 Now if you have code that takes the address of that, it will actually return the address of what? Perhaps the instruction MOVLW? This is dangerous because it will not necessarily behave the way that you expect. If you do a cast like you are doing, depending on the implementation in the compiler it may create a temporary variable on the stack, and then return the address of this temporary variable. This is also dangerous because although your allocation will work the pointer will not be valid later in the application, and even if you test it and the memory is still intact it may be deemed fair game to the compiler to hand out to someone else at the time, in that case it is dangerous as you are pointing to unallocated memory and will get undefined behavior (even in C++). Yes of course I am also using designated initializers in the examples in the article above, I agree that they work great (not only on small devices, on all devices), but of course you lose control of the memory allocation if you do it the way you are doing it (specifically casting the anonymous struct and then taking it's address) because if you start casting things you better know what you are doing because casting == telling the compiler you know better than the compiler - never a great idea 😉 I generally avoid designated initializers though since it was only added in C99 and many compilers from embedded vendors do not yet support them so I always run into portability problems when I do that.
  21. Hi Orunmila. Thank you for the quick reply. The initialization is using something called 'Compound Literals'. It's perfectly valid according to the GCC documentation, but beware, it can be 'dangerous' if you're using C++ (I'm not). Unfortunately, the GCC documentation does not seem to mention how to ensure the compound literals to be in a specific section. -But if anyone would know these things (apart from the compiler developers), it would be developers of embedded software like you. ;) Here's a link to an example, which you may find useful, because initializing this way is really beneficial on small devices: http://nickdesaulniers.github.io/blog/2013/07/25/designated-initialization-with-pointers-in-c/
  22. You are initializing the structure using an anonymous structure which is not specified to be located in a specific setion. I have not investigated it any further but I think it might actually be dangerous to take the pointer of an anonymous struct like that because I believe it will be allocated on the stack and it will not be obvious when the memory is being freed (although I may be mistaken here, it still looks dangerous to me). I think what you should do is something like this #define BOB_SECTION __attribute__((section(".bob"))) #define FRANK_SECTION __attribute__((section(".frank"))) struct Cat { uint16_t heads; uint16_t tails; }; FRANK_SECTION struct Cat actualCat = { .heads = 2, .tails = 17 }; BOB_SECTION struct Cat* gNeelix = &actualCat;
  23. I have a pointer to a structure and would like to initialize this to point to a structure. The pointer itself should reside in one section, while the structure's data should reside in a different section. The following example puts the pointer in section '.bob', but how do I ensure the structure data is inside section '.frank' ? #define BOB_SECTION __attribute__((section(".bob"))) #define FRANK_SECTION __attribute__((section(".frank"))) struct Cat { uint16_t heads; uint16_t tails; }; BOB_SECTION struct Cat *gNeelix = &((struct Cat){ .heads = 2, .tails = 17 }); -I've tried placing FRANK_SECTION in every place I could think of on the right hand side of the assignment, but I have not succeeded finding a way to get this to happen. What I'm trying to accomplish would be something like the following, but as a pure initializer: FRANK_SECTION static struct Cat sNeelix = { .heads = 2, .tails = 17 }; BOB_SECTION struct Cat *gNeelix = &sNeelix; Am I so lucky that you have any pointers ? :)
  24. This really is a nice little program to confirm operation of the xpress board! I forgot to check the stdio redirect option in for the eusart module in MCC and so was stuck for a couple minutes! One question is with regard to how the uC is programmed. Does the program go into ram on the xpress board? I have not looked in depth yet, but the program seems to go away when the board restarts. Keith
  1. Load more activity

  • Create New...