stryd_one Posted June 22, 2003 Report Share Posted June 22, 2003 While I'm on the subject of speed...What's the deal with latency time on reads and writes from the bankstick? I guess it would just be the latency of the chip (5ms - does that seem a bit slow for ram?) plus the amount of time to call and run the MIOS Function?I'm trying to do something with the MB, but I need a lot of fast RAM... I thought the bankstick might be it, but thats a max of 256k and I might need more... And now it seems a bankstick may be too slow... :( Are there other possibilities?Thanks again Quote Link to comment Share on other sites More sharing options...
d2k Posted June 22, 2003 Report Share Posted June 22, 2003 Heyhey...Just spotted this on the bankstick page:Note that the 24LC256 can also be replaced by a 24LC512. Although no application supports this 64k EEPROM yet, MIOS is able to access the full 16-bit address space. By stacking 8 * 24LC512, up to 512k are available.HTH...Dan Quote Link to comment Share on other sites More sharing options...
TK. Posted June 23, 2003 Report Share Posted June 23, 2003 Yes, a BankStick is very slow, a read needs ca. 100 uS (microseconds), a write ca. 10 ms (but you can write 64 bytes at once in order to improve the performance).However, these delays are not caused by the PIC, but by the IIC protocol. It's clocked with 400 kHz, and 40 bus cycles are necessary for a random read. Writes are taking much longer due to the general EEPROM limitations.For a lot of fast RAM the PIC is the wrong processor, but do you really need so much RAM direct accessible? Wouldn't it help to transfer the informations into a RAM buffer before they are required?Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
stryd_one Posted June 24, 2003 Author Report Share Posted June 24, 2003 I'm obviously far too accustomed to programming for a PC ... You're quite right Thorsten, I won't need all of the RAM available all the time, in fact the majority of the high-performance needs will be very predictable (IE reading the next step of notes to play, then the next step and so on)Writes will not need to be very high priority at all, as they will only need to be done as fast as a human can push buttons to set note data, but the reads will be fairly frequent... I think I should go into a little more detail so that I am not being confusing...I would like to work the seq so that it holds a "database" table of all the note/controller info, and then rolls through playing those notes...I guess this isn't so hard with 4 rows of 16 steps - that's 64 steps all up... But as it stands, my design carries a lot more... something more in the range of 2496 (ouch!)... If I rightly remember, most MIDI messages are 3 bytes in length (? or maybe there's only 3 bytes that will change anyway), that means 7488 bytes of data..Hey, 7.5K, actually that's not much, doesnt the PIC have 64K to play with? Maybe the banksticks won't be such a necessity? Maybe I'm drunk and posting at midnight....hehehheThe tricky part is, that I want to be able to read the table every time a MIDI clock message is received (24 times per quarter note)...at 180BPM (pretty fast) thats still only every 3.5ms or so... not too often really? You said a read only takes 100us ... :)keeping in mind that there are likely to be 2 or three core modules (or more if I need it), each possibly holding the full amount of banksticks, is this likely to be possible? Â Or am I dreaming a bit too much? ;)/edit Perhaps I should point out that these are the maximum requirements... the seq would only use this much data if it was totally full... Quote Link to comment Share on other sites More sharing options...
TK. Posted June 25, 2003 Report Share Posted June 25, 2003 I think the timings are more relaxed when you take the required transfer time of a MIDI message into account. A three byte MIDI event requires 960 uS - nearly one milisecond. This means that the BankStick is 10 times faster than the transfer itself. Note also the MIOS provides a 48 byte transmit buffer which relaxes the timings even more, since in this way the bytes are sent in background and your application can continue to read from BankStick or to calculate the next events (I read that you plan some interpolation features for CC events...).I also don't think that your code has to read so much data from the BankStick during every MIDI clock when everything which is time critical is stored in RAM. The planned MB64seq port for example will be implemented in a different way compared to the PIC16F solution, but will work with a better performance. Of course, the possibilities will not be so powerfull like your plans, but I guess that the principle method, the skeleton will maybe open your eyes. I've planned to realise it in following way (this is only a short abstract from my ideas, if I would have to write all ideas, it would be faster for me just to program the assembler code in order to "document" what I mean --- and every time I have to write more details, the day of release will be more delayed ;-)): either the USER_Timer or the incoming MIDI clock triggers the sequencer with 24 ppqn (note: higher resolutions should also be possible). The timer itself doesn't process the sequencer data at the same time, but only notifies to the main program that the pulse should be processed "as soon as possible".The main program checks if the sequencer has been triggered as often as possible. This handler will be called from USER_Tick - this hook is triggered ca. every 5-50 uS (microseconds) if nothing else is to do (no button event, no encoder event, no pot event, no MIDI event, no display event). If - for example - a button function has to execute a long running part of code, e.g. if it has to write something into the BankStick, the sequencer handler can also be called during every single write operation.In this way extreme low latencies are guaranteed without any OS overhead.What will the sequencer function do: anything you want ;-) Mainly it will handle with a lot of delay counters, once a counter reaches zero, any action will be performed - sending MIDI events from BankStick or derived from RAM variables, or whatever...Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
stryd_one Posted June 26, 2003 Author Report Share Posted June 26, 2003 Something I meant to say before and for some reason, didn't....For a lot of fast RAM the PIC is the wrong processor <snip>Best Regards, Thorsten.TK mate... I admit, I have no idea if the PIC is the best, worst, or somewhere in the middle, CPU for the kind of seq I want to build... As you know, I've got a very good idea of what I want in the seq... That's because I've dreamed about such a box for years... The only thing even remotely close was the Doepfer Shaltwerk (oh man thats nice)... I realised after all these years that nobody else is going to make it for me to buy...Honestly though, without the groundwork laid out by you, without your kind efforts and selfless sharing of code and wisdom, without your vision and insight into what is required... Without MIOS, I would not be able to build this box, and I would not be able to bring my plans to fruition.... My programming skills and hardware skills especially, are simply not good enough.But all these cool things you do for us all, make it possible for guys like me to do what they thought was not possible at all.So I will keep using a PIC running MIOS, until I either give up trying (hah!) learn everything you know (aaahahahah!!!!) or DIE! ;D ;D ;DBut jokes aside, TK you have given me a chance to do something I've wanted to do for years, and I really appreciate it. Thanks man 8)TK for President!! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.