-
Notifications
You must be signed in to change notification settings - Fork 22
Pin map does not reflect LPC4330 #32
Comments
I wrote that list by hand, so I wouldn't be surprised if there were mistakes in it. I'm not sure I understand the problem fully though. |
Several of the pins are not there, for example: SPI1_SCK PF_4 So I added them to the list. In doing so, I can now use those pins, but I don’y seem to be generating a proper SCK signal for SPI1_SCK on PF4. I have single stepped through the code right down to the ports and it seems to be setting up the SPI1 correctly, but I only get some glitches instead of a proper clock and MOSI and MISO seem a bit odd. I wonder if I need a pull-up resistor, or similar on the SPI1_SCK pin? Cheers
|
Looks like I could only use one of the SPI interfaces (SPI0) as the others all have pin clashes on the Bambino 210E. I note that I am not getting any traffic on MISO so may have MISO and MISO transposed but getting there with the TMC2130 SilentStepStick. I will update the pin table as I continue my Smoothie2. Work. |
This is great, thanks ! On Mon, Oct 3, 2016 at 12:06 PM, Douglas Pearless [email protected]
Courage et bonne humeur. |
As the map is hard to read, I am going to turn the definition into a grid so it is easy to see what is there and what is not. :-) |
To make it easier to read, I have turned it into a grid, I now need to review it to make sure it is correct, already found a few mistakes :-) Also, should this be controlled by the board type selected in the makefile as different variants may have different pins available, e.g. the Bambino210[E] etc?
|
Pins should be the same no matter the board, it's the chip that matters. On Tue, Oct 4, 2016 at 1:25 AM, Douglas Pearless [email protected]
Courage et bonne humeur. |
OK,I have added the missing pins (as I find them), all seems to work now. |
I will close this issue after my next pull request (fixing the G28 homing issue) |
I have updated my repo with an updated pin.cpp file, so I will close this once I push the it to the Smoothieware/Smoothie2 repo |
I have been trying to work out why my code would not support SPP0 and in particular SPP0_SCK pin which is on P3_0.
After a lot of code research I think that link 65 in libs\Pin.cpp is the issue:
map<int, PinName> pins = {{(0x00<<8)+0,P0_0},{(0x00<<8)+1,P0_1},{(0x01<<8)+0,P1_0},{(0x01<<8)+1,P1_1},{(0x01<<8)+2,P1_2},{(0x01<<8)+3,P1_3},{(0x01<<8)+4,P1_4},{(0x01<<8)+5,P1_5},{(0x01<<8)+6,P1_6},{(0x01<<8)+7,P1_7},{(0x01<<8)+8,P1_8},{(0x01<<8)+9,P1_9},{(0x01<<8)+10,P1_10},{(0x01<<8)+11,P1_11},{(0x01<<8)+12,P1_12},{(0x01<<8)+13,P1_13},{(0x01<<8)+14,P1_14},{(0x01<<8)+15,P1_15},{(0x01<<8)+16,P1_16},{(0x01<<8)+17,P1_17},{(0x01<<8)+18,P1_18},{(0x01<<8)+20,P1_20},{(0x02<<8)+0,P2_0},{(0x02<<8)+1,P2_1},{(0x02<<8)+2,P2_2},{(0x02<<8)+3,P2_3},{(0x02<<8)+4,P2_4},{(0x02<<8)+5,P2_5},{(0x02<<8)+6,P2_6},{(0x02<<8)+7,P2_7},{(0x02<<8)+8,P2_8},{(0x02<<8)+9,P2_9},{(0x02<<8)+10,P2_10},{(0x02<<8)+11,P2_11},{(0x02<<8)+12,P2_12},{(0x02<<8)+13,P2_13},{(0x03<<8)+1,P3_1},{(0x03<<8)+2,P3_2},{(0x03<<8)+4,P3_4},{(0x03<<8)+5,P3_5},{(0x03<<8)+6,P3_6},{(0x03<<8)+7,P3_7},{(0x03<<8)+8,P3_8},{(0x04<<8)+0,P4_0},{(0x04<<8)+1,P4_1},{(0x04<<8)+2,P4_2},{(0x04<<8)+3,P4_3},{(0x04<<8)+4,P4_4},{(0x04<<8)+5,P4_5},{(0x04<<8)+6,P4_6},{(0x04<<8)+8,P4_8},{(0x04<<8)+9,P4_9},{(0x04<<8)+10,P4_10},{(0x05<<8)+0,P5_0},{(0x05<<8)+1,P5_1},{(0x05<<8)+2,P5_2},{(0x05<<8)+3,P5_3},{(0x05<<8)+4,P5_4},{(0x05<<8)+5,P5_5},{(0x05<<8)+6,P5_6},{(0x05<<8)+7,P5_7},{(0x06<<8)+1,P6_1},{(0x06<<8)+2,P6_2},{(0x06<<8)+3,P6_3},{(0x06<<8)+4,P6_4},{(0x06<<8)+5,P6_5},{(0x06<<8)+6,P6_6},{(0x06<<8)+7,P6_7},{(0x06<<8)+8,P6_8},{(0x06<<8)+9,P6_9},{(0x06<<8)+10,P6_10},{(0x06<<8)+11,P6_11},{(0x06<<8)+12,P6_12},{(0x07<<8)+0,P7_0},{(0x07<<8)+1,P7_1},{(0x07<<8)+2,P7_2},{(0x07<<8)+3,P7_3},{(0x07<<8)+4,P7_4},{(0x07<<8)+5,P7_5},{(0x07<<8)+6,P7_6},{(0x07<<8)+7,P7_7},{(0x08<<8)+8,P8_0},{(0x09<<8)+0,P8_1},{(0x09<<8)+1,P8_2},{(0x09<<8)+2,P8_3},{(0x08<<8)+4,P8_4},{(0x08<<8)+5,P8_5},{(0x08<<8)+6,P8_6},{(0x08<<8)+7,P8_7},{(0x09<<8)+0,P9_0},{(0x09<<8)+1,P9_1},{(0x09<<8)+2,P9_2},{(0x09<<8)+3,P9_3},{(0x09<<8)+4,P9_4},{(0x09<<8)+5,P9_5},{(0x09<<8)+6,P9_6},{(0x0A<<8)+1,PA_1},{(0x0A<<8)+2,PA_2},{(0x0A<<8)+3,PA_3},{(0x0A<<8)+4,PA_4},{(0x0B<<8)+0,PB_0},{(0x0B<<8)+1,PB_1},{(0x0B<<8)+2,PB_2},{(0x0B<<8)+3,PB_3},{(0x0B<<8)+4,PB_4},{(0x0B<<8)+5,PB_5},{(0x0B<<8)+6,PB_6},{(0x0C<<8)+1,PC_1},{(0x0C<<8)+2,PC_2},{(0x0C<<8)+3,PC_3},{(0x0C<<8)+4,PC_4},{(0x0C<<8)+5,PC_5},{(0x0C<<8)+6,PC_6},{(0x0C<<8)+7,PC_7},{(0x0C<<8)+8,PC_8},{(0x0C<<8)+9,PC_9},{(0x0C<<8)+10,PC_10},{(0x0C<<8)+11,PC_11},{(0x0C<<8)+12,PC_12},{(0x0C<<8)+13,PC_13},{(0x0C<<8)+14,PC_14},{(0x0D<<8)+0,PD_0},{(0x0D<<8)+1,PD_1},{(0x0D<<8)+2,PD_2},{(0x0D<<8)+3,PD_3},{(0x0D<<8)+4,PD_4},{(0x0D<<8)+5,PD_5},{(0x0D<<8)+6,PD_6},{(0x0D<<8)+7,PD_7},{(0x0D<<8)+8,PD_8},{(0x0D<<8)+9,PD_9},{(0x0D<<8)+10,PD_10},{(0x0D<<8)+11,PD_11},{(0x0D<<8)+12,PD_12},{(0x0D<<8)+13,PD_13},{(0x0D<<8)+14,PD_14},{(0x0D<<8)+15,PD_15},{(0x0D<<8)+16,PD_16},{(0x0E<<8)+0,PE_0},{(0x0E<<8)+1,PE_1},{(0x0E<<8)+2,PE_2},{(0x0E<<8)+3,PE_3},{(0x0E<<8)+4,PE_4},{(0x0E<<8)+5,PE_5},{(0x0E<<8)+6,PE_6},{(0x0E<<8)+7,PE_7},{(0x0E<<8)+8,PE_8},{(0x0E<<8)+9,PE_9},{(0x0E<<8)+10,PE_10},{(0x0E<<8)+11,PE_11},{(0x0E<<8)+12,PE_12},{(0x0E<<8)+13,PE_13},{(0x0E<<8)+14,PE_14},{(0x0E<<8)+15,PE_15},{(0x0F<<8)+1,PF_1},{(0x0F<<8)+2,PF_2},{(0x0F<<8)+3,PF_3},{(0x0F<<8)+5,PF_5},{(0x0F<<8)+6,PF_6},{(0x0F<<8)+7,PF_7},{(0x0F<<8)+8,PF_8},{(0x0F<<8)+9,PF_9},{(0x0F<<8)+10,PF_10},{(0x0F<<8)+11,PF_11}};
I have not systematically compared this with the LPC4330 chip itself, before I embark on this exercise, am I correct in this assumption?
Note: I realise that I should change to a 'channel' approach as used in max31855.cpp, which for the LPC4330 is:
And I think I need a method of changing from 16bit mode to 8 bit mode to support different devices and I probably need to introduce mutexes to ensure they are thread safe for a proper RTOS implementation too.
I am wondering if I should create a wrapper for an SPI object that deals with all these issues so future processor ports will be simpler, not to mention different usage for the same peripheral?
Cheers
Douglas
The text was updated successfully, but these errors were encountered: