I was at the Embedded World and received my free PIC32-EMZ64. Very nice and very compact. And indeed powering it gave nice random LEDs burning and a horizontal and vertical line moving over the OLED display. I even had some control over the LEDs by some buttons. I'm now wondering if I have to wait until Christmas to hang it in the tree or if I can get some links on the Internet concerning the schematics and the software to start something a bit earlier with this module.
Kees
Same for me! :) I was even thinking on to start to reverse-engineer the PIN-out. So that I am able to do some basic stuff.
Without any schematic I have just created a dummy empty project to see if the development tools are working. I was used to MPLAB 8.88, so i had to install MPLAB X (still I hate it, because it is so slow for me). Also a new compiler XC32 1.4. Here I encountered no problem. :)
Then creating the empty project was quite funny, since the old plib stuffs are not supported for MZ. Harmony I do not want to have. I am quite home at low levels so using the peripherals is no problem. Finally I have got my system configured and running with 1ms interrupt. Normally I have a big endless loop which is polling if something have to be done (usually 1ms trigger). Starting an empty project gives a big number of loop cycles per sec for this while (1), and later filling the project decrease it. In the first it is decreasing quite fast, then it settles. So now for the empty project I have got around 2,6million runs of the while (1) in 1 sec.
Flashing and Debugging was ok with ICD3.
Now really, I am interested on the schematics because I want to try out an mp3 implementation, and as far as I have seen there are some audio input and output. I really hope that they are on a PWM line so I can do the whole stuff in the PIC32, even the sound generating. And the CAN could be also interesting! I wonder if the SD Card is connected to the SQI module. Because SDIO mode would also be intresting.
I'm too interested in the schematics. And I'm waiting for the LiteBSD to be ready to use for this board. This will enable me to start working on the can4linux driver for the PIC32 and LiteBSD.
I was waiting hoping that at least the schematics will be shared. But nothing, maybe tomorrow? :)
So i started to reverse engineer the pinout from the PCB. I only did the UEXT connector, it was quite easy accessible, and is basically a point to point connection network. I was able to find everything, and wrote also a small test project to drive each pin (selectable) with 1kHz to see if I really catches the right pin. I only had with one pin trouble: UEXT 4 RX. On this pin I did not measured the 1kHz signal, only very short spikes. I think this could be ok since there is a diode and resistor network.
So here is the pinout so far:
PIC32 PIN PIC32 Olimex Board
UEXT 1 3V3
UEXT 2 GND
52 RD4 SQICS0/RPD4/PMWR/RD4 UEXT 3 TX *
46 RD0 AERXD1/ETXD3/RPD0/RTCC/INT0/RD0 UEXT 4 RX Strange glitch is measured only.
6 RG8 AN12/C2IND/RPG8/SCL4/PMA3/RG8 UEXT 5 SCL *
5 RG7 AN13/C1INC/RPG7/SDA4/PMA4/RG7 UEXT 6 SDA *
45 RD11 AERXCLK/AEREFCLK/ECRS/RPD11/PMCS1/PMA14/RD11 UEXT 7 MISO *
53 RD5 SQICS1/RPD5/PMRD/RD5 UEXT 8 MOSI *
44 RD10 ECOL/RPD10/SCL1/SCK4/RD10 UEXT 9 SCK *
43 RD9 AERXD0/ETXD2/RPD9/SDA1/PMCS2/PMA15/RD9 UEXT 10 CS *
I think next day I will continue with the Buttons and LEDs. They are also quite easy to measure and verify. Then the Audio part, I am correct this should be only 5 signals, so also not a big effort.
The ethernet seems to be a problem, since they are boot SMDs and of course placed on two different sides. So I can not place the board so easy on my desk. This will be the last one I think.
Hi
really not necessary to reverse engineering this PCB :)
the web page will be set today, just we had too many things to take care of after the Embedded World and we ran out of man power!
I think this is Murphys law. If you start to reverse engineer the board you can be sure that on the next day it will be put on the web site. :) So I think it was worth the work :)
Thank you Kyrk.5 (for reverse engineering and stimulation) and Olimex for starting up the product. I hope you will also publish the existing demo program and the to be used environment of Microchip.
Kees
Hey guys,
The resources are available at this web-page: https://www.olimex.com/Products/PIC/Development/PIC32-EMZ64/ (https://www.olimex.com/Products/PIC/Development/PIC32-EMZ64/)
Each of the demo examples has a README.txt file inside.
Excuse us for the delay and best regards,
Lub/OLIMEX
Cool :)
I already started to build an mp3 player based on the Helix MP3 decoder. I hope I can utilize the PWM output for sound generating.
The Helix MP3 decoder works :)
I managed to get the MP3 playback working on this uC. But! There is always a but. I did not use any SD Card, instead I put the MP3 file in a C byte array and placed it in the flash. This way I did not had to add a FAT stack and SD Card driver. Sound generating is working with the PWM output. Here I use a 20uS timer interrupt to update the PWM output duty cycle. Since the 20uS gives a different sample rate than the decoded mp3, I do here a kind of re-sampling. Maybe not the cleanest way, since I only count the time and check if the original sampling rate would provide a new sample. The PWM Period is somewhere around 48KHz. I got 11 bit of resolution. Not 16 bit but more than 8 bit. Sounds fine.
I think the cut off freq from the Analog filter on the PCB is somewhere around 30kHz. So the PWM with 48kHz should be fine. Could be more but then the resolution will be to small.
ToDo-s:
- Change 20uS timer so that it is already matching the sampling rate of the decoded mp3. This way some calculation can be spared in the interrupt.
- If possible remove the timer and try to use the module with DMA. Hope this is even possible.
- Add SD Card. And hope very strong that there is enough CPU power, because with the current interrupt based sound generation had lot of lags before I did some optimization.
I hope really that the 200MHz PIC is able to decode the mp3 and create sound with the PWM output while doing some other stuffs also (+tcp +webradio). Lets see :)
Great, now we have already Christmas lights and playing "Jingle Bells" :-)
For me it would be interesting to copy a lot of the CAN utilities I made for the Duinomite to this hardware. I'm still using the old MPLAB X and as far as I have seen the existing software for this module has been made using Harmony. I have not used that and I'm wondering how compatible the environments are.
Anyway I think it is better to close this "Christmas lights" discussion, because it is clear: the module has become a real universal product.
If "Harmony" is the answer.... what was the question?
John
(I think it was: how can we make something truly horrible?)
hi..i also worked on this type of project. Creating the empty project was quite funny, since the old plib stuffs are not supported for MZ. Harmony I do not want to have. I am quite home at low levels so using the peripherals is no problem. Finally I have got my system configured and running with 1ms interrupt. Normally I have a big endless loop which is polling if something have to be done (usually 1ms trigger). Starting an empty project gives a big number of loop cycles per sec for this while (1), and later filling the project decrease it. In the first it is decreasing quite fast, then it settles. So now for the empty project I have got around 2,6million runs of the while (1) in 1 sec.
Flashing and Debugging was ok with ICD3.
board+assembly (http://www.7pcb.com/PCB-Assembly-Service.php)
In case you are willing, I expect people would be grateful for your code and how to build it, and so on.
Anything without Harmony may help others also to avoid it!
John
Nice that the "Christmas lights" have light up again :-)
As I understand at least a few guys succeeded in programming the MZ without Harmony. I also tried to copy some code from the MX to the MZ, but I ran into a problem.
As the CAN driver from Microchip is really buggy (also for the MX controllers), I programmed my CAN software, using direct memory access to the CAN registers in the controller (e.g. *(unsigned long *) (0xBF88B000) to read or write the CAN CONTROL register).
Using the new MPLAB-X and C32 compiler for the MZ, this seems not to be possible anymore. I was thinking this has to do with the MMU in the MZ controller. Am I correct in here and is there a possiblity to access the registers anyway?
Kees
It should be OK - but you may need some setup (and maybe the addresses changed) e.g. to map things into the accessible address space or, er, well, setup LOL.
I have a different MZ board but it's in its bag unless a (at least partial) plib arrives. (I looked at Harmony but will not accept its licence plus I just hate it. I've met that sort of rubbish before and it's dead already.)
I suppose a LED blink using no Harmony would be a good start if anyone has one...
(I've got the toolchain and PICkit3 etc.)
John
Hi John,
OK, I succeeded now to read the CAN CONFIG register. The address is different from the one in the MX controller, but I knew that. The problem was not the reading of the register, but getting it out to the debug output on USB. I forgot to convert the value to a string, like in the sprintf, stupid, stupid. Thanks for encouraging me, that it should work.
I'm going to configure the right I/O pins to the CAN controller and after that see if I can send some messages on the network.
As this is an "evening project" it will take some time, but I will keep the others informed about the progress.
Progress - excellent!
Don't beat yourself up about a slip like that as we all make them.
(The local expression here is if you never did owt wrong you never did owt. Er, "owt" is local word for "anything")
John
hello !
i buy pic32emz64 and i dont now what i do with this module , so i need some basic tutorial for start.
thanks
Welcome to the club Samuel,
My first reaction is if you buy something and you don't know what to do with it: Do you have too much money?
My second reaction: you can download the demo's on Github for the module and the Microchip MPLAB-X and Harmony environments and see how it is built up. At least you can see the hundreds of lines of C-code to get the "Hello World" :( . Please don't try to debug it, because you will get frustrated like all the others.
My third reaction is my personal expirience with the CAN interface on the module. I still did not succeed in getting it up and running on this module. Communication with the CAN registers is no problem, but I did not succeed in getting the CANbus to the operating mode. This means probably that I do something wrong in configuring the I/O for the CAN Rx and Tx pins, but neither Microchip Harmony nor Olimex demo software is helping me further in this. I hope I will find some time again in the near future to get the module free from dust again and start from scratch.
I would like to know what are the plans of Olimex concerning the PIC32MZ controller in the future. I'm very happy with the PIC32MX hardware, but upgrading to MZ seems to be very complex.
Kees
My PIC32MZ is also gathering dust. If Microchip offer something sane instead of Harmony I'll blow the dust off, meanwhile I've moved on to ARM and other non-MZ chips.
It's crazy - the MZ look good but ruined by Harmony (was anything else so badly named?). There again, Intel just would not drop the Itanium. Until they did.
John
Christmas is coming, shall we make a Christmas tree lights based on this HW? :)
Microchip want you to learn Harmony.
Instead, I'm using Raspberry Pi and AW boards.
John
Interactive Christmas lights, because the switches are functioning.
I guess we should further actualise the status concerning the CAN interfacing in the other discussion, because in there we also have the doubt concerning the hardware.
And John in my opinion we should leave Harmony out of this discussion. We all know now that this Harmony will never be on Broadway. Let us concentrate on the basic instruments (the PIC32MZ) which should have the possibility to produce a good tune with the right musicians.
A thought but maybe a way to get CAN is use an SPI module like MCP2515 ones on ebay etc.
(Much easier with Arduino and costs almost nothing, though.)
John
I just wanted to start analyze the CAN problem, but then I found my old MP3 player project and just changed the interrupt PWM sound generation to DMA based...
I wonder where can I download Jingle Bells :)
But now I will start to check the problem. Only problem is that I do not have any other CAN node. So I guess error frames will soon or later block me. Lets see, maybe the problem does not requires a fully operational CAN bus. Ideally I would use a CAN bus where some frames are sent and received by other nodes or by CANoe. I would try to attach the uC to this bus. When the things are not so ideally, I would try to get two samples of the HW and start to connect them. But this is hard, because there are 2 HW items and 1 SW. It must be flashed always twice to check if it is working. And as long as you are not sure that you can receive a frame, you can not check also the sending of it. Unless some other device can be used to check the bus like some kind of CAN analyzer tool (Vector CANoe or cheaper one) or an oscilloscope.
But let try it and I will see it :)
Make each other node an Arduino or RPi. They work, so you can start with a good CAN system.
Arduino + MCP2515 is very cheap, so are two of them!
John
I have to think about this:
- Generally a shield with MCP2515 would be ok. I think I would need 2 items. Arduino I have never used, so no way, then I would choose a PIC32 with arduino interface where I can connect the MCP shiled. Raspy I have, but one of them is used as a server, the other one is free. But I would like to have 2 so that I have a CAN bus where 2 nodes are communicating. Here I could attach the PIC32 first as listen only, then as node. Every choice seems to require some new hardware that I have to order, that means shipping time... I had to wait some days or weeks until something arrives from Bulgaria or China.
- Some slightly modified variant would be one PIC32 arduino interface with two MCP shields on it, communicating to itself :) Would be easy to develop because I do not need to program 2 uC.
- Same as previous but I could simply connect the MPC2515 shiled to the PIC32-EMZ :)
- Other solution would be a Vector stuff with CANoe. Maybee I can ask someone to borrow me a CANcaseXL. Time factor is not so critical here, but I am not sure if I can get the HW and SW.
- I could order a second PIC32-EMZ64. I believe that there is no problem with the CAN, maybe the PIC32 is little bit buggy or something like this.
I think the best solution would be if i would just order 2 MCP shields from China and connect them to the PIC32-EMZ (or other PIC32 does not matter)
Quote from: JohnS on December 12, 2016, 01:32:11 PM
A thought but maybe a way to get CAN is use an SPI module like MCP2515 ones on ebay etc.
(Much easier with Arduino and costs almost nothing, though.)
John
Having a internal CAN connected to the processor bus has advantages compared with connecting CAN via SPI.
That makes the PIC32 interesting for me.
I don't like CAN controller connected to the SPI bus.
And important as well, the board comes with CAN controller + transceiver + CAN connector,
you only have to connect three wires.
Quote from: kyrk.5 on December 12, 2016, 10:25:18 PM
...
Only problem is that I do not have any other CAN node. So I guess error frames will soon or later block me. Lets see, maybe the problem does not requires a fully operational CAN bus.
We would be happy if can reach one simple goal. Initialize the CAN controller and try to send out a frame. With no other node connected you will see the CAN frame on CAN_H and CAN_L repeated for ever.
You only need an oscilloscope to look at it
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
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.
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.
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.
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.
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
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 :(
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.
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
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.
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