work in progress stm32f4 MPU module LQFP 176

Hardware inside and outside of the ECU
Suprazz
Posts: 12
Joined: Mon Mar 07, 2016 6:12 pm

Re: stm32f4 MPU module LQFP 176

Post by Suprazz »

really!? in this case it's a good idea
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: stm32f4 MPU module LQFP 176

Post by AndreyB »

Image
it would actually cost more to solder these 54 pins than to get the chip itself. About $5 total.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stm32f4 MPU module LQFP 176

Post by kb1gtt »

How much RAM would we really want? I see the 8 bits wide data bus has many of the IO available on the existing layout, there are some conflicts. With the PE7,8,9,10, but those can be moved on the 176 board if required. We have easy access to addresses PF0 --> PF5. Is that enough addresses? We also have reasonably easy access to address's PF12 --> 15, and PG0 --> PG1. I guess we could make an add on board that sits on top of the MCU, but perhaps we should consider a respin of this 176 board. These data buses typically have high frequency content on the traces which causes a bunch of problems we aren't currently very concerned with. Looks like that's 133MHz to 200MHz-ish, then you typically have significant energy for several harmonics, so we are looking at signals that need to consider more than a 1GHz of frequency content. We might want to consider moving (or removing) the battery holder on the bottom of the board and add this SDRAM chip where the battery is currently located. That would help with minimizing noise from this data bus.

Should we spin a daughter board that connects to the P13 header or should we re-spin this 176 board? I guess we should spin a daughter board, then once validated, we should respin the 176 including the RAM chip.

Just to make it easier for me to find this stuff later on down the road, here's a link to that SDRAM chip. https://octopart.com/search?q=is42s16400j
Welcome to the friendlier side of internet crazy :)
Horsty
Posts: 31
Joined: Fri Oct 07, 2016 10:38 am
Location: Cologne / Germany

Re: stm32f4 MPU module LQFP 176

Post by Horsty »

just to get things right:

is this a replacement board for the STM32F4DISCOVERY with a bunch of more IO-pins?

or are you thinking of adding the chip directly to things like frankenso V0.5?
Track: Audi Coupé Quattro R5 Bj. '89 | 2.3 Liter | 7A | 170 bhp | Perlwhite L0A9
Daily 2014- : Volkswagen Lupo Bj. '99 | 1,0 Liter | ALL | 50 bhp | Flashred LP3G --> conversion to AEX 1.4 8v 60 bhp --> conversion to AEE 1.6 8v 75 bhp
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: stm32f4 MPU module LQFP 176

Post by AndreyB »

As of today this is yes, just a replacement board with more i-o.

The whole chip directly on Frankenso is not really popular so I doubt we will integrate the 176 on the Frankenso.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stm32f4 MPU module LQFP 176

Post by kb1gtt »

If we spun a new board, I'd encourage the use of the 176, but at this point, it would be a large amount of work to get this onto the existing Frankenso board, and wouldn't really offer any new features. The Frankenso does what it was designed to do with the IO it has. The additional IO is handy if you have more features to add.
Welcome to the friendlier side of internet crazy :)
Post Reply