Closed MrAlvin closed 4 years ago
GMagician
commented
4 years ago Ramps is not compatible, directly, with AGCM4. Analog to digital pin remapping is different. It should be possible to convert io remapping keeping arduino digital and redirect them to real samd51 ports...this may be an idea
GMagician
commented
4 years ago Please note. AGCM pin are not 5V tolerant, it should be powered with 9V (not 12V) and pin output current 2mA or 8mA depending on DRVSTR that now defaults to 2mA
GMagician
commented
4 years ago @thinkyhead on Due analog pins are redirected this way: A0-A15 -> D54-69 while in AGCM4 are redirected: A0-A7 -> D67-74, A8-A15 -> D54-61
On fast IO I kept AGCM4 mapping so if someone want to use A0 as digital if has to select pin D67 not D54. Now I may remap pin 54 to 67 when wrote on pin.h but this way I may have problem when you want to use other AGCM4 pins because there is no Due counterpart (neopixel and also SPI pins on AGGM4 are D50-52 but also hardwired and mapped to different D). What the best approach? My idea has been to keep AGCM4 pinout and create/duplicate boards. This is what I did with Ruramps4d (that I have to remove because it seems not possible to have outside Russia and so I can't terminate testing...). N.B. I'm going to create a 'RuRamps board like' that can be used with Due and AGCM4 but I don't know if I'll be able to do that (it's not my job) but I need some shield and I don't like ramps because of bad design, components and "connectors"
MrAlvin
commented
4 years ago Please note. AGCM pin are not 5V tolerant, it should be powered with 9V (not 12V) and pin output current 2mA or 8mA depending on DRVSTR that now defaults to 2mA
@GMagician Thank you for the heads up.
I use a new RAMPS shield of my own design, that deals with the 3V <-> 5V issues. And it makes sure that no more than about 1mA is drawn from or sent to any MCU pins, as this much lower mA capability per MCU pin is common among 32-bit MCUs.
I already have my design running on DUE, so now I am looking to also find out what it takes to make it work on the AGCM4 controller board
My new shield is however pin compatible to the RAMPS 1.4 shield.
I was not aware that the AGCM4 does not like a 12V DC voltage power input voltage! So, Thank you, and I will make sure that my new RAMPS shield will deal with this issue.
Ramps is not compatible, directly, with AGCM4. Analog to digital pin remapping is different.
Ah, I see. The Analog to digital pin remapping is different. I have been trying to find a pinout description for the AGCM4 board, but have not had any luck, so I simply assumed that it followed the same Analog to Digital pinout as the Mega and the DUE does.
Do you know of a pinout list that shows what digital numbers the AGCM4 correlates to each Analog pin? Or could I simply use what is listed in the variant.h file. Like: ` / Analog pins Digital pin number /
`
It should be possible to convert io remapping keeping arduino digital and redirect them to real samd51 ports...this may be an idea
Yes, I will most likely simply need to make a new 'pin_RAMPS.h' file that uses the correct AGCM4 digital numbers, that corresponds the io remapping that the AGCM4 uses.
By the way, I call my new shield design RAMPS 1.4.4 (because it is the same size as the RAMPS 1.4 shield) and when I know the design works, it will be released as open source hardware. For now there is some preliminary information about the shield here https://reprap.org/wiki/RAMPS_1.4.4 I am about to receive a new prototype batch of the design, and I hope this will be the last iteration before it is ready to be released. If you would like, I would be happy to send you one of the PCBs.
MrAlvin
commented
4 years ago N.B. I'm going to create a 'RuRamps board like' that can be used with Due and AGCM4 but I don't know if I'll be able to do that (it's not my job) but I need some shield and I don't like ramps because of bad design, components and "connectors"
@GMagician Perhaps I could help with some ideas and test results? As I have been working on designs, and testing out PCBs for some time now. PCB creation is not my job either, but it has been a hobby of mine for several years now, to make small PCBs for interesting, odd functions.
And as I have mentioned, I will be happy to send a PCB, and more pre-release details. And I think I have managed to address most of the issues that have been 'haunting' the RAMPS 1.4 shield . See for instance this forum post about temperatures: https://reprap.org/forum/read.php?219,824661,858950#msg-858950
So I think I have a finally managed to cram some good solutions, into the same PCB space, to the known issues that the RAMPS 1.4 shield has shown to have on occasion.
But I encourage you doing your own new design, as I find that the process alone, has its own rewards, and learning moments.
GMagician
commented
4 years ago I was not aware that the AGCM4 does not like a 12V DC voltage power input voltage
AGCM4 doesn't burn if you apply 12V but 9V is what is suggested on Adafruit web (some pages says 12V others 9V I asked in forum and they said 9V is better to avoid hot converter chip).
Or could I simply use what is listed in the variant.h file. Like:
At present, yes. I don't know why Adafruit mapped analog differently, also D50-52 are hardwired to programming pin (6 pin connector on Due as well) but here are the same physical pins so D50-52 works here but Adafruit also remapped them in other D pins (even this time not compatible with due). Before remap in AGDM4 pins like Due I have to check that it will be possible to use all native pins without issues.
my new shield design RAMPS 1.4.4
I like your idea the only negative thing, in my opinion, are the "ramps" like connectors. I had issues because of them (no lock system on connector I prefer KF2510 that are used on ramps). But your board is tempting me...it will save me time...I'm now facing low ESR capacitor use (needed on pololu Vmot gnd), resistor Wattage (size), led current, mosfet research and so on...not really a party :-D. I'll read on your forum link to get more detail about what your board will really be.. Thanks
GMagician
commented
4 years ago @MrAlvin please note:
HW SPI connector following the Arduino standard (in the middle of the board). So it is no longer necessary to stick to SW SPI for newer Arduino controllers, like DUE and Grand Central.
from your forum. On AGCM4 if you use these pins as SPI you lose D50-52 as digital pin because they are hardwired. In Due and Mega they are indipendent pins. On Ruramps this lead to SD detect pin to be unusable (don't know what happens on your board).
MrAlvin
commented
4 years ago AGCM4 doesn't burn if you apply 12V but 9V is what is suggested on Adafruit web (some pages says 12V others 9V I asked in forum and they said 9V is better to avoid hot converter chip).
Ah, okay, so they probably use a linear DC-DC voltage converter, just as the Mega does. And yes, for those DC-DC converters, it is much better to send them a lower voltage, as they burn off the un-needed energy as heat.
For this situation I have three options in my design.
One is on-board (using three diodes), that simply moves the heat burning, away from the controller board and onto the shield. This increases the air-to-surface contact and thus lowers the temperature on the AGCM4 voltage regulator. This option is still not optimal, but it is included because it is a very space, component and cost effective option. Both boards are however still likely to get warm, but they will both keep working just fine.
The other option is to use one more MP1584 DC-DC switch mode regulator board, and connect this to the Vin pin. This extra MP1584 module is however not (currently) integrated into in the design, so it would be a separate small board.
These first two options are for a 24V power supply.
The third option is for use with a 12V power supply. And this includes using the design-integrated DC-DC switch mode module, to go from 12V to 9-8.5V, and this is then connected to Vin, by a jumper.
But because of the lack of space, within the form-factor confines of the original RAMPS, it has not been possible to integrate the optimal solution. But just a solution that will work okay. And still have an easy option for implementing the better solution.
Before working within the confines for the RAMPS form factor, I actually had a different design in progress: RAMPS 1.7 and this shield has room for several more optimal options to be fully integrated. The forum thread that I linked to, is actually mostly about this 1.7 shield. The first 4 forum pages anyway. But I have come to appreciate the smaller form factor, so I have decided to get this up and running first.
But I suggest that we soon take detailed shield discussions to another forum, and not necessarily in this firmware thread. Okay?
At present, yes. I don't know why Adafruit mapped analog differently, also D50-52 are hardwired to programming pin (6 pin connector on Due as well) but here are the same physical pins so D50-52 works here but Adafruit also remapped them in other D pins (even this time not compatible with due). Before remap in AGDM4 pins like Due I have to check that it will be possible to use all native pins without issues.
For now, I will fully accept the world as it is: That the AGCM4 analog to digital pins relation is its own beast. And will require its own 'pins_RAMPS_AGCM4.h' file. It will be easy to implement now, and easy to adjust if something changes in the future So for now, I will accept that there is probably some kind of reasonably good reasoning behind the choice to make the analog to digital relation on the ACGM4 different than what it is on the Mega and DUE.
my new shield design RAMPS 1.4.4
I like your idea the only negative thing, in my opinion, are the "ramps" like connectors. I had issues because of them (no lock system on connector I prefer KF2510 that are used on RuRamps).
I like the KF2510 style much better too. So to continue with the simple pin headers is a mainly a choice based on the design challenge, of staying within the form factor.
I have a historic Mendel printer that needs new electronics, and it is fitted with KF2510 connectors. And because of the historic nature of this Mendel, I do not want to change away from the KF2510 connectrors, and I still want to use my 144 RAMPS shield. So to make the two worlds meet, I have simply designed, adapter boards. The adapter boards are in the mail, so I will only be able to show how they work, at a later date.
But your board is tempting me...it will save me time...
Well, does it have to be either or? Can it not be both?!
Like, I send you a fully populated and tested, but pre-release board (as this is what I have available right now), and you can use or not use as you please. It will get you something to test firmware on, here and now, and you can still work on your own PCB design as well.
I find that it is often a good thing to be able to connect design ideas with physical objects, as one gives an other level of evaluation, by being able to handle the physical object. This is one of the reasons that I have now been through 3 major design iterations (3.xx, 1.7 and now 1.4.4), and each design has had at least three iterations of produced boards. I find that it simply takes time (and errors) to get things to be the very best way that they can.
I'm now facing low ESR capacitor use (needed on pololu Vmot gnd),
hmm... low ESR capacitors are available from suppliers like digikey, with the same size and formfactor as is currently used on the RAMPS shields. These low ESR capacitors are just a bit more expensive. I do not know if physically bigger capacitors have less ESR. I did buy an ESR meter, but it has not yet been a top priority to address this issue. Other issues have so far taken higher priority. But I intend to do some ESR testing - eventually. And especially if I were ever to do a fabrication order for these boards. For now, I think this shield will need to remain accessible mainly to the solder adventurers. Then, a bit later it might become possible to get access to a pick-n-place machine for the SMD components, or do a bigger order with someone who offer pick-n-place on small series of PCBs.
resistor Wattage (size),
For ease of hand soldering prototypes, I use the 0805 size components. But on a few components I have now had to move to 0603 sizes, to make space. 0603 are still acceptably easy to hand solder.
About current. I have not experienced any current issues, in relation to SMD size components (except perhaps, for diode choices), on 3D printer solutions. The current issues (and pcb path/wire/connector resistance) lies primarily elsewhere. Namely with the high current components, like mosfets and stepper drivers.
And this is why I did some amp and heat tests, with results as listed in these documents: https://github.com/MrAlvin/RAMPS-1.4.4/blob/master/Resistance%20and%20temperature%20measuring/Org-RAMPS-1.4%20shield.pdf https://github.com/MrAlvin/RAMPS-1.4.4/blob/master/Resistance%20and%20temperature%20measuring/RAMPS-1.4.4C%20shield.pdf
led current,
I only use LEDs for mosfets and power supply indication, so the few mA for LEDs are easy to deal with for this use. For the Debug_LED (D13) (also duplicated on the top of RAMPS shields I design), I have opted to dedicate a SOT-23 size mosfet, so I can be sure that the D13 MCU pin simply is never ever overloaded because of a LED
mosfet research
Generally speaking; see what has been used on other boards. And then look for the ones with the lowest Rds-On resistance.
and so on...not really a party :-D.
I can tell that you and I might party differently :-) A night at my local hackerspace, doing PCBs and SMD placement and soldering - to me - does actually sound like a great time to spend a night, and would, to me, feel very much like a party :-)
On a general note about component choices. After looking at options, and zooming in on a few useful options, I tend to go with what is easily (and cheaply) available on ebay or aliexpress, as there is often some rather good and practical reasons why these chips are used in such abundance, that it makes sense for anyone to spend time on offering it up on these discount market places.
And for testing purposes, I think these components will do just fine.
Then for some select and more high quality boards, one can always move to more professional suppliers.
I'll read on your forum link to get more detail about what your board will really be.. Thanks
Your are welcome. And Thank you for taking the time to read ;-)
@MrAlvin please note:
HW SPI connector following the Arduino standard (in the middle of the board). So it is no longer necessary to stick to SW SPI for newer Arduino controllers, like DUE and Grand Central.
from your forum. On AGCM4 if you use these pins as SPI you lose D50-52 as digital pin because they are hardwired. In Due and Mega they are indipendent pins. On Ruramps this lead to SD detect pin to be unusable (don't know what happens on your board).
So, I have basically chosen to allow pins D50-D52 to be dedicated as SPI pins.
And for use with DUE, have made options available to be able to use D50 and D51 as regular digital pins. D52 (or selectable in software: D10 or ? I think D4) is still dictated its state, when ever running hardware SPI on the DUE. So I have opted to always ignore D52 as anything but a SPI dedicated pin.
On the Mega and AGCM4 boards, D50-D52 function as actual SPI pins. With a double for those pins on the center SPI connector. So for use with these boards, D50-D52 are already spoken for.
And for use with Re-ARM, it is very necessary to have them connected as SPI pins. And thus I have made provisions so it is easy to get them connected as the dedicated SPI pins, that they need to be.
By the way, Re-ARM has other issues with pins, as some 12-18 pins associated with the connectors on the Arduino mega-layout-style connectors simply have no connection to the Re-ARM processor. To deal with this, and still be able to use five TCM2130 drivers, the Re-ARM ethernet port, as well as use of either of the RRD text or graphics LCD displays, I have a solution implemented, on an adapter board, connected to the Aux-3 and Aux-4 ports. And I will soon introduce this adapter board on the https://reprap.org/wiki/RAMPS_1.4.4 wiki page.
These are all details that I have discovered, and found solutions for, during the (now many) test boards that I have designed, made, and tested over these past many months.
So the AGCM4 board is, sort of, yet another, board that I would like to make sure would also work with my new RAMPS shield design.
And the 1.4.4 is a small, non-perfect, but form-factor true, version of a RAMPS shield. Designed to fulfill some very specific design requirements.
Thus I feel that there is still room for a design where the KF2510 connectors are fully integrated. And this is why I offer to share details about what I have learned and discovered so far.
And with regards to my original question: Why do I get a DIO62_PIN error when compiling, I feel like I have gotten a very good and in-depth answer. And I now know what to do to create a solution. to my challenge. Thank You.
But lets continue to talk more PCB solutions, but perhaps via the reprap forum. It has a good private message system as well. Okay?
GMagician
commented
4 years ago I checked how to solve remapping but it will need more changes. Now I can simply redirect D54-D69 to proper analog pins and viceversa in fastio.
Problem is when/if marlin addresses these digital pins via framework function digitalWrite in such case original mapping is required (or a custom framework has to be written).
I think it's not a viable path.
MrAlvin
commented
4 years ago I checked how to solve remapping but it will need more changes. Now I can simply redirect D54-D69 to proper analog pins and viceversa in fastio. Problem is when/if marlin addresses these digital pins via framework function
digitalWritein such case original mapping is required (or a custom framework has to be written). I think it's not a viable path.
I agree. It must remain compatible with what is done when also using 'digitalWrite'.
github-actions[bot]
commented
4 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Description
DIO62_PIN error when compiling for AGCM4 on RAMPS14, with either of bugfix-2.0.x and dev-2.1.x - (AGCM4 = Adafruit Grand Central M4 board)
Tested compilation on platform.io (using VScode) as well as Arduino IDE 1.8.9
DIO62 ought to be the same as Arduino digital pin D62, and Arduino analog pin A8. And ought to translate to SAMD51 pin 54.
Steps to Reproduce
Test that '#define MOTHERBOARD BOARD_AGCM4_RURAMPS4D_13' compiles okay
Make a hack in 'pins_RAMPS.h' file so it can be used to compile for AGCM4 - see attached zip file for example of how to use '#define IS_OKAY' in 'pins_RAMPS.h'
Set '#define MOTHERBOARD BOARD_RAMPS_14_EFB' in configuration.h
In Arduino IDE, install and select board 'Adafruit Grand Central M4 (SAMD51)' Or
on platform.io set 'default_envs = SAMD51_grandcentral_m4'
Compile
Expected behavior: Compiles without error for the RAMPS_14 shield, just like it does for the BOARD_AGCM4_RURAMPS4D_13 shield.
Actual behavior: Results in quite a long error message - with the core issue being that Enable_Z leads to an error about DIO62_PIN not being found in HAL_SAMD51/SAMD51.h - though I think that the core issue of macro translation happens in the HAL_SAMD51/fastio.h file.
See attached zip file for a copy of complete error message - as well as copies of all other files mentioned in this issue report. AGCM4 issue reports.zip
Additional Information
I have been trying to decipher the gcc macro language being used in the Marlin HAL files (specifically the HAL_SAMD51/fastio.h file), as well as trying to find answers by looking in the variant.h file Arduino IDE package for AGCM4.
And I have a hunch, that some kind of number typo has been made, when creating the conversion list for the Marlin gcc macro's.
I can not quite decipher if DIO62 refers to the standard Arduino pin D62, and should thus be translated to SAMD51 pin 54 (as listed in the variant.h file for the ACGM4 Arduino package).
Neither of the Arduino pins D62-D64 translates correctly in the Marlin macro's in HAL_SAMD51/fastio.h file And AGCM4_RURAMPS4D_13 does not use D62, so the typos in HAL_SAMD51/fastio.h might otherwise have been caught when ever testing was done for AGCM4_RURAMPS4D_13 shield
I have also made a small .ino test file, to see if it is possible to do digital references to the AGCM4 analog A8-A12 pins. And this compiles just fine
So I hope someone who reads Marlin gcc Macro language better than me, will have a look at this issue.