Flyline

Members
  • Content Count

    16
  • Joined

  • Last visited

  • Days Won

    3

Flyline last won the day on March 20 2016

Flyline had the most liked content!

About Flyline

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Flyline

    PmodMTDS

    I have attached a PmodMTDS touch screen display to a WF32 using JC of a chipKit PmodUNO Shield. Out of the box Demos 1,2,4,5,6,and 7 work as explained in the software comments in the sketch ino files. However MtdsDemo3 repeadedly reports "mtds.begin() failed". After changing line 128 from fStat = mtds.begin(pinMtdsSelStd, 12000000); to fStat = mtds.begin(pinMtdsSelStd, frqMtdsSpiDefault);, the sketch runs as expected. I find that the default SPI bit rate parameter for the PIC32MX and PIC32MZ is set to 3500000 in the library file "mtdsHal.h". My assumption is that the parameter SPI bit rate of "12000000" is too fast for the PmodMTDS. None of the these sketches will not compile if using the WiFire (Rev C).
  2. Here is some additional information. The stepper motor I am currently testing measures 1625.5 steps per revolution. Given the motor specifications of +/- 7%, that is within tolerance. Hence as published, the step angle is 5.625/25 degree +/- 7% or 0.225 degrees +/- 7%. So the steps per revolution can be from 1488 to 1720 and the motor is within tolerance. The 1625.5 steps per revolution I measured is based on the number of steps to complete 10 revolutions. I am unsure of the consistency of the step per revolution until I test more motors but I do recommend that each motor be tested before using in a precision position application. I have not resolved the "Moderating ratio" issue.
  3. This question is in regards to the Digilent stepper motor at http://store.digilentinc.com/stepper-motor/. I understand step angle as so many steps per revolution or the number of degrees rotation per step. But I don't understand the feature that lists the step angle of 5.625°/25. What does "/25" refer to? Also can you explain the feature - "Moderating ratioL 1/25". I am unfamiliar with this term as well.
  4. Dr. Jim Frenzel at the University of Idaho figured it out for me last night. His explanation goes like this: Say tStart = FFFFFFFC and (CORE_MS_TICK * mS) = 00000006 so, in the incorrect implementation: tWait = 00000006 + FFFFFFFC = 00000002 Then, if you were to immediately compare the CoreTimer to tWait as unsigned numbers the CoreTimer will look larger, even though no time has elapsed. That’s why it is critical that you first subtract tStart from the current value of the CoreTimer, then do the comparison. Applying the above scenario to the correct version tStart = FFFFFFFC. (which happens to be -4 in two’s complement) and tWait = 00000006 Then (CoreTimer – tStart) = 0, and the next tick it will equal 1, and it increments until it reaches 6 and the while loop. is exited. As I expected - the error was my interpretation of how 2's complement math works for unsigned numbers.
  5. I believe I found the issue with the PmodLCS and the SPI interface.. I was using a 1 second time delay function that reads the core timer using the code in Listing 1. After 107 seconds, this polling delay would suddenly cut short my delays thus blasting an number of LCD SPI packets in a very short interval. Even though the delay function would eventually recover, the LCD operation was compromised causing the LCD to go blank. It is no coincident that the maximum delay using the delay code in Listing 2 below is 107.374 seconds. (2^32/40,000,000 = 107.374). But this limitation does not explain the failure of Listing 1 since I was only delaying 1000 ms or 40,000,000 core timer ticks. I believe that the problem lies in my understanding of how the XC32 compiler implements the unsigned magnitude compare embedded in the while statement. Listing 1. Bad polling delay function void DelayMs(unsigned int mS) { // CORE_MS_TICK_RATE = core timer frequency / 1000 or 40,000,000/1000 unsigned int tWait; tWait = (CORE_MS_TICK_RATE * mS) + ReadCoreTimer(); while(ReadCoreTimer() < tWait); /* wait for the time to pass */ } /* End of DelayMs */ Listing 2. Good polling delay function - 107 seconds maximum void DelayMs(unsigned int mS) { // CORE_MS_TICK_RATE = core timer frequency / 1000 or 40,000,000/1000 unsigned int tWait, tStart; tStart = ReadCoreTimer(); tWait = (CORE_MS_TICK_RATE * mS); while((ReadCoreTimer()- tStart) < tWait); /* wait for the time to pass */ } /* End of DelayMs */
  6. I have been working with the PmodCLS and have completed designs for all three serial interfaces/ I used the mpide code downloaded from https://reference.digilentinc.com/_media/reference/pmod/pmodcls/pmodcls-mpide-lib.zip. The function to clear the display and home the cursor shown below appears to have an error. According to the Instruction set found at https://reference.digilentinc.com/pmod/pmod/cls/user_guide, the array should not contain the '0' character. The string should be: "uint8_t dispClr[] = {ESC, BRACKET, DISP_CLR_CMD};" void LCDS::DisplayClear() { uint8_t dispClr[] = {ESC, BRACKET, '0', DISP_CLR_CMD}; //clear the display and returns the cursor home SendBytes(dispClr, 4); // After changing the text string, the "4" in this line should be changed to "3" } Since the example code is only for the SPI interface, be sure that JP1 is in the "SS" position so the device select operates correctly. I developed three test projects using the MPLAB X IDE (not Arduino). I used the same test code that displays a count that is incremented once a second for for all three serial interfaces. I left the UART and I2C test programs run over night resulting in over 30000 seconds. When I run the SPI interface, the LCD goes blank after 107 seconds even though the PIC32 continues to send SPI data. This failure is independent on what else is being displayed. This is a curious failure mode. I am wondering if anyone else has encountered this problem. I can supply my test projects upon request but the code is written for a PIC32MX370 processor which is a PPS device.
  7. This is a newly discovered issue and is currently being addressed at Digilent. I became aware of the problem about 6 months ago when I was working with MPIDE. As to how I became aware of the solution, I have a close working relationship with an engineer at Digilent and he advised me to remove R159 as well as using the most recent core build. I and others at Digilent were unaware the issue persisted with switching to Arduino IDE. I have been told that the problem is that the new PIC32Prog (used in the Arduino IDE for chipKIT) and some MAC FTDI drivers pull RTS low as well as DTR. If R159 is loaded, and RTS goes low, RTS will hold the MCU in reset and you can not program. " Note that this only an issues if R159 is loaded on the circuit board. NOTE: This is not an issue with the depreciated Cerabot 32MX7 since there is no FTDI on the circuit board.
  8. I have successfully tested the attached sketch on a chipKIT PRO MX7 using Arduino 1.6.8 and the PIC core release 1.1.0 (See http://chipkit.net/chipkit-core-is-released-for-use-in-arduino-ide/). I have modified the attached Blink sketch to test the mapping of the board LEDs and test the serial port. Yes, you are using the correct serial port. 1. Make sure that you ave programmed the chipKIT PRO MX7 with the "chipKIT_Bootloader_MX7ck" using MPLAB X. The boot loader is available on the Digilent web site. I have also attached the hex file below. To program the bootloader with MPLAB X, you will need to attach the PC to the DEBUG USB port. After programming the bootloader, you will no longer need to be attached to the DEBUG USB port. 2. Make sure you have JP11 shorted and R159 removed (See pdf file below). 3. Before attempting to load a sketch, hold BTN1 down while pressing the reset button. If the chipKIT Pro MX7 is reset and ready to download a file, LED1 on the processor board will flash about 4 times per second. 4. This sketch sets the UART for 38.4KB - Make sure you set the serial monitor for 38400. Blink.ino chipKIT R159.pdf chipKIT_Bootloader_MX7ck.zip
  9. As I work with the chipKIT WF32 and the WiFIre, I find that making external connections to these processor boards is not as convenient as they are for the chipKIT Pro MX7 that has Pmod connectors JA through JF. Additionally there are limited pins for taking 3.3V/5V and ground off board. I can only assume that these chipKIT boards were always intended to be used with a shield of some sort. If Digilent makes IO shields specifically for the WF32 and WiFire, please advise. Meanwhile, I find the the Pmod Shield-Uno can be used to provide standard Pmod connections provided a few modifications are made. 1. The bottom side female connectors for JP6-JP8 must be removed because the USB connector J13 on the Wf32 and WiFire are in the way. This is easily done by gently bending the female connectors on the bottom of the Shield-Uno back and forth until they break off at the surface of the PCB. The schematic diagram for the Pmod-Shield does not show a connection for the center pin of JP6 and JP8. Can I assume that since JP6 and JP8 do not feed through to the WF32 or the WiFire that A04/A18 and A05/A19 are not functional? 2. I observed that pins 1 and 2 of J3 on the WF32 / WiFire have no connection to J5 on the Pmod-SHield. This appears not to be an issue since J3:1 is not connected and J3:2 has jumper to J3:4. 3 J6 of the WF32 / WiFire has no connection to the Pmod-Shield making connections to I2C2 unavailable. I could not find a secondary connection for SCL2 and SDA2. 4. Although the majority of the processor programming is done in the Arduino IDE environment using the serial port, there are times that debugging with the MPLAB X IDE is beneficial. Hence, I permanently soldered a single row right angle 6 pin header in JP2. This allows me to slip on and off a chipKIT programmer without removing the shield. Do you for see any problems such as RFI emissions? 5. Reading through the Pmod Shield-Uno users manual I see that the signal names for JA and JB are the same. The chipKIT pin numbers appear to be correct. Digilent should update the users manual.
  10. Thanks Sergiu, I missed that even though I did a text search on the reference manual. I found the answer to my own question by searching the Arduino hardware/PIC32 files. I am not using mpide but the PIC32 core with the arduino IDE. The answer to my question is to be found in the file Boards_Defs which contains the following define statements.. /* Define the pin numbers for the LEDs */ #define PIN_LED1 13 #define PIN_LED2 86 The full path to the C:\Program Files (x86)\Arduino\hardware\chipkit-core\pic32\variants\Max32/Boards_Defs.h The pin number "86" is declared in C:\Program Files (x86)\Arduino\hardware\chipkit-core\pic32\variants\Max32/Boards_Data.c in the section'identified as " //* Pic32 EXTRAS start here (with #70"
  11. I am working with the MAX32 board and want to control LD5. The schematic shows that the control for this LED is connected to RC1. However, the Reference guide (and the Excel pinout table show this as not assigned to a chipKIT pin number. If I were working with XC32 and the MPLAB X IDE, I would simply write TRISCCLR = 0x01; and then use LATCSET and LATCCLR to turn the LED on or off. What are my options if I want to stay in the Arduino IDE format? .
  12. James, I finished the Hen House project using a Core build that hasn't been released yet. For once I am ahead of the tools. I have been working with Keith and he may know when the Core build will be released. Now it is on to the WiFire. I may stop by tomorrow and give you a demo. Richard
  13. Hi James Yes, I have invested considerable time developing a HTTP server around the Arduino chipKIT Core. (In fact, I'm working on it right now.) I had a build working when Keith sent me into a spin with a new core build last weekend. The new SD file system is all different and I use that heavily. I hope to have a completed "up to date project this week. I want this project to work on the WiFIre, the WF32 and the chipKIT PRO. The problem with the old core is that it wouldn't program the chipKIT PRO. I'll keep you posted. Richard
  14. I recently successfully completed a web server application for the chipKIT WF32 using the Digilent IP stack with the Arduino IDE. I wanted to see how difficult it would be to port the same web server application to the chipKIT PRO MX7 processor board. There appeared to be only a one or two lines of code that had to be commented out to make the conversion. The The Adruino IDE reported "No target found". So I backed off to the simple "ChipKIT_Blink" sketch and had the same result - "No target found". I reverted to the MPIDE environment using the same hardware and the sketch loaded and ran correctly. So I'm thinking the problem is with the Arduino IDE or the chipKIT core library. I am using Arduino rev 1.6.5 and chipkit-core-windows.16778041.v1.0.0-21-glc4b889.zip. Keith recommended removing R159 (no easy task for an older person and glued down R402 resistors.) Has anyone had any success programming the chipKIT PRO MX7 using the Arduino IDE?
  15. This is not so much a question as an observation. The pin assignments for the chipKIT boards can be the source of considerable confusion. With respect to the WF32, the on-board LEDs are labeled in the reference manual as LED3 through LED6. Normally the file "mpide\hardware\pic32\variants\WF32\Boards_Defs.h" maps these pins to chipKIT PIN_LED4 through LED1 (note the reverse order). To further add to the confusion, the WF32 Reference Manual incorrectly states on page 7, "In addition to the connector pin, Pin 13 also connects to the user LED LD3". The connection should be LED LD6 as correctly stated in Section 10.7 on page 12, The Pinout Table on pages 14 also correctly associates chipKIT Pin 13 with LD6. I revised my version of the Boards_DEF.h under the WF32 definitions to add the following define statements so the LD designations match thoes on the WF32 documentation: // #define PIN_LED3 48 - redefined below // #define PIN_LED4 47 - redefined below /* WF32 board LED lables */ #define PIN_LED6 13 #define PIN_LED5 43 #define PIN_LED4 48 #define PIN_LED3 47 Board_Defs.h