tom21091

Digilent Staff
  • Content Count

    160
  • Joined

  • Last visited

  • Days Won

    13

tom21091 last won the day on August 19

tom21091 had the most liked content!

3 Followers

About tom21091

  • Rank
    Prolific Poster
  • Birthday 02/10/1991

Profile Information

  • Gender
    Male
  • Location
    Pullman, WA

Recent Profile Visitors

2390 profile views
  1. tom21091

    DMC60c CAN Bus

    Yes I think so. As long as the controller ACKs the messages coming from the DMC60C it will continue to send the messages.
  2. tom21091

    DMC60c CAN Bus

    DMC60C is 1MBps. No, those green and yellow wires are connected together, either CAN or PWM, not both. The DMC60C must be connected to a CAN bus controller to send out the periodic messages. Otherwise it will flash red. When it detects a CAN bus controller the LEDs will flash Yellow (by default). -Tommy
  3. Default Device ID is 0, Current limit is disabled, continuous current limit 40A, peak current limit is 60A, current duration is 500ms. There is no voltage limit? All parameters and their defaults can be found in the DMC60C CAN Protocol Guide.
  4. tom21091

    DMC60c CAN Bus

    Hi opethmc, The current and voltage information is reported by the DMC60C every 100ms (by default) in the STSANALOG (0x020614C0) frame. This info can be found on page 28-30 of the CAN protocol guide. Fault status can be found in byte 4 (fs2) in the STSGENERAL(0x02061400) frame that is sent every 10ms (by default). You can find the fault counts by reading parameters 51 through 57. This can be done by sending PARAMREQ (0x02061800) frames containing the parameter you want to read, then scanning for a PARAMRESP(0x02061840) packet. This info can be found on page 12-28. Hope this helps! Tommy
  5. Hi Brian, Unfortunately there is no easy way to slow down the packets transmitted by the vcmdGetDescriptors command without changing the firmware. It sounds like this is more an issue with the CANable device. I don't think there is much we can do for you here. -Tommy
  6. Hi Kabron, I just tried installing both Digilent and ESP8266 board support packages and it seems like mine installed just fine. In your post on the VM forums, it sounds like they both work in Arduino, but not in Visual Micro. Is that the case? I do not think it has anything to do with the Digilent core. What happens is Arduino reads the json file from the URL you give it. It then downloads each component as .zip files into %localappdata%/Arduino15/staging/packages/ . These are then unzipped and placed in %localappdata%/Arduino15/packages/Digilent. That is all it does. I'm guessing Visual Micro just calls into Arduino to do this. In your case you say it tries to install the package into Arduino15/packages/Digilent/tools/xc32-tools/xc32-1.43/pic32mx/. I'm not sure why it would do this, but it probably has something to do with your Arduino installation. You might want to try cutting the esp8266 folder from Arduino15/packages/Digilent/tools/xc32-tools/xc32-1.43/pic32mx/ and pasting it into Arduino15/packages/ Otherwise, I would try reinstalling Arduino, or possibly trying another version of Arduino. Hope this helps! Tommy
  7. Hi Gaston, It looks like your CAN receiver doesn't have interrupts enabled. Try adding the following to the RX code, just above the readRegisters function in main() mcp25625_setRegister(MCP_CANINTE, 0x3);//Enable read buffer full interrupts mcp25625_setRegister(MCP_CANINTF, 0);//Clear interrupt flags Hope this helps! -Tommy
  8. Hi @victory460, James was correct, it is an issue in the source code for the SoftwareSerial library. The PIC32MZEFG100 does not have an SIDL bit in the CNCON register like the older chips. You can get around this by commenting out those lines in SoftwareSerial.cpp for now. I have added an ifndef line to fix this in the Digilent Core v1.0.4 which i just uploaded. Hope this helps! Tommy
  9. Check out this project on Instructables. It's doing exactly what you're talking about.
  10. Hi Philip, Thanks for pointing that out. It must have slipped past when I was transferring files over OSes. The checksum and file have been updated and should work now. If you still get the CRC error, delete the old xc32-tools found in /users/[name]/Library/Arduino15/staging/packages and try again. Thanks, Tommy
  11. Hy,

    Sorry to bother you. I've seen that you've been working with  PmodOLEDRGB.

    I tried to make the tutorial "Getting the PmodOLEDrgb to work on Zybo" available on the instructables.com website to work for Zedboard. When I program the FPGA and run the application nothing gets displayed on the OLEDrgb Pmod.

     

    Are there any setup steps that need to be done?

    I have no error messages and no warnings.

     

    Best regards,Cris

  12. Woah, I apologize for not getting back sooner. I thought I had responded to this a while ago! All you need to do to update the firmware is run the sketch https://reference.digilentinc.com/_media/chipkit_uc32/updbluc32.zip in MPIDE. This will update the firmware to be used in Arduino IDE WITHOUT the use of a PicKIT3 or another debugger. Open the sketch and program your board. When it is programmed, open the serial monitor and follow the instructions there to install the firmware update. Hope this helps!
  13. Hi testweenie, I would love to see this feature as well, although I'm not sure if it will be possible with this release. I'll forward this to our engineers and see what they have to say.
  14. Hah, my bad, deleted my first post. I'm not sure if it would make any difference, but you could try scoping it in Scope mode. There you can add a digital channel, but it will still sample at whatever frequency you have it set to sample at. You might try making a measurement script in the scope mode as well, although I've never tried it before. I would imagine that you can log the data every 8 clocks and save it to a file. You could also try logging the data in the logic analyzer with a high sample rate. You can find this in View>Logging. I would suggest simply slowing down the clock speed when debugging. Hope this helps!
  15. tom21091

    Xilinx AXI_GPIO Bug Fix

    In Vivado versions 2015.X-2016.2 there is a bug in the AXI_GPIO Core when adding a board part to the GPIO2 interface on the AXI_GPIO IP block in Vivado IPI (block design). You may get the following error: [IP_Flow 19-3452] Invalid long/float value '16]' specified for parameter 'GPIO Width(C_GPIO2_WIDTH)' for BD Cell 'axi_gpio_0'. To fix this go into Vivado/2016.2/data/ip/xilinx/axi_gpio_v2_0/xgui/axigpio_v2_0.tcl and remove the extra ']' at the end of line 246. Hopefully Xilinx will fix this small typo in the 2016.3 release. Hope this helps!