DerekM

Members
  • Content Count

    15
  • Joined

  • Last visited

About DerekM

  • Rank
    Member

Recent Profile Visitors

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

  1. @canisio, If you're interested, I also have a range of projects which use Pmod JF on the Zybo-Z7-20 as a GPIO test header: https://github.com/der-mur/book1-zynq-intro/tree/master/step-by-step
  2. I don't think the above is going to work either. Every time a task runs, the mask gets set to 0xF8. Edit to add: What you're trying to do is difficult because the OS will often change settings in the background. Surely there must be a way to do what you want using the FreeRTOS API?
  3. I am of course missing the point that you don't have easy access to the SCUGIC instance pointer. So instead, try to change the priority mask directly using Xil_Out32(). I had a quick look at this in FreeRTOS, and I think it is working (unless something else changes it later in the background.) printf("\r\nXSCUGIC_CPU_PRIOR_OFFSET = 0x%08x\r\n", Xil_In32(0xF8F00104) ); Xil_Out32(0xF8F00104, 0xE0); printf("XSCUGIC_CPU_PRIOR_OFFSET = 0x%08x\r\n\r\n", Xil_In32(0xF8F00104) ); // FreeRTOS code: xTimerStart( xTimer, 0 ); /* Start the tasks and timer running. */ vTaskStartScheduler();
  4. Does the fact that you are using FreeRTOS lock you out from changing the priority mask by normal means? For example, in a bare-metal application, when you configure your GIC you can just add the following code to change the mask: uint32_t reg_data; reg_data = XScuGic_CPUReadReg(p_XScuGicInst, XSCUGIC_CPU_PRIOR_OFFSET); printf("\r\nXSCUGIC_CPU_PRIOR_OFFSET = 0x%08x\r\n", reg_data); XScuGic_CPUWriteReg(p_XScuGicInst, XSCUGIC_CPU_PRIOR_OFFSET, 0xD0); reg_data = XScuGic_CPUReadReg(p_XScuGicInst, XSCUGIC_CPU_PRIOR_OFFSET); printf("XSCUGIC_CPU_PRIOR_OFFSET = 0x%08x\r\n\r\n", reg_data); (
  5. Okay, worked it out. Quite simple in the end (if somewhat annoying): When jumper JP2 is fitted, the MicroBlaze is being reset when Python/LabVIEW/etc access the COM port. The issue goes away when the jumper is removed. So it's a feature, not a bug 🙂. (A statement I've used many times in the past.)
  6. DerekM

    Pmod USBUART

    A quick answer is that you don't care about RTS/CTS as long as the component you are communicating with doesn't use them either. Just ignore them (unless someone from Digilent tells you differently!). Also, I think you may have the data_out pin connected to the wrong Pmod pin. In my testing with an AXI Uartlite on the Arty, the outbound data is connected to pin 2. So if Tx isn't working on your current configuration, remap it to pin 2.
  7. Hi, I have a strange problem when trying to communicate with the MicroBlaze processor on an Arty A7. Basically, Uart communications is fine when using Tera Term for basic printf messages when the application is downloaded to the board. However, as soon as another application is used to open the connection to the Com port (with Tera Term disconnected, obviously), the processor halts or possibly goes into a reset state. The issue does not occur when I use the Pmod USB-Uart to do the exact same thing (i.e. view messages using Tera Term on start-up, and then communicate with a command handler
  8. I can't explain the exact differences, but my understanding is that GDB is the legacy GNU-based debugger that was used in the early versions of Xilinx embedded tools. This is from around the mid-2000's when IBM PowerPC 405/440 (hard) and MicroBlaze/PicoBlaze (soft) processors were used on Xilinx FPGA's. Then around 2014, they also introduced their own new TCF-based debugger which was called Xilinx System Debugger (XSDB). It's still quite similar to GDB, but because Xilinx have more ownership over it, it's better developed/supported, and they recommend that you use XSDB (even though I'm sure th
  9. Spotted the issue by looking through your code; I just needed to enable the OSC_EN bit of the GENERAL_CFG_B register (0x4D). Column lines are driven low as expected now, and the row/column lines are switching correctly for key presses. I can carry on with the rest of my code now. Thanks a million for your help, really appreciated! Regards, Derek.
  10. Thanks for the reply Jon. Your set-up looks very similar to mine (all-be-it I have a different platform i.e. the RPi, but that's only related to the I2C comms which I know is working on my set-up), so this is promising. I'll look through the MPIDE code and try to reverse-engineer it for my purposes. I'll post back if I can get this working (or not). Derek.
  11. Hi, I'm currently having some trouble in getting the PmodIOXP and PmodKYPD to play well together. Separately, I have no issues in running either Pmod in a standalone fashion e.g. I can run the PWM output on the PmodIOXP with no issues, and I can drive the PmodKYPD correctly using the GPIO outputs of a Raspberry Pi. So I know there are no problems with either Pmod. However, when I connect the KYPD to the IOXP (via J1) and configure the IOXP for what I think is correct KYPD use, the column lines never go low as is standard for matrix switch operation. This means key presses cannot be detected by
  12. Apologies for the delay in replying. Yes, I've checked out loads of relevant Digilent code and they all indicate that the encoder rate is 3 pulses/revolution. But I am convinced that on the 1:19 motor I have, the rate is 1 pulse/revolution. From some datasheets I found, I think that this particular motor comes with a rate of 1 or 3 pulses/rev, so perhaps I just happen to have the model that does 1 pulse/rev. It's not a big deal at all though, don't feel like you need to follow up on this. But I would be interested if someone else thinks the rate on their 1:19 motor is 1 pulse/rev, just for my
  13. No problem. I'm happy that I have the direction issue sorted, but after some experimentation I'm not convinced that the encoder is outputting three pulses / revolution. I've set the motor running really slow (60RPM), and I can obviously count the revs at this speed (and indeed there are 60revs/minute). But on the scope I can see the sensor outputs also running at about 60Hz, which indicates one pulse / revolution. If it was three pulses/rev I would expect a frequency of 180Hz. Also, when I run the motor with regular settings (say, 2kHz with 50% duty-cycle), the sensor frequency is about 5
  14. Thanks, that makes sense now as regards the direction (active-low for CW, not active-high as I thought). Just fyi, it was this page that confused me. It says "To drive the motor at a specific speed, users will need to choose a static direction (forwards or backwards corresponding to high or low voltage) on the Direction pin", which I took to mean high = forward direction. Also, I think the block diagram for the PmodHB5 circuit on that page shows an incorrect mapping for M+/M- (M+ should be pin 5, M- should be pin 6). That also added to my confusion as regards direction. Thanks again for t
  15. A couple of questions/comments on the PmodHB5 and 1:19 Gear Motor combination, which I've been playing around with: 1. Is the motor direction being set correctly? It looks like when you set the DIR pin to high so that the motor will spin in a forward (CW) direction, the motor actually spins in a CCW direction rather than CW. Also, if you check the Sensor A and Sensor B signals in this case, it looks like Sensor B signal leads the Sensor A signal by 90 degrees, again indicating a CCW direction. Possibly I'm misinterpreting something here, but can you please clarify that the direction is be