PIC32-EMZ64 Christmas tree lights ?

[Heinz]

@kyrk.5 On eBay you can get cheap USB-CAN interfaces (app. 20 €). OBDI Interfaces are availlable too.
I would not go for this project with very expensive soft- and hardware by Vector 

[KeesZagers]

My problem is like Heinz said on a lower level than reading and writing CAN messages; it is simply getting the CANcontroller into the operational mode. If you read the Control register (*(unsigned long *) (0xBF88B000)) you can see it is in the configuration mode. You can change this mode to operational, after you have set the bitrate, FIFO's, etc. This worked perfectly in the MX controllers, but at the MZ I see that the request has been set, however the real status does not change. As long as this is not changed you will never be active on the bus. Like I said in the other discussion about the hardware, I doubt the hardware. Anyway there are two differences in the connection to the MCP2551, where at least the so-called CAN-CTRL pin is definitely wrong connected.

[kyrk.5]

KeesZagers: Please see my comment in the other topic that I made some days ago:
Re: PIC32-EMZ64 schematic
« Reply #23 on: December 13, 2016, 10:20:31 PM »


The mode change was working for me fine, however I did set any baudrate or sampling stuffs or whatever. That is why I started to think about how I could create a working CAN bus, where I can connect with the PIC32-EMZ64 to send and receive CAN messages.

Why do you think that the CAN-CTRL (Rs pin of the MCP2551) is connected wrong? My understanding is that applying here a High Level would send the MPC2551 into Low power mode. TriState would enable the Slope Control and a LowLevel would just select High speed.

[KeesZagers]

If you read the datasheet of the MCP2551 you can see that the RS pin has two functions.
1. Connect a resistor (default 10k) to ground. Another value of the resistor will influence the slope control.
2. As an alternative you can also connect the other end of the resistor to a higher voltage (3.3 or 5V), which will set to the transceiver to a sleep mode (low power). Any message on the bus will wake it up again.
So I guess that the CAN CTRL was meant to have the sleep possibility, however in this case the connection had to be on the other side of the resistor. Anyway I set the CAN CTRL to tri state which is the default situation and in that case I measure a voltage between 1 and 2 Volts. This is the same as I measure on the Duinomite modules.

I will read the other message and react on that too.

[kyrk.5]

Now I understand what do you mean why the wiring of this pin might be wrong. To be honest I am not able to decide from the available information what kind of wiring should be used here.

On the internet a lot of schematics simply connect this Rs pin to ground trough a resistor, and no uC pin is attached to it.
In the datasheet there is not example schematic.
I found one schematic on the internet, where there was a resistor and the Rs pin was connected to a uC pin trough an other resistor.
From the datasheet I think it is allowed to drive the Rs pin with voltage:
http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf
please see page 10. Standby/Slope-Control: Here sleep mode is determined with a minimum voltage. From this I would thing that the olimex solution is not bad. In TriState the Slope Control mode is active, when the uC Pin is output and High then sleep mode is entered. When Low then High Speed mode is entered.
While on page 4, table 1-1 is giving the impression that the mode change is done one current base.

Here is an interesting post:
http://www.microchip.com/forums/m637386.aspx
I think this might be the reason why your solution would be better (Rs pin to resistor and other side of the resistor goes to uC pin):
tom_usenet: "From what I'm reading you shouldn't connect the pin through a resistor to ground AND drive it from a CPU as the CPU will then be driving current into that resistor when it drives the pin high. That would be wasting current when you are trying to be in a low power mode. You should connect the resistor from the MCP2551 to the CPU pin. Drive high for shutdown and drive low to enable (and set the slew rate). "

In fact in low power mod applicaton every mA and uA is counting. Wasting current over a resistor is a no go

This change might be a point for olimex to improve the product in the future.

[JohnS]

Looking at the datasheet I think you want the Rs signal low, so drive the uC output low.

Right now you just want anything that lets packets transfer

(You could tie it to gnd but then must make sure the uC pin is never an output or you'd be shorting it out.)

The MCP2551 datasheet does strike me as one of the common type that's written ONLY for hardware engineers, with no thought to anyone else such as someone writing software.

I think the 10K resistor on Rs will do what you need but only if you make the uC pin an input.  If it's an output you need to set it low.

John

[kyrk.5]

Christmas is coming... So it is time to relive this thread

How did you use the EMZ64 board in the last half year?
Did somebody implemented a Christmas Light?
Some other intresting projects?

I am working on a CNC machine home project, so I grabbed the GRLB library from Arduino and ported to PIC32. First I have started with the Pinguino board - where a PIC32MX is present - and added a GRBL Shield that I have got from Ebay. After some day of porting the GRBL is was really moving the motors. Then I was thinking to give a try for the HMZ board. There is a PIC32MZ, everything went well expect that I need to change the USB stack. So from Harmony I just extracted a new one and added it to my project. Also I worked a lot on the Eeeprom Emulation. Now comes the EMZ64 Part
Often I need to test without a real machine, just with the Embedded HW. For this I use Pinguino-Micro and a EMZ64 board. They are on my desk all the time and easy to grab them. I consider to use the LCD for some displaying. Maybe positions or something like this. Lets see

I have noticed that my PC with ICD3+MPLABX debugging PIC32MX-s are far to slow. Not sure why, but for me it is completly unusable, a single step takes several seconds and I hear the CPU Cooler to spin up and down. However the MPLAB8 and ICD3 is still fast but it does not support the PIC32MZ only the older PIC32MX. As a workaround I have bought a JTAG-Edu, that is much faster. I think a slow development environment will let the users to change for other microcontroller. For me it was a big problem and give me headack because I was not able to even step trough my Code normally.
Any way, microchip does not seem to have groundbreaking new uCs. I wonder when they will have a multi-core controller.

The EMZ64 have an ethernet connector, sadly I have only WiFi in my flat. Now I plan to lay some CAT cables, because the neighbourd is full with WiFi. This would be a good time to test the Ethernet part of it. Sadly this and I think the year before where the ESPs coming and since they offer WiFi it did not make any sense for me to play here on the Ethernet. I wonder when Microchip will come out with a uC+WiFi. I used the ESP with a Pinguino Micro over the AT interface. It had so much bugs, so it took a while for me to implement a rock hard and roboust AT stack that does not freeze every second day.

The Audio part: I made my MP3 player for this EMZ64. I think I had only problems to drive the output, because the PWM module was not performant enough to generate high frequencies. I hade to make a trade of between bit resoulotion and frequence. While it is playing music but it is not in CD quality

[KeesZagers]

Nice to start this item every year again at XMas time :-)
As you probably remembered I wanted to use the PIC32EMZ64 with the CANbus communication. I succeeded in getting it operational. After that I was thinking what to do with it as CAN module. As the module does not have a lot of I/O, except of the audio, I thought I better wait for the planned PIC32EMZ144....... I guess this year my two PIC32EMZ64 modules will end up in my XMas tree again.

[JohnS]

In case you didn't know, a 144-pin (& other) board is mentioned in this thread:
http://www.thebackshed.com/forum/forum_posts.asp?TID=9449

It's not aimed at CAN but might do (I expect may need a different variant of the MZ).

(They can be bought built I believe and I expect with your own choice of MZ if needed.)

John

[KeesZagers]

Thanks John. As far as I have seen, no CAN support yet. And I must say, 90% of my CAN projects can be realised with the MX version of the PIC32, so the range of duinomite products are still good enough. What would be more of interest is a PIC32 with CAN-FD support, but that is not planned by Microchip yet.

[JohnS]

I expect you can have CAN by just fitting a PIC32MZ which has CAN (and a bus interface chip).

I think you're right that there's no PIC32MZ (or MX) with CAN-FD.

Maybe there's CAN-FD for the RPi.

John