Jump to content

SEQV4 with integrated 16x8 BLM


dustdrive
 Share

Recommended Posts

Thank you for your answer Thorsten, I didnt see it until now. Strange, normally I also get an email... :: )

 

The BLM is working and all the other components are working too but if I load the SEQV4 software with the BLM enabled, the interaction is edgy. The GP encoders are reacting somehow irregular and without touching the machine, notes are beeing triggered, note values are beeing changed randomly, and so on. If I disable the BLM everything is working nice and precisely (If I load the apps/examples/blm/ app the blm is running stable too). 

 

Has any of you experienced such an effect with a 4x16 BLM connected? 

 

Is the STM32 perhaps not strong enough?

 

Or is it more likely an electrical issue and I have to shield the cables (it is really packed in my case and the wires are very close to each other)? 

Which material could I use to shield the wires?

 

I'm grateful about any idea.

 

Thank you for time.

Link to comment
Share on other sites

  • Replies 62
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Yes, the STM32 has only weak "open drain" drivers for the SRIO chain.

This has been solved on the LPC17 core by using 74HCT541 based buffers.

However, it could be that such a special cable already helps:

(shielding not required - the inserted resistors are doing the magic! :))

More infos about the cable at the beginning of the MBNG thread.

Best Regards, Thorsten.

Link to comment
Share on other sites

Yes, the STM32 has only weak "open drain" drivers for the SRIO chain.

This has been solved on the LPC17 core by using 74HCT541 based buffers.

Good that I already ordered one.

 

However, it could be that such a special cable already helps:

(shielding not required - the inserted resistors are doing the magic! :smile:)

More infos about the cable at the beginning of the MBNG thread.

Great, I will have a look at it.

Thorsten, you are incredible!!!!!! Thank you.  :rolleyes:

Link to comment
Share on other sites

  • 1 month later...

I would like to understand the file mios32/trunk/modules/blm/blm.c . 

 

I have a clear impression until line 230, in BLM_GetRow :    

 

sr = (((blm_selected_column-1)&0x3) << 1) + side;

 

This changes everything. I just don't get the numbering of the button rows. It seems as row 1 (counting from 0) and row 3 are flipped. But where are they beeing reflipped?

 

The BLM_PrepareCol method, sets one of four cathodelines on low voltage via blm_selected_column. So if blm_selected_column is 0 (which it always will be after beeing 3) the row, closest to a person sitting in front of the machine ("row 6 and 7") is at low voltage and ready to register any button changes. At the next turn, when blm_selected_column is 1, the second closest row to a person sitting in front of the machine would be ready to register any button changes. But when blm_selected_column is 1,  sr is set to 0, so any changes for row 0 would be registered. But when running the program this row is corresponds to row 4 for the left side and row 5 for the right side. Where is my mistake? Here is an overview over blm_selected_column and the resulting sr value: 

 

blm_selected_column - 0, sr - 6 (in the end row 6)

blm_selected_column - 1, sr - 0 (in the end row 4)

blm_selected_column - 2, sr - 2 (in the end row 2)

blm_selected_column - 3, sr - 4 (in the end row 0)

 

(The row_offset for the LED's is pretty simple and clear - line 182)

 

Thank you for your time!

Link to comment
Share on other sites

The mistake is probably only, that you are trying to fix this at the wrong place.

 

I guess that the rows are flipped due to a hardware wiring issue.

Accordingly, I would change the routine which selects the rows of the hardware (BLM_PrepareCol) instead of the routine which processes the scanned data.

 

What you need is some kind of mapping:

First row selection: 0b1110 (as before)

Second row selection: 0b0111 (instead of 0b1101)

Third row selection: 0b1011 (as before)

Fourth row selection: 0b1101 (instead of 0b0111)

 

The selection pattern will be determined in line 167:

  // select next DOUT/DIN column (selected cathode line = 0, all others 1)
  dout_value = (1 << blm_selected_column) ^ 0x0f;

 

The most simple change to flip bit 1 and 3 would be:

  // select next DOUT/DIN column (selected cathode line = 0, all others 1)
  dout_value = (1 << (blm_selected_column ^ 2)) ^ 0x0f;

 

Best Regards, Thorsten.

Link to comment
Share on other sites

Thank you for your help!

 

It's really educational how you are approaching this problem Thorsten, thank you for sharing this!!!

 

I think I didn't formulate myself precisely enough. Sorry for that. Actually the 4x16 BLM is running fine with my SEQV4, but I just don't understand the code (mostly because of line 230: "sr = (((blm_selected_column-1)&0x3) << 1) + side;"). 

 

I will try to rethink it with Thorsten's approach. But Gridracer and T.K. - Thank your for your time and support!!!!!

 

Best Regards, manu. 

 

P.s. Now I finally reenabled the automatic mail notification, so I will respond faster next time, sorry...

Link to comment
Share on other sites

sr = (((blm_selected_column-1)&0x3) << 1) + side;

 

BLM_PrepareCol will increment the blm_selected_column and shift the new selection into the DOUT

*while* this is done, the DINs will be shifted out, thereafter BLM_GetRow will be called.

The DINs will contain the state of the previous (!) selection.

Therefore "blm_selected_column-1"

 

The & 0x3 applies a mask, so that the resulting value is 0, 1, 2 or 3 (so, it also takes care for the wraparound)

 

Best Regards, Thorsten.

Link to comment
Share on other sites

  • 4 months later...

Thanks to Thorstens explanation I was able to understand and to modify the blm.c to my needs. Now I have another problem, which I don't know how to approach. 

 

I bought the new LPC17 and everything is working fine, except for the lcd displays (40x2). Both displays are working fine with the STM32 board. When I connect the LPC17 board (tutorial 001 loaded) via USB to the computer the displays are showing no reaction.  

 

I have already tried the following: 

 

  1. Measured at J15A/B the current between VS and VD - it is the same current as for the STM32. 
  2. "Resoldered" every relevant connection, according to the schematics. 

Is there something else I can measure to trace the problem?

 

Thank you for your time! 

Edited by dustdrive
Link to comment
Share on other sites

It was! What a beginner's mistake  :pinch:, I guess. But now I know a little bit more about that part....

 

The "testlcdpin" worked great. Testing the supported pin's with this command and measuring B+ and B- together with the schematics, made me able to trace the problem.

 

 

Thank you very much, Thorsten! 

 
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...