LeafLabs Garden

A place to share, learn, and grow...

1. 

   gbulmer
   Moderator

   Aeth - That board looks lovely. Making that on 0.6" pitch is very impressive. Squeezing SD on too is even better.

   My board is on 0.9" pitch, and it has no SD.
   SD is one reason I may rework. SD for data logging would be extremely useful.

   I broke out every pin except USB D+/D-. I want this to be usable with beginners, and the thought of someone connecting batteries to a USB pin made me nervous.

   One driving force is Micromouse. A Micromouse maze is 168mm wide. It is generally asserted that to drive a 45degree diagonal, the mouse must be 80mm or narrower - the narrower the better. This restricts the size, and mainly the length of the controller board because I want to avoid putting the board above the (noisy) motors.

   I want beginners to have a board which would allow them to be competitive with Micromouse experts. By that I mean program algorithms well (so lots of memory), and drive the maze efficiently. Beginners' mice won't have the acceleration and top speed of experts' mice, where often two motors cost well over $200, but the ability to do 45 degree turns keeps the speed up.

   I also need it to be breadboard friendly, so single row pins is better. I do like siy's design which brings the extra pins out on 'on top'.

   Posted 3 years ago #
2. 

   bubulindo
   Member

   So, is there any board to be developed using the F4 family for us to make some libraries too?

   Posted 3 years ago #
3. 

   siy
   Member

   bubulindo, couple posts ago I've posted link to the repo with the design files for the board which supports F1/F2/F4 MCUs in 64-pin package. 100-pin package version is WIP.

   Posted 3 years ago #
4. 

   Rod
   Member

   gbulmer: I've submitted a Maple Mini clone (called MM4) for 64 pin processors such as the larger memory F1's the L1 and the F4 as a pull request to the github openstm32hw repository you set up. Its in 2 layers with ground planes as large as practical and has a width of 0.8".

   sly: very nice board. I'm impressed with your turn around times and how well you got it laid out on one layer.

   My turnaround on the board I just submitted should be 2 days at a cost of about $12 CDN each for 4, so I'll go commercial rather than DIY.

   aeth: nicely done. Very clever solution to the 0.6" standard socket width problem. You should submit your board to the repository as well.

   The current state of MM4_r0 is "submitted for a production turn, but un-tested". In software terms that is "it compiled, so I shipped it". Observations or test results are encouraged and appreciated.

   Posted 3 years ago #
5. 

   siy
   Member

   Rod, as I've mentioned above, it probably worth to discuss and set up some kind of test suite for the boards. This will be useful for everyone who will design or assemble compatible hardware. Unfortunately I have virtually no experience preparing such a test suites for combined software/hardware systems. If you have such an experience or just know how it usually done, I'd greatly appreciate any ideas and suggestions.

   Posted 3 years ago #
6. 

   Rod
   Member

   I guess you are right, that's a problem. I hadn't really thought it through consciously, but to test my board, one would drop a tested Maple Mini into a dual socket, and get your main board circuit operational. Then drop in an MM4 to test the desired incremental functionality.

   After you have a few known good MM4's you could forgo the dual socket.

   That is my plan, but I'm thinking about my end system, not the MM4 board alone.

   Hopefully the MM4 circuitry is sufficiently simple that if it doesn't come up stand alone you look for clocks and power, then if you can load the bootstrap, then if it runs as a DFU under the Maple development system.

   To test a totally new board like yours, I would think a useful additional step would be a 'counter toggle' that puts an 8 bit number out on half a GPIO point and then increments the counter and repeats. You could then ensure that all the GPIO pins were correctly connected with a scope. Maybe have that run in idle. First step of course would be flash the led.

   I wouldn't think one would need too many diagnostic functions selectable from a serialUSB command prompt. If any one function runs on a port, then presumably all functions would run.

   Posted 3 years ago #
7. 

   siy
   Member

   Sorry, I probably was not clear enough. I didn't mean manual testing or making board work in general. That's another issue. I'm thinking about semi-automated or (better) completely automated procedure which will test board and software (F4 version of libmaple) compatibility.

   Posted 3 years ago #
8. 

   Rod
   Member

   Seems a bit premature...

   I'm busy ramping up testing on production runs of a few thousand boards at the moment. What seems to work well is to refine the test suite with each new major purchase. Also, something that works really well, particularly with boards like these, is to base tests and test software on these boards. That way you are developing the board and testing/refining it at the same time.

   Its certainly the case that with each new major order, we upgrade our test fixtures as part of placing the order.

   So, trigger a test by toggling a line, watch the outputs on other lines, write data to an SPI memory, read it from the board under test and toggle other lines in response, etc. Build one small useful test at a time and just keep using them over again as you got forward.

   Posted 3 years ago #
9. 

   bubulindo
   Member

   @siy
   I'm clearly not as experienced as you guys, but if I got it right, do you mean making software that would check which chip it was running on and which modules were available?

   Do you mind, for my own education, expanding on what you meant?

   Thanks.

   Posted 3 years ago #
10. 

    siy
    Member

    As Rod mentioned, the testing issue is twofold: first part is testing of just assembled board (either, already proven or new design) that it actually (somehow) works; second part is testing of compatibility of the software with the given board (and vice versa), i.e. check that library properly works with given chip model installed on board and supports expected set of on-board features, for example, RTC crystal or microSD/TF card reader. At present second part can only actually check that board-specific part of library (board definition in wirish subdir) is correct, because there is no special way to tell library which other peripherals are actually installed on the board. Probably this might change in the future and beside existing definitions of pins and some on-chip features there will be definitions of additional on-board features. But this part is definitely point for further considerations and discussions.

    Posted 3 years ago #
11. 

    gbulmer
    Moderator

    I was thinking of testing the board itself, and I'd assumed software compatibility testing might grow out of that.

    Using SWD, there is no need for a bootloader, so the first test might be nothing more than 'blink' loaded over SWD. => Power, MCU, SWD and a LED are working.
    The second test might be upload a bootloader. => SWD or USART/USB/... working
    The third, upload blink over a bootloader, and so on. => USB and bootloader working

    Many of the STM Discovery boards have lots of pins, so they could be used to control/test boards with smaller numbers of pins, and they are crazy-cheap at the moment.

    I'd be happy with a simple pin test. For example upload and run a program on the target to set all (sensible) pins as output, one at a time, and wiggle each pin for a while, one at a time, while a 'control' board listens for disconnected pins (no wiggle) or multiple pin wiggles (short).

    It's practical to make test fixtures from veroboard or breadboard for boards with pinouts on a 0.1" pitch, if speed isn't too fast.

    Edit: We could 'standardise' on using SPI or USART for test-controller to target-slave coordination, then anyone designing new boards could use the same test framework.

    Testing some of the peripherals like USART, SPI, I2C, PWM might be smarter versions of the same approach.

    Posted 3 years ago #
12. 

    siy
    Member

    gbulmer, I like the idea. Discovery has on-board ST-LINK/V2 which can be controlled via texane/stlink utilities and used to flash necessary software directly to the tested board. So ST-LINK/V2 and dedicated application for the Discovery may perform necessary checks and report results directly to the host PC. Perhaps some user involvement will be necessary in order to press RESET/BOOT0 buttons sometimes (for boards which have these pins exposed this also can be controlled by application at Discovery).

    Posted 3 years ago #
13. 

    gbulmer
    Moderator

    siy - Yes. While the Discovery are cheap (I don't expect this to last for ever), they seem like a handy framework. As you say, the Discovery has STLINK/V2 SWD on board, so potentially a very low-cost way for folks to bootstrap boards, and have a hardware debugger.

    I am still amazed that a STM32F4 discovery board is cheaper than some of the USB/Serial cables;-)

    I noticed that Future Electronics are selling "real" ST-LINK/V2 for only $25. So if they keep selling at that price, it won't be too expensive when the Discovery boards run out.

    Posted 3 years ago #
14. 

    ala42
    Member

    You do not need a ST-Link, just use the internal serial bootloader. You also do not need an external board to control the I/Os, you can interconnect pins on the test board that are out of reach of each other on your PCB so that the external interconnection can not cover shortcuts.
    Even without external interconnections you can detect floating pins, on board pullups and pulldowns, check that they can be pulled or pushed by the CPU and you can detect pin interconnections. If you add a simple pin change detection test and manually touch your external I/O connector pins with a pullup or pulldown resistor to detect the pin change, even your end user can perform a quick board function test of a simple board like the maple mini without any special test equipment.
    If you like you could design a passive test adapter PCB to get the external interconnections. There are lots of options...

    Posted 3 years ago #
15. 

    siy
    Member

    ala42, yes, this is another possible option. The only thing I'd like to avoid as much as possible is the manual intervention into the process.

    Posted 3 years ago #

RSS feed for this topic

Reply »

You must log in to post.