-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting more models #13
Comments
I'd like to add new models, so I checked to see how the values for ports and pins are derived. The variables For example, in the model "UNO", the first pin is located in the register with address If this explanation is correct, I wonder if it wouldn't be better to represent pins and ports as simple lists (or vectors or alists) of pairs rather than two separate vectors, e.g.
It would also be quite convenient if we could refer to pins by name, e.g. Would you be willing to discuss a patch along these lines? |
Hi. We've used 2 vectors of numbers, rather than any other structure, simply because it uses the least memory, with no difference to the user. For example, the existing representation uses 220 bytes for the 'mega' mappings. A vector of pairs would use 326... I think supporting raw chips, and pin access by port letter is an excellent idea. The primitive
Now we can access, for example, |
The process for adding new models was previously quite complicated, and involved editing obscure pieces of code.
I have relocated the model-specific data to a well-structured store in 'models.c'. The pin-mapping vectors remain in 'stdlib.ms'. There is now a single primitive
(@if-model "modelname" ...)
for model-specific microscheme code, rather than a primitive(@if-model-modelname ...)
for each model.As a result, the process for supporting a new model is much simpler. One must add a new entry to the models[] array in 'models.c', and an
(@if-model "modelname")
block in 'stdlib.ms', containing pin mapping vectors.I will soon write a guide on exactly how these data should be derived, but the existing models provide a fairly good indication...
The text was updated successfully, but these errors were encountered: