minimum requirements for maple-compatible boards?

LeafLabs Garden » Support » Maple Hardware Support

minimum requirements for maple-compatible boards?

(17 posts) (7 voices)

Started 5 years ago by soundcyst
Latest reply from gbulmer

12 Next »

soundcyst
Member

i'm designing a board using an stm32f103ret6 (LQFP-64), and wondering what i need to include in the design to make sure it's maple-compatible, meaning, it will support maple's IDE and libmaple.

i realize a few things will need to be added to libmaple.h to accommodate the new chip, which is fine, as long as leaflabs is ok rolling that into the repository.

from libmaple.h, it looks like i'll also need a USB_DISC pin, though the schematic makes me wonder if it's also mandatory to have the USB_P pin and the gpio connected to BOOT0.

if those are required, is there any possibility of those being assignable in the .h file in future releases? PC9, 11 and 12 are unfortunately shared with the SDIO interface in high density devices.

is there anything else required that i'm missing? the USART debug stuff isn't entirely clear.. does that need to be broken out, or only if i want to use the assertion debug feature? (which i probably should support)

thanks!

Posted 5 years ago #
x893
Member

in principal you not need any except stm32.
firstly i think that maple it's easy life - but now i say one - not a promlem use that you want. USP_DISC and other not need - if you connect 1.5K resistor to +3.3V. more only relize your own ideas. of course if you can compatibility with a lammer's platforms (such as arduino, netduino, maple, etc.) it's a plus for more popularity of your product. if you make a custom product - forgot about lammers and make as you need.
If you see on maple code - it's not a ideal and many hardcodes and other not a classic soft reqs. But this mans works and make a popular 32 bit platform - thanks. if you see arduino - popular - but 99% it's only blinks lamps and electronics trap for rats. no nothingh really. but main ideal sold devices (it's a ideal for maple but currently arduino realize). make as you need and soft make as you want.

Posted 5 years ago #
soundcyst
Member

i had trouble understanding most of that..

i suppose i should clarify what i'm trying to design.

an analogy should help.
sanguino is to arduino, as the board i am designing is to maple.

it's slightly different hardware, but runs the same software libraries and uses the same bootloader and IDE.

sanguino is used in the reprap and makerbot 3d printers. ardupilot is another example for UAVs.

Posted 5 years ago #
gbulmer
Moderator

I have a similar-sounding design.
IIRC the only option was to move the pins to get at the peripheral.

You can initially boot those high-density chips and load using the USART, not USB. Are you using JTAG to blow a bootloader?

Posted 5 years ago #
soundcyst
Member

yeah, jtag or swd.. and not necessarily even a bootloader. i have iar and a jlink for work, so for the first rev, i'll probably just use that, but i'd like to make this and other designs maple compatible in the future, so i thought i'd ask the question..

Posted 5 years ago #
soundcyst
Member

any "official" words on this?

Posted 5 years ago #
mbolivar
LeafLabs

the bootloader wants USB_DISC, an LED, and a button. USB_DISC is necessary, but you can fake the last two/move them around (in fact, we did just that in the mini-boot bootloader branch).

the LED is just a status indicator; the button is just a way to signal perpetual bootloader mode. ("ok, i'm blinking fast to see if you want me to enter perpetual bootloader mode"; "ok, you pressed the button, so i'll just wait for new code forever..."). if you can live without those, we could refactor things so those steps would be omitted.

USB_P is not used.

the diff between the maple-bootloader master and mini-boot branches is likely a solid predictor of the work necessary to get the current bootloader up on your device. once that plays nice, you're likely golden as far as libmaple is concerned.

the IDE relies on serial-over-usb to request the chip to reset itself. this (of course) remains true in the upcoming serial bootloader. if you want IDE compatibility, you should preserve that. the short story is that we do a little DTR/RTS toggling to transfer control to the bootloader, then conduct the remainder of the transaction over the data lines.

the connections made at PC 9, 11, and 12 can be #defined to go somewhere else. in general, if you don't feel like breaking something out, then don't, and make your own BOARD_xxx entry (PIN_MAP, etc.) to reflect that; see boards.h:
https://github.com/leaflabs/libmaple/blob/master/wirish/boards.h

so far, that's all we've had to do to make libmaple play nice with our maple mini prototypes. i'm just finishing that up right now; a git push will occur sometime tonight.

we expect libmaple to grow more device-agnostic over time as we add more boards to the line. right now the bootloader situation is a bit of a mess, though. since many things are behind schedule as it is, that mess is likely to remain for a while.

in any case, we probably won't mind merging your changes in; in fact, patches are usually welcome, and it seems like you've got a cool project brewing.

Posted 5 years ago #
soundcyst
Member

oh, one or two ;)

https://github.com/soundcyst/maple/blob/master/maplish-bbuino/bumble-b.png

Posted 5 years ago #
soundcyst
Member

USB_P is not used.

does this mean R15 and R16 can be remvoved?

Posted 5 years ago #
josheeg
Member

if you wanted to use kicad a free and open source soluiton over eagle cad you can look at my dr-brog-arm board heavly fallowing maple r3-5

Posted 5 years ago #
mbolivar
LeafLabs

soundcyst: while i don't feel confident enough to answer your question myself, i've forwarded the question on to our hardware people.

Posted 5 years ago #
okie
Administrator

soundcyst:

yes, R15 and R16 can be removed without affecting compatibility with the bootloader, libmaple, and the IDE.

Posted 5 years ago #
Adam
Member

soundcyst:

I am very interested in the Bumble-B. If there's any way I can help, let me know.

In the meanwhile, I am working to port LWIP to the Maple+ZG2100. I would really like to have a Maple-compatible board that has wifi and a high-density STM32 chip in it, as the extra RAM would really help - running LWIP and an application is tight on the medium density devices. I am interested in streaming sensor data over wifi and uIP isn't fast enough.

Posted 5 years ago #
soundcyst
Member

@okie, thanks.

@adam, awesome!

i wrote a little blog post about the prototype, but basically, i'm using the same WiFi chip that the folks over at async labs use in their WiShield, YellowJacket, and BlackWidow boards. It's a (MicroChip) ZeroG2100, which has hardware AES and TKIP accelerators, but doesn't implement the network stack.

i picked up a YellowJacket for software prototyping so that I can try to get a very proto-faked version of my software running before i put it on the right board. i haven't gotten too far with it, though, as the YellowJacket is particularly unfriendly to networks running any form of security. i tried posting to async's forum, but an administrator needed to approve me to post, and it's been a few days.. they acknowledge that it's a part time gig for them, but still, it would be nice to be able to use their forum..

the good news is that the issue is likely in the networking software, rather than in the chip, so if lwIP fixes that, i'd be very inclined to use it. another issue with the yellowjackets is that they're finicky about which base stations they'll talk to, which also seems to be software-related. ideally, the bumble-b wouldn't have this issue, and would connect to any wifi network at all, regardless of the base station.

regarding speed, the ZeroG2100 only does 802.11b, so depending on your required bandwidth, that may be more of a limiting factor than any software.

but, if you're not gathering a constant data stream, the uSD card is wired to take advantage of the 4 data bits in SDIO, so logging there should be faster on a bumble-b than on any SPI-based uSD boards. perhaps logging to the uSD, then doing some quick encryption could lighten the packet load..

Posted 5 years ago #
Adam
Member

soundcyst,

I need streaming data via wifi, not to an SD card. 802.11b should be fast enough for now. I have done some performance tests on uIP and it is much slower than the link rate, and looking at the code, you can see it is meant for systems with much slower processor and much less RAM. So I think LWIP will speed things up enough.

And also, hopefully microchip or someone will offer a faster wifi module.

Posted 5 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.